Re: Semantics and Abstract Syntax (and some general OWL Lite, CR, & implementation) comments

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.

>
>> 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.

[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.

>> 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.

> 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.

[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]

> 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
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.
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.

Cheers,
Bijan Parsia.

Received on Thursday, 19 June 2003 14:47:35 UTC