Re: editorial comments on CR dated 6 april 2006

Changes in

http://www.w3.org/2001/sw/DataAccess/rq23/
v1.686

Fred Zemke wrote:
> 
> 
> 
> Some (hopefully) editorial comments:
> 
> 2.1.1 Syntax for IRIs
> It would be helpful to have examples of the two abbreviated syntaxes.
> One might think that abbreviated syntaxes must be written in angle
> brackets.

Examples added.

> 2.3 Triple patterns
> The last sentence of this section says "This definition also
> allows blank nodes in the predicate position."  But the
> second component of a triple pattern is a member of I union V,
> where I is the set of IRIs and V is the set of variables.
> Thus it seems that SPARQL blank nodes are not permitted in
> the second position.  Also the BNF for Verb says it may be
> VarOrIRIref or 'a', so it seems that a SPARQL blank node can not
> be a predicate.

Already fixed.  Blank nodes are not permitted in the predicate position of a 
triple pattern.

> 2.4 Pattern solutions
> The first two sentences in the box use the following terms:
> "variable solution", "substitution function", "pattern solution",
> and "variable substitution".  How are these terms related?
> Taken literally, it says that "a variable solution is a substitution
> function" and a "pattern solution is a variable substitution".
> Thus the first and second sentence seemingly have nothing to do
> with one another. In that case, why is the first sentence, about
> "variable solution", found in a box called "Definition: pattern
> solution"?  This is very confusing.  The reader is left
> suspecting that in fact all four terms are interchangeable.
> Furthermore, scanning the rest of the document, one finds that
> "variable solution" is never used at all, and the
> term "solution" is frequently used without qualification (neither
> as "variable solution" nor as "pattern solution"). We should use
> our terminology consistently.

The phrase "variable solution" has already been removed.  "pattern solution" 
should now be the only phrase to use "solution" and "solution" is used as a 
short form. "substitution function" is a mathematical term.


> 2.5.1 General framework
> Definition of "basic graph pattern E-matching", first bullet
> talks about BGP and BGP' being "graph-equivalent".  This term
> is not defined; instead "equivalent" is.  we should use our
> terminology consitently.

graph-equivalent is linked to RDF concepts on first mention and also in the 
scoping graph definition - it's terminolgy from RDF concepts.

I added the same link in "Definition:  Basic Graph Pattern E-matching"

The end of 2.5 says:

"""
This definition extends that for RDF graph-equivalence to basic graph patterns 
by preserving variables names across equivalent graphs
"""

(missing full stop - added)

is this what you meant?

> 9 Specifying RDF datasets
> A graph is specified using an IRI, which can be a QName, but there
> are no examples of using a QName to specify a graph.  This would
> be helpful.


In the sense that prefixed names are syntactic sugar for the full IRI, yes. 
It arises naturally as a prefixed name can be used anywhere for a <> IRI after 
the prefixed are defined.

Maybe one change would be to rename the grammar rule for QNAME and expunge the 
term QNAMEs from the document entirely as it presumes the additional RDF rule 
about turning QNAMEs into IRIs.

How about changing the example in 9.2 to use prefixed names for one of the 
graphs and adding a line of text about this?

> 10.1 solution sequences and result forms
> The first formal definition says that a "solution sequence" is
> a "list".  Both of these terms imply ordering.  Then the last
> sentence in the first box says "The solution sequence from
> matching the query pattern is an unordered collection...".  
> This is contradictory.  What we probably mean is that "The
> solution sequence from matching the query pattern is in an
> implementation-dependent order".  

Changed to:

"""
The solution sequence from matching the query pattern is a collection formed 
from the solutions of the query pattern with no defined order.
"""

I didn't want to say "implementation-dependent order" because it might read 
that an implementation must state and stick to some order.

> 10.1 Solution sequences and result forms
> the last sentence in the first box says "The solution sequence
> from matching the query pattern is an unordered collection...".
> This sentence is not part of the definition
> of "solution sequence" so it should be placed outside the box.

Done with the rewording above.

> 10.1 Solution sequence and result forms
> It would be helpful if the stages of processing solution sequences
> were always mentioned in the same order.  The order is given as
> ORDER BY, project, DISTINCT, LIMIT, OFFSET.  The text to be
> rearranged is:
> 
> a) In the box for the definition of solution sequence modifier
> (order modifier should be moved ahead of projection modifier)

Done

> b) The arrangement of subsections (10.1.3 ORDER BY should be
> moved ahead of 10.1.1 Projection)

Done

> 
> 
> A.5 Escape sequences in strings
> It says that \U may only be used for Unicode code points in the range
> U+10000 through U+10FFFF.  So the first two HEX digits must always be 00?
> If so, why not show the syntax as '\U00' HEX HEX HEX HEX HEX HEX ?
> A.6 "excape sequences in IRI references" - same comment.

This follows previous work

http://www.w3.org/TR/rdf-testcases/

and UNICODE is only defined upto #x10FFFF but there are private areas of teh 
codepoint space. Keeping it for any future expansion is the only reason I know 
of for leaving open the possibility of \U00 or for private use of UNICODE.

I'd like to clear this up along with a more general overhaul of \u escapes:
http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JanMar/0443.html


> 
> Fred
> 

	Thanks for the comments
	Andy

Received on Wednesday, 7 June 2006 17:58:36 UTC