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

[Ferdinando Villa]

 > 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. 

Ordinal measurements may not be as easy to deal with.  It might work in the
same way as above, but use the unit "rank".  However, the ordinal ontology
would need to contain constructs that deal with "direction" or "magnitude".
For example, "high" is distinct from and of greater magnitude than "low".
This ontology would have to be able to deal with arbitrary numbers of
levels, similar to the way we dealt with Observation in OBOE for coping with
experimental design.  The idea was to remove these kind of things (i.e.,
characteristics) from the core ontology because the way that people want to
use them are so variable. 
 
Similar concerns, plus one: I don't think the ordinal relationship between
classes such as {high, medium, low} has much of a chance to be captured in
OWL. Nor I think it should be, as you don't do much with it in workflows
unless it's a real numeric scale (whose ordinal properties are also not
expressed in OWL, so why bother?). If really necessary, we could make such
classification hierarchies subclasses of "Rank" and use a numeric property
for ordering such values, but all the logic necessary to do anythingwith it
remains outside OBOE.
 
 
 2.      Continuing the same subject. If we observe say color of a lion , is
that a measurement or just an observation? If we qualify such recording of
color as measurement, then given the specific association of  measurement
with units, we must have units for all qualitative scales. Having one unit
"qualitative" will be of no use, because this would lump  together unrelated
thing such as colors {read, orange..} , health level {exellent, good,.},
etc. Therefore, I would vote not to call such things as recording of color
measurement, but consider them as special kind of observation
The color of a lion is a measurement with unit "Name" and characteristic,
e.g., "Blue", where blue is selected from an extension ontology.  This is
the way we have it now as far as I understand it.  The overarching point is
that we are trying very hard to separate Observation and Measurement for
many reasons, such as context operating only on Observations.  This gives us
some powerful ways to deal with ecological data, such as interpreting
experimental design.  Therefore, I think that it is better to call things
such as color measurements; e.g., color of stick; length of stick.  I'd be
interested to see examples of how color could be defined/described as a
special kind of observation.


3.      Each specific dimension has a set of related units. Say, length may
be measured in meters, centimeters , microns . I believe that this
association of a specific dimension with a set of respective units is an
important intuition that helps to make sense of calculations. Why do not we
draw an additional property hasUnit with domain Dimension  and range  Unit

Hmm.  This sounds like a good idea.  I'll think about this some more.


4.      O&M scheme for Observation and Measurement has additional notion of
observation/measurement procedure. It looks as if this concept could be
easily added to OBOE by attaching property hasProcedure either to
observation or to Measurement or to both. If we have property has procedure
with domain that include both Observation and Measurement, then we might
need to think how measurement procedure is related to observation procedure.
Does it have sense to have both observation procedure and measurement
procedure?

Yes.  This would certainly make OBOE more complete, and I agree that this
property should operate at both the Observation and Measurement level.  For
example, we used a telescope for observing, but a tape measure for
measuring.  It seems that EML already captures much of the procedural stuff,
so we need to discuss if we want to become more redundant (e.g., EML covers
much of the unit stuff as well), or whether we just want to fill in the gaps
that EML can't cope with.  Personally, I think that OBOE should be a
stand-alone initiative, and therefore include the concept of observation and
measurement procedure.


5.      There is property hasMeasuredCharacteristic with domain Observation
and range Measurement. Is Measurement an event, procedure or characteristics
of something? I think that Measurement as such is not a characteristic but
an event. But measurement is a measurement  *of* a characteristic. Therefore
property hasMeasuredCharacteristi should have domain Measurement and the
range Characteristic. (but in this case it will duplicate property
hasSubject) . In fact the choice of range Characteristic is determined by
the name of the property hasMeasuredCharacteristic. The domain may be either
Measurement or Observation.

I totally agree and there has been some discussion about this.  I really
like your use of the word "event", I think this makes what we are actually
doing much clearer.  For example, we Observe a tree, each Measurement is an
event relating to that Observation, and a Measurement is of some
characteristic.  I second the move changing the property between Observation
and Meaurement to something like "hasMeasurementEvent". 
 
 
Our definition, if I remember correctly, was :Observation is a statement
that an Observable has been observed. I think more than this is going to
color OBOE with restrictions it does not need to have. By the way, we model
the result of the observation, not the process of the observation, and the
result is not an event. To annotate a dataset we don't need to know anything
about the measurement except its results. 

Cheers,
Josh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-kr-sms/attachments/20060621/6793261a/attachment.htm