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

Shawn Bowers sbowers at ucdavis.edu
Wed Jun 21 11:04:48 PDT 2006


> > 3.      Each specific dimension has a set of related units. Say,
> > length may be measured in meters, centimeters , microns . I believe
> > that this  association of a specific dimension with a set of
> > respective units is an important intuition that helps to make sense
> > of calculations. Why do not we draw an additional property hasUnit
> > with domain Dimension  and range  Unit
> Hmm.  This sounds like a good idea.  I'll think about this some more.

I think this is probably not practical, unless we restrict these types of
relations to SI units.  There are potentially many different kinds of
units/unit definitions in use (e.g., see Matt's previous email), and
enumerating these for each dimension would be time consuming, require
someone to maintain these connections for each new unit added, and
possibly be over restrictive for more abstract kinds of characteristics.

> > 4.      O&M scheme for Observation and Measurement has additional
> > notion of observation/measurement procedure. It looks as if this
> > concept could be easily added to OBOE by attaching property
> > hasProcedure either to observation or to Measurement or to both. If
> > we have property has procedure with domain that include both
> > Observation and Measurement, then we might need to think how
> > measurement procedure is related to observation procedure. Does it
> > have sense to have both observation procedure and measurement
> > procedure?
> Yes.  This would certainly make OBOE more complete, and I agree that
> this property should operate at both the Observation and Measurement
> level.  For example, we used a telescope for observing, but a tape
> measure for measuring.  It seems that EML already captures much of
> the procedural stuff, so we need to discuss if we want to become more
> redundant (e.g., EML covers much of the unit stuff as well), or
> whether we just want to fill in the gaps that EML can't cope with.
> Personally, I think that OBOE should be a stand-alone initiative, and
> therefore include the concept of observation and measurement procedure.

I agree -- we should include protocol/method.  This seems like low-hanging
fruit for oboe.

> > 5.      There is property hasMeasuredCharacteristic with domain
> > Observation and range Measurement. Is Measurement an event,
> > procedure or characteristics of something? I think that Measurement
> > as such is not a characteristic but an event. But measurement is a
> > measurement  *of* a characteristic. Therefore property
> > hasMeasuredCharacteristi should have domain Measurement and the
> > range Characteristic. (but in this case it will duplicate property
> > hasSubject) . In fact the choice of range Characteristic is
> > determined by the name of the property hasMeasuredCharacteristic.
> > The domain may be either Measurement or Observation.
> I totally agree and there has been some discussion about this.  I
> really like your use of the word "event", I think this makes what we
> are actually doing much clearer.  For example, we Observe a tree,
> each Measurement is an event relating to that Observation, and a
> Measurement is of some characteristic.  I second the move changing
> the property between Observation and Meaurement to something like
> "hasMeasurementEvent".

I don't agree with this, mainly because the same reasoning can be applied
to an Observation also being an "event".  In fact, for many cases, the act
of observing and measuring are probably tied to the same "event" -- It
seems weird to "observe" a bird, and then at some other time/event measure
the length of the bird, but assert that the measurement was of the bird
...

The idea of associating observation and measurement is that we are
observing an entity, and asserting a measured value for a characteristic
of the entity.  If anything, I would simplify these relations to:

  Observation.hasMeasurement -> Measurement
  Measurement.measurementFor -> Observation

Our measurement/observation structure is introducing a level of
indirection (or reification) between the entity and the characteristic of
the entitiy.  Because of this indirection/reification, it is a bit hard to
name the properties using the convention of "has-X/of-X" ...

-shawn


>
> Cheers,
> Josh


More information about the Seek-kr-sms mailing list