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

"Seaborne, Andy" <andy.seaborne@hp.com> wrote on 10/24/2006 05:36:04 AM:
> Lee Feigenbaum wrote:
> > 
> > 
> > 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
> > 
> > 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-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).

I agree that these tests are about the interplay of scope and algebra, and 
I hinted as to my thoughts on this on my recent post about the Semantics 
of SPARQL paper. Basically, the algebra needs to specify which graph 
pattern is an operand of FILTER. Via the semantics of the FILTER operator, 
it is only the solutions derived from said graph pattern which are 
constrained by the FILTER, i.e., the algebra determines the scope of the 
FILTER.

I'm content to wait on approving this test and the next until we agree on 
the operational-algebra style of definitions, about which it seems we are 
all mostly in agreement.

> > -- 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-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.
 
Right, that's why I included the test -- I changed my implementation to be 
scoped  to the full group, which means it gets applied conceptually at the 
end. (And in doing so, I went from failing this test to passing it, as you 
said.)

Lee

Received on Thursday, 26 October 2006 20:10:19 UTC