-
Notifications
You must be signed in to change notification settings - Fork 40
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
Comments
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. |
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. |
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. |
not sure when MSO will be ready we need an interim plan.. |
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. |
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? |
This is exactly what we are doing with SO refactored.
These are available in MSO. That's what MSO is.
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. |
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? |
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. |
I agree that I think we can be ready on the order of several months. I think the MSO is in good shape, although right now I’m trying to replace as many of the MSO/SO-specific object properties with RO relations instead. (Speaking of which, Chris, is has_component here to stay in the RO? We had to create some new relations for the exact use case specified in its comment, i.e., for assigning cardinality to has_part assertions, but I think we could use has_component instead.) I think the main tasks left to do are mostly engineering, including automatically generating the SO from the MSO (much of which is finished), generating .obo files, and quality control.
From: Michael Sinclair <notifications@github.com>
Reply-To: geneontology/go-ontology <reply@reply.github.com>
Date: Friday, June 22, 2018 at 12:41 PM
To: geneontology/go-ontology <go-ontology@noreply.github.com>
Cc: "Bada, Mike" <Mike.Bada@ucdenver.edu>, Mention <mention@noreply.github.com>
Subject: Re: [geneontology/go-ontology] go-plus equates ChEBI independent continuants and SO generically dependent continuants (#15894)
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#15894 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AHEa3ZBkokq4tR_lukWVYOI-UPC_VHZTks5t_TpWgaJpZM4UhKO7>.
|
Jim, I think your new axiomatizations are correct if you want to link to SO classes (as generically dependent continuants). If there are efforts already underway at formally linking to SO/MSO classes, we’d be interested in collaborating.
From: Jim Balhoff <notifications@github.com>
Reply-To: geneontology/go-ontology <reply@reply.github.com>
Date: Friday, June 22, 2018 at 2:23 PM
To: geneontology/go-ontology <go-ontology@noreply.github.com>
Cc: "Bada, Mike" <Mike.Bada@ucdenver.edu>, Mention <mention@noreply.github.com>
Subject: Re: [geneontology/go-ontology] go-plus equates ChEBI independent continuants and SO generically dependent continuants (#15894)
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<http://purl.obolibrary.org/obo/CHEBI_33699> == SO:mRNA<http://purl.obolibrary.org/obo/SO_0000234>
to
new: CHEBI:messenger RNA<http://purl.obolibrary.org/obo/CHEBI_33699> == bearer of<http://purl.obolibrary.org/obo/RO_0000053> some (concretizes<http://purl.obolibrary.org/obo/RO_0000059> some SO:mRNA<http://purl.obolibrary.org/obo/SO_0000234>)
and then change a definition for a particular GO term like so:
old: GO:mRNA polyadenylation<http://purl.obolibrary.org/obo/GO_0006378> == GO:RNA polyadenylation<http://purl.obolibrary.org/obo/GO_0043631> and (has output<http://purl.obolibrary.org/obo/RO_0002234> some SO:polyadenylated_mRNA<http://purl.obolibrary.org/obo/SO_0000871>)
to
new: GO:mRNA polyadenylation<http://purl.obolibrary.org/obo/GO_0006378> == GO:RNA polyadenylation<http://purl.obolibrary.org/obo/GO_0043631> and (has output<http://purl.obolibrary.org/obo/RO_0002234> some (bearer of<http://purl.obolibrary.org/obo/RO_0000053> some (concretizes<http://purl.obolibrary.org/obo/RO_0000059> some SO:polyadenylated_mRNA<http://purl.obolibrary.org/obo/SO_0000871>)))
Is this the right way to relate these?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#15894 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AHEa3QlGQctLOIVWNi5HYbNu1e8pSQj1ks5t_VJRgaJpZM4UhKO7>.
|
Ideally we would have no dependencies on any ontologies that were not
available using standard OBO PURLs for classes and the ontology, but we
need the full import closure to be coherent so if hardcoding some
temporary URLs works for us for now...
…On 22 Jun 2018, at 11:41, Michael Sinclair wrote:
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.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#15894 (comment)
|
Yes, 'has component' is the standard way to represent cardinality, it's
used a lot in uberon
having said that our strategy is often to isolate non-EL axioms and
reason on those in the advance
…On 22 Jun 2018, at 18:32, mikebada wrote:
I agree that I think we can be ready on the order of several months.
I think the MSO is in good shape, although right now I’m trying to
replace as many of the MSO/SO-specific object properties with RO
relations instead. (Speaking of which, Chris, is has_component here
to stay in the RO? We had to create some new relations for the exact
use case specified in its comment, i.e., for assigning cardinality to
has_part assertions, but I think we could use has_component instead.)
I think the main tasks left to do are mostly engineering, including
automatically generating the SO from the MSO (much of which is
finished), generating .obo files, and quality control.
From: Michael Sinclair ***@***.***>
Reply-To: geneontology/go-ontology ***@***.***>
Date: Friday, June 22, 2018 at 12:41 PM
To: geneontology/go-ontology ***@***.***>
Cc: "Bada, Mike" ***@***.***>, Mention
***@***.***>
Subject: Re: [geneontology/go-ontology] go-plus equates ChEBI
independent continuants and SO generically dependent continuants
(#15894)
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on
GitHub<#15894 (comment)>,
or mute the
thread<https://github.com/notifications/unsubscribe-auth/AHEa3ZBkokq4tR_lukWVYOI-UPC_VHZTks5t_TpWgaJpZM4UhKO7>.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#15894 (comment)
|
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. |
@msinclair2 right, if we can avoid specifying the intermediate specifically dependent continuant, that would be preferred I think. |
@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. |
@balhoff, I thought this one was fixed. Should we close it? |
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. |
Correct
…On Mon, Mar 4, 2019 at 9:11 AM Jim Balhoff ***@***.***> wrote:
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#15894 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADGOdox8sEV3YTPl5kr5PsffDimguqYks5vTSmZgaJpZM4UhKO7>
.
|
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
SubClassOfCHEBI:ribonucleic acid
and several other related classes. How are these bridges between SO and ChEBI being used?
The text was updated successfully, but these errors were encountered: