Re: another problem with proposal B

Hi Peter,

On 09/03/17 05:32, Peter F. Patel-Schneider wrote:
> Here is another problem with proposal B.
>
> Both of the following queries are syntactically valid but have undefined results.
>
> SELECT ?x WHERE {
>  BIND ( ex:a AS ?x )
>  FILTER EXISTS { SELECT (ex:b AS ?x) WHERE { } }
>  }
>
> SELECT ?x WHERE {
>  BIND ( ex:a AS ?x )
>  FILTER EXISTS { SELECT ?x WHERE { BIND (ex:b AS ?x) } }
>  }

These are redefining a variable already  in-scope for the FILTER so are 
not allowed.

Variables from the current row of the filter are fixed throughout the 
EXISTS evaluation and can not be refined.

It applies statically to any variable potentially bound (scoping rules - 
so applies to
OPTIONAL { ... ?x ... } FILTER EXISTS { BIND (ex:b AS ?x) }
). This is the same process as already exists in SPARQL, with the change 
that the in-scope set is seeded with the current row.

>
> The following query however does have defined results
>
> SELECT ?x WHERE {
>  BIND ( ex:a AS ?x )
>  FILTER EXISTS { SELECT ?y WHERE { BIND (ex:b AS ?x) } }
>  }
>
> This problem is different from that that added the disallowing of binding to
> filter variables at the top level of the EXISTS argument as in
>
> SELECT ?x WHERE {
>  BIND ( ex:a AS ?x )
>  FILTER EXISTS { BIND (ex:b AS ?x) }
>  }

I don't see it as different. The "Limitations on Assignment" apply 
deeply - as they do for any SPARQL query already.

 Andy

>
> peter
>

Received on Friday, 10 March 2017 14:04:14 UTC