Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
cmungall opened this issue Nov 17, 2022 · 9 comments
Open

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

cmungall opened this issue Nov 17, 2022 · 9 comments

Comments

@cmungall
Copy link
Contributor

cmungall commented Nov 17, 2022

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

Structure:

  • COB:characteristic
    • COB:characteristic_attribute
    • COB:characteristic_value

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:

  • [i] PATO:0001396 ! cellular quality (A)
    • [i] PATO:0001404 ! nucleate quality (A)
      • [i] PATO:0002505 ! nucleated (V)
        • [i] PATO:0001908 ! multinucleate (V)
          • [i] PATO:0001909 ! trinucleate (V)
          • [i] PATO:0001406 ! binucleate (V)

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
  }
Loading

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:

  • either A and V can be non-disjoint in COB
  • PATO classes can be treated as conflations
  • PATO can be treated as either solely A or V with implicit logical definitions to hidden node IDs, e.g
    • PATO is A: PATO:binucleate = PATO:nucleateQuality AND hasValue from OTHER:binucleate
    • PATO is V: PATO:nucleateQuality = inv(hasValue) some OTHER:nucleateQuality
  • PATO splits into two hierarchies

None are entirely unsatisfactory.

A split may look something like this:

Attributes:

  • [i] PATO:0001396 ! cellular quality (A)
    • [i] PATO:0001404 ! nucleate quality (A)

Values:

  • [i] PATO:new ! cellular quality value (V)
    • [i] PATO:new ! nucleate quality value (V)
      • [i] PATO:0002505 ! nucleated (V)
        • [i] PATO:0001908 ! multinucleate (V)
          • [i] PATO:0001909 ! trinucleate (V)
          • [i] PATO:0001406 ! binucleate (V)

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:
pato-ontology/pato#101

@matentzn
Copy link
Contributor

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
Copy link
Member

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 .
  1. 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" .
  1. Define height1_at_t1 height1_at_t2 as being determinants of height1:
:height1_at_t1 :determinant_of :height1 .
:height2_at_t2 :determinant_of :height1 .
  1. 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).

image

[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

@cstoeckert
Copy link

+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
Copy link
Member

wdduncan commented Nov 22, 2022

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
Copy link

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

@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
Copy link
Member

wdduncan commented Dec 8, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants