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

go-plus equates ChEBI independent continuants and SO generically dependent continuants #15894

Closed
balhoff opened this issue Jun 9, 2018 · 20 comments
Assignees

Comments

@balhoff
Copy link
Member

balhoff commented Jun 9, 2018

The go-lego ontology (the ontology used in Noctua, which imports go-plus) has hundreds of unsatisfiable classes that result from disjointness of 'independent continuant' and 'generically dependent continuant'. The disjointness axiom is asserted in ECO, which is imported into go-lego (but it is declared in BFO as well). Problematic class relationships include:

  • CHEBI:messenger RNA == SO:mRNA
  • SO:transcript SubClassOf CHEBI:ribonucleic acid

and several other related classes. How are these bridges between SO and ChEBI being used?

@ukemi
Copy link
Contributor

ukemi commented Jun 10, 2018

We should look at this closely as a group. I think it is interesting. We will need to look more closely at exactly how we use these. It will be a good group exercise.

@balhoff
Copy link
Member Author

balhoff commented Jun 11, 2018

After a little more investigation @ukemi and I see that the link from the SO terms to 'generically dependent continuant' is not asserted in SO, but is actually being asserted by OBI. Presumably ECO imports this content from OBI. However @cmungall's paper at https://doi.org/10.1016/j.jbi.2010.03.002 makes it clear that the SO terms are intended to be subclasses of 'generically dependent continuant'.

The paper mentions a "SOM" hierarchy (Sequence Ontology:Molecules) which would contain the actual molecules that would be material entities. There is a mention of this on the SO wiki but it doesn't seem actively maintained.

So... in the short term we could exclude ECO from Noctua reasoning (but it needs to be available for autocomplete), but it seems like SO terms and ChEBI terms should be related in a different way, and GO should make sure material entity terms are used where that is intended.

@balhoff
Copy link
Member Author

balhoff commented Jun 12, 2018

I just came across the Molecular Sequence Ontology (MSO) project by @mikebada and @msinclair2 and see that @cmungall and @nataled have been active there. So I'm guessing there is already a plan to deal with this issue.

@cmungall
Copy link
Member

not sure when MSO will be ready we need an interim plan..

@msinclair2
Copy link

We are nearing completion, we hope to be ready to release by the end of October (2018), but Mike Bada can tell you more. The MSO, but not the refactored SO, is pretty much in its final form, but its classes have to be updated as many additions have been made since when we started working on it.

My opinion is that, if all you need is the bridge and are working with the molecules (MSO), which I believe is what most of GO would form its cross products with, then the necessary relation, "generically depends on", has already been implemented. You can download MSO_reasoned.owl, and SO_refactored.owl, from the MSO repo under files. SO_refactored.owl is not ready to be reasoned over quite yet, and not all necessary axioms have been transferred, but you can find the SO class you need by searching for the label. You'll see it is asserted to generically depend on some MSO IRI. You can then find that IRI in the MSO and import that class into go-lego, because all the relevant MSO classes are independent continuants.

@balhoff
Copy link
Member Author

balhoff commented Jun 22, 2018

I'm wondering how things would be structured if we went ahead and revised usage of SO terms to reflect inheritance from generically dependent continuant. We would need to revise the "bridge equivalences" and also usages of SO terms as chemical entities in GO logical definitions. I'm not sure of the exact preferred pattern, but looking in RO I imagine it to be something like this:

For the equivalence definitions, we would change

old: CHEBI:messenger RNA == SO:mRNA

to

new: CHEBI:messenger RNA == bearer of some (concretizes some SO:mRNA)

and then change a definition for a particular GO term like so:

old: GO:mRNA polyadenylation == GO:RNA polyadenylation and (has output some SO:polyadenylated_mRNA)

to

new: GO:mRNA polyadenylation == GO:RNA polyadenylation and (has output some (bearer of some (concretizes some SO:polyadenylated_mRNA)))

Is this the right way to relate these?

@msinclair2
Copy link

msinclair2 commented Jun 22, 2018

revised usage of SO terms to reflect inheritance from generically dependent continuant

This is exactly what we are doing with SO refactored.

usages of SO terms as chemical entities

These are available in MSO. That's what MSO is.

old: CHEBI:messenger RNA == SO:mRNA

to

new: CHEBI:messenger RNA == bearer of some (concretizes some SO:mRNA)

You just need:

CHEBI:messenger RNA == MSO:mRNA

In the definition of SO:mRNA refactored, there is SO:mRNA generically depends on MSO:mRNA.

Concretizes is not the right relation here, I believe. "Generically depends on" does not currently exist in the RO. I have raised this issue on the RO but received no response. It should be there. Consult Arp et. al. for the definition on p. 105.

@balhoff
Copy link
Member Author

balhoff commented Jun 22, 2018

Thanks @msinclair2, yes it sounds like it would be best for GO to be able to use MSO directly. In the meantime it might be worth updating our definitions with these (or corrected) patterns. Thanks for the info on 'generically depends on'; is there an inverse that could go from the independent continuant to the generically dependent continuant?

@msinclair2
Copy link

Yes @balhoff, the inverse would be "generic bearer of". I've been trying to wake up @cmungall several times (nudge nudge) to get these into the RO. I'm not making them up, they are part of BFO. In the interim we have simply created this relation as part of the refactored SO.

@balhoff please look at our MSO_reasoned.owl. And consider actively participating. We need the input of someone who would actually use the new ontologies in logical definitions. One of the main goals of this project was to get SO out of its logical silo, the existence of which you have discovered in this issue.

@mikebada
Copy link

mikebada commented Jun 23, 2018 via email

@mikebada
Copy link

mikebada commented Jun 23, 2018 via email

@cmungall
Copy link
Member

cmungall commented Jun 23, 2018 via email

@cmungall
Copy link
Member

cmungall commented Jun 23, 2018 via email

@msinclair2
Copy link

msinclair2 commented Jun 23, 2018

Mike, I think if Jim would like to bypass the MSO as it currently is, he should just use:

CHEBI:messenger RNA == generic bearer of some SO:mRNA

as soon as 'generic bearer of' gets added to the RO. IMO concretizes should not be used as a workaround for generic dependence per se. The main issue was not having generic dependence and its inverse in the RO. As soon as I learn how to make pull requests I will make one for this for the RO.

@balhoff
Copy link
Member Author

balhoff commented Jun 25, 2018

@msinclair2 right, if we can avoid specifying the intermediate specifically dependent continuant, that would be preferred I think.

@msinclair2
Copy link

msinclair2 commented Jun 25, 2018

@cmungall, I created pull request #233 to add generically depends on and inverse.

@msinclair2
Copy link

msinclair2 commented Aug 30, 2018

@balhoff There is now a shortcut relation called "is carrier of" (see oborel/obo-relations#233 (comment)) incorporated into RO to fulfill the role you initially requested above.

@ukemi
Copy link
Contributor

ukemi commented Mar 4, 2019

@balhoff, I thought this one was fixed. Should we close it?

@balhoff
Copy link
Member Author

balhoff commented Mar 4, 2019

I wouldn't call it fixed, but we alleviated the problem by not pulling in the disjointness axioms from OBI. Since the plan with regard to MSO and SO is being actively discussed elsewhere, I guess we can close this and revisit once MSO is officially released.

@balhoff balhoff closed this as completed Mar 4, 2019
@cmungall
Copy link
Member

cmungall commented Mar 4, 2019 via email

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