- From: Andy Seaborne <andy.seaborne@talis.com>
- Date: Wed, 07 Jul 2010 11:19:38 +0100
- 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 UTC