rdf:plainLiteral spec. - errors (editorial)

Regarding the rdf:plainLiteral specification at
http://www.w3.org/TR/2009/CR-rdf-plain-literal-20090611/ :

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

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.


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

Received on Tuesday, 15 September 2009 22:43:02 UTC