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.

Sign up for GitHub

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

Jump to bottom

Add data property for molecular charge #723

Closed
wants to merge 5 commits into from
Closed

Add data property for molecular charge #723

wants to merge 5 commits into from

Conversation

cthoyt
Copy link
Collaborator

@cthoyt cthoyt commented Jun 7, 2023 •
edited
Loading

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

cmungall commented Jun 7, 2023

We haven't historically modeled data properties in RO. OWL is actually a terrible framework for this. We are forced into a choice between

  • annotation properties. Fundamentally weak. No semantics
  • data properties. Incorrect semantics for the realist model in OBO. (these would become properties of the class)
  • object properties following one of any number of competing proposals
    • something following a verbose measurement pattern
    • following BFO and having something abstract involving dispositions
    • ...

I think the best place for the SOT is either wikidata or chemrof. CHEBI can shadow as annotation properties.

@StroemPhi
Copy link

StroemPhi commented Jun 7, 2023 •
edited
Loading

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

balhoff commented Jun 7, 2023

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

cmungall commented Jun 7, 2023 •
edited
Loading

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:

ebi-chebi/ChEBI#4393

@cmungall cmungall mentioned this pull request Jun 7, 2023
Open
@cmungall
Copy link
Contributor

cmungall commented Jun 7, 2023

@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:
OBOFoundry/COB#195

@cmungall
Copy link
Contributor

cmungall commented Jun 7, 2023

another option is wikidata properties

@wdduncan
Copy link
Collaborator

wdduncan commented Jun 7, 2023

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

StroemPhi commented Jun 7, 2023 •
edited
Loading

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

wdduncan commented Jun 8, 2023

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

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

@wdduncan
Copy link
Collaborator

wdduncan commented Jun 8, 2023

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

cmungall commented Jun 8, 2023 via email

@cthoyt
Copy link
Collaborator Author

cthoyt commented Jun 8, 2023 •
edited
Loading

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

cmungall commented Jun 8, 2023 via email

@StroemPhi
Copy link

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

wdduncan commented Jun 9, 2023

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

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.

@github-actions github-actions bot added the stale label Oct 11, 2023
@jhpoelen
Copy link
Contributor

@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
Copy link
Collaborator Author

cthoyt commented Mar 25, 2024

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

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

@wdduncan
Copy link
Collaborator

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

@github-actions github-actions bot removed the stale label Mar 26, 2024
@github-actions GitHub Actions
Copy link
Contributor

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.

@github-actions github-actions bot added the stale label Jun 24, 2024
@anitacaron
Copy link
Collaborator

In RO Meeting, Monday Sep 09, 2024 (8am PT, 11am ET, 5pm CET) we decided to close this issue and tag @cmungall in case ChEBI et al. would like to re-use this thread in their own tracker. https://docs.google.com/document/d/19dhzj5QoliQZQgDJRczI878rLtexzMDo1g0K9_LRUWk/edit

@anitacaron anitacaron closed this Sep 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@cthoyt cthoyt

Labels
stale
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
7 participants
@cthoyt @cmungall @StroemPhi @balhoff @wdduncan @jhpoelen @anitacaron