Re: another problem with proposal B

The relevant bits of Proposal B on limiting assignment are:

2.2 Limitations on Assignment

Assignment (an "AS" in SPARQL syntax) to a variable which is in-scope for
the FILTER is not allowed. Any potential variables in a "current row", are
considered in-scope for the EXIST expression. Section 18.2.1 Variable Scope
defines the set of variables that are in-scope in the GroupGraphPattern
where the filter appears.

This is a syntactic restriction and is added to the notes in section 19.8
Grammar. See also notes 12 and 13 that already apply.


The relevant bits of the SPARQL document are:

18.2.1 Variable Scope

We define a variable to be in-scope if there is a way for a variable to be
in the domain of a solution mapping at that point in the execution of the
SPARQL algebra for the query. The definition below provides a way of
determing this from the abstract syntax of a query.

Note that a subquery with a projection can hide variables; use of a variable
in FILTER, or in MINUS does not cause a variable to be in-scope outside of
those forms.

Let P, P1, P2 be graph patterns and E, E1,...En be expressions. A variable v
is in-scope if:
Syntax Form  In-scope variables
BGP       v occurs in the BGP
Path    v occurs in the path
Group { P1 P2 ... } v is in-scope if it is in-scope in one or more of P1, P2, ...
GRAPH term { P } v is term or v is in-scope in P
{ P1 } UNION { P2 } v is in-scope in P1 or in-scope in P2
OPTIONAL {P}    v is in-scope in P
SERVICE term {P} v is term or v is in-scope in P
BIND (expr AS v) v is in-scope
SELECT .. v .. { P } v is in-scope
SELECT ... (expr AS v) v is in-scope
GROUP BY (expr AS v) v is in-scope
SELECT * { P }    v is in-scope in P
VALUES v { values } v is in-scope
VALUES varlist {values} v is in-scope if v is in varlist

The variable v must not be in-scope at the point of the (expr AS v)
form. The scoping for (expr AS v) applies immediately in SELECT
expressions.

In BIND (expr AS v) requires that the variable v is not in-scope from the
preceeding elements in the group graph pattern in which it is used.

In SELECT, the variable v must not be in-scope in the graph pattern of the
SELECT clause, nor used in another select expression earlier in the clause.


First the three clauses for the AS constructs are messed up.  They need to
read something like:

In BIND (expr AS v) the variable v cannot be in-scope in any of the
preceeding elements in the group graph pattern containing the BIND
expression.

In SELECT ... (expr AS v) ... G , the variable v cannot be not be
in-scope in G nor used in another expression nor as a variable earlier in
the select clause.

By the way, using "in" for scoping is misleading, as it gives the
impression that the variable is in-scope throughout the expression.  Using
"for" would be much better.

As written, 2.2 has no real effect.  It makes variables in-scope for the
argument to EXISTS but this doesn't do anything, as nothing looks at whether
a variable is in-scope in an enclosing expression.

The effect of 2.2 thus has to be to add a clause like

In FILTER ... EXISTS { P1 P2 ... } v is in-scope in an empty pattern that is
considered to be just before P1 in { P1 P2 ... } if v is in-scope in any of
the elements in the group graph pattern containing the FILTER expression.


This correctly (well correctly with respect to the silly evaluation rules
for Extend) makes illegal things like

SELECT ?a WHERE {
 FILTER EXISTS { BIND ( ex:a AS ?b ) }
 ?a ex:p ?b .
}

while correctly leaving legal things like

SELECT ?a WHERE {
 FILTER EXISTS { SELECT ?b WHERE { BIND ( ex:a AS ?a ) ?a ex:q ?b . } }
 ?a ex:p ?b .
}

However, the evaluation rules for EXISTS break down.


Summary: The syntax rules for Proposal B are broken.  The minimal fix to
make the syntax rules for Proposal B work do not exclude queries where the
evaluation rules for Proposal B break down.


peter


On 03/10/2017 06:03 AM, Andy Seaborne wrote:
> 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 18:37:03 UTC