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

Thu Jun 22 06:39:13 PDT 2006

Josh, (and others)

The diagram you sent has some point which makes current version of OBOE
inconsistent, and it seems that  our design requres a fundamental shift
towards the Ferdinando's revised version. Plese see my points below.

Sergey

Is measurement   a kind of observation? The present version of OBOE says no.
The  version revised now by  Josh  say yes. (Diagram A in the pdf file Josh
sent.). This brings us one step close to Ferdinando's proposal which also
suggest that Observation is a common superclass for such things as
Measurement, Count, etc.(Actualli it is AtomicObservation is a common
superclass) I agree with this proposal, (of Ferdinando and of Josh).
Observation should be a common supercalss for Measurement, Count,
Classification. But the time we agreed on that we may need to extensively
reconsider some features of the current version. For example:

1. Let us look carefully at diagram B in the file Josh sent yesterday.

In this diagram there are attributes characteristic [1,n] and value[1,1]
which are comon for Classification, Count and Measurement. Those who are
used to  OOP should shout: they must be moved up to common superclass. The
one we have is  Observation.

2. If Classification, Count and Measurement are subclasses of Observation,
then why would we need the properties measurement(0:n), count(0,n)
classification (0,1)?

The original intuition behind this is that Observation is asumed to be
something complex while the subclasses must be simple/atomic act of
observation.  Unfortunately,  this does not go well with the fact that
Observation is common superclass of these three.Because in this case the
properties measurement(0:n), count(0,n) classification (0,1) can be moved
down to subclasses , that is they will be inherited by  Classification,
Count and Measurement. Can a classification have attributes
measurement(0:n), count(0,n) classification (0,1). Can a Measurement have
attributes measurement(0:n), count(0,n) classification (0,1)? Of cource not.
So we have to remove attributes (roles, properties) measurement(0:n),
count(0,n) classification (0,1) from Observation. Alternatively, we may
refuse the idea of having Observation as superclass of Classification, Count
and Measurement. But since these three classes have common attributes
characteristic [1,n] and value[1,1], it would be illogical to refuse this
one. We need a common superclass, which may hold those common attributes.

3. In the current version the dichotomy between presumably complex
Observation and presumably simple Measurement was the way to pack the rows
of a table together. In the pdf files, where Josh explicatde examples given
by Matt and Mark the attribute C (which, as  Shawn  explained to me means
hasMeasuredCharacteristic)  was used to create n-ary relations. If we refuse
measurement(0:n), count(0,n) classification (0,1), then we have to refuse
hasMeasuredCharacteristic too. If we don't, then Classification and Count
and Measurement will inherit this attribute and we again land in the same
mess. So how do we now create n-ary relation? In Ferdinando's proposal
Observation can be CompoundObservation and AtomicObservation. Later on
Ferdinando took back idea of CompoundObservation, but then what do we have
instead, may be we just need a better name?

4. Personally I like the idea of how Ferdinando's proposal takles dichotomi
between complex (compound) observations and the other things such as Count,
Measurement and Classification. I like his idea of ObservationSpace. What I
do not like is that Observables can be both Entities and Characteristics.  I
think this is an overkill: Entity (thing, object) and Characteristic
(property)  are two fundamental phylosophical categories. Further
generalisation over fundamental phylosophical categories warants a big mess
and missunderstanding.  I will gaet back later with my comments on
Ferdinando's proposal

  _____  

From: seek-kr-sms-bounces at ecoinformatics.org
[mailto:seek-kr-sms-bounces at ecoinformatics.org] On Behalf Of Joshua Madin
Sent: Wednesday, June 21, 2006 3:57 PM
To: seek-kr-sms at ecoinformatics.org
Subject: Re: [seek-kr-sms] OBOE discussion: current version

Based on the comments this morning I have redrawn the core of oboe for
discussion (attached pdf). It seems to me that the unit-at-all-cost
framework will greatly simplify what we are trying to deliver for improving
data integration, but, as Ferdinando said, this framework will be hard to
justify and may cause problems down the line. In the attached ontology, I've
tried to divide the different notions of "measurement". All this does is
restrict the properties that can be used on different types of observation.

I've also included "hasProcedure" as a properties that acts on Observations.
This can also act on Measurements due the the subsumption hierarchy shown in
Figure A. I think that this is what Ferdinando meant, but I'm not sure.

Cheers. BTW: I just received new emails from Ferdinado and Matt -- but I'll
send this anyway.

Josh

>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 ameasurement 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 definitionto 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 relationshipbetween
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'sa realnumeric scale (whose ordinal properties are also not
expressed in OWL, so why bother?).If really necessary, we couldmake
suchclassificationhierarchies subclasses of"Rank" and use anumericproperty
for ordering suchvalues, but all the logic necessary to do anythingwith it
remains outside OBOE.

----------------------------------------------------------

Our definition, if I remember correctly, was :Observation is a statementthat
an Observable has been observed. I think more than this is going to
colorOBOEwith 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-kr-sms/attachments/20060622/227e42d5/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 25242 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-kr-sms/attachments/20060622/227e42d5/attachment-0001.gif