Re: BIND tests

On 25/01/11 03:26, Lee Feigenbaum wrote:
> I'm revisiting this now, and I think I better understand what Andy is
> observing and suggesting.
>
> First: I believe that the wording that Axel offers above does 'fix' the
> issue Andy identified without changing the semantics that the group
> decided upon previously. It is somewhat awkward though.
>
> Next: If we stuck with a group always being { ... } and a BIND only ends
> a BGP but not the group, then I think that we can keep the existing "in
> place" semantics for BIND without losing the query that motivated that
> decision:
>
> {
> :S :P ?o
> BIND (?o+1 as AS ?o1)
> :S :Q ?o1
> }
>
> The goal of making BIND "in place" was to allow this query, rather than
> have it be an error for binding to ?o1 which is bound in the same group.
> But if BIND ends the BGP and not the group, then the above is
>
> Join(Bind(BGP(:S :P ?o), ?o+1, ?o1), BGP(:S :Q ?o1))

Regardless of the BIND and group decision, that is what the translation 
to the algebra currently in rq25 does.  It is as SPARQL 1.0 with BIND as 
binary operator (like OPTIONAL and MINUS) that operates over it's LHS.

bind() is extend() in the current doc.

http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#defn_extend

It's FILTERs having group, not BGP scope, that was not considered. I, 
for one, had missed that at the time.

> It's ok to bind ?o1 in the Bind(...) operation because ?o1 is not in
> scope there. Yet any filter would still float to outside the group
> (outside the Join(...)).
>
> This would result in bind08 having the same result as bind05 -- since I
> think the bind08 that I committed was not a "desirable" result when we
> first discussed it but instead a side effect, I think this ought to be
> fine. Let's discuss tomorrow, and if we have agreement then I'll change
> the results of bind08 and we can entertain approval of the bind tests.
>
> Lee

Here are some more examples for FILTER and BIND.  We are only concerned 
with FILTERs that touch the variable being set.  The important feature 
of the examples is the assigned expression does not use the values from 
the BGP.

We have several ways of doing assignment, BIND, SELECT/expr, GROUP 
BY(AS), and BINDINGS is they are allowed in nested sub-queries.

Assume BGP ?s :p ?o  matches something.

Issue is whether the FILTER can test ?z
The formulation of the previous discussion was not but there are more 
cases than considered then ...

Q1:

SELECT *
{
   ?s :p ?o .
   FILTER(?z = 123)
   BIND(123 AS ?z)   # Unrelated variable to the BGP.
}

Q2:
SELECT *
{
   ?s :p ?o .
   FILTER(?z = 123)
   { SELECT (123 AS ?z) {} }
}

Q2 works. The algebra is:

   (filter (= ?o1 3)
     (join
       (bgp (triple :S :P ?o))
       (extend ((?z 123))
         (table unit))))

Q3:

SELECT *
{
   ?s :p ?o .
   FILTER(?z = 123)
   { BIND(123 AS ?z) }
}

works (presumably) because the BIND is inside a sub-group because ...

Q4:
# SPARQL 1.0 style:
SELECT *
{
   ?s :p ?o .
   FILTER(?z = 123)
   { ?s :p ?z . FILTER(?z =123) }
}

other ways to assign:

Q5:
SELECT *
{
   FILTER(?o = 123)
   ?s :p ?o .
   OPTIONAL { BIND(123 AS ?z) }
}

Q6:
SELECT *
{
   FILTER(?o = 123)
   ?s :p ?o .
   # Just because you can, does not mean you should!
   { SELECT ?z { ?s :p ?o } GROUP BY (123 AS ?z) }
}

Given the starting point of SPARQL 1.0, I think that BIND ends BGPs, 
does not end or restart groups, is the better choice.

	Andy

History+disclosure:
I'm fairly sure the discussion might be different if this WG were making 
the decision today. DAWG had two choices, lexical position and 
group-wide scope for filters.  It decided on group-wide because lexical 
position reduces the number of queries that get answers just on scope 
grounds.  I had a preference for lexical order as being, to me, more 
explainable.

Received on Tuesday, 25 January 2011 10:01:26 UTC