I've always been a fan of describing OWL in terms of rules. When introducing a someone to a new technology, it is nice to be able to describe it simply (a lesson that facebook taught us again recently ). And while it is a bit of a white lie to say that OWL is defined just by a set of rules, it makes it very easy to explain what something in OWL (or RDFS) means, by stating a rule that it follows.

I've actually been using a rule-based definition of OWL for years now, starting back at Intellidimension years ago, and then using OWLIM, and nowadays SPIN. All of these technologies have been 'approximating' OWL for years using variations of Datalog technology - implementing OWL as a set of rules.

While OWL 2's creation of three profiles and a subset hardly counts as keeping the standard simple, I have to say I appreciate the legitimacy that the OWL 2 RL profile has given to a practice that many of us (more than just the ones I have listed) have been doing for years now - of using rule-based systems to process OWL. And the RIF folks have even done us the favor of writing out just what rules OWL 2 RL is made of.

One of the things I have always liked about this approach is the flexibility it gives the system builder in trading off performance vs. expressiveness in the modeling language. You don't need someValuesFrom restrictions? Fine - take those rules out, and speed up the system. I've taken systems from intractable 20-minute response times down to almost instant by fine-tuning the rule system, while still maintaining the same semantics - because my model didn't use the discarded rules.

But today I want to talk about another advantage of this approach - that you can extend your model semantics as well. Suppose there is something in OWL-Full that you want to use, but it doesn't appear in the OWL 2 RL list of rules? What can you do about it? You could switch approaches, and use another style of reasoner, but then you lose the advantage of being able to tune your rule base. Another approach is to encode just the extensions that you want in rules.

Let's take a simple example of this, using SPIN as our rule language. You can follow along yourself if you like - all you need is the Free Edition of TopBraid Composer.

OWL-Full allows something called Data Range Expressions, in which you can define a range to be a set of values. A simple example of this is the notion of Adult, that is a person who has an age greater or equal to 21. An example of a model with this definition can be found at http://www.workingontologist.org/Examples/adult.rdf.

You can import this file into TopBraid Composer by right-clicking on the TopBraid project, selecting "Import RDF or OWL File from the Web" and pasting in the URL of the model, http://www.workingontologist.org/Examples/adult.rdf (see first figure).





Open the file adult.rdf by double-clicking, then expand owl:Thing to see the ontology. Click on "Adult" to see its definition - a Person who hasAge only from values greater or equal to 21 (see second figure).





Notice that there are also three instances of the class Person - with ages 23, 18 and 45. Evidently, two of these are adults, and one is not.





Now we run SPIN inferences (by pressing the button), and we see that indeed just the people of appropriate age are classified as Adults.





How did this work?

SPIN works by expressing the rules for OWL in SPARQL. Thanks to the RIF effort, mentioned above, we at TopQuadrant were able to write out all the OWL 2 RL rules in SPIN (since SPARQL has the same expressive power as RIF). This example simply imported these rules from http://topbraid.org/spin/owlrl-all. The SPIN inferencer finds these rules, and executes them when you press the button. We can see one of these rules in the following figure - it is a familiar rule, telling us how rdfs:subPropertyOf works.





But that doesn't explain the whole thing - if you know OWL 2 RL well, you know that DataRange Expressions are not part of the OWL 2 RL profile. There are good technical reasons why it was left out, but that doesn't keep us from wanting to do these inferences. So we express them in SPARQL and add them in to our rule set for the SPIN inferencer to work on. One such rule is shown in the next figure;



most of the rule matches the RDF rendition of the OWL data restriction. It matches restrictions of xsd:integer, where all the values come from the set defined by minexclusive for some value (in our case, 21). When all these things match, then we assert that the instance is a member of the restriction.

So in the case of :Person_1 who is 23 years old, the property :hasAge matches the variable ?datatypeproperty, and 21 matches the variable ?mval, while the actual age 23 matches the variable ?val. Since 23 > 21, ?val > ?mval, and the rule matches. Hence, :Person_1 is a member of the restriction, and by the rest of the rules from OWL-RL, is an :Adult.

This approach to OWL gives a lot of control to the modeler; they can use standard models (like the OWL 2 RL model we used here), but they can also augment this reasoning with new rules that do just as much inferencing as is needed for the application. These new rules can be consistent with the standard OWL-Full rules, or they could even be domain-specific business rules. In any case, the power lies in the hands of the modeler. In the particular case of SPIN, we have the added advantage that the modeler can write these rules in the standard SPARQL language.