Re: test cases for FILTER scope and order, take 2

Lee Feigenbaum wrote:
> 
> I'm resending my initial message. My thanks to Andy for pointing out 
> that my original test cases weren't really testing anything. I've 
> changed since then to using !bound(?x) as my FILTER of choice -- by my 
> thinking, in this case, if FILTER does not share the same scope with the 
> matching triple pattern, than bound(?x) will evaluate to false and 
> !bound(?x) will evaluate to true, meaning that the query will have one 
> solution. In the cases where FILTER does share the same scope with the 
> matching triple pattern, then !bound(?x) should evaluate to false, 
> thereby eliminating any solutions from the query.
> 
> I've checked in the updated tests. I think the two FILTER order tests 
> are OK as is, so they remain unchanged.
> 
> The rest of this message is the same as the original, except that I've 
> fixed the queries.
> 
> Andy or anyone else, please let me know if you think that this is still 
> foobar. Sorry for the hiccup.
> 
> Lee
> 
> __________________
> 
> 
> Hi DAWGers,
> 
> I've cheked into CVS six test cases for the scope and order of FILTER 
> clauses as per this (unresolved) email thread:
>   http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0186.html
> 
> What I've checked in (results-wise) is my *personal* thought on what the 
> behavior of FILTER is. My original message points out that the current 
> spec. is underspecified, so these test cases are not based on it. I'd 
> welcome discussion on what the results of these tests should be, and 
> hopefully from there we can determine an overall design and from there 
> we can fashion spec text.
> 
> The tests are described in this test manifest:
>   http://www.w3.org/2001/sw/DataAccess/tests/data/Filter/manifest.n3
> 
> I'm summarizing them here:
> 
> -- data --
> 
> @prefix ex: <http://example.org/>
> ex:s ex:p 1.
> 
> -- FILTER scope test cases --
> 
> -- dawg-filter-scope-001--
> 
> Opinion: A FILTER appearing in the same FilteredBasicGraphPattern (a 
> sibling in the query tree) as a triple pattern matching the graph should 
> constrain bindings arising from that triple pattern.
> 
> PREFIX ex: <http://example.org/>
> SELECT ?x
> {
>   ex:s ex:p ?x .
>   FILTER(!bound(?x)) .
> }
> 
> ==> {}

Passed.

> 
> 
> -- dawg-filter-scope-002
> 
> Opinion: A FILTER appearing in the same (inntermost) Group (an uncle in 
> the query tree) as a triple pattern matching the graph should constrain 
> bindings arising from that triple pattern.
> 
> PREFIX ex: <http://example.org/>
> SELECT ?x
> {
>   { ex:s ex:p ?x }
>   FILTER(!bound(?x)) .
> }
> 
> ==> {}
> 

Passed.

> 
> -- dawg-filter-scope-003
> 
> Opinion: Bindings introduced by a matching triple pattern which appears 
> in a BGP which is a sibling of a Group in which a FILTER appears is 
> unconstrained by that FILTER. (In this relationship, the FILTER is a 
> nephew of the triple pattern in the query tree.)  
> 
> PREFIX ex: <http://example.org/>
> SELECT ?x
> {
>   ex:s ex:p ?x .
>   { FILTER(!bound(?x)) }
> }
> 
> ==> {?x/1}

This isn't so much scope as about the algebra.

This looks correct if we had bottom-up evaluation of the SPARQL algebra.
If we change to bottom-up evaluation, this test does capture what I would expect.

Currently, ARQ fails this because the whole of the current solution being 
processed is available across the group and it's subelements (declarative 
semantics).

> 
> 
> -- dawg-filter-scope-004
> 
> Opinion: Bindings introduced by a matching triple pattern which appears 
> in a BGP in a sibling Group of a Group in which a FILTER appears is 
> unconstrained by that FILTER. (In this relationship, the FILTER is a 
> cousin of the triple pattern in the query tree.)  
> 
> PREFIX ex: <http://example.org/>
> SELECT ?x
> {
>   { ex:s ex:p ?x } .
>   { FILTER(!bound(?x)) } .
> }
> 
> ==> {?x/1}
> 
> 
> 
> -- FILTER order test cases --
> 
> --dawg-filter-order-001
> 
> Opinion: The order in which a FILTER appears vis a vis triple patterns 
> in the same FilteredBasicGraphPattern does not matter.
> 
> PREFIX ex: <http://example.org/>
> SELECT ?x
> {
>   ex:s ex:p ?x .
>   FILTER(?x=1) .
> }
> 
> => {?x/1}
> 

Passed.

> 
> -- dawg-filter-order-002
> 
> Opinion: The order in which a FILTER appears vis a vis triple patterns 
> in the same FilteredBasicGraphPattern does not matter.
> 
> PREFIX ex: <http://example.org/>
> SELECT ?x
> {
>   FILTER(?x=1) .
>   ex:s ex:p ?x .
> }
> 
> ==> {?x/1}

ARQ fails this tests because it leaves FILTER in place.  This would pass if 
ARQ were applying FILTERs to the end of groups conceptually.


	Andy

> 
> 
> Lee
>

Received on Tuesday, 24 October 2006 09:36:45 UTC