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

[Joshua Madin]

First, I appear to have confused people: Shawn is correct, I was just  
trying to replicate what Ferdinando had said in his email.  This is  
NOT what oboe looks like.  I'm working on placing a visual  
representation of the current version of oboe on the SEEK wiki for  
reference.  I apologize for the confusion.

Second, as it stands, I see both Observation and Measurement as  
records.  So yes to your question Ferdinando: we only care about  
record.  Observation simply defines the thing of which different  
characteristics were measured.  More than one characteristic can be  
measured, such as name, height, color, etc.  It provides a neat  
mechanism for describing context, which is ultimately our goal.   
Maybe the problem (like most of our problems) is the term that we've  
used to name this function: "Observation".  Maybe careful definition  
will solve this problem.  Or maybe we should call it something else?

josh



On Jun 22, 2006, at 9:19 AM, Ferdinando Villa wrote:

> The main problem here is again seeing Observation as the event and
> Measurement as its result. The discussion below sees Observation as  
> the
> record of the event and Measurement, Count, Classification as kinds  
> of such
> records. So it should probably be called ObservationRecord - and I  
> guess the
> issue is, do we want to ALSO model the perdurant Observation then.  
> My guess
> is no - we don't really care about the Observation. So the  
> Observation class
> as Shawn sees it is irrelevant to the purposes of OBOE, as the whole
> when/how/where is captured as contextual ObservationRecords. We  
> only care
> about the record. Am I wrong?
>
> f
>
> --
> Ferdinando Villa, Associate Research Professor, Ecoinformatics
> Ecoinformatics Collaboratory, Gund Inst. for Ecol. Economics and  
> Dept. of
> Botany
> University of Vermont           http://ecoinformatics.uvm.edu
>
>> -----Original Message-----
>> From: seek-kr-sms-bounces at ecoinformatics.org
>> [mailto:seek-kr-sms-bounces at ecoinformatics.org] On Behalf Of
>> Shawn Bowers
>> Sent: Thursday, June 22, 2006 12:16 PM
>> To: Serguei Krivov
>> Cc: seek-kr-sms at ecoinformatics.org
>> Subject: Re: [seek-kr-sms] OBOE discussion: current version
>>
>>
>>> 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.
>>
>> I am a bit confused here -- and maybe Josh, you can clarify.
>> My impression is that OBOE isn't currently changing in this
>> way.  Josh constructed the diagram to try to mimic /
>> understand / capture Ferdinando's suggestions.
>>
>>> Is measurement a kind of observation? The present version
>> of OBOE says
>>> no.
>>
>> This is correct.  A measurement (for oboe's purposes anyway)
>> implies there was an observation, but a measurement in and of
>> itself isn't the observaton.  (In fact, this implication is
>> *not* a general requirement of measurements, e.g., in
>> measurement theory and the like statements such as
>> 5 grams or 10 meters are reasonable objects of discussion
>> themselves. As a simple example, the eml-unit dictionary
>> describes transformations between such measures, without ever
>> talking about *what* is being measured).
>>
>>> 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.
>>
>> That is only because Josh was trying to *capture*
>> Ferdinando's suggestion, not nec. change oboe in this way.
>>
>>> (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.
>>
>> Again, I think this is incorrect.
>>
>>> 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.
>>
>> I wouldn't say "refuse" the idea -- I would say that modeling
>> measurement (and its various types) as observations has some
>> problems --
>>
>>> 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.
>>
>> I don't really understand what this means.  I think the
>> reason to distinguish measurement and observation is because
>> they are actually different things.  In the general setting,
>> one can have observations independently of measurements, and
>> measurements independently of observation -- suggesting these
>> are fundamently different entities.
>>
>> Also, we need to be very careful about talking about data
>> structure when we talk about oboe.  Not all day is tabular --
>> and so it is a mistake to design oboe to only work with data
>> formatted this way.
>>
>> -shawn
>>
>>
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> _______________________________________________
>> Seek-kr-sms mailing list
>> Seek-kr-sms at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/
>> seek-kr-sms
>>
>
> _______________________________________________
> Seek-kr-sms mailing list
> Seek-kr-sms at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek- 
> kr-sms