Thinking Clearly .

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.

So many workshops and conferences….

Anyway, I’m one of the organizers for SWWS ‘07, so I thought I’d give it a shout out. There is a lot going on in this space, but it still seems to be the case that the common knowledge (and thus unified message) of what’s going on isn’t there. SWWS seems a good place to try to pull that together.

While scalability of the underlying engines (e.g., query engine, parser, reasoner) is important, equally important is scalability of the UI. It would be also really great to get a better handle of what kind of applications face what sorts of scale problems. I guess that Linked Data folks have something to say here.

Going through the OWLED 2007 papers, two quotes about OWL 1.1 jump out at me. The first is from Kent Spackman, of SNOMED fame:

Without a solid DL foundation, the Semantic Web would have remained largely irrelevant to health care terminology standardization. Even so, the initial version of OWL was developed without taking adequate account of features of DL that had already been used in both the GALEN [6] and SNOMED [7] efforts. The development of OWL 1.1 eliminated one of the most significant barriers to use of OWL for SNOMED, since it permits the identification of tractable sublanguages capable of handling the size and complexity of SNOMED [8]. Although adding property chain inclusion axioms was reportedly the most difficult step in developing OWL 1.1 [9], this was essential. Without it, adoption of OWL by the SNOMED community would have required awkward workarounds with their attendant complications and complexities – effectively killing movement in that direction. With it, we have a clear path to using OWL 1.1 for further development and integration with other biomedical ontologies. [emphasis added]

It’s always nice to get a super-positive endorsement, esp., one that, given the high density of praise, is remarkably hype-free. (Whether you agree with Kent’s identification of representational requirements is a separate issue.) One really nice bit of his singling out property chain inclusions (think of them as a generalization of transitivity and subpropertying) is that they highlight the synergy between the extensions to OWL in OWL 1.1 and the proposed fragments. Various versions of SNOMED (and other biomedical ontologies) fall into the logic EL++, which has very nice computational properties. However, they also use complex role inclusions, which put them outside the OWL 1.0 part of EL++. Thus we see extending and sensible subsetting marching happily hand in hand.

The second quote is a table:

This table (in spite of the confusing “CWA” column…I think they mean that the features are used in so called “closure axioms”) is really helpful for seeing what various OWL 1.1 features get you. This paper also had one of the few well described use of rules (in particular, of a DL Safe “SWRL” rule) in an OWL ontology. In my coding of features requested/offered in OWLED 2007 papers it was clear that “rules”, in some sense, were very important, but it was typically unclear what sort of rules would suffice. Indeed, it’s interesting that in the standardization session, DL Safe SWRL rules did not end up in “standards track”. I think this is because of the confusion surrounding “rules” (which is a very unhelpful term) and modeling in OWL. This paper gave clear indication of what the ontologists lacked, what they wanted, and what they actually used (they did check their entailments with KAON2). It’s hard to overstress the value of such clarity.

Just a quick update post ESWC (SPARQL tutorial), OWLED (organizing and…everything), and DL (nothing but hanging out; I did jump, fully clothed, into a pool; I expect photos will show up at some point): Lot’s of good and important stuff happened.

One of the most interesting things at OWLED was that Sandro Hawke annouced that the W3C team has started work on a charter for a potential W3C working group to extend OWL along the lines of OWL 1.1. While this is not a done deal, by any means, it is an important step. Thanks to everyone who helped including all the wonderful moral support we’ve received. There are still devils and details, as always, but I’m very happy with how things are going.

More to come as I unpack.

Goodness me…it really wasn’t that long ago that I wrote “OWLED 2006 is nigh”. Sigh. Things are always nigh!

This time we’re bigger than ever. We had more submissions (in the 40s over in the 30s) and we have far more registrants (90! 90 people have registered!) than last year. The schedule is quite full, but interesting. I don’t recognize loads of people which is either the good thing that we’ll have lots of new faces or the bad thing that sleep deprivation has finally destroyed my brain. Time will tell…someone.

One of the highest profile and, let’s face it, important parts of an OWLED is the “standardization” bits. In the first OWLED, we agreed on a set of features that became OWL 1.1. At the second, we agreed to submit OWL 1.1 to the W3C and pursue a working group. This OWLED we’ll agree to….whatever we’ll agree to. It’s pretty open.

When we started OWLED, I, at least, wanted some institution that would ensure that there was some hope that the work I and so many others were doing would have a sane route to adoption. I also wanted a good way to deal with the “easy” stuff that we all knew how to do, had heard people clamor for a million times, and perhaps had already done in idiosyncratic ways (e.g., QCRs, user defined datatypes, etc.). Even before a working group started, I think OWL 1.1 has helped matters. You now can use QCRs and expect all the tools to support your syntax. A small, but important, step.

While a lot of stakeholders are clearly coming out to OWLED 2007, many are not, and we only have two days. I’m hoping I can gather some feedback on needs, thoughts, and desires for OWL in advance. I divide possible enhancements into four categories:

1. OWL 1.1 issues (these should go to the issues list); these are mostly for the working group
2. OWL “1.2” issues; these are small, easy things that would be widely useful but didn’t get into OWL 1.1; inverse functional datatype properties are a good example; richer annotations are another
3. OWL 2.0 stuff; radical but still important!; n-ary predicates, non-monotonic features; fuzzy or probabilistic features; macros; things which we may not know exactly how to do or we might not know what we should do
4. OWL-adjuncts; query languages, rules and the like; language features that plug into or layer on top of owl, and typically have a distinct working group

(I omitted APIs, protocols, and surface syntaxes. These are important too, but sorta separate.)

I, personally, will be pushing for SPARQL/OWL (with mixed TBox/ABox queries) and DL-Safe rules (both under number 4). I think we could write specs for these and have implementations in fairly short order, and I think these would be enormously useful to the community. SPARQL/OWL, at least the core that I’m thinking of, is definitely a “OWL 1.2 adjunct”: easy, mostly implemented, users all over; let’s write that spec!

So that’s my brief. What’s yours? Please please please either add a comment to this post, send an email to public-owl-dev, or drop me a private note (preferably with a subject tag [OWL1.2], [OWL2.0], etc.) describing your feature, topic, or use case. I will try to filter through it all and present some sort of coherent…thing…to guide discussion.

You don’t have to be at OWLED to make a suggestion! If you aren’t there, I can’t promise that it will be as well championed as it would be if you were there, but I shall do my best.

Most of the work must, of necessity, take place after OWLED (or between OWLEDs), but there is an enormous amount of energy that comes from sitting in a room with a bunch of enthusiasts and making a joint decision.