EXISTS : ways forward

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.

There are suggested text items at the end of:
https://github.com/w3c/sparql-exists/wiki/Problem:-Some-uses-of-EXISTS-are-not-defined-during-evaluation


**** Problem 2: Substitution happens where definitions are only for
variables

Suggestion: identify and forbid pattens that involve the substitution of
certain constructs.

BIND(... AS ?VAR)
SELECT (... AS ?VAR)
VALUES ?VAR
VALUES(...?VAR...)

This can be a static or dynamic test - I prefer a static check which is
done once after parsing (there are already such checks - e.g. "AS ?VAR"
the ?VAR must not be an in-scope variable from the expression or pattern).

With BOUND, the issue is more about syntax.  We can define
"BOUND(someValue)" to have a replacement of "true"^^xsd:boolean in the
algebra.


**** 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.

The scoping graph includes all blank nodes passed in to pre-binding.

{ ?s ?p ?o } => { ?s ?p ?o' . FILTER (sameterm(?o', _:b))  }

while it is written in syntax above, the process happens in the
algebra and in the algebra, blank nodes are concrete terms so it is
meaningful to talk about them in filters etc. They do not behave like
variables except in basic graph patterns.

We can explain that this is the same as (implementation, simple
entailment) treating only blank nodes in the original query, i.e. at he
time of parsing, as BGP variables and then treating substitution blank 
nodes as constant terms.

{ ?s ?p _:b  } where _:b is matched concretely, not as a variable.


**** 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.


**** 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 {}.

Optionally, we can explain this (an implementation note) the same as
replacing in-scope variables with a different name. If v is not in scope
on the outer {} of EXISTS {}, then replace with a different, unused name.

18.2.1 Variable Scope
https://www.w3.org/TR/sparql11-query/#variableScope

Received on Monday, 19 September 2016 16:11:12 UTC