search

OBOFoundry / COB

An experimental ontology containing key terms from Open Biological and Biomedical Ontologies (OBO)
https://obofoundry.github.io/COB
Creative Commons Zero v1.0 Universal
35 stars 8 forks source link

Add a "characteristic attribute" and "characteristic value" class #218

Open cmungall opened 1 year ago

cmungall commented 1 year ago

The proposal here is to delineate two distinct aspects of characteristics: the attribute and the value

Structure:

Example ABox (from an example from @jamesaoverton):

:N1A1
  a NCBITaxon:9238 ; # 'Adelie Penguin (Pygoscelis adeliae)'
  RO:0000053 [       # 'has characteristic'
    a PATO:0000125 ; # 'mass' - under "characteristic attribute"
    :hasValue [
      a PATO:0045030 ; # 'normal mass'
      :determinedBy [
        a OBI:0000445 ; # 'mass measurement assay'
      ]
    ] ;
    :hasValue [
      a PATO:0000125 ; # 'mass'
      :hasQuantity "3750"^^xsd:float ;
      :hasUnit unit:g
    ] ;
  ] .

let's not get diverted by discussion of "normal" here, that is not the issue. The example can be replaced using other parts of PATO, e.g:

the general schema is

classDiagram
  Entity --|> Attribute : hasCharacteristic
  Attribute --|> Value : hasValue
  Value --|> Assay: determinedBy
  class Entity {
    Any type
  }
  class Attribute {
    CharacteristicAttributeClass type
  }
  class Value {
    CharacteristicValueClass type
    float hasQuantity
    unit hasUnit
  }

This leaves a lot out: for Value, at least one of a float-unit or a specific value class should be specified. values could be derived from other values (in particular, "binning" into categories as done in mouse phenotyping pipelines), etc.

challenges

The main challenge for this is that it deviates from PATO which currently conflates attributes and values

This doesn't automatically cause incoherency - some solutions:

None are entirely unsatisfactory.

A split may look something like this:

Attributes:

Values:

historic note

PATO originally was two separate hierarchies, A and V. I am responsible for collapsing these. This was to be consistent with BFO. I am no longer so sure this was a good idea

For those philosophically inclined, A=determinable, V=determinant. See https://plato.stanford.edu/entries/determinate-determinables/

More importantly, the A vs V distinction is common to many practical systems like QUDT (A=QuanityKind):

img

See also: https://github.com/pato-ontology/pato/issues/101

matentzn commented 1 year ago

The main challenge for this is that it deviates from PATO which currently conflates attributes and values

I wouldn't mind rethinking this as well.

It will be very hard to elicit feedback on this very important issue here - it is very complex. How do you suggest we make progress on it?

wdduncan commented 1 year ago

I am all for a standardized way to represent values. If I understand correctly, you are proposing that "values" are the determinants when applying determinable/determinate distinction.

I have played around with using this distinction to represent instances that change over time (I've attached a toy ontology). But, I haven't posted about it b/c I thought it may be too philosophical for COB.

Here is simple example of using the property height as a determinable that changes (i.e., has different determinants) over time.

  1. Define an instance of height that inheres_in an instance of a person.

    :person1 a :person .
:height1 a :height;
:inheres_in person1 .

  2. Define two instances of height with each a distinguished by existing at different times and having different literal values.

    
height1_at_t1 a :height;
:exists_at "2020-01-01";
:has_quantity_value "155 cm" .

height1_at_t2 a :height; :exists_at "2021-01-01"; :has_quantity_value "160 cm" .


3. Define  `height1_at_t1` `height1_at_t2` as being determinants of `height1`:

:height1_at_t1 :determinant_of :height1 . :height2_at_t2 :determinant_of :height1 .


4. To enable reasoning, define the property chain:

determinate_of o inheres_in


This infers that `height2_at_t1` and `height2_at_t2` inhere in `person1` (which I think makes sense).

<img width="376" alt="image" src="https://user-images.githubusercontent.com/3186638/202875816-aeb82225-10bd-4cd3-af50-17b1a1ee96cd.png">
[determinates.owl.zip](https://github.com/OBOFoundry/COB/files/10048158/determinates.owl.zip)

You may also have multiple levels of determinants. E.g., taking a liberally-interpreted example from the Stanford article:

:color1 a :color . :red1 :determinate_of :color1 . :scarlet1 :determinate_of :red1 .



[determinates.owl.zip](https://github.com/OBOFoundry/COB/files/10048159/determinates.owl.zip)
cstoeckert commented 1 year ago

+1 @wdduncan we discussed this some on the Nov 21, 2022 OBI call. My take is that there would not be attribute and value classes just instances of characteristics that can be related as you indicated. To protect the philosophy-averse, the predicates would be called has_attribute and has_value to relate an entity to a determinable (characteristic) and a determinable (characteristic) to a determinant (characteristic), respectively. @jamesaoverton has a model of this.

wdduncan commented 1 year ago

Thanks @cstoeckert

I think has_value may cause some confusion. The moniker "value" may to be more appropriate for relating entities to literal values (although, owl:hasValue can have range individual or literal). Perhaps a different label can be found.

To be clear, I'm not a fan of the label I used in my toy example (i.e., "determinate_of"). I think it is too philosophical. However, there is already a determined by relation in RO that relates systems to material entities :(

Good to hear that OBI discussed this. This idea has been around a while. If implemented, I think the relation (whatever the name will be) should be in RO. It has wider applicability than OBI. Also, it can be applied to entities other than characteristics. E.g, representing a person at a particular stage of life:

:pat a :person .
:pat_as_child a :person .
:pat_as_child :participates_in [a :child_stage] .

:pat_as_child :determinate_of :pat .
... define particular characteristics of :pat_as_child ....
cstoeckert commented 1 year ago

Definitely these should go in RO. I think we want relations with domain and range constraints that help define how to use them for standardized modeling of characteristics and to distinguish has_attribute and has_value (or whatever it ends up being called). If we made the relations more general they would be less useful for validating these particular shapes.

wdduncan commented 1 year ago

If we made the relations more general they would be less useful for validating these particular shapes.

Seems reasonable to ... at least for now :)

(or whatever it ends up being called)
how about determines characteristic / characteristic determined by?

jamesaoverton commented 1 year ago

I created a repository and GitHub Pages site for my current work on qualitative and quantitative values, which includes my take on the attribute/value distinction: https://github.com/jamesaoverton/qqv.

I do think the 'has value' relation I'm talking about in that draft is a kind of 'has determinate' relation, between a more general characteristic (the attribute) and a more specific one (the value). I agree that "determinate" sounds too philosophical. I'm also worried that I don't sufficiently understand the philosophical literature on determinates.

wdduncan commented 1 year ago

@jamesaoverton

my take on the attribute/value distinction: https://github.com/jamesaoverton/qqv.

Thanks for putting this documentation together. It looks really good!

I don't sufficiently understand the philosophical literature on determinates.

Not sure anybody does :) But I think we all get the general/basic idea ...

As noted above, I tend to associate the word "value" with a literal, not an individual. At a later date, it might also be worth exploring how the determinable/determinate distinction can be used for representing changes in the individuals that bear the characteristics (e.g., pat-as-child is-determinate-of pat-the-person).

wdduncan commented 1 year ago

I think the qqv approach is worth exploring. I made a few comments about it here: https://github.com/jamesaoverton/qqv/issues/1