[seek-kr-sms] OBOE clarifications and questions
Ferdinando Villa
ferdinando.villa at uvm.edu
Thu Jun 15 12:17:57 PDT 2006
>
> 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".
>
Couldn't agree more. Never seen anything starting with "compound" or "sub"
last in a successful conceptualization. Compositional and nesting features
need to emerge from properties and from those alone. Any hint of that in
class names is almost always a design error.
> > 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.
>
Also agree fully. We had long discussions about column vs. row annotation in
Texas, but this pertains to the mechanics of annotation and the semantics of
representation, not to the semantic of the observation process. In my view,
the rationale for multiple values (rows) in a dataset can almost always be
traced to the contextualization, which can imply more than one value points,
and the context (not the semantics) is under the control of the experimenter
or even the workflow environment (e.g. aggregation or propagation to match
temporal resolutions). So the moment we have a contextualization
relationship, we have all the semantics we need to define the issue of rows
vs. column somewhere else - namely, where we define the physical
representation of the data. When the contexts differ between rows, we have a
case of separate datasets in the same physical storage, rather than a
rationale for representing individual data points as separate observations.
ferdinando
> >> -----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
> >
> _______________________________________________
> 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