[seek-kr-sms] OBOE discussion: current version
Ferdinando Villa
ferdinando.villa at uvm.edu
Thu Jun 22 09:19:26 PDT 2006
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
>
More information about the Seek-kr-sms
mailing list