W3C home > Mailing lists > Public > public-owl-wg@w3.org > September 2008

Response to the review comments of the Syntax document, Sections 9--15

From: Boris Motik <boris.motik@comlab.ox.ac.uk>
Date: Sat, 13 Sep 2008 22:18:26 +0100
To: <public-owl-wg@w3.org>
Message-ID: <000301c915e6$43533e00$2b12a8c0@wolf>

ello Mike, Bijan, and Vojtech (and everybody else :-),

Here are my responses to your review comments in Sections 9--15. Here is the diff:

http://www.w3.org/2007/OWL/wiki/index.php?title=Syntax&diff=12819&oldid=12769

Please let me know should you have further comments.

Regards,

	Boris

@Vojtech, Section 9.1.4: "A disjoint union axiom DisjointClasses(..." should be "...DisjointUnion(...". The BNF also does correspond
to Fig. 13, where there is 'disjointClassExpressions' instead of 'ClassExpressions' (I assume the BNF is correct?)

Thanks: it was meant to be DisjointUnion. I've also added disjointClassExpressions to the BNF: otherwise, just having "class" and
"classExpressions" in the diagram would be not very informative.


@Vojtech, Section 9.2.1: How about mentioning, aside reference to complex role inclusions, also the fact that such constructs have
typically been handled using a combination of OWL and rule languages?

I'm not sure whether this would be appropriate for this document. Integration of OWL and rules is really a completely different
topic. Furthermore, this might open a can of worms regarding integration with RIF.


@Mike, Section 9.2.4: This example is missing the "This however..." conclusion that accompanies the PropertyRange example. It needs
it.

I added the sentence; thanks! I've also added the sentence to the data property domain section (Section 9.3.4). The data property
range section (9.3.5), IMHO, doesn't need the sentence; please let me know should you think otherwise.


@Mike, Section 9.4: I don't recall a particular motivation for the properties arguments preceding the class expression. If there is
no specific motivation, I suggest modifying this so that the class expression is first. This would match the RDF syntax and make
things a little easier for users. (A change from KeyFor to HasKey or something similar would probably go along with a reorder).

I've followed Bijan's design here, which, I believe, has followed the usual DL syntax. The common reading is "Such-and-such
properties are the key for such-and-such class". I personally don't really care about the actual syntax. I haven't, however, changed
the spec yet: can you please coordinate with Bijan and perhaps the other interested parties?


@Mike, Section 9.4: This level of semantic detail is inconsistent with the rest of the document and repeats information in the
semantics document.

I'm not sure I agree with this comment. Keys have a semantics in OWL 2 that is quite different from the semantics of all other
constructs. Since this document is meant to serve as a reference, it seems to me it is important to be upfront about the semantic
consequences of our design. Please note that the Semantics document doesn't really contain an intuitive discussion of the semantics
or an example. Let's discuss this further should you not be happy with my answer.


@Vojtech, Section 10: "...representing this structure at the level of the structural specification may be difficult and/or
impossible." I understand that logicians are fine with such a formulation (as, in some reasonable calculus, 'difficult' AND
'impossible' EQUALTO 'impossible' surely holds...), but normal people might find it funny? Hence, 'or' might suffice? 

Thanks for drawing my attention to this sentence: it was kind of difficult to parse anyway. I've rephrased the paragraph as follows:

	The structure of such comments, however, is dependent on the syntax, so
	representing them in the structural specification may be difficult or even
	impossible; hence, such comments are simply discarded during parsing.


@Vojtech, Section 10.1: Why is the BNF written bottom up?

No particular reason. In many other places (e.g., Section 3, Section 2.4, Section 9.1.1, and so on), BNF has been written like that
as well. I can reorder the syntax if this is considered necessary; however, it seems to me that sometimes it is beneficial to follow
the "define before use" approach.


@Vojtech, Section 11: I would suggest to split the section into two subsections for better readability: one with the auxilliary
definitions (most terms, probably except that of 'simple OPE in Ax', don't appear anywhere else in the spec) and one with the actual
global restrictions.

I agree: this section wasn't really the epitome of clarity! I've reorganized the section and have also added a bunch of examples, in
hope that these make it easier to understand all the definitions. Please let me know what you think.


@Mike, Section 11, comment about "No SubObjectPropertyOf axiom in Ax contains the owl:TopObjectProperty property, and no
SubDataPropertyOf axiom in Ax contains the owl:TopDataProperty property.": This constraint seems to be unnecessarily strict. The
properties should be permissible in the super property position of such axioms (and even the subproperty position if the axioms are
tautologies).

That's true; however, the axioms in which top properties occur as superproperties are really tautologies, so they are not really
interesting. In order to reduce the number of exceptions, I'd propose to simply bar the top properties in axioms altogether.

@Mike: I've tried to hoist most of the examples into an example box. The only place where the word "example" now occurs outside the
example boxes is the introduction: the introduction itself is a kind of example itself, isn't it? Please let me know should you find
further places that require clean-up.
Received on Saturday, 13 September 2008 21:20:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:07 UTC