Re: Proposed updates to the SPARQL 1.1 test suite

Sure, some of the problematic cases are not likely to be written by non-expert
users but the problematic cases cover just about anything a non-expert user is
going write, including

SELECT ?x WHERE { ?x :p :b . FILTER EXISTS { ?x :p :c . } }

and

SELECT ?x WHERE { ?x :p :b .
                  FILTER EXISTS { SELECT ?x WHERE { ?x :q :d . } } }

and

SELECT ?x WHERE { ?x :p ?y .
                  FILTER EXISTS { SELECT ?z WHERE { ?z :p ?y . } } }


Rewriting problematic cases as unproblematic ones is very tough.

Consider

SELECT ?x WHERE { ?x :p ?y . OPTIONAL { ?y :p ?z }
                  FILTER EXISTS { ?x :q ?z } }

How can that be transformed into an "equivalent" query that doesn't use ?x or
?z in a BGP or a subquery in the EXISTS.


peter



On 06/20/2016 05:38 PM, Jeremy J Carroll wrote:
> 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 <mailto: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
>

Received on Tuesday, 21 June 2016 02:25:07 UTC