Changes

Queries to Pharmacoracle are written in the [https://www.w3.org/TR/owl2-manchester-syntax/ Manchester syntax] in the same way as for the [https://protegewiki.stanford.edu/wiki/DLQueryTab DL Query Tab] of [https://protege.stanford.edu/ Stanford's desktop Protégé]. An advantage of this approach is that the queries it replaces the need of a separate rules engine (rules are to some extent built into the OWL semantics). A disadvantage is that the performance in a production environment may be suboptimal (slow). I believe that the standard way to use OWL is to make a triplet store database (RDF database, e.g. JENA) based on the OWL ontology. The rules can then be written as SPARQL queries to this database. It is possible that there are more lessons to be learned from the PGx clinical decision support [https://bioportal.bioontology.org/ontologies/GENE-CDS ontology of Mathias Samwald], which is at the core of the [https://doi.org/10.1371/journal.pone.0093769 An Ontology-Based, Mobile-Optimized System for Pharmacogenomic Decision Support at the Point-of-Care] of the [http://upgx.eu UPGx] project. They use the [http://trowl.org/ TrOWL reasoner] instead of the [http://www.hermit-reasoner.com/ HermIT] reasoner that is at the core of Pharmacoracle.

The Pharmacoracle infrastructure is written in Python. But the [http://owlcs.github.io/owlapi/ OWLAPI] is mainly JAVA technology, and making the Pharmacoracle totally JAVA, might speed up things. A link between OWL and Python is provided by [http://www.lesfleursdunormal.fr/static/_downloads/article_owlready_aim_2017.pdf Jean Baptiste Lamy's Owlready2], which we use to translate PharmGKB's JSON-LD to OWL, but it seems that for the Pharmacoracle the OWLAPI should be is run separately.