- From: Simon Raboczi <raboczi@tucanatech.com>
- Date: Sun, 10 Oct 2004 22:58:05 +1000
- To: andy.seaborne@hp.com
- Cc: Eric Prud'hommeaux <eric@w3.org>, public-rdf-dawg@w3.org
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 UTC