Comments on Concepts editors' draft 2003-06-19

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

Received on Friday, 20 June 2003 08:17:54 UTC