proposed reply for Semantics and Abstract Syntax (and some general OWL Lite, CR, & implementation) comments

[ Proposed response for

This message responds to your comments, in each case not suggesting any
changes to the S&AS document.  This is not actually a rejection of your
comments, however.  I feel that you are generally satisfied with the
situation as it stands, but that some improvements could be made, if

One comment that you make corresponds to a re-opened issue that may result
in a change - if this indeed happens we will let you know.  

> 1) Somewhat editorial: I think it would be invaluable for implementors, 
> and even casual readers, to have the DLs that OWL Lite and OWL DL are 
> notational variants of (mostly) explicitly mentioned (they are, 
> respectively, to my best current knowledge, SHIF(D) and SHION(D)).

Yes, the closest correspondences are to SHIF(D) and SHOIN(D), with some
limitations on how datatypes are treated.

It would be useful to have this somewhere.  However, I don't think that the
best place for this is in S&AS.  If you have a suggestion for a suitable
place to stick this information, let us know.  (If the wording fits nicely
in S&AS, it might even make it in there.)

> *Especially* given the misinformation and misimpressions about OWL Lite 
> (e.g., that it "leaves out" expressivity to permit lower complexity 
> reasoning and implemenational simplicity, with the perhaps canonical 
> example being "there's no class boolean constructors, so you don't have 
> to worry about unions, etc.!"), it's really handy to be able to just 
> hit the right papers.
> Is there any reason why the Abstract Syntax conceals some of the 
> expressivity? 

Yes.  :-)  See below.

> I mean, given that OWL Lite can express general inclusion 
> axioms, what exactly does it help to have the restrictions on the left 
> hand sides of the various axioms? The syntactic restrictions seem to 
> only be of interest at the authoring or serialization level.

The simpler axiom forms are intended to be reminiscent of frame systems.
Most people write ontologies using mostly these forms, so it was decided to
provide a syntax slanted towards them.  Some of this is already covered in

> Similarly, even we have somewhat explicit intersections (from the 
> text), but nothing saying "intersectionOf" in the syntax. Ok, I suspect 
> this makes the mapping to triples easier, but it makes understanding 
> the language from the implementation point of view much more difficult.

The tradeoffs in the syntax of OWL Lite are somewhat unusual.  The syntax
of OWL Lite is supposed to be similar to frame syntax, thus the lack of
explicit intersectionOf.  I agree that from the logical point of view there
is no reason for this, but it is supposed to be easier to write and to parse.
There are short allusions to this in various places - a long allusion
would be quite lengthy and probably not suitable.

> (Assuming I'm right about the expressivity. I'm not nearly as confident 
> as I'd like to be, which, I take it, indicates a problem with the 
> document. I'm certainly not the only one.)

> Re: OWL Lite in general. I do worry that the "teachability" and 
> "usability" of concealing expressivity will turn out to be like the 
> abbreviated forms in RDF/XML: A seemingly good idea at design time; a 
> major wart to most ever after. Fortunately, since OWL Lite is a 
> restriction rather than an extension, and not a restriction on 
> *expressive power* (i.e., you need to build a reasoner that handles 
> complement, general inclusion axioms, etc. to handle owl lite, so it's 
> trivial to extend it to a subset of owl dl except for general 
> cardinalities and hasvalue), it's being a pain is relatively painless: 
> ignoring it causes few problems.

> I put this out as a caution against further second guessing. While I'm 
> *afraid* it'll turn out to be merely pointless or annoying, I have no 
> real evidence. People are funny.

It may indeed turn out that the OWL Lite syntax limitations are not
correct.  No one gets the syntax right on the first (or even second or
third or ...) try.  However, it should be relatively painless to fiddle
with the OWL Lite syntax.

> ***************
> 2) Completely Editorial: I would like the normative version of the 
> document to be a single HTML file. I know, off hand, of no other (at 
> least modern) W3C recommendation that is split up merely for 
> navigational purposes. It's inconvenient, it's inconsistent even with 
> the other OWL specs, and annoying, especially for offline reading.

I agree somewhat, but do find the separated version to be helpful
sometimes.  I was asked to make the switch from a single to a compound
document, and I'm not particularly interested in switching back.

> ***************
> 3) Given that we're already pushing the expressivity/computational 
> complexity front, I would very much like to have various role 
> constructors, roughly what gets into ALC* or ALCtrans, though I 
> understand that transitive closure isn't addable while preserving 
> decidability (though *that* would be, for me, a more attractive OWL 
> Lite, i.e., something I could add transitive closure to and retain 
> decidability). CardinalityQ, too. I miss it.

There is the possibilty of qualified cardinalities coming back.  The
working group has re-opened an issue on this.  One sticky point with
qualified cardinalities is their syntax in triples.

Transitive closure is a different matter.  Transitive closure plus inverse
is decidable but even more difficult to work with than transitive roles
plus inverse.  Adding in transitive closure would be a major change to the
language, even without the computational difficulties.

> I would be encouraged by a Note that made it clear how to define 
> subsets (and supersets) of OWL/DL that mapped into the range of DLs 
> from ALC on up. I don' t think it needs to hold up the language though.

I some sense this is not too hard in the abstract syntax.  There is
accepted syntax for many DL constructs in a form that could easily be added
to the abstract syntax.  However, making the RDF-compatible semantics work
out might require significant work.

> Which actually brings me to my last comment:
> ***************
> 4) Get the damn thing out the door.
> I'm not clear that a long CR for implementation is either useful or 
> wise. No, I'm fairly clear it isn't. The language seems perfectly 
> reasonable, if not my ideal. It fixes loads of important bugs in 
> DAML+OIL, which, i'll point out, has been a perfectly servicable 
> language for many people and purposes. Let us play with this for a few 
> years and THEN we can tweak it further.

Well, hopefully, the tweaking can start in a few months.  I expect that
implementors will not exactly target OWL Lite or OWL DL or even OWL Full.
(I know that I won't, if I can ever get some time to do implementation.)  I
hope that implementors will deal with supersets, leading to implementation
experience that can be used to produce more powerful designs.

> Speaking as an implementor and kibbitzer to implementors, what I'd like 
> right now is a truly stable spec rather than something that might or 
> might not change in 6 months. We WILL find bugs. We will find bugs and 
> infelicities even after a 6 month CR period.

I expect that there will remain bugs in the documents forever.  They are,
after all, quite long and quite complex.  I hope that none of these will be
significant.  There has been one significant bug found during the last call
period, having to do with late changes to the mapping rules, which has just
been addressed.

> Speaking ENTIRELY in my own voice, brash as it may be.

Feel free.

> Cheers,
> Bijan Parsia.

Please respond, copying, as to whether you
are satisfied with this response, whether you need to wait until certain
changes to the design of OWL are done, or whether further correspondence is
needed now.

Peter F. Patel-Schneider
Bell Labs Research
Lucent Technologies

Received on Friday, 30 May 2003 15:28:06 UTC