proposed reploy for ``OWL Abstract Syntax and Semantics review comments''

Here is my proposed reply.



Thank you for your detailed comments.  Here is a reply that handles most of
them, and defers one until more work is performed.  Let us know if this is
sufficient for now.

> The following comments are divided up into substantial and editorial
> comments (editorial last).
> 
> --- owlsas-rdfcore-datatype-denotation
> 
> Section 2.1
> "In OWL, as in RDF, a datatype denotes the set of data values that is
> the value space for the datatype."
> 
> - Not true of RDF? A datatype can be treated as a class in RDF - the
> class corresponds to its value space, but not the same thing. Strike "as
> in RDF"

Yes, not really true of RDF.  I will remove this phrase.

> --- owlsas-rdfcore-equvalent-class
> 
> 2.3.2.1 BNF for axiom
> [[
> 	| 'EquivalentClasses(' description { description } ')'
> ]]
> 
> Other 'equivalentX' productions specify a minimum of two equivalent Xs.
> The reason for this production is nonobvious and should be spelled out.

I will add

<p>
In OWL DL it is permitted to have only one description in an 
<span class="syntax">EquivalentClasses</span> construct. 
This allows ontologies to include descriptions that are not connected to
anything, which is not semantically useful, but makes allowances for
less-than-optimal editing of ontologies.
</p>

> We also note that the rule given in section 3.3 does not cover the
> (semantically empty) case of n=1 for the EquivalentClasses(d1 ... dn)
> production.

Actually it does.  The translation would just be the translation of d1.

> --- owlsas-rdfcore-owl-vocabulary
> 
> Section 3.1
> Definition of OWL Vocabulary
> 
> (Clarification sought) I may have misunderstood, but shouldn't
> "rdf:type" be excluded from the definitions of the various "V_x"s ?

In this section there is no need to exclude the RDF or RDFS vocabulary.
The next section does all the exclusion (see disallowed vocabulary from
RDF, for example).

> --- owlsas-rdfcore-unnamed-ontologies
> 
> Section 3.4
> Unnamed ontologies: informally, multiple Annontations on an unnamed
> ontology don't need to be satisfied by the same "x" according to this
> table. Don't think that's right.

*******************
Correct.  It is not right.  Fixing it will require some surgery to Section
3.4.

> --- owlsas-rdfcore-ontology-component-association
> 
> Section 4.1
> 
> While the abstract syntax naturally associates (via syntactic
> nesting) ontologies with all their directives, no such association is
> made in the RDF graph expression of the ontology (apart from
> Annotations). Therefore, multiple ontologies expressed as an RDF graph
> cannot be extracted to produce the component ontologies in the abstract
> syntax.

Yes.  This is the case.  However, in the absence of a mechanism for making
associations between RDF resources and RDF statements it is not possible to
do this.

> --- owlsas-rdfcore-rdf-translation-opaque
> 
> Section 4.1
> 
> >From a presentation point of view, the translation table in 4.1 seems
> overly opaque. However, an alternative compact expression of the
> translation into RDF Graph form is not immediately obvious.

Agreed.  

> ---
> 
> The following comments are all editorial: since they are trivial, no IDs
> have been assigned.
> 
> In general, the presentation of the BNF for the abstract syntax is very
> well done; the "literate" style is to be commended.

Thanks.

> ---
> 
> Section 2.2
> "The second kind of fact is used to make individual identifiers be the
> same or pairwise distinct." Nit - same/distinct denotations?

This would be more precise, but I don't think that it would be any more
readable. 

> ---
> 
> 2.3 Axioms
> [editorial] WG -> working group; don't hyphenate "more-neutral"

Changed.

> ---
> 
> 2.3.1.3
> [editorial] "The only information in axiom for them is annotations."
> Insert "the".

Changed instead to ``axioms''.

> ---
> 
> 2.3.1.3 & throughout
> [editorial] suggest "dataValuedPropertyID" and
> "individualValuedPropertyID" (different intercapping)

The intercapping was chosen to alude to ``data-valued properterty ID''
instead of ``data valued properterty ID''.

> ---
> 
> 2.3.2.3 Para 1.
> [editorial] "As well," suggest "In addition," instead.

Good change.

> ---
> 
> 3.1
> Definition of datatype theory
> [editorial] stumbled over the parenthetical "(non-disjoint)" - is it
> necessary? Would suggest to strike.

This probably was a holdover from something that talked about XML Schema
datatypes and is no longer useful.  It is removed.

> ---
> 
> 3.1
> [editorial, accessibility] This is a nit, but when I first viewed this
> document, the "I"s and "l"s were indistinguishable. Maybe italicise the
> "l"?

Changed to ``v''.

> ---
> 
> 3.2 and elsewhere
> [nit] It may be in standard use, in which case ignore this comment, but
> the terminology 'oneOf' for sets of singletons doesn't seem to express
> (when read informally in Engligh) its intended behaviour. If it's not
> too late would replace with 'singletons' or some other term.

This would require a substantive change.  

> ---
> 
> 3.2 [nit]
> [[
> restriction(p x_1 ... x_n)
> ]]
> Suddest adding ", for n > 1" since n=1 cases are dealt with below this.
    ^^ gg [nit]

Actually, using this for n=1 is benign, and thus I can treat the
clarification addition as an editorial change.

> ---
> 
> 4.
> [typo] "abstarct" in the first para.

Fixed.

> ---
> 
> 5.1 and throughout
> [editorial, nit++] inconsistent capitalisation rules applied to
> headings. Would capitalise "Universe" here. This barely qualifies as a
> comment, apologies.

Fixed.  :-)

> ---
> 
> 5.2, the "Note". The term "constructor" is not defined in the document
> and is only used in one other place.

... and the other use is not very good.

I've changed the other use to ``and restrictions''.
I've changed this to ``construct descriptions''.

> ---
> 
> Some additional comments from RDFCore are to be supplied by Brian
> McBride shortly.

Received on Friday, 9 May 2003 17:45:38 UTC