Thinking Clearly .

I’m very happy to see the first of several rounds of OWL WG Working Drafts displayed prominently on the W3C’s front page. C&P, which became a W3C member last summer, has been participating in several capacities: as WG members and in more behind-the-scenes roles.

I’m happy about this because I know how much work Working Drafts represent, though in this case I can’t remember many WGs starting off with such mature member submissions (I guess XML Schema did well in that regard, as did XML, in some sense).

We’re especially excited about revising OWL because, from our point of view, such revision is both a cause and effect of modest but appreciable growth in the commercial use of OWL:

1. There is non-trivial new functionality in four areas: syntactic sugar representing common and useful modeling idioms; new core expressivity: the new OWL will be able to say more things that machines can understand; a clean user-defined datatype mechanism, since users want to extend OWL to cover their datatype reasoning needs; and, finally, improved metamodeling and annotation facilities.
2. Crucially, these areas of new functionality have two important properties: first, they are practically motivated by commercial and industrial users of OWL who have hard problems they’re trying to solve; second, they are sanely conceived and backed by theoretical soundess and goodness—much like relational database technology, which is thought to be the apex of technological practicality, is backed by theoretical soundness that the vast majority of RDBMS users will never understand and have no need to understand
3. The part of OWL that we specialize in, OWL DL, is growing and will continue to grow, we believe, because it offers, for some class of problems, a handy bit of kit, as they say. But it’s not intended to, nor will it, solve every problem—not even every problem in the universe of problems for which ontologies are useful. We say this all the time to our customers and they’re generally sophisticated enough to understand it. That’s a good thing.
4. Even more exciting for us and crucial to our users, the OWL WG has on its plate upcoming a set of standardized tractable fragments, which will give users interoperable subsets of OWL expressivity. Those fragments or species are all motivated by use cases and are realistically implementable. We’re implementing some of them for future products and those efforts are proceeding well.

Pellet was among the first OWL reasoners to support OWL 1.1 features, and we’ll continue to make sure it covers the OWL waterfront, including specialized reasoners and data engines for various tractable fragments.

OWL is not going to take over the world; for my money, it doesn’t have to. What it must do, however, for us to continue to invest in it, is solve problems that our customers have, that is, real world problems for which they are happy to part with their real world money—and to do so better than the alternatives.

In a recent post, Petr talked about optimizations for queries involving undistinguished variables. There is a close relationship between undistinguished variables and bnodes in RDF whose semantics is being discussed in the OWL working group for OWL 1.1. In this post, I’d like to discuss how they relate and explain how using (un)distinguished variables can change the results you get from a reasoner. First off, the term undistinguished variable is used interchangeably with the term nondistinguished variable so don’t be confused. In the literature you might also see the term existential variable being used for the same purpose.

Let’s start with reviewing bnodes in RDF and then we’ll get to bnodes in SPARQL. Contrary to common belief, bnodes in RDF are not just unnamed individuals but they are existential variables (see the bnode definition from RDF semantics). Treating bnodes as existential variables does not cause a difference in ontology consistency results or entailments regarding named individuals. The difference is visible when you are checking entailments where bnodes are used in the consequences. For example, consider the following simple ontology which I will call ontology A:

:Parent owl:equivalentClass [
       a owl:Restriction ;
       owl:onProperty :hasChild ;
       owl:someValuesFrom owl:Thing ] .

:Alice a :Parent .

:Bob :hasChild :Charlie .

Suppose we have another ontology B as follows:

:Bob :hasChild _:x .

According to the bnode semantics of RDF, ontology B is entailed by ontology A. This is because the bnode _:x in ontology B plays like a wildcard role and matches the individual Charlie from A. Suppose you have yet another ontology C:

:Bob :hasChild :Somebody .

Ontology C is not entailed by ontology A because there is no evidence that the named individual Somebody is same as the individual Charlie. If bnodes were just unnamed individuals then ontology B and C would be treated equivalently because we would just assign an arbitrary name to the bnode <em>:x and ontology B would not be entailed.

In contrast to the formal semantics of RDF, thinking of bnodes as unnamed individuals is common practice for people using RDF/OWL. The situation is similar for tool support. I’m not aware of any reasoner that treats bnodes in the consequences as existential variables (Pellet supports entailment checking but it does not support bnodes in consequences). These are some reasons why OWL working group is considering to adopt the unnamed individual semantics (a.k.a. skolemization semantics) for bnodes in OWL 1.1 that is in agreement with the current practice and users’ expectations. This is an ongoing discussion and there is no resolution on this topic yet.

Now let’s move to the semantics of bnodes in SPARQL queries which is defined similar to the RDF semantics. The SPARQL specification says:

Blank nodes in graph patterns act as non-distinguished variables, not as references to specific blank nodes in the data being queried.

A nondistinguished variable in the query traditionally means that the variable can be bound not only to asserted individuals but also to individuals whose existence is inferred. For example, in ontology A, since we know Alice is a parent we can infer the existence of her child even though there are no explicit assertions regarding that child in the ontology. This means the following SPARQL query:

SELECT *

WHERE { ?parent :hasChild _:a }

would return two results where variable parent is bound to Alice and Bob. That is, if you have a query engine that respects the semantics of bnodes. Pellet query engine supports bnodes in SPARQL queries with this semantics. As far as Pellet is concerned, the previous query is exactly same as the following query:

SELECT * 
WHERE { ?parent a [
       a owl:Restriction ;
       owl:onProperty :hasChild ;
       owl:someValuesFrom owl:Thing ] . }

However, if you change the query to use a distinguished variable in place of the undistinguished </em>:a as in:

SELECT * 
WHERE { ?parent :hasChild ?child }

then the query would have a single result (Bob as the parent and Charlie as the child). The difference in the results might seem surprising because two queries look very similar. But you can see the clear analogy between the first and last query and ontologies B and C. In both cases, replacing bnodes with named individuals/variables change the results we get.

Now let’s consider one last tricky case. Let’s change ontology A to contain one extra assertion as follows:

:Alice a :Parent .
:Bob :hasChild :Charlie .
:Dudley :hasChild _:c .

As expected, the first two queries (both using existential variables) will return three results (Alice, Bob, Dudley). But what do we expect for the last query which uses the distinguished variable child? If we are treating bnodes in the ontology as existential variables (as defined in the RDF semantics) then there are no differences between Alice and Dudley since owl:someValuesFrom is an existential restriction. This suggests we should still get a single answer for the last query (Bob). However, in practice, if you try to run this query against an OWL reasoner (I tried Pellet and Jena rule reasoners) you will get two answers (Bob and Dudley) where the child of Dudley is bound to a newly generated bnode identifier like _:b0.

This is just another example of how tools treat bnodes in the source ontology more like unnamed individuals not as pure existentials. And this is why I believe OWL 1.1 should adopt the skolemization semantics for bnodes and leave the existential variables to SPARQL. After all, existential variables only make a difference in query answering (note that you can think of ontology entailment as a SPARQL ASK query). It makes sense to have explicit existentials in the query language but not in the ontology language (which already supports existentials through restrictions like owl:someValuesFrom anyway).

I’ve been representing C&P in the W3 OWL working group, and my recent focus has been on methods for defining and reusing user-defined unary datatypes in an ontology. The OWL 1.1 documents, which were taken as a working group input, allow users to define restrictions on built-in datatypes in-line using a custom syntax. The following snippet used in the description of Child from the family.owl example provides an example:

<owl:Restriction>
  <owl:onProperty rdf:resource="#hasAge"/>
  <owl:allValuesFrom>
    <owl:DataRange>
      <owl11:onDataRange rdf:resource="xsd:nonNegativeInteger"/>
      <owl11:maxExclusive>10</owl11>
    </owl:DataRange>
  </owl:allValuesFrom>

</owl:Restriction>

Note the use of the owl11 namespace and new vocabulary onDataRange and maxExclusive. This recycles some of XML Schema, notably constraining facets, without re-using the XML Schema syntax. An alternative approach, which embeds the XML Schema syntax directly into RDF/XML might yield the following revision to the example

<owl:Restriction>
  <owl:onProperty rdf:resource="#hasAge"/>
  <owl:allValuesFrom>
    <owl:DataRange rdf:parseType="Literal">
      <xsd:SimpleType>
        <xsd:restriction base="&xsd;nonNegativeInteger">
          <xsd:maxExclusive value="10"/>
        </xsd:restriction>
      </xsd:SimpleType>
    </owl:DataRange>
  </owl:allValuesFrom>

</owl:Restriction>

Such reuse has warts in some cases, but it’s believed these can be worked around. It’s notable too that these warts only appear in OWL/RDF, not in OWL/XML.

It’s too early to tell which datatype syntax will be used in the specifications. The custom syntax is more accessible to RDF tools and makes adding constraining facets in the future easy because they’re just URIs. On the other hand, the benefit of embedding the XML Schema syntax is reuse of that community’s tools, which due to time and industry support, are more mature than the RDF alternatives. I suspect that additional pros and cons will come out soon.

If you’re interested in this part of OWL, please provide thoughts on the alternatives in comments here or on the pellet-users or public-owl-dev mailing lists. I’m happy to relay them into the WG discussion.

In spite of incredibly sore hands and a tendancy to go into shock every hour or so (let’s just say that the corticosteriod injection into the wrist did not go well; sufficiently so that we didn’t even try the knuckle joints), I managed to flesh out a proposal for a new Annotation System for OWL.

Currently, in OWL DL, annotations only occur on “entities” (i.e., classes, properites) via a specially declared set of AnnotationPropertys [sic!]. OWL 1.1 also allows annotations on axioms, so not only can you say that “The class Person was created by Bijan”, but you can also say, “person subClass Cheetah was created by notBijan yesterday”. Obviously, axiom annotations are critically important for any serious ontology engineering project, esp. if it is developed by a team.

In both cases, however, the annotations are “semantics free”. Now, obviously they have semantics in the sense that editors can react to them and so can applications and definitely so can people. However, from the reasoner point of view, they are nothing more than comments and can be thrown away without harm. But, as a result, the reasoner can’t help either! So if you use Dublin Core qualified elements (e.g., date-modified) in your annotations, you cannot use a statement like (date-modifed subPropertyOf date) in the way you might hope and expect. In fact, if you have a date-modified annotation statement and add that TBox statement, you end up in OWL Full.

OWL Full’s solution, roughly, is to be pretty smushy so that AnnotationPropertys [sic] can be ObjectPropertys [sic] and thus the reasoner is sensitive to them. In OWL 1.1, you can get much the same effect via punning: Instead of making your statements about entities using annotations, just use regular properties and let punning make that class an instance.

There are several problems with this approach. The most significant to my mind is that it seriously mixes annotations with domain statements. Most of the time, this is just wrong: As an ontology author, I don’t want to have to consider whether owl:Class is an instance of Person, esp. if all I did was put an annotation on Person.

Also, you might want the logic of your annotations to be fairly different than the logic of your domain. For example, you might want the logic of your annotations to be very simple. Or you might want your annotations to have closed world assumption semantics (e.g., so you can validate the annotations, rather than inferring stuff about them). Currently, the only way to get this in OWL is with a non-standard extension or by separating out your annotations into a separate document.

My proposal builds this separability into OWL, so you can annotate more or less as normal, but get the effect of isolating your annotations from your domain. I also introduce the notion of “mustUnderstand” annotations, that is, annotations which can affect the domain. One might use this for language extensions like Pronto or constraints, but also for more specific interventions. For example, you might want to have some production rules—or some Javascript!—that hack your domain axioms in a variety of ways. The new annotation system would allow for such hacks but, perhaps, in a more controlled way.

Anyway, it’s still in flux, so feedback is welcome. I imagine that you’ll be able to access the various annotation spaces via SPARQL easily enough (similar to what Boris proposed in his metaviews paper). Such annotations can also be used for metamodelling extensions, though that is a tricky area, for sure.

The new annotation system involves some extra complexity, alas. I tried to make it “dumb down” in a useful way, so that just a simple extra statement in your OWL 1.0 or OWL 1.1 documents will get you some nice new behavior. It’s still early days, of course.

Feedback welcome.

Waterboarding is torture; really really bad torture. People who refuse to acknowledge this should be barred from any government position wherein they have oversight over interrogation. At the very least!

There are lots of things going on!

• The OWLWG has had its first telecon (see the agenda, minutes). Our homework for the next telecon is to review the OWL 1.1 documents and the OWLWG charter. So if you had been thinking about taking a peek, this is a good time
• The fall semester has started up again, so I’m again teaching a third-year (that’s, “senior year” to my USites) class with Sean Bechhofer on Knowledge Representation. Per usual, my slides are online (with some commentary).
• OWLED task forces have seen a bit of activity with my posting about “easy keys” (the proposal is not fully fleshed out yet). This led to some yammering about BNodes and their semantics. I’ll do a post in the future about it, but one thing I regret is that I use “existential” as a shorthand for “existentially quantified variables”. BNodes are just existentially quantified variables with graph scope. However, most people don’t work with them as full existentially quantified variables, that is, as plural terms (that is, variables) as opposed to singular terms. I believe that this is what is confusing Reto and why he appeals to singularizing additional constructs (e.g., inverse functional properties) and his implicatures. Existentially quantified variables do not only imply existence, which is fine (and singular terms do this as well!), but also potential plurality. It’s this latter bit that is tricky and dangerous and what I would like to excise from BNodes.
• I will say that I’m a bit disappointed over all with the response to my, I thought, hilariously subjected post, “RDF: XULing or Grueling”. Much was positive (though Harry Haplin went off the rails for some reason), but very little was usefully substantive (at least from my perspective). I really really want a case study of RSS 1.0. I would be shocked if such a thing showed that RDF would have been a sensible wire format in any reasonable variant of history. Also, I have to say, that if it really, really, really is true that MOST adoption problems stem from the facts of RDF/XML, then we are an exceeding stupid community not to simply up and fix that. I conclude from this that either we are stupid, or that the syntax problems aren’t a sufficient condition for widespread lack of adoption, or that at least a good chunk of the community doesn’t believe that syntax problems are all that, regardless of reality. Seriously, if Turtle would cause a doubling of good press for RDF and a doubling of the rate of (happy) adoption, just freaking advocate the hell out of it. Doesn’t have to be in the W3C. Hijack it and run like the wind on a windy day.

So, lots going on!