[seek-kr-sms] OBOE discussion: current version

Matt Jones jones at nceas.ucsb.edu
Wed Jun 21 12:47:36 PDT 2006


Hi,

Ferdinando Villa wrote:
> > > 1.      Observable is either Entity or Characteristic (at the 
> > > moment).  Characteristic has only one subclass Dimension, which defines 
> > > the set of base quantities such as length, weight, etc. , Dimension 
> > > includes only things measured in quantities. Thus at the moment we are 
> > > missing specification for observations of such characteristics as color, 
> > > smell, taste or anything which is measured in qualitative scale.
> >
> >   This is a question that has come up a lot recently and really needs
> >   to be confronted with some good examples.  The idea was that nominal
> >   measurements would just be given unit "name" and a characteristic,
> >   such as "red".  This would mean having these characteristics in an
> >   extension ontology such as a "classifiation ontology" (which would
> >   plug into OBOE's charactersitic).  
> 
>     I don't think this is right. Simply, the values of that observation
>     come from a finite set of color classes (or instances). Not a
>     measurement, if we define measurement as comparison with a reference
>     unit (meter of tree) using an abstract unit for the dimension (meter
>     for length). It is a measurement if we define measurement to
>     encompass assigning a class to an observable in a context as the
>     result of measuring it. I'd rather call it a "Classification",
>     subclass of Observation and siblings of Measurement. And we could
>     have "Ranking" as subclass of Classification, where classes must
>     have an ordinal relationship. But stretching the definition to make
>     it fit in the unit-at-all-costs framework and giving the
>     characteristic the role of subsetting the value space doesn't sound
>     right at all. This was the thought behind proposing an explicit
>     value space.

I'm in agreement with Ferdinando.  I find the nominal and ordinal types 
of Measurements to be distinctly different from those quantitative 
measures that have units.  EML distinguishes these via the measurement 
scale and asks for different information for each type.  I'd prefer if 
nominal and ordinal things did not have a unit.  And I would prefer if 
they did have a mechanism for defining their value space, at least in 
the annotation.  For example, for a purely nominal variable, one needs 
to be able to say that the domain of allowable values includes 'Male' 
and 'Female', and provide a definition for each.  For ordinal variables, 
one needs to be able to define the categories, give a definition for 
each, and give their relative rank ordering. Almost every study will 
define these things slightly differently, so it probably belongs in the 
annotation, not in the ontology, although I'm sur ethis is arguable.  If 
its in the ontology, then we must have a first-rate, user-oriented UI 
for adding to the ontology because it will need to be extended for each 
and every dataset.

There is extensive infrastructure in EML for these definitiions, and a 
lot of thought went into the fields and the rationale for every piece of 
information, including the exceptions we allow in EML.  I've noticed in 
general that OBOE drops a lot of the stuff that we deemed important in 
the measurementScale tree in EML 
(http://knb.ecoinformatics.org/software/eml/eml-2.0.1/eml-attribute.html#measurementScale). 
  Could someone in the know explain why each element in EML's 
measurementScale element is not considered important in OBOE, in 
particular distinguishing nominal/ordinal/numeric types, and dealing 
with datetime values,  and the fields missing from OBOE like precision, 
bounds, enumeratedDomain, textDomain, and numberType?  Precision and 
enumeratedDomain are the most obvious problems, but I'm also concerned 
about the bounds element.  Precision was originally a required field in 
EML, but was changed to optional only for the pragmatic reason that many 
people didn't have good precision estimates even though its pretty bad 
science to no have them.

Thanks for the clarifications.

Matt

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matt Jones                                   Ph: 907-789-0496
jones at nceas.ucsb.edu                    SIP #: 1-747-626-7082
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara     http://www.nceas.ucsb.edu/ecoinformatics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


More information about the Seek-kr-sms mailing list