Re: Subquery tests: [was: ACTION-270 completed]

Test 8 has a problem of a different kind:

------------
prefix ex: <http://www.example.org/schema#>
prefix in: <http://www.example.org/instance#>

select ?x ?max where {
   {
     select ?x (max(?y) as ?max )where {?x ex:p ?y}
   }
   ?x ex:p ?max
}
------------

In the inner SELECT, the projected ?x is neither a group-by variable nor 
an assigned variable via AS.  It's illegal to use it in such circumstances.

http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#aggregateExample

[[
In aggregate queries and sub-queries only expressions which have been used
as GROUP BY expressions, or aggregated expressions (i.e. expressions 
where all
variables appear inside an aggregate) can be projected.
]]

 Andy

Steve - this should move to somewhere not labelled as an example.
It's also not completely true - I can project an expression of aggregate 
expressions and group-by variables as well e.g.

SELECT (COUNT(*)+?x AS ?y ) WHERE { ...}  GROUP BY ?x

(COUNT(*)+?x AS ?y ) is used as a GROUP BY expression, nor is it an 
aggregated expression.


Also, my experience is that the "@@ note" is not true.

On 07/07/2010 11:19 AM, Andy Seaborne wrote:
>
>
> On 07/07/2010 8:39 AM, Olivier Corby wrote:
>>> http://www.w3.org/2009/sparql/docs/tests/data-sparql11/subquery/
>>>
>>>
>>> Tests: 4,5,6,7
>>> Both queries and manifest have dataset descriptions
>>>
>>> FROM and qt:data
>>> FROM NAMED and qt:graphData
>>>
>>> test 6: change to qt:data to get answers in the results file.
>>> test 8: change to qt:data to get answers in the results file.
>>
>> Test 4 is designed this way to check that "from" does not apply ant that
>> dataset applies with graph pattern.
>> Test 5 declares that we need sq05.rdf in the dataset and the from named
>> specifies sq05.rdf, so for me it is correct
>> Test 7 is designed this way to check that "from" does not apply ant that
>> dataset applies with graph pattern.
>
> It seems to me that we're testing the relationship of the manifest to
> the query, not the subquery feature. This is most striking in test 4
> where the manifest and the query differ and it assumes the manifest wins
> and is going to override the FROM/FROM NAMED in the query (if we
> interpret the manifest as being like the protocol).
>
> To test that the dataset is the same in subqueries and outside, how
> about something like:
>
> SELECT ?x
> where {
> { ?s ?p ?o } UNION {select * where {?s ?p ?o} }
> }
>
> or
>
> SELECT ?x
> where {
> { ?s ?p ?o {select * where {?s ?p ?o} } }
> }
>
> i.e. do something inside and outside a subquery and the result record
> the same bindings or do something that compares them.
>
> I agree with the results for these (in the case of 4, because the
> manifest overrides the FROM).
>
>> Test 6 & 8 has an error, we need to replace qt:graphData with qt:data
>>>
>>>
>>> Test 3:
>>> Got: 1 --------------------------------
>>> --------
>>> | x |
>>> ========
>>> | in:c |
>>> --------
>>> Expected: 2 -----------------------------
>>> --------
>>> | x |
>>> ========
>>> | in:a |
>>> | in:c |
>>> --------
>>>
>>> (this is what is in the original email)
>>>
>>> This makes sense to me because:
>>> select ?x where {
>>> graph ?g {
>>> {select ?x where {?x ?p ?g}}
>>> }
>>> }
>>> and the inner SELECT ?x masks out the ?g in the subquery.
>>
>> Test 3 is correct, there are two triples with two different subjects in
>> current graph. Variable ?g is not bound in subquery.
>
> And a good test it is too - one of my engines gets the wrong answers.
>
> The query doc needs some work here - we don't yet have the way that
> subqueries fit into the algebra and project does cause an aliasing
> issue. I think the defn in SPARQL 1.0 for evaluation of GRAPH is good
> enough but (Steve, as subquery editor) do let me know if it's not.
>
> Andy

Received on Friday, 9 July 2010 12:02:42 UTC