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

[Kennedy, Jessie]

Hi Folks

 

I've been following your recent discussion with interest (although not
as fully as I'd like). As Bob Morris noted, TDWG are working on similar
stuff. In addition to the specific SDD work on colours and descriptions
I've been working with some members of the different TDWG subgroups to
try and define a core ontology for TDWG. We started from the work on
standards from the specimen based groups (Darwin Core and ABCD), the
Taxon names ands concepts group (TCS) and from the Descriptions group
(SDD), in addition the geospatial group with Read Beaman will be
contributing. 

 

The interesting thing is that everyone is talking about observations,
and of course there are many interpretations of what an observation
means (as has also been exemplified on this list). We had events
initially in our base ontology from which things like observation were
subclassed but now we've gone for modelling the observation record
rather than the event, in a similar way to is being discussed here,
however we've not got into measurements side as much as you have. If
you're interested in where we've got to with our model (using UML for
the time being for communicating our understanding on our wiki) please
have a look at the TDWG ontology pages

http://wiki.tdwg.org/twiki/bin/view/TAG/TDWGOntology

 

We talked about observations as being a record of an identification to a
taxon concept (possibly any concept) by someone at a given place and
time  (and it may have an associated measurement like a count but we
haven't put that in the core as we didn't think it was fundamental to an
observation maybe we should?). Observations may have associated
gatherings (which can be independent from observation - again debatable
by some) if a specimen is collected. The specimen may of course have
descriptions taken about it (measurements of different kinds) and may be
located in an collection somewhere. I was quite happy with the
observation not being a thing (like a specimen) but you seem to be
talking about taking measurements of an observation... is this a
measurement of a specimen in the field that isn't collected as a
voucher? Is it an aggregate measurement such as the average of a
population in the field, or an average of say the length of the leaves
on a specimen in the field? Do the differences between these thing
smatter? I'd be interested to hear more about what you think an
observation is...whatever I think we have to be clear what we mean
because we could generalise it so much it could be anything we want it
to be.

 

We've been trying to segment the existing standards as much as possible
to try and determine the general classes being reused by the different
schemas to offer as much reusability as possible. In trying to get
agreement we quickly realised that as soon as we started putting
properties on classes people would start to disagree with the definition
of the class so we opted for putting a gloss on the class (this needs
updated in the current version) and only defining possible relationships
between classes (to give more sense to our meaning of the class).
Depending on which of our user community we viewed things from would
change whether or not a particular relationship was seen to be
fundamental to the class or not. So we've kept it minimal, but
multi-purpose I hope.

 

We're going to use the ontology in a mini project over the summer to try
and convert an existing data provider's data to RDF using LSIDs to cross
reference between the objects. We will extend the bdicore ontology to a
domain ontology required for this purpose.

 

Re your discussion on quantitative and qualitative measurements, in our
work on plant description ontology we had structure-property-value-unit
for quantitative measurements and structure-property-state for
qualitative descriptions. 

But we had other mechanisms for dealing with more complex 'measurements
such as ratios e.g leaf length to width.

 

Well I'd love to talk more about this with you guys but have too many
other things just now - most pressing is going off on holiday for a
break :-)

 

Look forward to catching up with you when I get back...

 

Jessie

 

________________________________

From: seek-kr-sms-bounces at ecoinformatics.org
[mailto:seek-kr-sms-bounces at ecoinformatics.org] On Behalf Of Joshua
Madin
Sent: 21 June 2006 20:57
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 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/9c8c65e3/attachment-0001.htm