OWL 2 SS&FSS spec. editorial errors, comments

Regarding the OWL 2 Structural Specification and Functional-Style Syntax
specification at http://www.w3.org/TR/2009/CR-owl2-syntax-20090611/:



* Section 3.1 says:

     The version IRI MAY, but need not be equal to the ontology IRI.

   That is missing the closing comma:

     The version IRI MAY, but need not be, equal to the ontology IRI.

* Similarly, section 5.8 says:

     Each IRI I used in an OWL 2 ontology O can, and sometimes even
     needs to be declared in O ...

   but also needs a comma:

     Each IRI I used in an OWL 2 ontology O can, and sometimes even
     needs to be, declared in O ...


* Section 3.1 says:

     3.1 Ontology IRI and Version IRI
     ...
     The following list provides conventions for choosing ontology
     IRI and version IRI in OWL 2 ontologies.

   That should say:

     3.1 Ontology IRIs and Version IRIs
     ...
     The following list provides conventions for choosing ontology
     IRIs and version IRIs in OWL 2 ontologies.

   (Per usage in RFC 3987, starting with its title ("Internationalized
   Resource Identifiers (IRIs)"), and per normal English patterns for
   acronyms, the plural of "IRI" is "IRIs".)


* Section 3.1 says "side-effect."  That seemingly should be simply
   "side effect."


* Section 3.2 says:

      Each ontology document can be accessed from an IRI ...

   That's imprecise and possibly a bit confusing.  A document can be
   accessed _using_ an IRI or _via_ and IRI, but it can't actually be
   accessed _from_ an IRI--an IRI is only a string of characters.
   Nothing except those characters can be accessed _from_ the IRI.

   I wonder if there's some other wording to use that's more correct
   (e.g., "... can be accessed _from_ a location denoted by an IRI")
   but not too wordy ("via an IRI"?).


* Section 3.7 says:

     Either Table 2 or the prefix declarations of the ontology
     document being parsed MUST contain a declaration for pn:
     associating it with a prefix IRI PI.

   Something seems backwards about that wording.  (The "must" sounds
   like a condition that applies to Table 2, so that if the condition
   isn't satified, Table 2 could be at fault.)

   It might be clearer to apply the "must" to the abbreviated IRI's
   prefix name (e.g., "the prefix name must be one for which there is
   a declaration contained in ..." (or a less wordy version of that)).


* Section 3.7 says:

     Each part of the ontology document matching the prefixDeclaration
     declares ...

   That apparently should be:

     Each part of the ontology document matching prefixDeclaration
     declares ...

   or:

     Each part of the ontology document matching the prefixDeclaration
     production declares ...

   (or possibly:

     Each part of the ontology document matching the prefix declaration
     declares ...

   depending on other wording).


* Section 3.7 says:

     The abbreviated IRI is split into a prefix name pn: — the part
     up to ...

   and

     The IRI <http://www.example.com/ontology1#> is associated with
     the prefix name : (this prefix is often called "empty" or
     "default").

   Strings like that, especially those containing symbols frequently
   used for punctuation, going double for isolated symbols, really
   should be quoted.


* Section 4 says:

     OWL 2 ontologies can refer to well-known data values such as
     strings or integers.  Each kind of such values is called a
     datatype, and the set of all supported datatypes is called a
     datatype map.

   That and other wording that refers to "_a_ datatype map" seems to
   imply that OWL 2 supports multiple datatype maps, although other
   text seems to say that OWL 2 defines exactly one datatype map.


* Section 4 says:

     The value space is a set determining the set of values of the
     datatype.

   Isn't the value space the set of values itself?  If so, that wording
   should be simplified.  (If it really is some other set that somehow
   determines the set of values, then that, especialy the determination,
   should be clarified.)


* Section 4.2 says:

     Although floating-point numbers are numbers, they are not
     contained in the value space of owl:real.

   Should that say "Although floating-point values are numbers ..."
   (or "... represent numbers"), or maybe "Although values of type
   xsd:float and xsd:double represent numbers ..."?


* Section 4.3 says:

      ... only basic language ranges [BCP 47] are normative in the
      rdf:langRange constraining facet.

   That sounds ambiguous.  Usually, "normative" applies to text in a
   specification (saying which part "counts" and which doesn't), but
   the usage here is different and less clear.  Does the above text
   mean:
   1) that only basic language ranges (but not extended language ranges)
      are _required_ to be supported,
   2) that only basic language ranges are _allowed_, or
   3) that somehow only basic language ranges must be interpreted
      normatively (per the spec.) but extended language ranges don't
      have to be?)

   (The mentions of "normative constraining facets" might also be
   ambiguous.)


* Section 4.5 says:

     ...:

       * xsd:hexBinary
       * xsd:base64Binary

     As specified in XML Schema [XML Schema Datatypes], the value spaces
     of these two datatypes are disjoint.

   Is that actually correct?

   The XML schema specification's section 3.3.16.1, Value Space (for
   hexBinary) says:

     The ·value space· of hexBinary is the set of finite-length
     sequences of zero or more binary octets.  The length of a value
     is the number of octets.

   Its section 3.3.17.1, Value Space (for base64Binary) says,
   identically:

     The ·value space· of base64Binary is the set of finite-length
     sequences of zero or more binary octets.  The length of a value
     is the number of octets.

   According that that wording, both the value space of hexBinary and
   the value space of base64Binary are the same set--the set of
   finite-length sequences of zero or more binary octets.

   Is the XML schema specification buggy (intending to make the two
   value sets disjoint but not wording those sections right (perhaps
   by defining each value set to have values _corresponding_ to (but
   not being) those sequences, so that the value sets weren't the
   same set))?


* Section 4.7 says:

     A time instant may not contain a time zone offset ...

   That wording seems to be ambiguous, meaning either "a time instant
   _must_ not have a time zone offset" (it must not have) or "a time
   instant _might_ not have a time zone offset" (it might be that it
   does not have).  (The latter meaning seems to be what was intended
   in this case.)


* In section 5, in Figure 2, the association line between Entity and
   IRI has a navigability arrow at one end.  That does not appear to
   be correct: a) presumbly, the OWL spec shouldn't be that concrete
   (talking about navigability in the first place), and b) the
   association is navigable in the other direction too--otherwise you
   wouldn't be able to give an IRI and have an OWL interpreter get to
   the entity or entities associated with that URI.

   (Also, can the other end of the association also give a cardinality
   to make clear whether one IRI can denote different entities (re
   "punning")?)


* Section 5.2 says:

     An IRI used to identify a datatype in an OWL 2 DL ontology MUST

       * identify a datatype in the OWL 2 datatype map (see Section 4), or
       * have the xsd: prefix, or
       * be rdfs:Literal, or
       * not be in the reserved vocabulary of OWL 2 (see Section 2.4).

     IRIs from the reserved vocabulary MUST NOT be used to identify
     datatypes in an OWL 2 DL ontology, with the exception of
     rdfs:Literal, the IRIs of the datatypes in the datatype map, and
     the IRIs with the xsd: prefix .

   The second paragraph is confusing:  (It seems that) it doesn't specify
   anything that the previous paragraph with its bullets doesn't already
   specify, but it doesn't indicate that it is intentionally restating
   implications of the first paragraph.

   If it is simply intentionally restating things, it should probably
   begin with "That is, " or something similar.


* Section 5.5 says:

     Annotation properties can be used to provide an annotation for
     an ontology, axiom, or an IRI.

   Regarding "IRI":  Is it really for an IRI, or for the entity denoted
   by an IRI?


* Section 5.6.2 says:

     If an individual is not expected to be used outside an ontology
     ...

   That should be something like

     If an individual is not expected to be used outside a particular
     ontology  ...

   (The current wording is somewhat ambiguous, possibly meaning
   "... outside any ontology...")


* Section 7 says:

     Datatypes, such as strings or integers, can ...

   That wording is confusing because it abbreviates something too much.
   (Strings are not datatypes--clearly, a string is not a datatype.)

   That should probably say something like:

     Datatypes, such as the set of strings or the set of integers,
     can ...

   or maybe something referring to (some system's) names of datatypes,
   as in:

     Datatypes, such as the xsd:string or xsd:integer, can ...


* Section 9.6.1 says:

     An individual equality axiom SameIndividual( a1 ... an ) states that
     all of the individuals ai, 1 ≤ i ≤ n, are equal to each other.

   Is that really "equal" or should that say "identical"?


* Section 10.2.3 says:

     An annotation property domain axiom AnnotationPropertyDomain( AP
     U ) states that the domain of the annotation property AP is the
     IRI U.

   That wording and the object and association role names in Figure 23
   seem to be confusing.

   Upon a first reading of that section 10.2.3 text, it appears that
   it inaccurately says the domain of the property is the IRI instead
   of saying the the domain is the entity that the IRI denotes.

   Then one can see that that occurrence of "domain" probably refers
   to the association role name "domain" of the structural object.

   However, that is confusing, since elsewhere the word "domain" refers
   to the domain of a properties (represented by a structural objects,
   specified by syntax).

   Additionally, there might not be any text saying whether the
   annotation is associated with the IRI or associated with the
   entity (or entities) denoted by the IRI.

   The terminology of section 10 should be reviewed and possibly
   revised.


Daniel
-- 
(Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]