- From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
- Date: Thu, 17 Jul 2003 11:47:57 -0400 (EDT)
- To: bparsia@isr.umd.edu
- Cc: public-webont-comments@w3.org
> Subject: Re: Semantics and Abstract Syntax (and some general OWL Lite, CR, & implementation) comments > From: Bijan Parsia <bparsia@isr.umd.edu> > To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com> > Cc: public comments <public-webont-comments@w3.org> > 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 http://www.w3.org/2001/sw/WebOnt/webont-issues.html#I3.2-Qualified-Restrictions > >> 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 http://www-db.research.bell-labs.com/user/pfps/owl/semantics/ > [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 here. > [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 :) OWL Test Cases is a compound document. > 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 public-webont-comments@w3.org, 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 OFFICIALLY POSTPONED, see above. > 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: http://www.w3.org/2001/06/manual/#Large, > 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 document. > Cheers, > Bijan Parsia. Please reply to public-webont-comments@w3.org as to whether you are satisfied. Thanks for your continuing comments. Peter F. Patel-Schneider Bell Labs Research
Received on Thursday, 17 July 2003 11:48:20 UTC