SolrCommandRunner should skip models that are unsatisfiable
Opened this issue · 6 comments
Testing the loader, we now fail with:
2018-01-18 00:14:59,213 INFO (ParserWrapper:82) Finished loading ontology: http://model.geneontology.org/0000000300000001 from: file:/home/bbop/local/src/git/noctua-models/models/0000000300000001.ttl
2018-01-18 00:15:45,210 ERROR (SolrCommandRunner:609) Unsatisfiable: 0000000300000001.ttl == [<http://purl.obolibrary.org/obo/EMAPA_36026>, <http://purl.obolibrary.org/obo/EMAPA_25090>, <http://purl.obolibrary.org/obo/EMAPA_16777>, <http://purl.obolibrary.org/obo/EMAPA_16133>,
...
This is understandable as (IIRC) it is part of a set of mock-up models--I doubt anything sensible would be loaded even it was satisfiable. I think the best course of action would be to continue on with other models if any single model unsatisfiable. I would like to have something in there soon for demo purposes and this would be the fastest way forward.
Hopefully I'll be able to supply a PR soon...
Okay, I'm able to proceed, but I'm now able to see the practical logic behind it as currently all models I've tried have failed so far like:
2018-01-22 13:05:56,437 INFO (ParserWrapper:75) Start loading ontology: file:/home/bbop/local/src/git/noctua-models/models/5459649100000001.ttl from: file:/home/bbop/local/src/git/noctua-models/models/5459649100000001.ttl
2018-01-22 13:05:58,519 INFO (ParserWrapper:82) Finished loading ontology: http://model.geneontology.org/5459649100000001 from: file:/home/bbop/local/src/git/noctua-models/models/5459649100000001.ttl
2018-01-22 13:06:48,213 WARN (SolrCommandRunner:609) Unsatisfiable: 5459649100000001.ttl == [<http://purl.obolibrary.org/obo/EMAPA_36026>, <http://purl.obolibrary.org/obo/EMAPA_25090>, <http://purl.obolibrary.org/obo/EMAPA_16777>, <http://purl.obolibrary.org/obo/EMAPA_16133>, <http://purl.obolibrary.org/obo/EMAPA_17267>, <http://purl.obolibrary.org/obo/EMAPA_18235>, <http://purl.obolibrary.org/obo/EMAPA_17266>, <http://purl.obolibrary.org/obo/EMAPA_17265>, <http://purl.obolibrary.org/obo/EMAPA_17264>, <http://purl.obolibrary.org/obo/EMAPA_16776>, <http://purl.obolibrary.org/obo/EMAPA_16654>, <http://purl.obolibrary.org/obo/EMAPA_16775>, <http://purl.obolibrary.org/obo/EMAPA_17303>, <http://purl.obolibrary.org/obo/EMAPA_18238>, <http://purl.obolibrary.org/obo/EMAPA_19168>, <http://purl.obolibrary.org/obo/EMAPA_17269>, <http://purl.obolibrary.org/obo/EMAPA_17268>, <http://purl.obolibrary.org/obo/EMAPA_18236>, <http://purl.obolibrary.org/obo/EMAPA_36027>, <http://purl.obolibrary.org/obo/EMAPA_17263>, <http://purl.obolibrary.org/obo/EMAPA_18550>, <http://purl.obolibrary.org/obo/EMAPA_18190>, <http://purl.obolibrary.org/obo/EMAPA_18549>, <http://purl.obolibrary.org/obo/EMAPA_17575>, <http://purl.obolibrary.org/obo/EMAPA_17773>, <http://purl.obolibrary.org/obo/EMAPA_18785>, <http://purl.obolibrary.org/obo/EMAPA_17574>, <http://purl.obolibrary.org/obo/EMAPA_17772>, <http://purl.obolibrary.org/obo/EMAPA_18784>, <http://purl.obolibrary.org/obo/EMAPA_17771>, <http://purl.obolibrary.org/obo/EMAPA_18189>, <http://purl.obolibrary.org/obo/EMAPA_17770>, <http://purl.obolibrary.org/obo/EMAPA_18188>, <http://purl.obolibrary.org/obo/EMAPA_18782>, <http://purl.obolibrary.org/obo/EMAPA_17576>, <http://purl.obolibrary.org/obo/EMAPA_19031>, <http://purl.obolibrary.org/obo/EMAPA_19032>, <http://purl.obolibrary.org/obo/EMAPA_18781>, <http://purl.obolibrary.org/obo/EMAPA_18780>, <http://purl.obolibrary.org/obo/EMAPA_35617>, <http://purl.obolibrary.org/obo/EMAPA_19030>, <http://purl.obolibrary.org/obo/EMAPA_17605>, <http://purl.obolibrary.org/obo/EMAPA_17803>, <http://purl.obolibrary.org/obo/EMAPA_17769>, <http://purl.obolibrary.org/obo/EMAPA_17802>, <http://purl.obolibrary.org/obo/EMAPA_17846>, <http://purl.obolibrary.org/obo/EMAPA_17801>, <http://purl.obolibrary.org/obo/EMAPA_16678>, <http://purl.obolibrary.org/obo/EMAPA_17800>, <http://purl.obolibrary.org/obo/EMAPA_18218>, <http://purl.obolibrary.org/obo/EMAPA_18779>, <http://purl.obolibrary.org/obo/EMAPA_16915>, <http://purl.obolibrary.org/obo/EMAPA_16914>, <http://purl.obolibrary.org/obo/EMAPA_17607>, <http://purl.obolibrary.org/obo/EMAPA_17606>, <http://purl.obolibrary.org/obo/EMAPA_19029>, <http://purl.obolibrary.org/obo/EMAPA_17166>, <http://purl.obolibrary.org/obo/EMAPA_16033>, <http://purl.obolibrary.org/obo/EMAPA_18217>, <http://purl.obolibrary.org/obo/EMAPA_16479>, <http://purl.obolibrary.org/obo/EMAPA_18216>, <http://purl.obolibrary.org/obo/EMAPA_35555>, <http://purl.obolibrary.org/obo/EMAPA_17837>, <http://purl.obolibrary.org/obo/EMAPA_16589>, <http://purl.obolibrary.org/obo/EMAPA_17799>, <http://purl.obolibrary.org/obo/EMAPA_16588>, <http://purl.obolibrary.org/obo/EMAPA_17798>, <http://purl.obolibrary.org/obo/EMAPA_17797>, <http://purl.obolibrary.org/obo/EMAPA_35488>, <http://purl.obolibrary.org/obo/EMAPA_17796>, <http://purl.obolibrary.org/obo/EMAPA_35489>, <http://purl.obolibrary.org/obo/GO_0055036>]
tagging @cmungall
It should be safe to load incoherent consistent models. We should never use the reasoner with inconsistent models
It looks like the only unsatisfiable GO class is virion membrane. This is pretty weird and we should investigate, I assume it's old+new axioms superimposed.
All the rest are EMAPAs, this should only affect MGI annotations that reference these
@ukemi - this is another challenge of allowing EMAPA plus Uberon, it's another thing that can become inconsistent. Uberon has a lot of strict axioms that may be vioated by the EMAPA subclasses. In future I'd like to use uberon for all metazoa in Noctua, and map to ssAOs after the fact
- I am sorry but I just get to know that I am assigned to this issue. It seems that the codes are already updated to continue loading if the ontology is inconsistent, but please let me know if there is anything I can do about this issue. Thank you.