- From: Matthew Perry <matthew.perry@oracle.com>
- Date: Tue, 15 Mar 2011 09:05:01 -0400
- To: W3C SPARQL Working Group <public-rdf-dawg@w3.org>
Hi, My review the query document is below. Thanks, Matt -------------------------------------------------------- More significant comments: --- 9.2 --- Examples should show example data and results to be consistent with rest of doc. --- 9.3 --- which, using the translation of :p* is equivalent to the query: PREFIX : <http://example/> SELECT * { { :x :p{0} ?o } UNION { :x :p+ ?o } } This translation is not used anymore (uses ZeroOrMorePath instead) --- 10.1 (question / comment) --- SELECT ?title ?price { ?x ns:price ?p . ?x ns:discount ?discount BIND (?p*(1-?discount) AS ?price) FILTER(?price < 20) ?x dc:title ?title . } does this become SELECT ?title ?price { {?x ns:price ?p . ?x ns:discount ?discount BIND (?p*(1-?discount) AS ?price) } {?x dc:title ?title . } FILTER(?price < 20) } or SELECT ?title ?price { {?x ns:price ?p . ?x ns:discount ?discount BIND (?p*(1-?discount) AS ?price) } FILTER(?price < 20) ?x dc:title ?title . } --- 11.7 --- It seems that unbound and error will be treated differently now (e.g. encountering a blank node during a sum() gives an error but encountering an unbound value has no effect). I recall that errors used to have the same effect as unbound. If I understand correctly, these queries would have different results now whereas before they gave the same result. SELECT (SUM(?X) + SUM(?Y) AS ?XY) WHERE { ?X :P ?Y } SELECT SUM(?XY) WHERE { SELECT (?X + ?Y) AS ?XY WHERE { ?X :P ?Y } } --- 18.1.7 --- Definition: Property Path A Property Path is a sequence of triples, ti in sequence ST, such that, for i=0 to length(ST)-1, the object of ti is the same term as the subject of ti+1. Does this cover paths matched by { ?s :p.^p ?t } (i.e. an object-object match) Minor comments / typos: --- 1.1 --- [Sections => Section] 11 introduces the mechanism to group and aggregate results, which can [be] incorporated as subqueries as described in Section 12. --- 8.3.3 --- Differences also arise because in a filter variables from the group are in-scope => Differences also arise because variables from the group are in-scope within a filter but are out of scope within a MINUS. --- 9 --- Variables [can not => cannot] be used as part of the path itself, only the ends --- 9.3 --- Where the query matches on arbitrary length paths, [each cycle is considered at most once => cycles are avoided] by stopping if an RDF term in the data would be a matched again in the evaluation of the + or * property path [operators => operator]. For example, on the data [below], which [is a graph with a cycle in it => includes a cycle], --- 11.2 --- In order to calculate aggregate values for a solution, the solution is first divided into one or more groups, and [the the => the] aggregate value is calculated for each group. Definition: Property Path Expression A property path expression is an expression used to match properties in a graph formed after translation of the path syntax as defined [above -- this link doesn't go anywhere]. --- 18.2.1 --- We define a variable to be in-scope if there is a way for a variable to be in the domain [of] a solution mapping at that point in the execution of the SPARQL algebra for the query The scoping for (expr AS v) applies immediately. In SELECT expressions, the variable may [use => be used] in an expression later in the same SELECT clause and may not [be be => be] assigned again in the same SELECT clause. --- 18.2.5.6 --- If the clause is ( 'BINDINGS' Var* '{' ( '(' BindingValue* ')' | NIL )* '}' )? then for each list of BindingValue, form the solution mapping [of => remove] from the variable in the coresponding position in Var*, omitting if the BindingValue is word UNDEF.
Received on Tuesday, 15 March 2011 13:05:33 UTC