- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Wed, 14 Jul 2010 22:59:34 -0400
- To: Andy Seaborne <andy.seaborne@talis.com>
- CC: Olivier Corby <Olivier.Corby@sophia.inria.fr>, SPARQL Working Group <public-rdf-dawg@w3.org>
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