[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