Closed gaurav closed 6 years ago
Maybe I'm confused but doesn't this need to be an issue for the Phyloreferencing Ontology (because the expressivity profile of that ontology will determine which reasoners can and cannot be used).
If I understand OWL RL correctly, we'll need to implement our own rules to support terms like propertyChainAxiom
(which we need to implement has_Sibling
). I think that means we'll need to write our own rules, in which case this would be best implemented in JPhyloRef with the following steps (which I think belongs in this repository):
We could also think about simplifying our ontology so that it is in the OWL RL profile, such as by replacing propertyChainAxiom
with some other terms, which would be an issue for the Phyloref Ontology.
Am I right in thinking that these are our two options, or am I missing something?
No, a standard RL reasoner should read the axioms, not separately stated rules. OWL RL is an OWL expressivity profile, not a separate language or something.
Sounds good! I've filed an issue to support OWL RL in the Phyloref ontology at phyloref/phyloref-ontology#25. I'll close this issue for now as we don't need any additional support for rule-based reasoners in JPhyloRef, but we can open a new one if we run into any issues while setting up an OWL RL profile.
We've previously discussed using rule-based reasoners to speed up reasoning on large phylogenies (see the section A review of our software development plan from our blog post on our first Duke University meeting). This isn't urgent right now, since FaCT++ is fast enough for our immediate needs, but it might be worth thinking about this while planning the integration of new reasoners.
A rule-based reasoner would require rules to be developed for generating the inferences we need in SPARQL/Cypher/SWRL or a custom language. This would then be executed by a rule-based reasoner such as Arachne or HyLAR.
Developing it in within JPhyloRef would allow us to re-use the existing code to identify which queries we need and to test them using the
test
andwebserver
commands. Once it is has been successfully integrated here, we could try to integrate them directly into the Curation Tool, thus removing the dependency on JPhyloRef entirely.