Re: Comments on Concepts editors' draft 2003-06-19

One small nit.  Section 3.5 of Concepts cites an example (Figure 5) from 
the Primer.  In response to comments that the Primer examples should be 
more "international", "zip" has been changed to "postalCode" in the 
current Primer editor's draft (it's still Figure 5).

--Frank

Graham Klyne wrote:

> 
> With reference to:
>   http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/
> (19 June 2003 editors' draft)
> 
> As I said in an earlier message, I think this is looking pretty close to 
> ready.  My most serious comments are to section 5.1.
> 
> I repeat my suggestion that any working group discussion in the telecon 
> be based on the editors' draft reviewed here, rather than attempt to 
> push out a new release.
> 
> BTW, the date in the editors' draft URI is misleading.
> 
> ...
> 
> Section 1, final para, editorial:
> 
> Suggest:
> "applications in the primer" --> "applications mentioned in the primer"
> 
> ...
> 
> Section 1.1, 2nd para, editorial.
> 
> "RDF's abstract syntax is a graph..."
> 
> I think the first two sentences of this paragraph are out of place, and 
> suggest they be moved up to a new final paragraph in section 1.  No 
> wording change needed.
> 
> ...
> 
> Section 2.1, final bullet, editorial.
> 
> The term "lingua franca" should not be italicized (at least, according 
> to my Oxford dictionary)
> 
> ...
> 
> Section 3.4, second para, significant.
> 
> s/arc/predicate/
> 
> ...
> 
> Section 3.4, 4th para (just after bulleted list), editorial.
> 
> Strictly speaking "which" is incorrect here.  Use "that".
> 
> ...
> 
> Section 3.5, 1st para, editorial suggestion.
> 
> The word "object" is used in two different senses in the first two 
> sentences.    Suggest replace "two objects" with "two things" (twice in 
> first two sentences).
> 
> ...
> 
> Section 5, definition of "lexical space", maybe significant.
> 
> The definition isn't clear about what is meant by a "string".  I suggest 
> adding:  ", which are sequences of Unicode characters".
> 
> ...
> 
> Section 5, para 5, editorial suggestion.
> 
> "A datatype is identified by one or more URI references."
> 
> While strictly correct, I'm not sure that "one or more" adds any 
> important information, reads awkwardly and possibly confusingly.  I 
> would be inclined to delete it.
> 
> ...
> 
> Section 5, final bullet, significant.
> 
> "however these facets cannot be accessed by any standard method within 
> RDF."
> 
> This is possibly not necessarily true or maybe just confusing.  (e.g. 
> suppose the XML schema group define RDF vocabulary for datatype facets:  
> wouldn't that be a "standard mechanism within RDF"?)
> 
> Suggest:  "however, RDF does not define a standard mechanism to access 
> these facets."
> 
> ...
> 
> Section 5.1, "The lexical space", final bullet, maybe serious.
> 
> The phrase "start and end element" seems wrong to me.  I think this 
> should be just "element" or "start and end element tags".
> 
> ...
> 
> Section 5.1, lexical-to-value mapping, muddled?
> 
> I don't understand this, and it seems over-complicated.
> 
> My understanding is that we decided that XML literals are self denoting 
> like plain literals, hence the lexical mapping maps the lexical value to 
> itself.  The surrounding description of the lexical space and the value 
> space, which are both canonical XML, supports this view.
> 
> ...
> 
> Section 6.4, 3rd para (just after numbered list), editorial.
> 
> I think this description of disallowed octets could be confusing.
> 
> For example, the current work-in-progress draft of RFC2396bis [1] uses 
> '['...']' in IPv6 literals in the 'authority' component of a URI, and 
> requires them to be escaped everywhere else.
> 
> I think the problem stems from the dual purpose of escaping in URIs (to 
> protect special characters from interpretation, and to include otherwise 
> disallowed characters in a URI.  I'm not sure how to fix this, other 
> than to suggest maybe "less is more";  e.g.
> 
> "The disallowed octets that must be %-escaped include all those that do 
> not correspond to US-ASCII characters, and any others that would 
> otherwise be interpreted inappropriately according to the URI 
> specification and URI scheme specification concerned."
> 
> [1] http://www.apache.org/~fielding/uri/rev-2002/rfc2396bis.html
> 
> ...
> 
> Section 6.5, para 1, editorial.
> 
> I'm not sure what "named" means here.  Suggest drop this word.
> 
> ...
> 
> Section 6.5, para 4, 2nd Note, editorial.
> 
> (a) s/tag only relates to/tag relates only to/
> 
> (b) I initially misread "typed data" here to mean something "user keyed 
> data".  Suggest s/typed data/data of some type/, or something like 
> that.  (or "data values"?)
> 
> ...
> 
> Section 6.5, para 4, 3rd Note, editorial suggestion.
> 
> I found this was unnecessarily diffident about what it was saying.
> Suggest:
> s/implicitly/consequently/
> s/is not intended to/does not/
> 
> ...
> 
> Section 6.6, para 1, editorial.
> 
> While I (think) I understand the intent, I realized I don't really know 
> what "pairwise disjoint" means:  can you add a less mathematical 
> explanation of this?
> 
> ...
> 
> Section 6.6, para 2, editorial.
> 
> The previous para has just referred to three different sets, so I suggest:
> 
> "Otherwise, this set of blank nodes is arbitrary."
> 
> ...
> 
> Section 6.6, implementation note, editorial.
> 
> This note seems to be misplaced.  It appears at the end of a section 
> about blank nodes, but actually talks about rdf:XMLLiteral representations.
> 
> I think it really belongs (possibly with some massaging of the example) 
> just before section 6.1.
> 
> ...
> 
> That's all.
> 
> #g
> 
> 
> -------------------
> Graham Klyne
> <GK@NineByNine.org>
> PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
> 


-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875

Received on Friday, 20 June 2003 08:24:19 UTC