search

monarch-initiative / monarch-ontology

Top level monarch importer ontology
4 stars 3 forks source link

BFO entity-continuant-thing incorrect equivalence #16

Open kshefchek opened 5 years ago

kshefchek commented 5 years ago

In the latest load of monarch.owl entity, continuant, thing, and ind. continuant are linked by equivalence axioms.
bfo-clique

kshefchek commented 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.

matentzn commented 5 years ago

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:

  1. (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. @cmungall
  2. Add a pipeline step in which the axiom is removed before ingesting or otherwise processing monarch.owl
  3. Add to the monarch.owl build pipeline a file with negative assertions, i.e. axioms that should always be removed before a monarch.owl release is created.
  4. I guess you could get rid of the Domain and Range restrictions in ECO as a kind of quick fix (maybe you should do that anyways, because it puts a strong burden on how other ontologies use the relation).

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!

matentzn commented 5 years ago

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>)
dosumis commented 5 years ago

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

kshefchek commented 5 years ago

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?

ddooley commented 5 years ago

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.

matentzn commented 5 years ago

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

kshefchek commented 5 years ago

I'm still seeing the cycle, @nicolevasilevsky would we need to mint a new mondo release to see these changes?

nicolevasilevsky commented 5 years ago

@kshefchek I am not sure, sorry! @cmungall can hopefully answer your question when he is back.

matentzn commented 5 years ago

@kshefchek pm in Gitter, we will hack it.

dosumis commented 5 years ago

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.

matentzn commented 5 years ago

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

cmungall commented 5 years ago

I suggest a multi-pronged attack

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

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

  3. OBO provides a pan-OBO SPARQL check to report all cases of axiom injection, and the OBO ops acts on this

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