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

Jeremy,

all your suggested changes and non-changes look OK to me.

(Re. XML literals, I hadn't reealized the difference previously, so I think 
the note you suggest is helpful.)

Thanks.

#g
--

At 15:33 30/06/03 +0100, Jeremy Carroll wrote:
>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

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

Received on Monday, 30 June 2003 16:06:56 UTC