[seek-kr-sms] OBOE clarifications and questions
Shawn Bowers
sbowers at ucdavis.edu
Thu Jun 15 11:05:47 PDT 2006
Hi all,
Comments below ...
On Thu, 15 Jun 2006, Serguei Krivov wrote:
> 1. What is blue arrow labeled by capital C ? This certainly can not be
> property-value pair for property hasContext. You use green arrows for
> hasContext
I believe Josh was using the current version of OBOE, and not Ferdinando's
extended version. Here, the blue arrow labeled C standards for
hasMeasuredCharacteristic --
In the current OBOE, observations are associated with Entities (i.e.,
things such as Frogs, Plants, etc.) and measurements are associated with
Characteristics (i.e., properties of things such as height, weight,
biomass, etc.) An observation has zero or more associated measurements,
which are linked through the hasMeasuredCharacteristic link.
> 2.I believe that an observation that represent one row of any table should
> be a :CompoundObservation, that is an instance of CompoundObservation . And
> in that case some of those bluer arrows which are now labeled by C should be
> labeled as hasObservation. One row that contain 3 columns with data
> represent 3 observations that are related.
We don't currently have a separate definition for "CompoundObservation".
In my opinion we don't need one (see also below). In the ontology, a
compound observation would just be an observation that is "composed"
(e.g., through context relations) of other observations -- but with no
additional "features".
Also, the blue arrows labeled C relate observations to measurements,
whereas the ones labeled "hasContext" are what I think you are referring
to (i.e., that form "compound observations").
> 3. In general I believe that the relation between columns should have
> different representation from representation of relation between rows.
> I think that property hasObservation of class CompoundObservation should be
> used to link different values stored in one row. The relation hasContext
> should be used to link the different rows of a table. Is anybody disagree
> with this?
I think this is too constraining. I also think this is mixing in notions
of annotation with the ontology itself, which artificially and
unnecessarily limits the generality of oboe. By annotation, I mean the
specification of how dataset values correspond to ontology instances --
the mapping from dataset instances to ontology instances.
> 4. First I thought that for each table, a green arrow hasContext pointing
> upwards on the upper portion of each diagram supposed to link one row of
> respective table to another row. But then I noticed that it actually
> aggregates the subplot observation for a specific plot. How do we link then
> the rows of the tables that belong to different plots. This may be
> hierarchical perhaps. May be we should use property hasContext to link
> aggregated object representing observation on plot.
Again, you are confusing annotation with the ontology itself. Only a
portion of the annotation is shown in Josh's diagram -- more information
is needed to see how the mapping is actually realized in the examples. I
think what Josh's examples are showing are essentially an "instantiation
template" for each row of the table (R1).
-shawn
>
> Thanks,
> Sergey
> ----------------------------------------------------------------------------
> ----------
> Serguei Krivov, Assist. Research Professor,
> Computer Science Dept. & Gund Inst. for Ecological Economics,
> University of Vermont; 590 Main St. Burlington VT 05405
> phone: (802)-656-2978
>
>> -----Original Message-----
>> From: seek-kr-sms-bounces at ecoinformatics.org [mailto:seek-kr-sms-
>> bounces at ecoinformatics.org] On Behalf Of Joshua Madin
>> Sent: Wednesday, June 14, 2006 7:00 PM
>> To: Ferdinando Villa; Corinna Gries
>> Cc: seek-kr-sms at ecoinformatics.org
>> Subject: Re: [seek-kr-sms] OBOE clarifications and questions
>>
>> Hi Ferdinando and all,
>>
>> I've inserted a few comments below --
>>
>> On Jun 14, 2006, at 9:14 AM, Ferdinando Villa wrote:
>>
>>> Hi Matt,
>>>
>>> a few quick additions to Josh response to clarify your points 4)
>>> and 5). I'm
>>> in a rush so I hope this is readable:
>>>
>>> The contextualization relationship (observation -|>> observation)
>>> relates a
>>> "main" observation to others that are not related to the semantics
>>> of the
>>> main observable, but are essential to define the semantics of how
>>> it was
>>> observed. So in your relation R1 we annotate four observations in
>>> which
>>> Biomass is contextualized by Subplot, Nitrogen and Phosporus.
>>> Subplot, in
>>> turn, is contextualized by Plot. Each observation is annotated as a
>>> separate
>>> instance of oboe:Observation, linked through the contextualization
>>> relationship.
>>>
>> I apologize. I annotated Matt's data sets incorrectly, and I've
>> attached alternative versions to this email (Matt_examples_2.pdf).
>> The first annotation is what I had yesterday, the first alternative
>> is how I think it should be, and the second alternative is what I
>> think Ferdinando is suggesting above. I consider the addition of
>> fertilizer a "characteristic" of the subplot (first alt), not an
>> observation. So, plot provides context for subplot, the subplot has
>> various characteristics (e.g., amount of added nitrogen), and subplot
>> provides context for biomass (of some biological entity).
>>
>>> The different contexts make R1, R2 an R3 classify as different
>>> classes, so
>>> they would not combine.
>>>
>>> This is obviously at a very abstract level, which is intentional.
>>> To get to
>>> the numbers, each observation must define a "value space" as you
>>> called it.
>>> This is not in the current OBOE although I put it in a revised
>>> version that
>>> Josh sent around (as "Observation space"), not yet vetted by the
>>> group. The
>>> value space is the set of all possible values generated by an
>>> observation of
>>> a certain class. So for things like plots/subplots, the value space
>>> of the
>>> space observation that contextualizes biomass is the enumerated set of
>>> subplots (seen as individuals of an appropriate ontology), whose
>>> semantics
>>> (external to OBOE) will specify labels, polygons, and may require
>>> or allow
>>> further contextualization in higher-level subdivision (plots etc).
>>
>> I'm really interested in the idea of a value space. Could you give a
>> more specific example of how it would be used, maybe using Matt's
>> data sets. Is this something that we need? How is it different from
>> what we currently have?
>>
>>> For
>>> things like measurements, the value space is abstract and defined
>>> in terms
>>> of an abstract unit (the ideal reference subdivision of the space)
>>> and a
>>> "realized unit" that links the abstract unit to the semantic type
>>> of what
>>> the measurement is (a meter of shore, a second of "quality
>>> time" :). For
>>> things like land use, the space is the set of classes that can be
>>> used to
>>> tag each observation value. OBOE currently has a simplified way to
>>> describe
>>> this that probably works, but I now feel is a bit of a shortcut for
>>> the
>>> explicit definition of the observation space.
>>>
>> Right. OBOE currently deals primarily with abstract units (or
>> standards), characteristics and entities, which together form a
>> realized unit... E.g., meter (abstract unit) of height
>> (characteristic) of tree (entity). Composite or semantic units
>> already have a characteristic describing them and therefore only have
>> abstracts unit and entities. E.g., The characteristic ArealDensity
>> <-- count (abstract unit) of trees (entity) per meters square
>> (abstract unit) of forest (entity).
>>
>>> The remaining problem is how to define the mapping between a set of
>>> observation values and the values of the observations that provide its
>>> context. This is necessary unless we see each data point of the main
>>> observation as an instance of observation, which however would make
>>> the size
>>> of the annotation potentially huge (dependent on the size of the
>>> dataset).
>>> Anyway this is a representational issue more than a semantic one
>>> and I don't
>>> think it should be in OBOE (I have proposed a separate representation
>>> ontology that also details data formats and parsing modalities,
>>> also not
>>> vetted by the group yet). While a these mappings are likely to be
>>> precisely
>>> definable with full generality only in higher-order logics, well-
>>> behaving
>>> datasets can be annotated by simply specifying the ordering in
>>> which the
>>> contexts are applied. Of course the specification of these can be
>>> complex
>>> and we need to work on this. But this should not change the
>>> semantic power
>>> of using contextualization in OBOE.
>>>
>> I've attached Ferdinando's representation.owl ontology. When opening
>> in Protege 3.2 beta, you'll need to point to the local file
>> "Observation.owl" which I sent several days ago.
>>> Does this answer some of your question, or confuse things further?
>>>
>>> cheers
>>> 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
>>>> Matt Jones
>>>> Sent: Tuesday, June 13, 2006 7:41 PM
>>>> To: seek-kr-sms at ecoinformatics.org
>>>> Subject: [seek-kr-sms] OBOE clarifications and questions
>>>>
>>>> Josh,
>>>>
>>>> Nice job on OBOE. I've been looking it over and learning a
>>>> lot, but there a number of specific areas that I don't
>>>> understand. Maybe you could clarify?
>>>>
>>>> 0) Is OBOE, and are other ontologies, available on the SEEK
>>>> wiki? They should be, and probably as links into the CVS
>>>> tree. The site review team requested this. I linked a
>>>> couple in to the wiki here:
>>>> http://seek.ecoinformatics.org/Wiki.jsp?page=KROntologies
>>>> Can you do the rest? Maybe Rich's ontologies should be made
>>>> available under the 'As-is' Formal Ontologies section for
>>>> reference purposes?
>>>>
>>>> 1) how do counts differ from moles? Isn't the NIST 'amount'
>>>> the same as the absolute scale in OBOE?
>>>>
>>>> 2) how to deal with log units?
>>>>
>>>> 3) How to deal with multiple relations with integrity
>>>> constraints? For example, a 'site' table, and a 'tree
>>>> measurement' table that has a foreign key into the site
>>>> table. Can we create annotations that refer to attributes in
>>>> both tables?
>>>>
>>>> 4) context doesn't seem to be enough to handle experiments --
>>>> it captures some information, such as spatial nesting of
>>>> experimental units, but it doesn't fully capture the
>>>> dependency information in tuples. In particular, it seems to
>>>> me that experimental manipulations are different from spatial
>>>> nesting. See example below. Can you clarify?
>>>>
>>>> I looked at the GCE examples you sent. They show the
>>>> 'Experimental Treatment' as the subject of the Measurement
>>>> for Treatment (with unit 'Name'). Is this list of subjects
>>>> controlled? And is 'Experimental Treatment' a special
>>>> characteristic that should be treated specially?
>>>> The value of the Measurement is set to 'N'. Where is the
>>>> value space for these treatments defined? And how does one
>>>> differentiate between manipualted and control values (ie, in
>>>> the value column in one experiment the values 0, 5, 10 might
>>>> indicate control, 5g/m^2, and 10
>>>> g/m^2 treatments) -- are these defined formally somewhere?
>>>>
>>>> Here's an example to expand on #4. The three relations below
>>>> (R1, R2, and R3) all measure biomass in subplots within
>>>> plots. In R1, the subplots are given both a nitrogen and
>>>> phosphorus addition treatment which affects the
>>>> interpretation of the biomass measured. So biomass has some
>>>> concrete dependency on the nitrogen and phosphorus treatments.
>>>> In relation R2, only a phosphorus treatment is added. R1
>>>> and R2 could be combined incorrectly by taking the mean by
>>>> plot,subplot,nitrogen in
>>>> R1 and then concatenating with R2. Or it could be correctly
>>>> combined by taking only those observations in which
>>>> Phosphorous manipulation is 0 and combining that set of
>>>> records with those from R2. Likewise, R3 has no
>>>> manipulations, so should really only be compared against
>>>> observations in R2 where the nitrogen treatment is 0 and R1
>>>> where both nitrogen and phosphorous are 0. These are the
>>>> semantics that OBOE should capture reagarding the dependecy
>>>> between the measured value (biomass) and the manipulated
>>>> treatments and their levels. Can OBOE do that?
>>>>
>>>> Relation R1
>>>> ----------
>>>> Plot Subplot Nitrogen Phosphorous Biomass
>>>> 1 A 5 3 56
>>>> 1 B 0 3 87
>>>> 1 C 5 0 78
>>>> 1 D 0 0 24
>>>> 2 A 5 3 58
>>>> 2 B 0 3 88
>>>> 2 C 5 0 76
>>>> 2 D 0 0 26
>>>>
>>>> Relation R2
>>>> -----------
>>>> Plot Subplot Nitrogen Biomass
>>>> 1 LR 5 56
>>>> 1 LL 0 87
>>>> 1 UR 5 78
>>>> 1 UL 0 24
>>>> 2 LR 5 58
>>>> 2 LL 0 88
>>>> 2 UR 5 76
>>>> 2 UL 0 26
>>>>
>>>> Relation R3
>>>> -----------
>>>> Plot Subplot Biomass
>>>> 1 1 56
>>>> 1 2 87
>>>> 2 1 58
>>>> 2 2 88
>>>> 3 1 76
>>>> 3 2 26
>>>>
>>>>
>>>> Thanks for the clarifications,
>>>>
>>>> Matt
>>>>
>>>> --
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> Matt Jones Ph: 907-789-0496
>>>> jones at nceas.ucsb.edu SIP #: 1-747-626-7082
>>>> National Center for Ecological Analysis and Synthesis (NCEAS)
>>>> UC Santa Barbara http://www.nceas.ucsb.edu/ecoinformatics
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> _______________________________________________
>>>> 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
>>>
>
> _______________________________________________
> 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