- From: Barclay, Daniel <daniel@fgm.com>
- Date: Tue, 15 Sep 2009 18:43:23 -0400
- To: <public-owl-comments@w3.org>
- Message-ID: <4AB0188B.6070602@fgm.com>
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 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. Daniel -- (Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]
Received on Tuesday, 15 September 2009 22:43:02 UTC