Thinking Clearly .

Following closely on the heels of the recent release of Pellet 1.5.2, we’ve updated OwlSight. Since OwlSight runs on raw Pellet power, the new version, .52, updates the back-end to take advantage of the recent Pellet release.

If you have not already taken a look at OwlSight, cruise on over to the OwlSight page and take it for a spin. For those not already in the know, OwlSight is a lightweight browser-based ontology browser utilizing both GWT (and GWT-Ext) and Pellet as its core technologies. Until next time, stay classy cyberspace.

We’re starting to give more talks at more conferences since our SemWeb infrastructure framework—from OWL reasoners and ontology browsers, to RDF linked data browsers, to policy management apps— is really starting to round itself out. Upcoming talks include:

1. 28 April, Boston, BioIT World Conference’s “Harnessing the Semantic Web for Your Organization” workshop . Mike Smith is giving a talk with our NCI customers about how HCLS and other bio orgs can start to take advantage of semantic web stuff.
2. 19 to 21 May, San Jose, Semantic Technology Conference (Bad URL that will break for the 2009 conference; ironic, that!). Evren Sirin, Mike Smith, Pavel Klinov, and I will be giving three talks—Pellet, Pronto, and XACML-DL Policy Analysis. Actually, I’ll be there trying to act “managerial”; I leave the talk-giving to the smart guys.
3. 2 to 4 June, Palisades, NY, POLICY 2008. Markus Stocker and I will be giving a demo talk of XACML-DL, our XACML policy analysis tool.

Upcoming we’re targeting a conference about Ontologies and Model-Driven Architectures (MDA)— which is what OMG is doing now that CORBA is dead-dead-dead—that’s sometime in the fall in Toulouse, which is nice.

One of our new customers—who’s sponsoring a pending Pellet maintenance release, version 1.5.2, that should be out ver soon—is using Pellet to drive a pretty complex code-generation process, and that’s an area where we think Pellet has a huge upside. And we’ve found giving talks and papers with customers as partners is a good pattern.

If you’re planning on attending any of these conferences, shoot me an email as we’d love to chat with users, friends, fans, and interested bystanders.

So we talked about 5 or 6 SemTech 2008 proposals based on our products, services, and technology bits. The guys convinced me that of those 6 ideas, there were 4 actual, strong proposals:

1. A Pellet tutorial
2. A talk about Pronto, our probabilistic reasoner integrated with Pellet
3. A talk about XACML-DL, our XACML policy analyzer
4. A talk about JSpace, our Linked Data browser

I thought we had a very small chance for (1)-(3), but a better than 50% chance for (4); my reasons were based on what typically shows up at SemTech, the interests of the organizers (in my view), and past talks that have been accepted.

Hence, I was a bit surprised when we got notifications today that (1) and (3) were accepted; (4) was not accepted; and we haven’t heard back on (2), though I’m assuming that it won’t be accepted.

(Update: Actually, the talk on Pronto was accepted, they just sent notification quite late. This is interesting because while we think, long term, there is commercial utility here, it really is quite a complex subject. One thing I realized in watching Pavel do this work over the summer is how surprising valid probabilistic reasoning can be.)

The Pellet talk is called “What to do with an OWL Reasoner”, and we’re hopeful there will be people who attend SemTech for whom that’s an interesting question. I was very surprised that the talk on XACML-DL got in, not because it’s not an interesting bit of tech, since it is, but more because we haven’t said much, if anything publicly about it yet. It has no buzz whatever.

We think policy management may be the big win for OWL in the enterprise space; but it’s still very much a dark horse.

Just as a précis: our XACML-DL analyzer, based on Pellet, for a near arbitrary set of XACML policies, can:

• perform formal policy verification and deep testing (think HTTP unit testing, only way sexier);


• perform policy change analysis;


• detect policy redundancy;


• perform policy repair, debugging, and explanation;


• support policy federation (disjointness checking, etc);


• perform policy set optimization.

I’ve recently started saying, to explain the commercial appeal of policy management generally, that every IT solution creates, eventually, a new round of IT problems, and XACML is a perfect example of that. So you’ve moved from procedural and imperative ACL code all over yr enterprise to declarative, orthogonal ACL decision points using XACML. That’s potentially a huge win in programmer productivity, in security quality, and in compliance. But now that you’ve got a few thousand XML files describing yr ACL policies, how the hell are you going to manage them? Are they game-able? Are they coherent? Are there redundancies and, thus, inefficiences?

Who knows and how does one go about finding out?

Those are precisely the kinds of management services for domain-specific policies that OWL is well-suited for, and there lots and lots of such policy languages out there in the world.

Hurrah hurrah! The moment has finally arrived. The W3C has announced today that they are starting up a new OWL working group.

I’m really excited by this, since, after all, I’ve been working toward this for, geez, two years or so? Two and a half? Well, since before the first OWLED. I think it’ll be a big boost for the community and that users will benefit quite a bit.

The working group won’t be the only place where OWL evolution will be happening, of course. OWLED, for example, marches on and I’m hoping for great things from the task forces. There’s lots to do and lots of fun to be had while doing it.

Interesting, tonight, we Mancunians from IMG who are not moving to Oxford threw a bash for those who are. Ian Horrocks (who is the reason I have a job at the University of Manchester) has been successfully wooed by Oxford. Ian will be (co)-chairing the OWL working group.

Interesting times!

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.