Re: Coments on 1st Working Draft

[I'm only responding here to the comments on the Abstract Syntax
documents.  I'll leave responses concerning the other documents to others.]


From: "Martin Bryan" <mtbryan@sgml.u-net.com>
Subject: Coments on 1st Working Draft
Date: Thu, 8 Aug 2002 09:04:10 +0100

> Congratulations on a superb first working draft for the OWL specifications.
> This is the clearest explanation of how to markup ontologies I have seen to
> date.

Thanks, and thanks for responding.

> As ever with first drafts, there are a few rough edges that need smoothing,
> as noted below.

Yes, definitely.   I expect that revised versions of all the documents
will be produced in the near future.  In particular there are many open
issues whose resolution may require changes to the documents.

> Abstract Syntax
> Section 2 states that "elements that can occur any number of times
> (including zero) are enclosed in braces". Yet in most cases where braces are
> used in the spec the presumption is that at least one occurence is required.
> For example unionOf (<description> {<description>}) would seem illogical if
> the text comment in parenthesis was taken into account. Is
> unionOf(<description>) really allowed?

I think that in all cases in the document a brace-enclosed element can
occur zero times without problems.  Of course, many of these may not be
particularly useful, but they do make sense.  For example,
unionOf(<description>) would be equivalent to <description>.  In fact,
unionOf() has a reasonable interpretation, namely equivalent to
owl:Nothing.  

The most questionable of these constructions are the ones like
DifferentIndividuals(John), which has no impact at all.  However, changing 
the production to 
  <fact> ::= DifferentIndividuals( <iid> <iid> {<iid>})
makes the grammar bigger and gains very little in clarity.

> Section 3.
> At present <authorship-etc> is only allowed to be specified at ontology
> level. This assumes that all entries in the ontology are created/validated
> at the same time by the same person. In practice ontologies are created by
> teams, different members of which are responsible for different entries. The
> spec contains no mechanism for indicating the responsibility for specific
> entries, the time of their creation or the period in which they can be
> considered valid. No mechanism is identified for annotating entries, e.g. by
> use of the XML schemas annotation element. Some standardized mechanism for
> identifying fact and axiom managment information is required.

I agree that this it would be useful to be able to annotate other types of
constructs.  There is an outstanding issue (number 4.4) that addresses this
lack in the current formulation of OWL, which has been carried over from
DAML+OIL.

> The fact that class/datatype IDs can be the same as property or individual
> IDs goes against the principles of the use of the term ID within XML. Under
> what circumstances is it invisaged that a class would have the same name as
> an individual, or a property the same name as a datatype?

There is an ongoing debate within the working group related to this point.
One way of looking at the use of a URI reference as the name of more than
one of a class, a property, or an individual is that there is a
relationship between the class, property, and/or individual so that they
are either closely related or are the same.  This, I think, does not go
against the principles of XML.

> 5.1.2
> The OWL Lite restrictions on minCardinality and maxCardinality given in the
> formal productions state that only (1) may be used, yet section 3,4 of the
> Feature Synopsis for OWL Lite and OWL clearly states that 0 is permitted for
> both these productions.

Correct.  I'll change the abstract syntax document accordingly.

> 5.1.3
> The formal production for ObjectProperty is defined in such a way that an
> object cannot be both Functional and Transitive. Yet the text of the
> preceding paragraph ends "Finally, individual-valued properties can be
> specified as transitive" with no qualification about the use of this term
> with respect to functionality.

The next paragraph goes on to state when a property cannot be transitive.

[...]

> Martin Bryan

[...]

If you have any questions about this reply, please don't hesitate to ask.
If you notice any other problems with the documents, please let us know.


Peter F. Patel-Schneider 
Bell Labs Research

Received on Thursday, 8 August 2002 09:01:49 UTC