LC3 Responses/DB11

To: daniel@fgm.com
CC: public-owl-comments@w3.org
Subject: [LC response] To Daniel Barclay

Dear Daniel,

Thank you for your comment
     <http://lists.w3.org/Archives/Public/public-owl-comments/2009Sep/0018.html>
on the OWL 2 Web Ontology Language last call drafts.

Please acknowledge receipt of this email to <mailto:public-owl-comments@w3.org> (replying to this email should suffice). In your acknowledgment please let us know whether or not you are satisfied with the working group's response to your comment.

Regards,
Jei Bao
on behalf of the W3C OWL Working Group

CUT AND PASTE THE BODY OF THE MESSAGE (I.E. FROM "Dear" TO "Group") INTO THE BODY OF AN EMAIL MESSAGE. SET THE To:, CC:, AND Subject: LINES ACCORDINGLY.

PLEASE TRY TO REPLY IN A WAY THAT WILL ALLOW THREADING TO WORK APPROPRIATELY, I.E., SO THAT YOUR REPLY CONTINUES THE THREAD STARTED BY THE ORIGINAL COMMENT EMAIL

Section 1 says "unicode" instead of "Unicode" (in the last paragraph
(two occurrences)).


Section 1 says:

    This extension, however, does not change that conceptual model,
    and thus does not affect specifications that depend on it such as
    SPARQL [SPARQL].

That seems to need a comma before the word "such."


Section 1 says:

    The value space of rdf:PlainLiteral consists of all data values
    assigned to RDF plain literals, which allows RDF applications to
    explicitly refer to this set (e.g., in rdfs:range assertions).

The wording "all ... values assigned" seems to be confusing.

It sounds like it's trying to refer to only all plain literals that
are actually used somewhere, as opposed to referring to all possible
plain literals.

Additionally, saying "values ... assigned to ... literals" instead
of something like "values ... represented by ... literals" makes its
sound like it's referring to something other than the normal values
represented by the literals.


Section 2 says:

   This specification uses Uniform Resource Identifiers (URIs) for
   naming datatypes and their components, which are defined in RFC
   3986 [RFC 3986].

No, RFC 3986 does _not_ define datatypes and their components (or even
just those components).  (That is, the wording is scrambled.)


Section  2 says:

   For readability, URIs prefixes are often abbreviated by a short
   prefix name according to the convention of RDF [RDF].

That probably would be clearer as "abbreviated with ..." or "abbreviated
using ..."


(I notice that the bulleted items about prefix names and namespace
prefixes seem to use the terminology precisely.  Excellent.)


Section 2 says:

   A plain literal without a language tag is interpreted in an RDF
   interpretation by itself.

Something seem to be unclear about that sentence, although its hard to
identify what.

(What kind of interpretation is it talking about?  It's not talking
about syntactic interpretation (e.g., reading a string per N3 or
RDF/XML rules), since it's not talking about any RDF interchange
syntax; and it's (seemingly) not talking about interpreting a lexical
form as referring to a value; but it seems that it's not clear what
kind of interpretation is talking about.  (I know that  "intepretation"
has meanings in logic that I'm not fully familiar with.))


Section 3 says:

   In languages such as OWL 2, this can be used to specify that a
   data value must contain the language tag.

That probably should be "a data value must contain a language tag."
(Something about that context makes the wording "the language tag"
sound like it is referring to a particular language tag rather
than referring to the language tag part of the syntax.)


Section 5.1.1 says:

   Note that, since in the value space of rdf:PlainLiteral language
   are in lowercase, this function converts $arg2 to lowercase.

That seemingly should say "... language tags are ..."


Section 5.2.1 says:

  ... otherwise, this function returns -1, 0, or 1 depending on
  whether the value of the string-part of $comparand1 (or
  $comparand1 itself, respectively, if it has no language tag) is
  respectively less than, equal to, or greater than the value of
  the string-part of $comparand2 (or $comparand2 itself,
  respectively, if it has no language tag).

The two occurrences of "respectively" inside the parentheses seem
to be extraneous.  (They don't coordinate the order of anything
(as the other "respectively" instance coordinates the list "-1, 0,
or 1" with the list "less than, equal to, or greater than ").)


Section 5.2.1 says:

   The first version of this function backs up the XQuery
   operators "eq", "ne", "gt", "lt", "le", and "ge" on
   rdf:PlainLiteral values.

"Backs up" seems to be the wrong term there.


Section 5.3.2 says:


   This means that the function returns false if the argument is a
   string rdf:PlainLiteral data value.

The wording "the argument" is ambiguous.