W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2010

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

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Wed, 07 Jul 2010 11:19:38 +0100
Message-ID: <4C3454BA.1070805@talis.com>
To: Olivier Corby <Olivier.Corby@sophia.inria.fr>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>


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 Wednesday, 7 July 2010 10:20:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:43 GMT