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

Andy, thanks very much for patching these up!

We'll move to approve subquery tests 5-10 on Tuesday.

Lee

On 7/13/2010 3:57 PM, Andy Seaborne wrote:
> 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 Thursday, 15 July 2010 03:00:12 UTC