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

Peter - if okay w/Guus these are okay w/me and should not need a WG 
decision.  However, I have one nit -- you say "properterty" twice in 
one of your reply sections -- fix spelling.
  -JH







At 16:14 -0400 5/9/03, Peter F. Patel-Schneider wrote:
>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.

-- 
Professor James Hendler				  hendler@cs.umd.edu
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  240-731-3822 (Cell)
http://www.cs.umd.edu/users/hendler

Received on Saturday, 10 May 2003 22:47:34 UTC