- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Mon, 20 Jun 2016 11:28:00 -0700
- To: Jeremy J Carroll <jjc@syapse.com>, Gregg Kellogg <gregg@greggkellogg.net>
- Cc: public-rdf-tests@w3.org, public-sparql-dev@w3.org
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 Monday, 20 June 2016 18:28:33 UTC