-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add support for rule-based reasoners #21
Comments
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
We could also think about simplifying our ontology so that it is in the OWL RL profile, such as by replacing 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.The text was updated successfully, but these errors were encountered: