[obs] Joining DwC, OBOE, PO and PATO

[Chris Mungall]

On Oct 27, 2010, at 1:11 PM, Shawn Bowers wrote:

> Hi,
>
> Jumping in a bit late to the discussion ...
>
>> Although keeping all phenotype observations within the OBO model is
>> attractive (i.e., not using OBOE after all).  If DwC were to accept  
>> an
>> Observation class, then this could be directly of a bfo:Entity  
>> which was a
>> bearer_of a Quality, making life much simpler.
>
> There is a fundamental difference between PATO (more generally EQ) and
> OBOE when talking about properties of individuals. The focus of OBOE
> is on defining measurements of individuals (e.g., "field
> observations"). A measurement states that a particular entity (an
> individual) had a specific value for a property within some context,
> where the context could be a variety of spatial, temporal, or even
> experimental settings. The measurement is not by definition essential
> to the individual (e.g., the height of a tree varies over time, each
> individual tree has a different height, etc.). PATO, from what I've
> read, is not designed to express measurements and measurement context,
> but instead is focused on describing the types of properties and their
> associated values (e.g., spherical shape or green color). These could
> be used within a measurement setting, or to classify entity types
> (e.g., a curved wing is a wing that has a curved quality).

This is a good summary

> A strength of OBOE is that we can describe the properties of
> individuals that change over space/time/experiment/etc. This is also
> true of other observation models (not just OBOE).
>
> In OBOE, going back to your original example, one way you could
> specify the measurement of the individual using PATO terms might be
> something like this:
>
> _:o2
>  a oboe:Observation ;
>  oboe:ofEntity [
>    a po:PO_0009001 ;  # fruit entity
>    ] ;
>  oboe:hasContext _:o1 ;
>  oboe:hasMeasurement [
>    oboe:ofCharacteristic [
>      a po:PATO_0000014 ; # color
>      ] ;
>    oboe:hasValue [
>      a po:PATO_0000320 ; # green
>      ] ;
>    ] .
>
> _:o1
>  a oboe:Observation ;
>  oboe:ofEntity _:blank1 .  # an Occurrence

One issue here is that if you try and declare characteristics and  
values to be disjoint classes, you'll get an inconsistence if you  
import PATO and run a reasoner. This is because green is a subclass of  
color.

PATO adopts the BFO model of qualities, which many find unintuitive  
compared to, say, DOLCE. In this model, in any given green apple at a  
point in time, there is a single "instance of green-ness" inhering in  
that apple. There is no seperate instance of a color characteristic -  
the instance of green-ness is also an instance of a color.

If you have the inclination, the logical-philosophical foundations are  
in this paper:
http://ontology.buffalo.edu/bfo/SQU.pdf

But as I've said many find this model unintuitive and awkward for KR.

One way to conceptualize PATO and to bridge the two models is to think  
of PATO as only covering the attributes. When PATO says "green" it  
means "an instance of a color attribute whose value is GREEN-VALUE",  
where GREEN-VALUE is something currently outside PATO.

Sorry, trying to cram a few years worth of discussions and papers into  
an email

There is a chance BFO will change with BFO2 so PATO would probably  
change then too.

> Again, this does not say that the color of the individual is green.
> Instead, it says someone observed within the occurrence that the
> individual was green. And these are fundamentally different statements
> ...

Absolutely. It allows you to have separate seemingly contradictory  
observations without a logical contradiction

> Note above that I'm using Green as the value of the measurement, which
> also implies the characteristic Color. However, one could imagine
> wanting to attribute something more specific to the characteristic
> than just color (at least for some qualities). This also becomes
> important for numeric values (e.g., the Wavelength is 515nm).
>
> Shawn
>
> On Tue, Oct 26, 2010 at 9:29 PM, Cam Webb <cwebb at oeb.harvard.edu>  
> wrote:
>> Dear Chris,
>>
>>> You would be more interoperable with other OBO-compliant resources  
>>> if you
>>> model it this way, using the bfo bearer_of property to connect a  
>>> fruit
>>> individual with a color individual:
>>>
>>> [] a oboe:Observation ;
>>>    oboe:ofEntity [
>>>        a oboe:Entity ;
>>>        a po:PO_0009001 ;
>>>        bfo:bearer_of [
>>>            a pato:PATO_0000320
>>>        ] ;
>>>    ] ;
>>
>> Thanks for this suggestion (although bearer_of doesn't seem to be a  
>> term in
>> bfo 1.1, but only in ro_proposed?).  A possible problem with this  
>> solution
>> may be that such an oboe:Observation has no oboe:Measurement  
>> (though an
>> oboe:Measurement is not specified in the oboe ontology as being  
>> required for
>> a oboe:Observation...).  Perhaps another solution is to simply make  
>> the
>> observed quality an instance of the PATO term:
>>
>> []   a oboe:Observation ;
>>    oboe:ofEntity [
>>        a oboe:Entity ;
>>        a po:PO_0009001 ;
>>        ] ;
>>    oboe:hasMeasurement [
>>        a pato:PATO_0000320 .  # <----------
>>        ] .
>>
>> Although keeping all phenotype observations within the OBO model is
>> attractive (i.e., not using OBOE after all).  If DwC were to accept  
>> an
>> Observation class, then this could be directly of a bfo:Entity  
>> which was a
>> bearer_of a Quality, making life much simpler.
>>
>> [] a dwcnew:Observation ;
>>    dwcnew:ofEntity [
>>        a po:PO_0009001 ;
>>        bfo:bearer_of [
>>            a pato:PATO_0000320
>>            ] ;
>>        ] .
>>
>>> I don't know much about the oboe ontology, an dhow these can  
>>> interoperate
>>> with OBO ontologies. Is oboe:Entity intended to be the maximally  
>>> general
>>> class? If so then it may be redundant to declare this individual  
>>> as being
>>> both type oboe:Entity and of type fruit (since presumably fruits are
>>> entities).
>>
>> True, I was just adding it for extra information (for me).
>>
>> Thanks again,
>>
>> Cam
>>
>> _______________________________________________
>> obs mailing list
>> obs at ecoinformatics.org
>> http://lists.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/obs
>>