measurementScale Was: [VOTE] should we release eml-2.0.0 now?

[Peter McCartney]

Scott et al. 

We have put some simple rules in xylographa for making best guesses since,
as we all realize, you must make if you want to be able to put in the
information that you DO know such as domain info. Given that interval and
ordinal scales are much less common than ratio and nominal scales in
ecological data, we have made the assumption that unless the data contain
negative values or the imported metadata indicates a range that includes
negative values, the data are probably ratio. If the data are alpha numeric,
then we assume they are nominal. None of these rules are reliable of course,
and you have to be committed to checking them over after the fact. However,
since we can often glean something about domain in an automated way, you
have to make a choice if you want to be able to put it in the document. In
retrospect, it was bad design (I can say this because I was one of the ones
that suggested doing it this way!). 

Frankly, im more bothered by our failure to fix temporal coverage so that it
will accept something other than a date type. We did this for other places
where dates were used but not here. This has turned out to be the most
aggravating flaw we've had to deal with. Any feedback on how people are
handline that? The fix would be to make its domain a union of xs:string and
xs:date.



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


-----Original Message-----
From: Tim Bergsma [mailto:tbergsma at kbs.msu.edu] 
Sent: Thursday, January 23, 2003 10:24 AM
To: Matt Jones
Cc: Scott Chapal; eml-dev
Subject: Re: measurementScale Was: [VOTE] should we release eml-2.0.0 now?


Scott,

from a philosophical point of view...

No, there is no way to automate choice of measurement scale.  Someone has
pointed out choice of measurement scale on the Stevens typology depends in
part on what you want to do with the data.  So, for instance, measurement
scale can't be predicted from, say, DictionaryUnit.  This is probably a flaw
in the typology, and as Matt points out, will probably persist for 2.X.  Let
me know if I've misunderstood your question.

Tim.


Matt Jones wrote:
> 
> Scott,
> 
> I have no intention of making any changes to EML whatsoever. There
> might be some bug fixes if they arise (e.g., spelling, mismatched 
> element names, etc.), but I would personally oppose any structural 
> change that broke backwards compatibility over the next several years. 
> That includes changes to measurementScale and ID's and references 
> elements.  At this point our focus should be on adoption and use of 
> the agreed EML 2.0.0 specification.  Let's produce some metadata and make
the data available!
>   I know that's what we're focusing on now at NCEAS.
> 
> Matt
> 
> Scott Chapal wrote:
> > Peter McCartney <peter.mccartney at asu.edu> writes:
> >
> >
> >>for example, im not sure we wont just decide upon more feedback that
> >>classifying attributes into stevens measurement scales was a 
> >>mistake. if so, id rather scrap it then struggle to make it work.
> >
> >
> > OK, here's some feedback.
> >
> > Has anyone proposed a way to automate the choice of
> > measurementScale? Ironically, as a result of the 11th hour dateTime 
> > debate, dates and times are the easiest!
> >
> > We are now faced with encoding NOMINAL, ORDINAL, INTERVAL and RATIO
> > into the attribute (variable) definitions of the data 
> > themselves...in order to provide a mechanism for auto-generating EML 
> > via XSL.
> >
> > If, however, the 2.0 version of eml-attribute (measurementScale)
> > will not persist in future versions, I don't want to bother going to 
> > all that work.  Is measurementScale, in its current form here to 
> > stay?
> >
> > Comments?
> >
> >
> >>Im also not sure that we wont decide to return to triples as better
> >>tools for working with them are developed in SEEK.
> >
> >
> >
> 
> --
> *******************************************************************
> Matt Jones                                    jones at nceas.ucsb.edu
> http://www.nceas.ucsb.edu/    Fax: 425-920-2439   Ph: 907-789-0496
> National Center for Ecological Analysis and Synthesis (NCEAS)
> 
> Interested in ecological informatics? http://www.ecoinformatics.org
> *******************************************************************
> 
> _______________________________________________
> eml-dev mailing list
> eml-dev at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/eml-dev

-- 
Tim Bergsma
LTER Information Manager
W.K. Kellogg Biological Station
Michigan State University
Hickory Corners, MI   49060
629/671-2337
tbergsma at kbs.msu.edu
http://lter.kbs.msu.edu _______________________________________________
eml-dev mailing list
eml-dev at ecoinformatics.org
http://www.ecoinformatics.org/mailman/listinfo/eml-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20030127/3289fa86/attachment.htm