Re: Test cases

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>

```

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