oborel / obo-relations

RO is an ontology of relations for use with biological ontologies
http://oborel.github.io/
Other
91 stars 46 forks source link

Add data property for molecular charge #723

Open cthoyt opened 1 year ago

cthoyt commented 1 year ago

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):

Term Name Description
RO:0018041 chemical property A grouping data property; this won't be used directly
RO:0018042 has charge The charge is the sum of all the positive and negative charges shown in the structure. Replaces http://purl.obolibrary.org/obo/chebi/charge. This data property includes a range constraint with 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:

[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

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

curie label
wikidata:P2200 electric charge
chemrof:has_charge_state has charge state
cmungall commented 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.

StroemPhi commented 1 year ago

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:

balhoff commented 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

  • 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?

cmungall commented 1 year ago

actually, @balhoff's suggestion is more sensible than mine.

however, there are a few implications we need to work through

  1. do we model this as a functional property? I think so. No element can simultaneously have multiple different values for charge
  2. if we do this we end up with >1000 incoherencies. This is a good thing and a bad thing. It's good that we detect it. But it's bad in that we don't want an incoherent product. And it will likely take CHEBI a very long time to fix these
  3. this gets complicated as the incoherency will be for all purposes a crytpic incoherency, as I don't think any reasoner that supports has-value constructs will run over chebi (?). It's actually easier to check for this kind of thing over a direct triple representation

Here is the issue:

https://github.com/ebi-chebi/ChEBI/issues/4393

cmungall commented 1 year ago

@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?

See also: https://github.com/OBOFoundry/COB/issues/195

cmungall commented 1 year ago

another option is wikidata properties

wdduncan commented 1 year ago

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.

StroemPhi commented 1 year ago

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

wdduncan commented 1 year ago

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.

StroemPhi commented 1 year ago

@wdduncan sorry it was late here, I meant "the cheminf:charge which ro:concretizes the cheminf:charge descriptor".

wdduncan commented 1 year ago

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.).

cmungall commented 1 year ago

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: @.***>

cthoyt commented 1 year ago

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?

cmungall commented 1 year ago

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: @.***>

StroemPhi commented 1 year ago

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.)

wdduncan commented 1 year ago

Thanks for the context @StroemPhi ! To be clear: I am not opposed to using DPs. I use them in the OHD. E.g., see:

github-actions[bot] commented 9 months ago

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.

jhpoelen commented 3 months ago

@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.

cthoyt commented 3 months ago

@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

jhpoelen commented 3 months ago

@cthoyt thanks for sharing your comment. What do you suggest we do with this RO PR?

wdduncan commented 3 months ago

@cthoyt Since this PR touches a number of larger issues concerning data properties, can we close it?

github-actions[bot] commented 2 weeks ago

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.