Open kshefchek opened 5 years ago
Note that the actual equivalentClass axioms are obscured by the scigraph clique merge, I can track them down if it will be useful.
Okay, after spamming you all in emails, here the short answer. This issue is caused by the following two axioms:
ReflexiveProperty('derives from') (http://purl.obolibrary.org/obo/RO_0001000)
Domain('derives from', 'independent continuant')
The first axiom means that everything derives from itself. The second axiom means everything that derives from something is an independent continuant. So: Everything is an independent continuant (and by extension an entity).
Now to solve this, you have as far as I can see this a bunch of options:
Is there even a proper release process for monarch.owl or do you just ingest the whole thing with the imports as they are at that time (i.e. no QC at all)?
Let me know if I can be of further help!
The following is a comment for those interested in the usage of the 'derives from' relation, and can be ignored by anyone else. This is also a reminder that redefinig the semantics of RO relations in ontologies downstream (such as giving them additional characteristics are restricting the domain) reduces re-usability and compatibiliy with other ontologies. This is a breakdown were 'derives from' is used across monarch.owl.
InverseObjectProperties(<http://purl.obolibrary.org/obo/RO_0001000> <http://purl.obolibrary.org/obo/RO_0001001>)
The inverse assertion of 'derives from' is asserted in
'derives from' is transitive:
'derives from' is reflexive (see above comments):
Domain & Range of 'derives from' is independent continuant (see above comments):
'derives from' used in definitions:
'derives from' in existential restrictions/subclasses:
'derives from' in a property chain
SubObjectPropertyOf(ObjectPropertyChain( <http://purl.obolibrary.org/obo/BFO_0000051> <http://purl.obolibrary.org/obo/RO_0001000> ) <http://purl.obolibrary.org/obo/FOODON_00002420>)
(which I recommend): Get rid of the reflexivity at the source. The culprit comes from the MONDO import FOODON (http://purl.obolibrary.org/obo/mondo/imports/foodon_import.owl). It is possible FOODON needs this for driving inference, as 'derived from' is used in one of their property chains.
There should be a general policy + SOPs on importing RO relations and their axiomatization from RO. It's OK to extend RO with new relations in your own ontology (although we should encourage everyone to extend RO instead). It is not OK to add axiomatization to RO relations that changes their meaning. It would be really good to have a test for this. From this issue it looks like Monarch needs a test like this in place ASAP, perhaps making updating a source ontology dependent on compliance.
The upcoming RO meeting and the related doc and spring-cleaning of RO is a good opportunity to formulate and document a clear policy on this.
Thanks @matentzn and @dosumis! Out of the four options proposed in https://github.com/monarch-initiative/monarch-ontology/issues/16#issuecomment-425839707 what do you think is best?
I'll take the reflexivity property off of 'derives from' in FoodOn; we had been using it in a property chain but that is now dropped. That may at least solve problem short term.
@kshefchek Can you try running the pipeline and see whether that already fixes the issue? Then we dont need any complicated additional scripts :) @ddooley Thanks so much for dealing with this so fast!
I'm still seeing the cycle, @nicolevasilevsky would we need to mint a new mondo release to see these changes?
@kshefchek I am not sure, sorry! @cmungall can hopefully answer your question when he is back.
@kshefchek pm in Gitter, we will hack it.
On 11 Oct 2018, at 21:16, Kent Shefchek notifications@github.com wrote:
I'm still seeing the cycle, @nicolevasilevsky https://github.com/nicolevasilevsky would we need to mint a new mondo release to see these changes?
Yes (unless Mondo is on an automated release cycle like GO).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/monarch-initiative/monarch-ontology/issues/16#issuecomment-429102920, or mute the thread https://github.com/notifications/unsubscribe-auth/AAG4xw1oGINasz-c7UE8mia20RPS7ii2ks5uj6cdgaJpZM4W8_Ah.
(Since it is too risky to do this without @cmungall I send Kent a hack he can insert in the pre-processing pipeline that solves the issue temporarily, until Chris gets around to mint a new release)
I suggest a multi-pronged attack
OBO implements a policy, as you suggest. We may want to prevent axiom injection in general, but there are arguably legit uses, such as Uberon injecting equivalence axioms for ssAOs (but note we only do this in bridge files, not the main release, and certainly not in -base).
Add a check to ROBOT report to warn of any accidental axiom injections. Good players would heed this, and would not release any axiom injections. The check may have to be ad-hoc and include some assumptions about ID spaces.
OBO provides a pan-OBO SPARQL check to report all cases of axiom injection, and the OBO ops acts on this
Projects like Monarch implement highly defensive measures for ontology imports, making the defensive assumption that 1-3 fail and the world is out to poison it. Some kind of de-inject command in either ROBOT or scowl would help.
On 1 Oct 2018, at 6:29, David Osumi-Sutherland wrote:
(which I recommend): Get rid of the reflexivity at the source. The culprit comes from the MONDO import FOODON (http://purl.obolibrary.org/obo/mondo/imports/foodon_import.owl). It is possible FOODON needs this for driving inference, as 'derived from' is used in one of their property chains.
There should be a general policy + SOPs on importing RO relations and their axiomatization from RO. It's OK to extend RO with new relations in your own ontology (although we should encourage everyone to extend RO instead). It is not OK to add axiomatization to RO relations that changes their meaning. It would be really good to have a test for this. From this issue it looks like Monarch needs a test like this in place ASAP, perhaps making updating a source ontology dependent on compliance.
The upcoming RO meeting and the related doc and spring-cleaning of RO is a good opportunity to formulate and document a clear policy on this.
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/monarch-initiative/monarch-ontology/issues/16#issuecomment-425860527
In the latest load of monarch.owl entity, continuant, thing, and ind. continuant are linked by equivalence axioms.
![bfo-clique](https://user-images.githubusercontent.com/1467299/46159057-3cdcee80-c234-11e8-8a95-85808e135ace.png)