Converting between rule formats

A frustrating issue that arises in rule-based reasoning is the plethora of rule formats. From a syntactic point of view, these formats can range from more or less similar (e.g., SPIN, Apache Jena, SPARQL-related) to wholly different ones (e.g., Datalog). This means that interesting rule engines, which you may want to compare regarding performance, may support different rule formats.

I ran into this issue when looking for a rule engine to implement Clinical Decision Support (CDS) for a mobile patient diary [1]. The heavyweight reasoning would still be deployed on the server side (were Drools was utilized), whereas urgent, time-sensitive reasoning (e.g., in response to new vital signs) would deployed on the mobile client.

Mobile patient diary

Since the mobile patient diary was going to be developed using Apache Cordova, I looked at both Java and JavaScript rule engines. I ported some reasoners manually to the Android platform, including some OWL reasoners (Roberto Yus did the same for a similar project). If you’re interested, all the benchmarked Android reasoners can be found here; regarding JavaScript reasoners, I compared the RDFQuery, RDFStore-JS (outfitted with naive reasoning) and Nools reasoners; benchmark results were reported in the literature [2-4]. In the context of this work, I also worked on optimizing OWL2 RL [4], a partial rule-based axiomatization of OWL2 for ontology reasoning, which I posted about before.

Ideally, I wanted a solution where I only needed to maintain a single ruleset for a given purpose (e.g., for CDS or OWL2 RL reasoning), which could then be converted to any other rule format when needed. I chose SPARQL Construct as the input format since SPARQL is well understood by most Semantic Web / Linked Data developers. Further, the SPARQL Inferencing Notation (SPIN) easily allows storing SPARQL queries together with the domain model.

To support this solution, I developed a simple web service for converting SPARQL Construct rules to Datalog, Apache Jena format and Nools format. Note that the Nools format is very similar to the Drools format – so it may be used to convert to Drools rules as well (given some adjustments). Further, the service can convert RDF data to the Datalog and Nools formats as well.

Note that this conversion may be far from perfect – since I focused solely on the language features that I needed at the time. Also, this is a limited number of formats that were motivated by my needs at the time. So, feel free to contribute to the project!


[1] W. Van Woensel, P.C. Roy, S.R. Abidi, S.S.R. Abidi, A Mobile and Intelligent Patient Diary for Chronic Disease Self-Management, in: Stud Heal. Technol Inf., 2015: pp. 118–122. doi:10.3233/978-1-61499-564-7-118.

[2] Van Woensel, N. Al Haider, P.C. Roy, A.M. Ahmad, S.S.R. Abidi, A comparison of mobile rule engines for reasoning on semantic web based health data, in: Proc. – 2014 IEEE/WIC/ACM Int. Jt. Conf. Web Intell. Intell. Agent Technol. – Work. WI-IAT 2014, 2014. doi:10.1109/WI-IAT.2014.25.

[3] W. Van Woensel, N. Al Haider, A. Ahmad, S.S.R. Abidi, A Cross-Platform Benchmark Framework for Mobile Semantic Web Reasoning Engines, in: Semant. Web — ISWC 2014, 2014: pp. 389–408. doi:10.1007/978-3-319-11964-9_25.

[4] W. Van Woensel, S. S. R. Abidi, Benchmarking Semantic Reasoning on Mobile Platforms: Towards Optimization Using OWL2 RL, in: Semantic Web Journal, Forthcoming (2018).

Creating custom OWL2 RL rulesets

Yes, you may have noticed an abundance (cornucopia?) of OWL2 RL-related posts on this blog. I’ve done some work in this field, and thought it best to split up the work into more manageable chunks.

I’ve found that when working with OWL2 RL,

  • A number of important options for optimization exist;
  • Certain rules involving n-ary lists can be supported in multiple ways.

Given these considerations, wouldn’t it be cool if someone can easily create their own OWL2 RL ruleset, geared towards their particular application scenario (availability of a “stable” ontology; need for full  OWL2 RL conformance; need for n-ary rules)?

I first discuss these considerations below. Next, I talk about a web service that can generate a custom OWL2 RL ruleset accordingly.


Regarding optimization, I’ve proposed 3 selections to create OWL2 RL subsets. You can find a summary below.

In [1], I elaborate on these selections (and their impact on performance) in much more detail.

Equivalent OWL2 RL rule subset

Leaves out logically equivalent rules; replaces a set of specific rules by a single general rule; and may drop rules based on redundancy at the instance level.

Note that this subset focuses in particular on reducing the OWL2 RL ruleset, not necessarily optimizing it for reasoning (e.g., using more general rules has been shown to reduce performance, as shown in [1]).

Purpose and reference-based subsets

Divides rule subsets via their purpose and referenced data, allowing smaller rulesets to be applied in certain runtime scenarios.

OWL2 RL rules perform either inference or consistency-checking (purpose), and refer to instances and schema or only schema elements (reference). Further, rules that will not yield inferences over a particular ontology can be left out as well, by applying a separate pre-processing step (domain-specific).

Importantly, the applicability of this selection depends on the concrete use case, and whether the ontology can be considered relatively stable (i.e., not prone to change).

First, one can create two separate OWL2 RL rulesets, respectively containing rules that (a) refer to instances & schema assertions, and (b) only refer to schema assertions. While ruleset (a) is relevant whenever new instances are added, ruleset (b) is only relevant at initialization time and whenever the ontology changes. A (rather trivial) proof in [1] confirms that this process yields the same inferences as the full OWL2 RL ruleset.

Second, one can create a domain-specific ruleset, leaving out rules that will not yield inferences over a given ontology. Although this selection may yield huge performance improvements, note that it is especially brittle in dynamic settings — aside from ontology updates, even new data patterns may render a rule relevant (e.g., reciprocal subclass-of statements). In case of ontology updates, or new data patterns, the domain-specific ruleset will need to be generated again.

Removal of inefficient rules

This selection leaves out rules with a large performance impact.

Currently, it only leaves out the #eq-ref rule, which infers that each resource is equivalent to itself. This rule generates 3 new triples for each triple with unique resources, resulting in a worst-case 4x increase in dataset size (!).

N-ary rules

So-called ­n-ary rules refer to a finite list of elements. A first subset (L1) of these rules enumerate (i.e., list one by one) restrictions on single list elements. For instance, rule #eq-diff2 flags an ontology inconsistency if two equivalent elements of an owl:AllDifferent construct are found. Rules from the second subset (L2) include restrictions referring to all list elements, and a third ruleset (L3) yields inferences for all list elements . E.g., for (L2), rule #cls-int1 infers that y is an instance of an intersection in case it is typed by each intersection member class; regarding (L3), for any union, rule #scm-uni infers that each member class is a subclass of that union.

To support rulesets (L1) and (L3), two list-membership rules can be added that recursively link each element to preceding list cells, eventually linking the first cell to all list elements. Three possible solutions can be applied for (L3), each with their own advantages and drawbacks. These solutions are summarized here and elaborated in more detail in [1].

Web service

I developed a web service that allows anyone to create their own custom OWL2 RL ruleset, by applying one or more optimizations and/or solutions for n-ary lists. It includes an initial OWL2 RL ruleset as a set of SPARQL Constructs (find it separately here). You can find the project on GitHub!

I previously posted about simple Java and Android projects that utilize an OWL2 RL ruleset for ontology reasoning. To convert the OWL2 RL ruleset into different formats (such as the Apache Jena one), there’s a project for that too.

Just plugin your own custom OWL2 RL ruleset, and feel free to share your results/thoughts in the comments!


[1] W. Van Woensel, S. S. R. Abidi, Benchmarking Semantic Reasoning on Mobile Platforms: Towards Optimization Using OWL2 RL, in: Semantic Web Journal, Forthcoming (2018).

OWL2 RL on Android

AndroJena represents a porting of Apache Jena to the Android platform. Hence, it represents an ideal starting place for working with semantic web data on mobile systems.

To help people to get started with AndroJena, I’ve created separate Android Studio modules for AndroJena, ARQoid and Lucenoid (i.e., ported Android versions of their Jena counterparts). I also created a simple AndroidRules project that includes these modules to perform ontology reasoning, utilizing an OWL2 RL ruleset [1]. Clearly, you can use any other ruleset as well. You can find everything on GitHub!

The project was created to be usable out-of-the-box — just point Android Studio towards the project folder (File > Open…) and select the AndroidRules project. If you run into issues, checkout the README file.

The AndroidRules app loads a small subset of the pizza ontology and infers types for DominosMargheritaPizza.

In another post I describe a project that implements OWL2 RL reasoning using the regular Apache Jena.


[1] W. Van Woensel, S.S.R. Abidi, Benchmarking Semantic Reasoning on Mobile Platforms: Towards Optimization Using OWL2 RL, Semant. Web J. (2018).

OWL2 RL + Apache Jena

In the context of realizing ontology reasoning on resource-constrained platforms [1], I created an OWL2 RL ruleset in SPARQL Construct format. Note that, to support all n-ary rules, the ruleset includes a set of auxiliary rules that, as a side-effect, generate intermediary (meaningless) inferences. If support for these n-ary rules is not required, these rules could be removed (last 9 rules).

You can find this ruleset here, and the accompanying axioms here.

To illustrate how to use Apache Jena and the OWL2 RL ruleset for ontology-based reasoning, I created a simple Java Maven project on GitHub. This could be an efficient alternative for those having performance issues with Jena’s built-in ontology reasoning support; seeing how OWL2 RL is an OWL2 profile that trades expressivity for performance.

(Note that I used my conversion web service to convert the OWL2 RL ruleset into the Apache Jena rule format.)

Check it out and let me know what you think!

Note that another post discusses how OWL2 RL can be utilized for ontology reasoning on the Android platform.


[1] Van Woensel, S.S.R. Abidi, Benchmarking Semantic Reasoning on Mobile Platforms: Towards Optimization Using OWL2 RL, Semant. Web J. (2018).