Thinking Clearly .

The OWL WG is meeting in Washington, DC (well, Gaithersburg, actually—ick!) and, among many decisions reached today, has decided to name the next version of the Web Ontology Language “OWL 2”.

I’m excited by that decision in part because I think it will give the Semantic Web community and other groups of users, too, a new opportunity and reason to take a new, fresh look at OWL.

Tomorrow (4 April) is the last day; tonight is the traditional Working Group Dinner, which I’m especially looking forward to, since it’s being held at Dogfish Head Pub.

And, after a long day of spec-making, Beer is a Good Thing.

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.

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!