Correlated EXISTS

[afs]

---

Preview | Diff

[TallTed]

Incomplete, but better than no review... Some clear fixes; some less clear questions.

[TallTed]

Suggested change

	<td>`EXISTS` and `NOT EXISTS` filters</td>
	<td>`FILTERs` using `EXISTS` and `NOT EXISTS`</td>

[hartig]

First, to @TallTed's edit suggestion: since FILTERs is not a keyword in SPARQL, I would not code-fence it. Additionally, for this rephrasing, it should be "or" instead of "and". So, better something like:

Suggested change

	<td>`EXISTS` and `NOT EXISTS` filters</td>
	<td>`FILTER` statements using `EXISTS` or `NOT EXISTS`</td>

or:

Suggested change

	<td>`EXISTS` and `NOT EXISTS` filters</td>
	<td>`FILTER` containing `EXISTS` or `NOT EXISTS`</td>

Now, more generally: Is this really only about filters? Shouldn't BIND with EXISTS or NOT EXISTS be considered as well?

[hartig]

In fact, I wonder why EXISTS and NOT EXISTS need to be mentioned at all here.

For every FILTER expr, it holds that no variable is in-scope, no matter whether expr contains EXISTS/NOT EXISTS or not. The notion of in-scope variables is about variables that may be in a solution mapping produced for a query construct and a FILTER itself does not result in solution mappings. So, no variable can be in-scope for a FILTER. Of course, there may be variables that are in-scope for a group pattern that contains a FILTER, but that case is covered by the Group-related row above in this table.

[TallTed]

Suggested change

	<p>In <code>BIND (expr AS v)</code> requires that the variable <code>v</code> is not
	<p><code>BIND (expr AS v)</code> requires that the variable <code>v</code> is not

[TallTed]

This appears to be non-normative text. I am therefore writing to replace the lowercase RFC2119 language.

Suggested change

	<p>In <code>SELECT</code>, the variable <code>v</code> must not be in-scope in the graph
	pattern of the <code>SELECT</code> clause, nor used in another select expression earlier in
	<p>In <code>SELECT</code>, the variable <code>v</code> cannot be in-scope in the graph
	pattern of the <code>SELECT</code> clause, nor have been used in another select expression earlier in

[TallTed]

Suggested change

	as an argument or a "null" token. . Normally this the "null" token. This would be set in
	as an argument or a "null" token, and is normally the "null" token. This would be set in

[TallTed]

It's not clear what is reset on exit. I think, maybe, replace that phrase with the global reset to the old value on exit, as suggested below. The hyphen should become either a full stop (as suggested below) or an em-dash (which I think doesn't work as well, here).

Suggested change

	Another way is to have a global (to the execution) variable. In eval-exists, the
	old value is recorded, the global set to the new value, and reset on exit - this forms a
	stack for nested EXISTS.
	Another way is to have a global (to the execution) variable. In eval-exists, the
	old value is recorded, the global set to the new value, and the global reset to the old value on exit. This forms a
	stack for nested `EXISTS`.

[TallTed]

Suggested change

	Replacements may happen several times, depending on recursive order
	Replacements may happen several times, depending on recursive order,

[TallTed]

I don't quite understand what's trying to be said here. It might just need the is I've added, but a larger change may be needed.

Suggested change

	but each time a replacement is made, the variable not used anywhere else.
	but each time a replacement is made, the variable is not used anywhere else.

[TallTed]

Suggested change

	is not affected by the values insertion operation because it is renamed apart.
	is not affected by the value insertion operation because it is renamed separately.

[TallTed]

Suggested change

	Long term: change eval() to be arity three - 3rd argument is "current row".
	Long term: change eval() to be arity three — 3rd argument is "current row".

[TallTed]

Order doesn't seem to be important in this <ol>. If there is nothing that refers to these notes by number, then this <ol> should be changed to an <ul>

[afs]

The numbering is essential so people can talk about the notes conveniently. It is a long list - saying the "8th bullet" is convenient. Counting manually is not convenient.

[hartig]

@afs do you already want feedback on this one? (I am asking because it still has WiP status in the GitHub UI and you didn't say anything in the description.)

[afs]

@hartig - I was going to bring it up at the next SPARQL TF.

I use marking as "draft" to indicate its still changing so it's more like "FYI" in this state and not a request for feedback but feedback on the design is welcome. (here - the areas are marked @@.)

On this PR, one area that might be of interest is whether "eval(pattern, D, G)" could be useful generalized to take a correlation
row as an extra argument. While it may not be necessary for EXISTS and handling the correlation row could be EXIST specific. But being mindful of future possibilities and the desire to not have too many algorithm variations, it might be a useful way to go while the spec is in WG (i.e pre features+maintenance). It isn't worse than EXIST-specific handling. The timing with regard to your current work might be quite good.