W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2011

Query Document Review

From: Matthew Perry <matthew.perry@oracle.com>
Date: Tue, 15 Mar 2011 09:05:01 -0400
Message-ID: <4D7F63FD.5090602@oracle.com>
To: W3C SPARQL Working Group <public-rdf-dawg@w3.org>

My review the query document is below.


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/>
    { :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)


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.

WHERE { ?X :P ?Y }

         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.

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:03 UTC