From: Seaborne, Andy <andy.seaborne@hp.com>

Date: Wed, 08 Jun 2005 13:24:08 +0100

Message-ID: <42A6E368.5030208@hp.com>

To: Geoff Chappell <geoff@sover.net>

CC: public-rdf-dawg-comments@w3.org

Date: Wed, 08 Jun 2005 13:24:08 +0100

Message-ID: <42A6E368.5030208@hp.com>

To: Geoff Chappell <geoff@sover.net>

CC: public-rdf-dawg-comments@w3.org

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

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 20:52:06 UTC
*