new reply to comments by Bijan Parsia

Here is my proposed reply to Bijan.


> Subject: Re: Semantics and Abstract Syntax (and some general OWL Lite, CR, & implementation) comments
> From: Bijan Parsia <>
> To: "Peter F. Patel-Schneider" <>
> Cc: public comments <>
> Date: Thu, 19 Jun 2003 14:49:16 -0400
> On Friday, May 30, 2003, at 03:41  PM, Peter F. Patel-Schneider wrote:
> > 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
> > possible.
> Yeeess. I think that's right.

> > 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.
> Qualified cardinalities right?
> FWIW, I think this is a huge issue for many existing daml+oil users. I 
> worry that people will just try to use the daml vocabulary with OWL, 
> which seems icky.

The Web Ontology working group reopened deliberations on qualified
cardinality restrictions, but on 8 May 2003 decided to postpone work on
qualified cardinality restrictions.  The official information on this
postponement can be accessed at

> >> 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.
> I strongly disagree. S&AS is, in my opinion, reasoner implementors will 
> go, especially those interested in implementing complete reasoners. 
> That was my experience, and I lost a LOT of time trying to figure out 
> how OWL lite was lighter than SHIF(D) (in a substantial way) and how 
> that made anything easier.
> I would suggest that there be an "implementors note" break out box 
> somewhere early in S&AS, prolly toward the end of the Abstract Syntax 
> presentation. It could say something like:
> *****
> IMPLEMENTORS' NOTE: OWL Lite and OWL DL closely correspond to the 
> description logics known as SHIF(D) and SHION(D), with some limitation 
> on how datatypes are treated. The abstract syntax for  OWL Lite doesn't 
> contain many of the common explicit constructors associated with 
> SHIF(D), but the expressivity remains.
> *****
> > 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.)
> I actually can't think of a better place to put it.

This has been added as a Note just before Section 2.1.  To see the change
look in

> [snip]
> >> 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
> > Guide.
> That explains why in the *concrete* syntax, but not in the *abstract* 
> syntax. I.e., why not
> represent multiple subclassings as the subclass of an intersection (in 
> the abstract syntax)?
> I mean, I could imagine that it would complicate the mapping to 
> triples, but I don't see off hand.
> Are ANY users (as opposed to implementors) going to look at the 
> abstract syntax, or S&AS for that matter? If so, I would suggest that 
> S&AS should be made convenient for implementors, not end users. That 
> you have to use natural language to explain something that could easily 
> be directly expressed in the abstract syntax makes the abstract syntax 
> a bit less useful.

This is a question that will most likely be answered by developers of
OWL-related systems that include user interfaces.  It is probably easier
for implementors of such systems to internally use a syntax that is close
to syntax that they present to users, and the abstract syntax might be such
a syntax.

> >> 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.
> Right, and that's fine for OWL lite, but it doesn't explain bubbling up 
> these restrictions to the Abstract syntax level.

It is part of the design criteria of the abstract syntax to

	facilitate[] access to and evaluation of the language.  This
	particular syntax has a frame-like style, where a collection of
	information about a class or property is given in one large
	syntactic construct, instead of being divided into a number of
	atomic chunks ... [Section 2 of S&AS]

which indicates that a more accessible syntax is better even though that
might somewhat obscure the actual expressive power of the language.

> > There are short allusions to this in various places - a long allusion
> > would be quite lengthy and probably not suitable.
> I would accept language along the lines I gave above. My favored 
> solution would be a more explicit abstract syntax, but that's probably 
> too much work. But then there *really* needs to be a blocker of the 
> misunderstandings that in my own experience, and from that of my 
> students, are far too easy to make.

The statement of correspondence between OWL Lite and SHIF(D) should help

> [snip]
> >> ***************
> >> 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.
> Er...but none of the other documents, afaik, either in webont or 
> rdfcore are compound. Few if any, again afaik, modern W3C recs are 
> compound. I would have thought that that would be determinative :)
> Not a biggy, but it does annoy me each and every time. And I often 
> forget that it's compound and thus load up only the first page and find 
> myself off line with not what I wanted. Oh well. Bookmarking the single 
> file will work. But I predict other people's annoyance.
> [snip]

No change is likely to be made here.

> > 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.
> CardinalityQ: need to wait


> Adding "Implementors' note": I will be satisfied if something like this 
> is added. I won't be if not. I think
> 	S&AS is exactly the right place for this information and it doesn't 
> seem like a large change.

DONE, see above.

> Single HTML file: Looking at:,
> I'm not convinced that S&AS is actually "large" enough to count as a
> large one. It certainly doesn't need compression to facilitate download
> in most circumstances. But I guess if it is "large", then as long as the
> other advice is followed, I can't strongly object. I might then object
> that similarly long documents *aren't* broken up.

NOT DONE, but as you say, it is possible to easily access the combined

> Cheers,
> Bijan Parsia.

Please reply to as to whether you are

Thanks for your continuing comments.

Peter F. Patel-Schneider
Bell Labs Research

Received on Wednesday, 16 July 2003 16:01:41 UTC