Open cthoyt opened 1 year ago
We haven't historically modeled data properties in RO. OWL is actually a terrible framework for this. We are forced into a choice between
I think the best place for the SOT is either wikidata or chemrof. CHEBI can shadow as annotation properties.
If this is in order, we can follow-up with several other ChEBI properties for formula, inchi, inchikey, mass, monoisotopic mass, and SMILES.
There are classes for this in CHEMINF:
We haven't historically modeled data properties in RO. OWL is actually a terrible framework for this. We are forced into a choice between
- data properties. Incorrect semantics for the realist model in OBO. (these would become properties of the class)
I don't understand why this can't be done correctly. Why not a value restriction like my_chemical SubClassOf has_charge value 2
?
actually, @balhoff's suggestion is more sensible than mine.
however, there are a few implications we need to work through
Here is the issue:
@StroemPhi these are classes rather than properties - I know I am in the minority on this in OBO but I don't think it makes sense to model properties as classes in OBO unless there is a strategy for automatically relating these to direct properties. How are these intended to be used in practice in an ontology like CHEBI?
another option is wikidata properties
another option is wikidata properties
Do you mean import them into RO or have ChEBI use the wikidata properties?
I am not opposed to adding DPs to RO, but there is always the issue of what to do with units. (I don't know what units are used to measure charge.) Do you embed the unit in the literal (e.g., 10 mg
), create a specific DP for that unit (e.g., weight in milligrams
), or attach the unit and value info to an instance of the property (e.g., :x a mass; :has_unit :mg; owl:hasValue "10.0"^^xsd:float
).
In an ideal world, I like option (1), but there are number of pragmatic issues with it (and lots of discussion has been had about it). Option (2) seems inelegant/hacky, but may be the best way to go if you are ardent about only wanting to use a DP. Given these issues, I tend to gravitate towards option (3), but I am probably in the minority on this.
How are these [classes] intended to be used in practice in an ontology like CHEBI?
@cmungall this is a good question to which I don't have an answer due to my limited knowledge. I just wanted to note that there are these classes. Similarly AFO has such ICE classes under afo:molecular structure. I assume these classes where defined to be able to make assertions about the literal values they provide the meaning for (e.g. from which specification/algorithm the literals were computed/derived). But I agree, I would also love to see how these classes are supposed to be used in the real world in pragmatic ways when relating them to ChEBI.
When trying to grok these classes in CHEMINF, I see that they are only used on chebi in cheminf:molecular entity, e.g. the cheminf:charge descriptor is about a molecular entity.
To "unpack" for example the chebi:charge literal of chebi:aluminium(0) using CHEMINF and other OBO ontologies, I would assume that there is some way to say that a chebi:aluminium(0) instance will always ro:[have as a] characteristic an instance of cheminf:charge which ro:is concretized as ro:concretizes a cheminf:charge descriptor that obi:has [as a] representation the value "0".
I'm really sorry if I pollute this PR thread with my comments and will refrain from further doing so, if they are too distracting or plain wrong. I just want to learn/know how to do it right.
edited: corrected wrong RO relation
ro:[have as a] characteristic an instance of cheminf:charge
Yes
cheminf:charge which ro:is concretized as a cheminf:charge descriptor that obi:has [as a] representation the value "0".
No, cheminf:charge is quality, not an information content entity
. You could say that a cheminf:charge descriptor (as subclass of ICE) is concretized as some quality/characteristic, though.
@wdduncan sorry it was late here, I meant "the cheminf:charge which ro:concretizes the cheminf:charge descriptor".
I meant "the cheminf:charge which ro:concretizes the cheminf:charge descriptor".
From a domain/range perspective this is permissible. However, whether this makes sense, depends on the context. concretizes
relates information/ICEs to the patterns of SDCs that "convey" (communicate?) information. E.g., the pattern of pixel colors on your screen convey the information in this PR.
In regards to charge descriptor
, it would be very strange (IMHO) to assert that every charge descriptor
concretizes
some charge
. Surely, you can also write down a charge descriptor
. So, (if I wanted to be a BFO/IAO purist), I would represent this as charge descriptor is about some charge
. Then (if needed) you would represent the concretizations (e.g., patterns of ink, pixels, magnetic fields on a hard drive, holes in punch card, etc.).
Hi Philip
Your comments are most welcome! My provocative challenge was addressed more generally at the IAO school of modeling!
On Wed, Jun 7, 2023 at 1:58 PM Philip Strömert @.***> wrote:
How are these [classes] intended to be used in practice in an ontology like CHEBI?
@cmungall https://github.com/cmungall this is a good question to which I don't have an answer due to my limited knowledge. I just wanted to note that there are these classes. Similarly AFO has such ICE classes under afo:molecular structure https://www.ebi.ac.uk/ols4/ontologies/afo/classes/http%253A%252F%252Fpurl.allotrope.org%252Fontologies%252Fresult%2523AFR_0001072?lang=en. I assume these classes where defined to be able to make assertions about the literal values they provide the meaning for (e.g. from which specification/algorithm the literals were computed/derived). But I agree, I would also love to see how these classes are supposed to be used in the real world in pragmatic ways when relating them to ChEBI.
When trying to grok these classes in CHEMINF, I see that they are only used on chebi in cheminf:molecular entity https://www.ebi.ac.uk/ols4/ontologies/cheminf/classes/http%253A%252F%252Fpurl.obolibrary.org%252Fobo%252FCHEBI_23367?lang=en, e.g. the cheminf:charge descriptor https://www.ebi.ac.uk/ols4/ontologies/cheminf/classes/http%253A%252F%252Fsemanticscience.org%252Fresource%252FCHEMINF_000131?lang=en is about a molecular entity. To "unpack" for example the chebi:charge literal of chebi:aluminium(0) https://www.ebi.ac.uk/ols4/ontologies/chebi/classes/http%253A%252F%252Fpurl.obolibrary.org%252Fobo%252FCHEBI_33629?lang=en using CHEMINF and other OBO ontologies, I would assume that there is some way to say that a chebi:aluminium(0) https://www.ebi.ac.uk/ols4/ontologies/chebi/classes/http%253A%252F%252Fpurl.obolibrary.org%252Fobo%252FCHEBI_33629?lang=en instance will always ro:[have as a] characteristic https://www.ebi.ac.uk/ols4/ontologies/ro/properties/http%253A%252F%252Fpurl.obolibrary.org%252Fobo%252FRO_0000053 an instance of cheminf:charge https://www.ebi.ac.uk/ols4/ontologies/cheminf/classes/http%253A%252F%252Fsemanticscience.org%252Fresource%252FCHEMINF_000120?lang=en which ro:is concretized as https://www.ebi.ac.uk/ols4/ontologies/ro/properties/http%253A%252F%252Fpurl.obolibrary.org%252Fobo%252FRO_0000058 a cheminf:charge descriptor https://www.ebi.ac.uk/ols4/ontologies/cheminf/classes/http%253A%252F%252Fsemanticscience.org%252Fresource%252FCHEMINF_000131?lang=en that obi:has [as a] representation https://www.ebi.ac.uk/ols4/ontologies/obi/properties/http%253A%252F%252Fpurl.obolibrary.org%252Fobo%252FOBI_0002815 the value "0".
I'm really sorry if I pollute this PR thread with my comments and will refrain from further doing so, if they are too distracting or plain wrong. I just want to learn/know how to do it right.
— Reply to this email directly, view it on GitHub https://github.com/oborel/obo-relations/pull/723#issuecomment-1581501046, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOLFKGENGPMRRY6LNPDXKDTQ3ANCNFSM6AAAAAAY6DIRPU . You are receiving this because you were mentioned.Message ID: @.***>
I think everyone overestimated my knowledge of the modeling paradigms present in the ontologies - I converted the following OBO to OWL
[Term]
id: CHEBI:33429
name: monoatomic monoanion
subset: 3_STAR
synonym: "monoatomic monoanions" RELATED [ChEBI]
property_value: http://purl.obolibrary.org/obo/chebi/mass 0.00000 xsd:float
property_value: http://purl.obolibrary.org/obo/chebi/charge -1 xsd:integer
property_value: http://purl.obolibrary.org/obo/chebi/smiles "[*-]" xsd:string
is_a: CHEBI:23905
is_a: CHEBI:36830
and it tags http://purl.obolibrary.org/obo/chebi/charge as <owl:AnnotationProperty rdf:about="http://purl.obolibrary.org/obo/chebi/charge"/>
. So would it be possible to massively simplify his discussion and just make this an annotation property with a range of xsd:integer?
I appreciate the desire for simplicity - this is why I suggested wikidata. It's a great simple vocabulary for standardizing simple triples. Using chemrof is also entirely compatible with having simple triple shadows - and it gives you semantics for doing the kinds of error checking I suggested. There is absolutely no a-priori reason why CHEBI needs to use RO for these properties. And in fact given how messy these are in CHEBI, I would say RO is a really poor fit.
The reason to use RO would be to clearly state the semantics of these properties in a way that is interoperable with other ontologies in OBO and that allows for reasoning. Jim's suggestion is the most RO-compatible way of doing this. And it would do exactly what RO is designed to do - prevent inconsistencies. Unfortunately those inconsistencies are already there as CHEBI (see my linked ticket) which suggests CHEBI isn't ready to use RO for this use case yet. In fact at a bare minimum, we need to stop modeling floats as strings.
On Thu, Jun 8, 2023 at 1:32 PM Charles Tapley Hoyt @.***> wrote:
I think everyone overestimated my knowledge of the modeling paradigms present in the ontologies - I converted the following OBO to OWL
[Term] id: CHEBI:33429 name: monoatomic monoanion subset: 3_STAR synonym: "monoatomic monoanions" RELATED [ChEBI] property_value: http://purl.obolibrary.org/obo/chebi/mass "0.00000" xsd:string property_value: http://purl.obolibrary.org/obo/chebi/charge "-1" xsd:string property_value: http://purl.obolibrary.org/obo/chebi/smiles "[*-]" xsd:string is_a: CHEBI:23905 is_a: CHEBI:36830
and it tags http://purl.obolibrary.org/obo/chebi/charge as <owl:AnnotationProperty rdf:about="http://purl.obolibrary.org/obo/chebi/charge"/>. So would it be possible to massively simplify his discussion and just make this an annotation property with a range of xsd:integer?
— Reply to this email directly, view it on GitHub https://github.com/oborel/obo-relations/pull/723#issuecomment-1583297496, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOMIOZEANZ2BHCUEDPDXKIZEXANCNFSM6AAAAAAY6DIRPU . You are receiving this because you were mentioned.Message ID: @.***>
Thanks @wdduncan for your thoughts! They sparked me to reread this aboutness paper. Although it still leaves me with open questions (thanks "IAO school of modeling" 🤯), I now understand your point about my rather unsensical use of ro:concretizes
here better. Regarding your mentioned iao:is about
BFO/IAO purist approach, I wanted to note that CHEMINF created is descriptor of as a subproperty thereof and asserted the SubclassOf axiom is descriptor of some charge
on cheminf:charge descriptor
. AFO is somewhat inconsistent in this regard, as it sometimes uses iao:is about
, afo:describes
(a subproperty of is about
) or afo:quantifies
(a subproperty of afo:describes
) in the SubclassOf axioms of their related ICEs, like charge state, molecular formula or molecular mass. In know that AFO is not part of OBO but at least from an NFDI4Chem perspective we need to keep Allotrope on our radar for interoperability reasons.
Coming back to the actual problem at hand and just to make sure I'm understanding the general context of this PR correctly. Our goal/hope/intention is to improve the axiomatization of ChEBI with relations from RO and maybe classes from other OBO ontologies, so that it can be reused in a better axiomatization of ontologies like MOP & RXNO and to address the problems @cmungall mentioned in his CHEMROF talk at the Ontologies4Chem workshop last year, right?
(PS: I'm adding so much context to this PR thread to allow others to get a better grasp on the bigger picture, similarly to how I learn by reading your previous discussions in such threads.)
Thanks for the context @StroemPhi ! To be clear: I am not opposed to using DPs. I use them in the OHD. E.g., see:
This PR has not seen any activity in 90 days and has been marked as stale. If it is no longer needed, please close the PR. Otherwise, please update the PR with a status update.
@cthoyt Hi! We are reviewing this pull request in today's RO meeting. https://docs.google.com/document/d/19dhzj5QoliQZQgDJRczI878rLtexzMDo1g0K9_LRUWk/edit . Are you still interested to have your pull request reviewed? If not, please close this pull request. If so, please comment.
@jhpoelen the question isn't really about review at this point. I think my proposal has been rejected. However, the need still exists, so the question is how to proceed forward with a discussion about how to encode a relationship we can reuse across many places (ChEBI, Wikidata, etc.) that doesn't require ontological commitments that break ChEBI
@cthoyt thanks for sharing your comment. What do you suggest we do with this RO PR?
@cthoyt Since this PR touches a number of larger issues concerning data properties, can we close it?
This PR has not seen any activity in 90 days and has been marked as stale. If it is no longer needed, please close the PR. Otherwise, please update the PR with a status update.
This pull request continues the effort to standardize properties used in the ChEBI ontology into RO that was started in #662 and #696.
This pull request adds two data properties (as opposed to object properties and annotation properties):
xsd:integer
If this is in order, we can follow-up with several other ChEBI properties for formula, inchi, inchikey, mass, monoisotopic mass, and SMILES. Reminder, the goal is to take the following content and give it a proper, reusable, trustworthy identifier:
CC @cmungall, are there chemrof mappings to be added here?
Context
We now have explicit institutional support from the ChEBI team to do this and are directly working with @CarMoreno to make it happen! We will be able to update https://gitlab.ebi.ac.uk/chembl/chebi/chebi-2.0/chebi-ontology-generator/-/blob/dev/ontology_pipeline.py#L55 with changes made here.
Extra information about ChEBI curation can be found here.
See Also