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

After fixing a bug in ARQ, all the tests now pass for me (I added the 
sqNN to the name to make it easier to go back to the test):

Test: sq01 - Subquery within graph pattern
Test: sq02 - Subquery within graph pattern, graph variable is bound
Test: sq03 - Subquery within graph pattern, graph variable is not bound
Test: sq04 - Subquery within graph pattern, default graph does not apply
Test: sq05 - Subquery within graph pattern, from named applies
  WARN [main] (ALog.java:48) - sq05 - Subquery within graph pattern, 
from named applies : query data source and also in test file
Test: sq06 - Subquery with graph pattern, from named applies
  WARN [main] (ALog.java:48) - sq06 - Subquery with graph pattern, from 
named applies : query data source and also in test file
Test: sq07 - Subquery with from
  WARN [main] (ALog.java:48) - sq07 - Subquery with from  : query data 
source and also in test file
Test: sq08 - Subquery with aggregate
Test: sq09 - Nested Subqueries
Test: sq10 - Subquery with exists
Tests = 10 : Successes = 10 : Errors = 0 : Failures = 0

So it's now tests 5,6,7 which have the manifest and the FROM/FROM NAMED 
in the query - the manifest and the query agree so it appears to be 
about presentation not objective of the test.

I've changed the queries to remove the dataset descriptions and checked 
in the manifest and queries. Olivier, if that's not right do change them 
to what you intended.

Test: sq01 - Subquery within graph pattern
Test: sq02 - Subquery within graph pattern, graph variable is bound
Test: sq03 - Subquery within graph pattern, graph variable is not bound
Test: sq04 - Subquery within graph pattern, default graph does not apply
Test: sq05 - Subquery within graph pattern, from named applies
Test: sq06 - Subquery with graph pattern, from named applies
Test: sq07 - Subquery with from
Test: sq08 - Subquery with aggregate
Test: sq09 - Nested Subqueries
Test: sq10 - Subquery with exists
Tests = 10 : Successes = 10 : Errors = 0 : Failures = 0

 Andy


On 09/07/2010 1:02 PM, Andy Seaborne wrote:
> 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 Tuesday, 13 July 2010 19:58:17 UTC