Re: Test cases

Geoff Chappell wrote:
> OK, the first is the test OPTIONAL-FILTER.
> 
> In addition to the results given for the test, I also get:
> 
> 	title="Title 1", price=unbound
> 
> I get to this from this transformation:
> 
> ?book dc:title ?title .
>       OPTIONAL
>         { ?book x:price ?price .
>           FILTER ?price < 15 .
>         } .
>     }
> 
> or 
> 	A OPTIONAL (B AND C)
> or
> 	(A AND (B AND C)) or (A AND NOT(B AND C))
> or 
> 	(A AND B AND C) or (A AND NOT B) or (A AND NOT C)
> 
> 
> the result comes from the last term (A AND NOT C) or
> 
> 	{?book dc:title ?title } NOT FILTER ?price < 15

Geoff,

I agree with the rewriting in logical terms but I think it needs to take into 
account when variables are being bound.

OPTIONAL
         { ?book x:price ?price .
           FILTER ?price < 15 .
         } .

means that the FILTER is applied when "?book x:price ?price" matches.  When 
rewriting, that additional piece of information needs to be catered for as well. 
  I think this is covered by requiring S, a group solution, to be a solution of 
the OPTIONAL within the group.

One way is that the evaluation of FILTER ?price < 15 needs to be something like:

   {?book dc:title ?title }  FILTER( bound(?price) && ?price < 15 )

to reflect the other rewrites.

	Andy

> 
> I believe the transformations are valid given the current definitions of
> various flavors of graph pattern solutions. 
> 
> My take is that to get the result specified by the test, FILTERs would have
> to be treated as inseparable from the graphs they are constraining -- i.e.
> they couldn't be stand-alone graph patterns but would have to always be
> paired with a graph. That would seem to imply that the FILTER keyword
> doesn't just introduce a filter pattern but is an operator of sorts that
> isn't a synonym for AND (so NOT(A FILTER B) != NOT A or NOT B.) 
> 
> I think that might be the intent of FILTER patterns, but it's doesn't appear
> to be currently supported by the syntax:
> 
> """[23]   GraphPatternNotTriples   ::=   OptionalGraphPattern |
> UnionGraphPattern | GroupGraphPattern | GraphGraphPattern | Constraint"""
> 
> i.e. a Constraint is treated as a stand alone pattern...
> 
> or the semantics:
> 
> """Definition: Graph Pattern
> 
> A Graph Pattern is one of:
> 
> Basic Graph Pattern 
> Group Pattern 
> Optional Graph Pattern 
> Union Graph Pattern 
> RDF Dataset Graph Pattern 
> Value Constraints"""
> 
> And 
> 
> """Definition: Group Graph Pattern 
> 
> A group graph pattern GP is a set of graph patterns, GPi.
> 
> A solution of Group Graph Pattern GP on graph G is any solution S such that,
> for every element GPi of GP, S is a solution of GPi."""
> 
> i.e. this says that a solution of a group pattern must be a solution of GP0
> AND GP1 AND....
> 
> Hope that makes some sense.
> 
> Best,
> 
> Geoff 
>

Received on Wednesday, 8 June 2005 12:24:40 UTC