Re: EXISTS : ways forward

My first response to Andy's message was quite detailed.  This is a much more
high-level response that presents a different way forward at about the same
level that Andy has.

On 09/19/2016 09:10 AM, Andy Seaborne wrote:
> Sorry for the silence - other things overtook my time and I couldn't
> find contiguous periods of time to work on the issues of EXISTS.
> 
> I took a pass over all the issues and put down a brief suggestion for each
> one.  These are outline proposals, not detailed proposals.  As a first step, I
> want to get general direction for solutions aired.
> 
>         Andy
> 
> Outlines:
> 
> **** Problem 1: Some uses of EXISTS are not defined during evaluation
> 
> This should be treated as an erratum to SPARQL : anything that can a
> pattern can appear in EXISTS{}.  This applying ToMultiSet to get from a
> solution sequence back to a multiset for EXISTS.

Agreed.

> **** Problem 2: Substitution happens where definitions are only for
> variables
> 
> Suggestion: identify and forbid pattens that involve the substitution of
> certain constructs.
[...]

Many of these, particularly subqueries, are useful and have an obvious
meaning.  Instead of making them illegal the solution should give them their
intuitive meaning.  The problem here is substitution so the solution is likely
to be to change the meaning of EXISTS so that it doesn't depend on substitution.

> **** Problem 3: Blank nodes substituted into BGPs act as variables
> 
> The core issue is to treat bnodes from the data (pre-binds) differently from
> bnodes from the surface syntax.
[...]

This is already done for bnodes in solution bindings.  These bnodes influence
SPARQL but do not act as variables.  This existing part of SPARQL evaluation
can be used as the core of a solution for this problem.

> **** Problem 4: Substitution can flip MINUS to its disjoint-domain case
> 
> This isn't a problem per-se - it's a possibly unexpected outcome;
> evaluation is still defined.
> 
> Proposal: we note the effect and advise again substitutions in the
> right-hand-side of the MINUS (pattern in MINUS { pattern }).
> 
> Alternatively, like issue-2 forbid it.

The flipping meaning of MINUS is a problem for understanding SPARQL.  EXISTS
substitution makes it even harder to understand MINUS.  A solution that
doesn't make MINUS harder to understand is desirable here.

> **** Problem 5: Substitution affects disconnected variables
> 
> We use the scoping rules and define substitution only for variables in a
> potion that is in-scope of the outermost {}.

Yes, EXISTS should not mess with disconnected variables.  This doesn't address
Problem 2, however.

peter

Received on Sunday, 25 September 2016 20:52:30 UTC