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

[Joshua Madin]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-kr-sms/attachments/20060621/760de63a/attachment-0002.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OBOE_master.pdf
Type: application/pdf
Size: 26852 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-kr-sms/attachments/20060621/760de63a/OBOE_master-0001.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-kr-sms/attachments/20060621/760de63a/attachment-0003.htm