test cases for FILTER scope and order, take 2

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)) . 
} 

==> {} 


-- 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)) . 
} 

==> {} 


-- 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} 


-- 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} 


-- 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} 


Lee