Re: SPARQL / Language spec ready for review

Simon Raboczi wrote:
> 
> 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...
> ]]

v 1.107
Changed to "matched against a graph" - we haven't talked about what is being 
queried much yet in the doc.


> 
> ===
> 
> [[ 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

v1.107
Agreed - not sure how that happened.  <em>'ed to emphasis they are defined 
terminology.

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

No need.

If |GP| >= 1, then |subst(GP, SB)| >= 1 so its not necessary.
If GP is the empty set, then its trivially true.

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

v 1.107
Done

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

v 1.107
Have added some words.  As syntax is still unstable, I was avoiding naming it.

"""
Constraints in SPARQL take the form of boolean-valued expressions; the language 
also allows application-specific filter functions.
"""
> 
> ===
> 
> [[ 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"

v1.107
Done

> 
> ===
> 
> [[ 1.104 -- 4.2 Multiple Optional Blocks
> In this example, there are two, independent optional blocks. ...
> ]]
> 
> Neither of the commas are required.

v1.10
Both of OK - have removed second beause teh world does not like commas.

I see another panda.

> 
> ===
> 
> [[ 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"

v1.107
Done.

> 
> ===
> 
> [[ 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"

v1.107
Done.

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

nack.  FROM is a hint.  This is my current understanding from the discussions on 
the list.

The wording was intentional.  Techncially it should be MAY.  A query processor 
can ignore FROM (e.g. overridden externally by context or protocol).

Note that "specified" still has a lot off wiggle room.  "access" is dubious as 
well it might imply that the graph MUST be read each time, not using a cached or 
earlier version.  These possibilities are supposed to be allowed.

The URI of a graph is not the URI of its serialization.

> 
> ===
> 
> [[ 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?)

v1.107
First typo's done.
Second already says "use the resulting triples to provide"

Please take other issues to the list.  Note that there two two kinds of people: 
those that like commas in lists and those who like the uniformity of no separator.

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

Agreed but will leave to Eric/Dave.  There should be no NULLs anywhere.  NULLs 
are a way of presenting absence.  This section is just hanging around until we 
have a proposed resolution of SOURCE.

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

Done.

> 
> ===
> 
> (Section 11 and further tomorrow...)
> 
>

Received on Monday, 11 October 2004 08:39:54 UTC