Re: Improving EXISTS

On 07/03/2016 04:08 PM, james anderson wrote:
> good morning;
[...]
> there is agreement, as noted in numerous messages over the past week, that the
> recommendation language is deficient in many regards.
> in particular, with regards to exists.
> as demonstrated by this thread, the language permits interpretations which,
> although plausible, lead to consequences which were unlikely to have been its
> intent.
> there is agreement, that, where the intent of the recommendation is to achieve
> interoperability, those cases are problematic.
> 
> alternative to the “broken” interpretation, however, it is possible to read
> the description of exists in a way which is consistent with other aspects of
> the recommendation, consistent with the general state of the art of query
> processor implementation (see
> please, https://www.researchgate.net/profile/Thomas_Neumann2/publication/47863714_Scalable_Join_Processing_on_Very_Large_RDF_Graphs/links/00b7d51d1687cae740000000.pdf)
> and, which yields neither run-time type errors nor unreasonable results.
> 
> from that perspective, the definition is not “broken”.
> it should be clarified.
> 
> 
> best regards, from berlin,
> ---
> james anderson | james@dydra.com <mailto:james@dydra.com> | http://dydra.com

We differ strongly on whether the problems with the spec are simply a matter
of interpreting unclear language or overriding what the spec mandates.


I don't see any room for interpretation, for example, in these definitions
from Section 18.6 of https://www.w3.org/TR/2013/REC-sparql11-query-20130321/

******************
Definition: Substitute

Let μ be a solution mapping.
substitute(pattern, μ) = the pattern formed by replacing every occurrence of a
variable v in pattern by μ(v) for each v in dom(μ)

Definition: Evaluation of Exists

Let μ be the current solution mapping for a filter and P a graph pattern:
The value exists(P), given D(G) is true if and only if eval(D(G),
substitute(P, μ)) is a non-empty sequence.
******************

that allows any interpretation of

@prefix : <http://example.org/> .
SELECT ?x WHERE {
  ?x :p :c .
  FILTER EXISTS { ?x :q :d . } }

on the graph

{ ( _:x <http://example.org/p> <http://example.org/c> ) ,
  ( <http://example.org/d> <http://example.org/q> <http://example.org/d> ) }

other than returning a single solution mapping of { ( ?x , _:x ) }.

The definitions are here clear, unambiguous, and free of technical problems.


So here the spec mandates a particular answer that I believe is not the one
that should result.  Fixing this problem is, however, not a matter of
clarifying the spec but instead of overriding it.

There are other cases where the spec produces answers that are also not
subject to interpretation but that differ from what at least some
implementations produce.

peter

Received on Monday, 4 July 2016 14:50:07 UTC