Re: problem with proposal B and algebra simplification

[I took the liberty of replacing the () around the VALUES values with the
correct {}.  This does not affect the argument I am making here.]

On 03/10/2017 06:05 AM, Andy Seaborne wrote:
> 
> 
> On 09/03/17 11:49, Peter F. Patel-Schneider wrote:
>> I thought that I had already reported this problem with proposal B, but
>> maybe not.
> 
> I don't think you have.
> 
>> The translation to the SPARQL algebra may not produce any place for values
>> insertion to take place.  This is due to the simplification step in
>> 18.2.2.8.
>>
>> For example, the graph pattern
>>     { VALUES ?x { ex:b } }
>> is translated into an SPARQL algebra expression containing only a multiset,
>> something like
>>     {{ (x,ex:b) }}
>> This results in counterintuitive behaviour on queries like
>>
>> SELECT ?x WHERE {
>>   BIND ( ex:a AS ?x )
>>   FILTER EXISTS { VALUES ?x { ex:b } }
>> }
> 
> This query is illegal because it attempts to reassign a variable already a
> bound in the current row.

Not so.     VALUES is not an assignment operator in SPARQL.
There is no requirement in SPARQL that the variables in VALUES constructs must
be previously unbound.  Nothing in Proposal B states that variables in VALUES
constructs must be previously unbound.  If you believe differently please
indicate the wording that states that this is illegal.

> If it were a different name, ?z say, then its just fixed data independent of
> the current row.
> 
> As soon as the query adds anything that can influenced by the current row, the
> current row variables will be available.
> 
>     Andy
> 
>>
>> peter

peter

Received on Friday, 10 March 2017 16:56:52 UTC