Re: ACTION-373 look at subquery tests (3 new test cases proposed for subquery and comments to approved test cases)

On 19 Apr 2011, at 18:30, Lee Feigenbaum wrote:

> On 4/19/2011 12:41 PM, Axel Polleres wrote:
> > In completion of ACTION-373 I finally managed to check the subquery test cases.
> >
> > Existing test cases were all approved in
> >   http://www.w3.org/2009/sparql/meeting/2010-07-13#resolution_3
> >   http://www.w3.org/2009/sparql/meeting/2010-07-13#resolution_3
> >   http://www.w3.org/2009/sparql/meeting/2010-07-13#resolution_4
> >   http://www.w3.org/2009/sparql/meeting/2010-07-13#resolution_5
> > and
> >   http://www.w3.org/2009/sparql/meeting/2010-07-20#resolution_2
> > resp.
> >
> > However, I have some questions/comments on those still and propose 3 new TCs for extending coverage.
> > Summarizing, I have a question regarding ordering in results in the test cases, apart from that
> > my only concerns on the approved TCs regarding their descriptions (mf:name).
> >
> > 1) This is a very general comment on the test cases/test case structure:
> >
> >     e.g. subquery01 (sq01.rq) doesn't have an ORDER BY clause, so any order of the results should be fine.
> >
> >     That brought me to check again the compliance section for test cases, which doesn't say anything about order, but just that
> >     "A SPARQL implementation passes a query evaluation test if the graph produced by evaluating the query against the RDF dataset (and encoding in the DAWG result set vocabulary, if necessary) is equivalent [RDF-CONCEPTS] to the graph named in the result (after encoding in the DAWG result set vocabulary, if necessary)."
> >
> >     Do I understand right that this doesn't cover ordering? Did DAWG discuss anything about ordering of results in test cases?
> >     in my understanding, in the result-set.n3 format is multiple solutions are unordered:
> >
> >       ## =======================================
> >       ## Modelling style: uses multiple instances of a property
> >       ## to represent multiple results.
> >       ## e.g. :ResultTable has many :hasSolution properties, one per row
> >
> >   I wonder how compliance of ORDER BY tests is then to be tested, whether anyone has thought of that earlier,
> >   or whether I just overlooked forgot some earlier discussion in this regard?
> 
> The sorted tests use the rs:index property to specify order, I believe?
> See the sort/ directory.

looked into that, seems that rs:index is missing from result-set.n3 
as far as I can tell. 

Suggested path to resolve this:

 1) I adapted result-set.n3 by adding rs:index property (it was not mentioned there), i.e. added 

 :index rdf:type rdf:Property ;
        rdfs:comment    "index of the current solution, this property is only to be used when order of solutions is relevant for passing the test. If one solution has an inex property all solutions must have it and solutions have to be indexed from 1 to n." ;
        rdfs:domain     :ResultSolution ;
        rdfs:range      xsd:integer ;
        .

   Note that this has been changed under the 2001 directory i.e. at:
     http://www.w3.org/2001/sw/DataAccess/tests/result-set.n3
    but since this can be considered an erratum, that should be ok. So, I committed that change.

 2) Extending the text in README.html as follows:

 "A SPARQL implementation passes a query evaluation test if the graph produced by evaluating the query against the RDF dataset (and encoding in the DAWG result set vocabulary, if necessary) is equivalent [RDF-CONCEPTS] to the graph named in the result (after encoding in the DAWG result set vocabulary, if necessary). Note that, solution order only is considered relevant, if the result is expressed in the test suite in the DAWG result set vocabulary, with explicit rs:index triples; otherwise solution order is considered irrelevant for passing."

 I committed that in the tests README.html
 
> 
> > 2) Editorial, I suggest to change descriptions of sq01 and sq06:
> >
> >   s/"sq0x - Subquery within graph pattern"/"sq0x - Subquery within GRAPH graph pattern"
> >
> >   since any subquery is within a "graph pattern", as "graph pattern" is the general term for all graph patterns.
> 
> Go ahead and make this change in the manifest, please.
> 

done.

> 
> > 3) What does sq05 illustrate as opposed to sq01?
> >    Also Description of sq05 "sq05 - Subquery within graph pattern, from named applies" is not clear to me.
> 
> I don't think it's worthwhile to revisit tests that are valid but
> potentially superfluous...
> 

left the test case, adapted description slightly.

> > 4) Description of sq06 "sq06 - Subquery with graph pattern, from named applies" is not clear to me.
> >     Suggested: change to
> >        "sq06 - Subquery on default graph"
> >     ?
> 
> Go ahead and make this change in the manifest, please.
> 

done.

> > 5) Description of sq07 "sq07 - Subquery with from" is not clear to me.
> >     change to
> >        "sq07 - GRAPH graph pattern within subquery"
> >     ?
> 
> Go ahead and make this change in the manifest, please.
> 

done.

> > 6) As for coverage, I suggest to add three more test case that
> >      a) illustrate the limit-per-resource use case http://www.w3.org/2009/sparql/wiki/Feature:LimitPerResource
> >      b) illustrate a subquery that uses built-ins within CONSTRUCT.
> >      c) illustrate the join semantics of subqueries (as opposed to an injecting semantics which some people might expect)
> >
> >     To this end, I added subquery11-subquery13 to CVS, check http://www.w3.org/2009/sparql/docs/tests/data-sparql11/subquery/manifest.ttl
> 
> Great. Andy, Greg, Olivier, etc., can you try these 3 test cases out?
> 
> thanks,
> Lee
> 
> > best,
> > Axel
> >
>

Received on Tuesday, 19 April 2011 22:26:30 UTC