W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2004

Re: SPARQL / Language spec ready for review

From: Simon Raboczi <raboczi@tucanatech.com>
Date: Sun, 10 Oct 2004 22:58:05 +1000
Message-Id: <06DF1431-1ABC-11D9-9647-000A95C5686E@tucanatech.com>
Cc: Eric Prud'hommeaux <eric@w3.org>, public-rdf-dawg@w3.org
To: andy.seaborne@hp.com


On 09/10/2004, at 2:37, Seaborne, Andy wrote:

> Thanks for the comments so far.  Changes and non-changes described 
> inline.
>
> I'll carry over these comments when you send further reviewers 
> feedback.

I have no further comment on your comments to my comments, so I'll skip 
copying them all out again.   Continuing from section 2.2 in revision 
1.104:

===

[[ 1.104 -- 2.2 Triple Patterns
A triple pattern is matched against the graph by finding values for 
values for variables...
]]

should be

[[ suggestion -- 2.2 Triple Patterns
A triple pattern is matched against the target graph by finding values 
for variables...
]]

===

[[ 1.104 -- 2.3 Graph Patterns
The keyword WHERE is followed by a Graph Pattern which is made of one 
or more Triple Patterns.
]]

I would prefer "Graph Pattern" and "Triple Patterns" to not be in 
monospace font.  Monospace suggests verbatim valid SPARQL syntax, which 
"WHERE" is, but which the other two aren't

===

[[ 1.104 -- 2.3 Graph Patterns -- Definition: Graph Pattern (Partial 
Definition) -- Conjunction
For binding B, we write subst(GP, B) for the set of triples patterns...
]]

"triples" should be "triple"

===

[[ 1.104 -- 2.3 Graph Pattern Matching
Graph Pattern GP matches RDF graph G with set of bindings SB if 
subst(GP, SB) is a subgraph of G.
]]

I think this should be "...is a non-empty subgraph of G."

===

[[ 1.104 -- 2.4 Multiple Matches -- Definition: Pattern Solution
A Pattern Solution of Graph Pattern GP on graph G is any set of 
bindings SB such that GP matches G for with SB.  Each binding B in SB, 
has a different variable.
]]

"for with" should be "for" or "with".
No comma after "Each binding B in SB".

===

3 Constraining Values

We should at least mention that it's the "AND" clause syntax that's 
being introduced, rather than expecting the reader to figure that out 
solely from the example.

===

[[ 1.104 -- 4 Including Optional Values
...The application writer would such additional information but does 
not want the query to not match just because the some information is 
missing.
]]

I'm not quite sure how to rewrite this, but it needs to be rewritten!

===

[[ 1.104 -- 4.2 Multiple Optional Blocks
A query may have zero or more top-level optionals blocks.
]]

"optionals" should be "optional"

===

[[ 1.104 -- 4.2 Multiple Optional Blocks
In this example, there are two, independent optional blocks. ...
]]

Neither of the commas are required.

===

[[ 1.104 -- 4.2 Multiple Optional Blocks
... Reversing the order of the optional blocks would reverse the blocks 
in which the variable was introduced and was used to constraint. ...
]]

"constraint" should be "constrain"

===

[[ 1.104 -- 4.3 Optional Matching -- Formal Definition
In an optional match, either a graph pattern matches graph and so 
defines...
]]

"matches graph" should be "matches a graph"

===

[[ 1.104 -- 8 Choosing What to Query
The FROM clause gives URIs that the query processor can use to supply 
RDF Graphs for the query execution.
]]

The use of "can" rather than "must" baffles me here.  If a FROM clause 
is present, there's no wiggle room -- the target graph has been 
precisely specified.  The only alternative is for the query processor 
to signal an error because it cannot access the named RDF Graph(s).

===

[[ 1.104 -- 8 Choosing What to Query
A query processor could use this URI to retrieved the document, parse 
it and use the resulting to provide the query graph.  ...
]]

"retrieved" should be "retrieve"
"resulting" should be "result"
(Parenthetically, how about ditching the CommaOpt in the FROM clause 
example of multiple target URIs?)

===

[[ 1.104 -- 9 Querying the Origin of Statements
.. A data store that does not support source SHOULD bind SOURCE 
variables to NULL and fail to match source-constrained queries.
]]

I'm uncomfortable with the introduction of NULL in this section.  I'd 
prefer the SOURCE variable be bound to a new bNode representing the 
unknown source, for each triple pattern bearing a SOURCE prefix  I 
believe this gives the desired behavior.

===

[[ 1.104 -- 9 Querying the Origin of Statements
.. Alice guess of Bob's age (3) is /not/ returned.
]]

"Alice" should be "Alice's"

===

(Section 11 and further tomorrow...)
Received on Sunday, 10 October 2004 12:58:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:21 GMT