Matrix entity type

[Peter McCartney]

Well  EML's scope of purpose is determined by the needs of the research
community, so if there is a need to describe matrices as data then by
definition it fits the scope. Our original proposal for BDI specified that
our data processing components would produce an EML that describes this new
data product. In development of our Xylopia project, this thinking has
evolved logically to using an EML package as the container for passing data
between processing steps - thereby creating the journaling process. So the
question becomes: can output such as cross tabulations or corrlations
matrices that are often fed as input into a subsquent processing step be
adequately described using the table entity type. To me, the answer is "not
really". If it is a two dimensional matrix, then I can describe one the
headers for parameter as the attribute list, and the other as the first
column in the rows. If its multi-dimensional, then it's a bit more
difficult.

I sense that part of your email was questioning whether people are really
going to archive such entites as opposed to the raw data that produced them.
Fair question as much of our early thinking probably assumed they would not.
However, ive looked a little more into DDI (data documentation initiative)
which is a metadata standard developed primarily for census-type data which
shares the same structure as what I am talking about (the data are some
aggregation of cases -housholds- that represent a vector of multiple
dimensions (income, education attained, relgion, etc). These people actually
archive data in these kinds of summary structures so it takes on a relevance
beyond simply being able to describe data as its being transformed through a
pipeline.

We always anticipated that new entity types would be proposed.


Peter McCartney (peter.mccartney at asu.edu)
Center for Environmental-Studies
Arizona State University
 


-----Original Message-----
From: Scott Chapal [mailto:scott.chapal at jonesctr.org] 
Sent: Tuesday, March 11, 2003 7:54 AM
To: Peter McCartney
Cc: 'eml-dev at ecoinformatics.org'
Subject: Re: Matrix entity type


Peter McCartney <peter.mccartney at asu.edu> writes:

> Has anyone else felt the need for a new entity type to describe 
> matrices?  Im sitting here writing the spec for a cross-tabulation 
> module i want to add to Xylopia am realizing that while its possible 
> to describe its output using the table entity module, thats really not 
> a good fit. I really dont need to define each column as a distinct 
> attribute - they are all the same data type and meaning and Im forced 
> to use an entirely different model to define the row headers even 
> thought order of rows versus columns is really arbitrary.What i need 
> is one description for each dimension of the matrix, plus one 
> attribute to describe the cell's datatype and calculation. This module 
> would be useful for describing lots of statistical output up to N 
> dimensions.

I was thinking about this driving in today and contemplating the purpose
which it would fill....and again reconsidering the scope of purpose for EML.
Whether this is 'needed' is bound up in the definition of EML's 'Scope of
Purpose', which is probably evolving as people increasingly understand the
possibilities.  The current EML purpose statement:

"To provide the ecological community with an extensible, flexible, metadata
standard for use in data analysis and archiving that will allow automated
machine processing, searching and retrieval."

appears sufficiently broad to support the notion of a matrix to represent
analytic output.  But is it needed?  Or could a reference/pointer to the
analytic method and data source(s) suffice to recreate the 'matrix' output
just-in-time?

Here's how STMML uses the matrix data type:

<matrix id="m1" title="mattrix-1" dictRef="foo:bar"
  rows="3" columns="3" dataType="xsd:decimal"
  delimiter="|" matrixType="squareSymmetric" units="unit:m"
  >|1.1|1.2|1.3|1.2|2.2|2.3|1.3|2.3|3.3!</matrix>

BASE: xsd:string
ENUMERATED VALUES:
* rectangular
* square
* squareSymmetric
* squareAntisymmetric
* diagonal
* upperTriangular
* lowerTriangular
* unitary
* rowEigenvectors
* rotation22
* rotationTranslation32
* homogeneous33
* rotation33
* rotationTranslation43
* homogeneous44
* square
* square

-- 
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20030311/ac002e54/attachment.htm