-
Notifications
You must be signed in to change notification settings - Fork 8
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
Comments
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? |
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
This infers that You may also have multiple levels of determinants. E.g., taking a liberally-interpreted example from the Stanford article:
|
+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. |
Thanks @cstoeckert I think 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:
|
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. |
Seems reasonable to ... at least for now :)
|
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. |
Thanks for putting this documentation together. It looks really good!
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., |
I think the qqv approach is worth exploring. I made a few comments about it here: jamesaoverton/qqv#1 |
The proposal here is to delineate two distinct aspects of characteristics: the attribute and the value
Structure:
Example ABox (from an example from @jamesaoverton):
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
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):
See also:
pato-ontology/pato#101
The text was updated successfully, but these errors were encountered: