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

Note items marked
**TODO
are not yet processed, but await responses to this e-mail.

Graham Klyne wrote:

> 
> Section 1, final para, editorial:
> 
> Suggest:
> "applications in the primer" --> "applications mentioned in the primer"
> 


Done

> 
> 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.
> 



Hmm this point is overlaboured.
In abstract:
[[
RDF Concepts and Abstract Syntax defines an abstract syntax on which RDF is 
based, and which serves to link its concrete syntax to its formal semantics.
]]

In section 1
[[
This document defines an abstract syntax on which RDF is based, and which 
serves to link its concrete syntax to its formal semantics.

]]

In section 1.1
[[
RDF's abstract syntax is a graph, which can be serialized using XML (but 
which is quite distinct from XML's tree-based infoset [XML-INFOSET]). The 
abstract syntax captures the fundamental structure of RDF, independently of 
any concrete syntax used for serialization. The formal semantics of RDF are 
defined in terms of the abstract syntax.
]]

The 1.1 comment then leads into text about XMLLiteral, which resonates a 
little with the infoset reference. It would probably be better to not 
delete it altogether:

**TODO
How about deleting the quoted text from 1.1 and changing the 1 text to
[[
This document defines an abstract syntax on which RDF is based, and which 
serves to link its concrete syntax to its formal semantics.
This
abstract syntax is quite distinct from XML's tree-based infoset [XML-INFOSET].
]]



> 
> Section 2.1, final bullet, editorial.
> 
> The term "lingua franca" should not be italicized (at least, according 
> to my Oxford dictionary)
> 
> ...
> 

Done


> Section 3.4, second para, significant.
> 
> s/arc/predicate/
> 
> ...
> 

Done


> Section 3.4, 4th para (just after bulleted list), editorial.
> 
> Strictly speaking "which" is incorrect here.  Use "that".
> 
> ...
> 

Done


> 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).
> 
> ...
> 


Done


> 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".
> 
> ...
> 


Replaced "a set of strings." by "a set of Unicode [UNICODE] strings."
to mirror the phrase used in the defn of the lexical form of a literal.


> 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.
> 
> ...
> 


rejected. I prefer the strict correctness of the text "one or more"


> 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."
> 


accepted


> ...
> 
> 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".
> 
> ...


correct - I have checked, and the term does use "tag" so I have corrected 
this. Now "when embedded between an arbitrary XML start tag and an end tag"


> 
> 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.
> 
> ...
> 


I hate to suggest it but, how about:

** TODO
Note: the lexical space and value spaces differ in that
the lexical space is a set of Unicode strings, whereas the value
space is a set of UTF-8 octet sequences.

Otherwise leaving the text unchanged so that the same text is used to talk 
about the lexical space and the value space.


> 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
> 
> ...
> 


No changes made - this area is a mess I look forward to being able to defer 
to IRI spec as an erratum - we got through last call with the current text 
- I agree it is fragile.


> Section 6.5, para 1, editorial.
> 
> I'm not sure what "named" means here.  Suggest drop this word.
> 
> ...
> 


I prefer to leave it, since it emphasises that a typed literal is different 
from a plain literal with a language tag not only because RFC 3066 is a 
different set of strings from URIs, but because the second component has a 
different name.


> 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"?)


I will delete the phrase "how to best represent typed data to the end-user" 
since this note originally related to abuse of the langauge tag in typed 
literals.


> 
> ...
> 
> 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/
> 


done


> ...
> 
> 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?
> 
> ...
> 


No. I feel that expanding this e.g. "(no two have a common member)" will 
not really make it any more accessible. Someone who struggles with this 
phrase is best off looking for another source of info e.g. google for 
"pairwise disjoint"


> 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."
> 


Done


> ...
> 
> 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.
> 


OK
WIth some simplification of the wording which is somewhat redundant in that 
position.


> ...
> 
> That's all.
> 
> #g
> 
> 
> -------------------
> Graham Klyne
> <GK@NineByNine.org>
> PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
>

Received on Monday, 30 June 2003 10:34:27 UTC