- 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