Re: Proposed updates to the SPARQL 1.1 test suite

I agree that there is a defect.

However, for 

EXISTS is implemented differently in different SPARQL implementations
whenever a variable appears in a subquery but is not projected back up to
the top level of the EXISTS argument.

and

EXISTS results in invalid semantic structures whenever a variable in a
solution mapping appears anywhere in the argument
- in a VALUES construct,
- as a BIND variable,
- as a SELECT variable,
or
- in a BOUND expression.

I suggest that the queries that illustrate these are a little funky, in the sense, that to write them, one is likely to be a sufficiently advanced SPARQL developer to wonder what the semantics is, and then to get a little confused. Then the more cautious query writer may choose to rename some variables or make some other adjustment to the query.


> On Jun 20, 2016, at 11:28 AM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> On 06/20/2016 10:00 AM, Jeremy J Carroll wrote:
> [...]
>> (On (a) I found Peter’s assertion that EXISTS is broken to be somewhat
>> polemical: there is clearly a much narrower set of unclear queries than any
>> query containing EXISTS)
>> 
>> 
>> Jeremy Carroll
> 
> 
> Almost all subqueries in the EXISTS argument except those that don't use any
> variables in the solution query are problematic.  It is not possible to
> determine if an EXISTS will be problematic just by examining its syntax if
> any variable in the solution query shows up in a BGP (whose match makes a
> difference to the final result).  Even the most simple queries using EXISTS
> are problematic, for example
>  SELECT ?x WHERE { ?x :p :b . FILTER EXISTS { ?x :p :c . } }
> 
> 
> 
> EXISTS is implemented differently in different SPARQL implementations
> whenever a variable appears in a subquery but is not projected back up to
> the top level of the EXISTS argument.
> 
> EXISTS is not implemented correctly in some SPARQL implementations whenever
> a variable in a solution mapping is mapped to a blank node and that variable
> occurs in a BGP.
> 
> EXISTS is not implemented correctly in some SPARQL implementations whenever
> a variable in a solution mapping is the only variable in commmon between the
> two sides of a MINUS.
> 
> EXISTS results in invalid semantic structures whenever a variable in a
> solution mapping appears anywhere in the argument
> - in a VALUES construct,
> - as a BIND variable,
> - as a SELECT variable,
> or
> - in a BOUND expression.
> 
> 
> 
> I call this "broken".
> 
> 
> Peter F. Patel-Schneider
> Nuance Communications