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

[Shawn Bowers]

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