Thinking Clearly .

Following Monday’s announcement of the release of OwlSight .50, we’re pleased to announce another update to OwlSight, version .51. This is a minor bug fix release and no new functionality was added. Thanks to those users who took the time to report issues:

• URL escaping of parameters passed into OwlSight
• Rendering of datatype values for Individuals has been fixed
• If an error occurs while generating an explanation, control is properly returned to the main application window.

If you are interested in learning more about OwlSight, please head over to the OwlSight page on owldl.com.

What could possibly be tricky about DL Safe SWRL rules? Well, the fact that I have to write out “DL Safe SWRL Rules” rather than merely “DL Safe Rules” or “SWRL Rules” should be some sort of indicator.

Recall that (arbitrary) SWRL rules act as a very expressive sort of class (or property, or class ‘n’ property, or…) axiom, the DL Safety restriction acts (most directly) on named individuals only. The restriction to named individuals is common to (most) databases and, in some ways, to Prolog and many rule languages as well.

(Sometimes, in query contexts, you’ll hear the term “active domain”. So, “domain”: the set of individuals we are talking about. “Active” I’m not so clear on, but I think the intuition is that it’s the part of the domain that you’ve directly touched and are working with by naming those individuals directly. Remember that in OWL it’s easy to describe things for which you have no name. Existential/someValuesOf restrictions are the obvious case. I can say that you have a parent without knowing, without knowing at all, who that parent is. I can say that you have a parent who is a doctor without knowing if that parent is your mom, your other mom, your dad, your step-dad, etc. That’s what makes arbitrary SWRL rules so powerful, yet difficult to work with: they have to consider all these possibilities (and more!). DL Safe SWRL rules merely need to consider the parents we’ve actually named.)

However, this is only one point of similarity. There are lots of ways that even DL Safe SWRL rules retain their SWRLiness…so one needs to be careful not to leap from, “Oh, DL Safe SWRL rules are more like Datalog rules because their variables range over the active domain alone!” to “So, I can slap a Datalog engine in front of my OWL reasoner and everything is hunky dory!”

No. This just isn’t true. There are cases where a full fledged OWL reasoner will give the same answers (for a particular class of answers) as a Datalog engine given the same input (e.g., a certain OWL KB and a bunch of DL Safe SWRL rules). But, as we saw, a SWRL KB with the rules interpreted as DL Safe will produce the same answers, for a certain class of answers as that SWRL KB with the rules treated generally. The relations between the formalisms (and their associated reasoner behavior) is not always obvious. Just off the top of my head, I’d say that as long as you don’t use any funky features such as negation as failure most more or less naive combinations of a rule engine with a DL reasoner to process DL Safe SWRL rules should be sound (i.e., won’t give you wrong answers) but not complete (i.e., will miss answers). (Don’t hold me to this!)

Take a simple example, ever so lightly adapted from the original DL Safe rule paper:

:Child (x) :- :GoodChild(x).
:Child (x) :- :BadChild(x).
	
:Oedipus rdf:type [a owl:Class;
        owl:unionOf (:BadChild, :GoodChild)].

(We’ll presume both rules are interpreted with the DL Safety restriction.)

(Ok, I’m not even pretending to make these directly usable anymore. It’s so much work! It really shouldn’t be the case that standardization makes building tutorials like this a slit-your-wrists matter. However, there is an SWRL encoding in RDF/XML of (a slightly modified version of) table 3 of the paper, which includes the Oedipus example.)

Question: Is Oedipus a child or not?

Let’s ask Pellet:

   > ./pellet.sh -if http://owldl.com/ontologies/dl-safe.owl -r -c TREE -s OFF
    Input file: http://owldl.com/ontologies/dl-safe.owl
    Consistent: Yes
    Time: 2050 ms (Loading: 1456 Consistency: 82 Classification: 32 Realization: 480 )
    Classification:
     owl:Thing - (dl-safe:Remus)
        dl-safe:BadChild - (dl-safe:Cain)
        dl-safe:Child - (dl-safe:Oedipus, dl-safe:Cain)
        dl-safe:GoodChild
        dl-safe:Grandchild
           dl-safe:Person - (dl-safe:Abel, dl-safe:Adam, dl-safe:Cain, dl-safe:Romulus)

Pellet says answer is “yes”, even though we don’t know whether Oedipus is a good child or a bad child…we just know that he’s one or the other. And that’s exactly right. A Prologgy engine won’t show that. For example, you can try this rendition in a Prolog in Javascript implementation:

    % Below this line to the next percent sign goes in the top box.
    child(X) :- goodChild(X).
    child(X) :- badChild(X).
    rdfType(oedipus, unionOf([goodChild, badChild]).
    goodChild(bijan).
    % This goes into the query box
    child(X).
    % Hit "Run Query" and the result will include the following line mentioning bijan but no binding for oedipus
    X = bijan

Now, the rule engine person might chime in: “Ok, but you’re missing something…the rules that make sense out of the OWL part!” At this point, I heave a big ole sigh and say, “Not going to happen.” At least, not naively. You could go the Boris/KAON2 route in which case you translated the ontology part into potentially quite a few rules. Unless you are in one of the specific tractable fragments like HornSHIQ or DLP which have a fairly close correspondence between OWL Axioms and Rules, you aren’t going to get anything readable out of it. Implementing something like KAON2 is a comparable effort to implementing something like Pellet. You aren’t going to pop a simple axiomatization of the OWL vocabulary into a rules engine and get anything useful.

There is no magic pixie make-your-life-easy-by-rules dust. Sorry.

(This doesn’t mean standard rule engines aren’t useful, by any stretch of the imagination. A lot of the “best” ontologies fit into Horn-fragments of OWL or mostly into Horn-fragments of OWL which means that rule tech can be fairly straightforwardly applied. I’m not engaged in advocacy at the moment, but trying to raise the level of clarity. Decisions made for bad reasons are often bad!

Similarly, there are things you might be able to do to massage this particular example. But working from ad hoc examples is a pretty bad way to proceed (at least for completeness and correctness; for optimizations it’s a little more justifiable).)

Another perhaps tricky bit is contraposition. You can flip conditionals around if you have negation available. For example, consider the sentences:

      If Bijan has finished the SWRL series, then he is working another series.
      If he is NOT working on another series, then Bijan has NOT finished the SWRL series.

In many rule systems, contraposition doesn’t really hold because you have no (classical) negation. But SWRL rules (including DL Safe ones) are standard first order conditionals.

A simple way to play with this is to make use of the correspondence between SWRL and OWL axioms. Basically, you can convert any OWL axiom to a SWRL rule, though DL Safety will restrict the meaning a bit.

Ok, this part of the series has been sitting in my queue for over a week. I just don’t have the time (classes starting) and energy (arthritis flare) to work up these examples. It’s pretty easy to take any arbitrary OWL axiom and SWRLize it and it’d be really great if someone would do this for some existing ontology so that we’d have some examples. Even better would be a little script that did this :) (XSLT on OWL 1.1 XML format should work easily enough.) I imagine this blog series will inform the Safe Rules OWLED task force, so further examples or tools for playing with DL Safe SWRL rules are welcome. I think the next post will be about how distinguished and undistinguished variables in query languages like SPARQL relate to the DL Safety restriction. Then a bit about syntax. Then maybe a bit about extensions and built-ins. That probably completes the series :) Oh maybe one about working with SWRL using a first order logic reasoner… And maybe one about implementation… and fragments… No. :)

In the previous post, I gave a hint at the enormous power of (arbitrary) SWRL rules by showing how they can be used (directly and fairly easily) define various built in OWL constructs. SWRL faces the standard tradeoff for expressivity: loss of efficiency. SWRL is undecidable, that is, there is no algorithm that can, in finite time, compute the whether (for example) an axiom is entailed by a SWRL knowledge base. It is, in fact, semi-decidable—if an axiom is entailed, then there is an algorithm that can show that; but if an axiom is not entailed, it’s possible to “go into an infinite loop”, i.e., not to terminate.

In some future post I’ll explain exactly why, how, and when I think decidability matters, but for the moment, let’s presume that it is a desirable property. Also, we should remember that a critical goal of SWRL is to augment OWL, so we should expect serious users of OWL (e.g., people building large OWL ontologies) to want to use these rules and want to use them in conjunction with a reasoner in their existing ontologies. Thus, it would be good if we could add rule support as an extension of existing reasoners (e.g., Pellet!) and get workable performance.

DL Safety is a simple idea which is implicit in many rule systems (especially those with a database or Prolog connection) and has been used in other contexts to regain decidability: Variables in DL Safe rules bind only to explicitly named individuals in your ontology. Adding this restriction is sufficient to make SWRL rules decidable.

What does this restriction really mean? One way of thinking about it is that it shifts SWRL rules from being a kind of super powerful TBox and RBox (i.e., class and property) axiom to them being a (slightly odd) sort of data manipulation (i.e., ABox) axiom.

Consider the SWRL rule for the ancestor relation (discussed in part 1):

      ancestorOf(?X, ?Z) :- ancestorOf(?X, ?Y), ancestorOf(?Y, ?Z).

As you might recall, this is equivalent to declaring that ancestorOf is transitive property. If we impose the DL Safety restriction on it, then that is no longer true (though they coincidence in some cases; transitive properties are a strict expressive superset of the DL Safe version). Let’s consider a case where the DL Safe and non-DL Safe version of this rule diverge.

Consider a simple chain of ancestors:

    :mary :ancestorOf :sheevah.
    :sheevah :ancestorOf :akane.
    :akane a :AncestorOfACreep.

(Yes, I’ve switched to Turtle syntax because, well, either I’m perverse or the tool chain is perverse. My perversity may lie in using this freaking toolchain!)

We can ask for the ancestors of :akane by making a class that uses nominals:

    :AncestorOfAkane  a owl:Class;
        owl:equivalentClass [a owl:Restriction;
            owl:onProperty :ancestorOf;
            owl:hasValue :akane].

With nothing else in the ontology, the only instance of :AncestorOfAkane will be :sheevah, i.e., the direct ancestor. If we add a owl:TransitiveProperty assertion, or the DL Safe rule above, then :mary will also be found to be an instance of this class. So far so good. But what if we know that :akane has a descendent who is a creep, and we want to know who else is an ancestor of a creep. (Yeah, so I hate Akane’s descendants. Sue me. They’re creepy!)

    :akane a :AncestorOfACreep.
    :Creep a owl:Class.  

    :AncestorOfACreep a owl:Class;
        owl:equivalentClass [a owl:Restriction;
            owl:onProperty :ancestorOf;
            owl:someValuesFrom :Creep].

If we are reasoning with the DL Safe rule, then only :akane is an instance of :AncestorOfACreep, because the DL Safe rule does not propagate values to unnamed/unknown entities, and we don’t know any of :akane’s decendents. We only know that she has at least one creepy one.

If we’ve made :ancestorOf transitive (or the rule is interpreted as unrestricted, i.e., not DL Safe), then not only do :mary and :sheevah become instances of :AncestorOfACreep but so do all possible instances of :AncestorOfAkane. So we have a new subsumption relation, as you can see in this screenshot of OWLSight:

Clicking on the “Why?” button gives us the axioms sufficient to produce the subsumption:

Since Pellet can process DL Safe rules (and backs OWLSight), we can browse the DL Safe rule version of this ontology:

As we can see, the only instance of :AncestorOfACreep is :akane, however, all the expected members of :AncestorOfAkane appear:

Unfortunately, there is a bug in the explanation finder which, for some reason, thinks that :ancestorOf is transitive: doesn’t understand that SWRL rules are axioms (more on this in a future post):

You can also play with these from the Pellet command line. I have both versions of the ontology available both in Turtle and in RDF/XML (courtesy of Joshua Tabuer’s Validator/Converter—which, alas, is a bit finicky and doesn’t pretty print RDF/XML nicely at all; but hey, it worked). I use the following options:

     ./pellet.sh -if http://www.cs.man.ac.uk/~bparsia/2007/examples/dl-safe-ancestor.txt  -c TREE -r -s off -ifmt N3 

If you use one of the .owl files, you can leave off the -ifmt. You might try commenting out the transitivity axiom to see what things look like with neither rule. When using SWRL syntax, Pellet will throw up a lot of warnings: Just Ignore Them. UPDATE: Thanks to Mike Smith (in comments) for pointing out that -s off will turn off the warnings.

I’ve not tested these with KAON2, which would have some problems with the nominal I’m using instead of a query. You could pretty easily make some SPARQL queries that exhibit the difference.

I used transitivity because it’s a fairly obvious sort of rule and the unrestricted SWRL version can be paraphrased can be in plain OWL. It’s important to note that unrestricted SWRL can say a hell of a lot more than this!

Still to come: DL Safe SWRL rules vs. other sorts of rules; some SPARQL connections; SWRL and SROIQ; builtins; implementation issues; and who knows?

By my rather hasty coding, 9 OWLED 2007 papers mentioned SWRL (or DL-Safe rules) as a need, often a critical need. There’s 1 that goes for DLP, and 5 for SPARQL over OWL (which is closely related to rule extensions). There was also a lively panel devoted to rules and queries, and, last but not least, there is an OWLED task force developing a report on DL Safe rules (and one developing a spec for SPARQL/OWL).

So, “we” want some sort of rules, and all the benefits they bring. SWRL is something of a de facto standard for extending OWL with rules with DL Safe SWRL rules (as I shall canonically call them) being the most commonly implemented varient.

However, it’s also clear that most people aren’t too clear on exactly what the difference is between arbitrary SWRL and DL Safe SWRL (remember that DL Safe SWRL is a restricted version of SWRL). It’s very clear that most don’t understand the consequences for modeling (and definitely not for implementation). It’s a complex topic, so I’m going to have a series of posts. Some of the material overlaps with the part I wrote of a chapter for the new edition of the Ontology Handbook on “Rules and Ontologies”.

So, first, what is SWRL? Syntactically, SWRL is an extension to OWL with a new sort of conditional (i.e., if-then statements). OWL already has several sorts of conditional, e.g., (I’m using OWL 1.1’s functional syntax):

    SubClassOf(Person, ObjectUnionOf(Human IntelligentComputer)) 
    SubObjectPropertyOf(parentOf, ancestorOf) 

The first line says that if you are a Person, then you are either a Human or an IntelligentComputer, and the second says that if you have the parent relation then you have the ancestor relation.

However, for a variety of reasons, OWL conditionals are very constrained and specialized. For example, the SubClassOf conditional can only have class expressions in the “if” or the “then” parts. For example, you can’t mix classes and properties (directly) as in:

    SubClassOf(parentOf, ObjectUnionOf(Human IntelligentComputer)) 

That’s just ill formed. These specialized conditionals have several advantages: They allow for variable free syntax; they are more intention revealing; and they help enforce restrictions which make OWL easier to process (e.g., by making it decidable).

However, there is a price: expressivity. This is especially obvious when it comes to the property conditionals. In OWL 1.0, they were restricted to relations between single named properties. Hence the famous “you can’t define uncleOf in OWL” issue.

SWRL generalized OWL conditionals in two ways:

1. It allows for arbitrary patterns of variables


2. It allows for fairly free mixing of expressions (e.g., property and class expressions)

SWRL is like OWL (and unlike many traditional rule languages, e.g., Prolog or Datalog) in that it embraces the open world assumption. There is no negation as failure, among other things, in SWRL. Thus, if anyone says that they “translate” SWRL Rules to Prolog, be wary. This might be a sensible thing to do, but it’s highly unlikely to respect SWRL semantics.

All these facts conspire to make SWRL very expressive. There are lots of built in features of OWL that become redundant in SWRL. Consider transitivity. While OWL has a specific construct to express that a property is transitive (e.g., TransitiveObjectProperty(ancesterOf)), you can encode that directly with SWRL rule:

      ancestorOf(?X, ?Z) :- ancestorOf(?X, ?Y), ancestorOf(?Y, ?Z). 

(I’m using a Prolog like style for the syntax.)

This rule means exactly the same thing as the OWL construct. (Note: Some people think that the rule is “more transparent”, but I think it’s much worse than the simpler OWL construct for a number of reasons, mostly having to do with readability.)

So, (full) SWRL rules are really a kind of OWL axiom. They can make for more expressive property and class axioms (for example, you can’t make classes whose members depend on certain sorts of cyclic structure in OWL, but easily do so with SWRL rules).

In the next post, I’ll explore the DL Safety restriction.

Yay! Hurray! My first snow as a resident of the UK!

(Though not my first snow in the UK.)

Today we had hail, rain, bright sun, and crazy snow….very nifty. And last week we had the “oh wow” winds. As in, “Oh wow, I have to downshift in order to turn the pedals on my bicycle.” Now, it is, of course, a testimony to my wimpdom that I could be stopped dead by a little, ok, a lot, of very fast wind. But still!

On the SPARQL front, I am participating in Yet Another SPARQL Tutorial, but this time it’s a full day and seems rather sensible. Hosted by ESWC 2007, and co-presented with a slew of good folks (Axel Polleres organized it, though some of the other folks were putting together submissions as well). I think it’ll be nice with lots of interesting information.

Coincidentally, Axel has put together a worked out SPARQL Rules proposal. This isn’t too shocking, especially given the presence of CONSTRUCT, but it’s very nice to have it worked out. Folk wisdom is ok, but details drive the devil away. It’s an interesting thing to experiment with.

My bit will be, as one might expect, SPARQL over more expressive entailment regimes (through OWL), plus, I hope, a bit about different ways of interpreting results.

On a slightly related note, Michael Kay discovers some value in XQueryX (the XML syntax for XQuery), albeit with the amusing twist that he finds manipulating XQueryX to be the proper domain of XSLT.

Kendall and I went a good chunk of the way to a SPARQLX (i.e., SPARQL XML format). Perhaps it’s time to revive it. The advantages seem to be the same: XSLT transformations to various legacy formats, the ability to indicate in advance (by a schema) what query feature you do or don’t accept (and thus better WSDL typing), better embedding in other XML formats, etc.