EXISTS: scoping restriction #272

afs · 2025-08-25T16:30:56Z

This PR extracts proposed scoping changes for EXISTS/NOT EXISTS.

The only content changes are in the grammar notes (9 and new note 15), and in a new entry in the table in 18.3.1 Variable Scope. This can be seen in the diff. The rest is HTML changes that make no appearance changes.

Preview | Diff

afs · 2025-08-25T17:52:37Z

@kasei - you had some comments about text for scoping beyond just EXISTS.

This could be a good place to discuss those.

TallTed · 2025-08-25T18:06:26Z

spec/index.html

-                <td>Group <code>{ P1 P2 ... }</code></td>
-                <td><code>v</code> is in-scope if it is in-scope in one or more of P1, P2, ...</td>
+                <td>Group `{ P1 P2 ... }`</td>
+                <td>`v` is in-scope if it is in-scope in one or more of P1, P2, ...</td>


Suggested change

<td>`v` is in-scope if it is in-scope in one or more of P1, P2, ...</td>

<td>`v` is in-scope if it is in-scope in one or more of `P1`, `P2`, ...</td>

TallTed · 2025-08-25T18:06:39Z

spec/index.html

-                <td><code>GRAPH term { P }</code></td>
-                <td><code>v</code> is <code>term</code> or <code>v</code> is in-scope in P</td>
+                <td>`GRAPH term { P }`</td>
+                <td>`v` is `term` or `v` is in-scope in P</td>


Suggested change

<td>`v` is `term` or `v` is in-scope in P</td>

<td>`v` is `term` or `v` is in-scope in `P`</td>

TallTed · 2025-08-25T18:06:52Z

spec/index.html

-                <td><code>{ P1 } UNION { P2 }</code></td>
-                <td><code>v</code> is in-scope in P1 or in-scope in P2</td>
+                <td>`{ P1 } UNION { P2 }`</td>
+                <td>`v` is in-scope in P1 or in-scope in P2</td>


Suggested change

<td>`v` is in-scope in P1 or in-scope in P2</td>

<td>`v` is in-scope in `P1` or in-scope in `P2`</td>

TallTed · 2025-08-25T18:07:00Z

spec/index.html

-                <td><code>OPTIONAL {P}</code></td>
-                <td><code>v</code> is in-scope in P</td>
+                <td>`OPTIONAL {P}`</td>
+                <td>`v` is in-scope in P</td>


Suggested change

<td>`v` is in-scope in P</td>

<td>`v` is in-scope in `P`</td>

TallTed · 2025-08-25T18:07:09Z

spec/index.html

-                <td><code>SERVICE term {P}</code></td>
-                <td><code>v</code> is <code>term</code> or <code>v</code> is in-scope in P</td>
+                <td>`SERVICE term {P}`</td>
+                <td>`v` is `term` or `v` is in-scope in P</td>


Suggested change

<td>`v` is `term` or `v` is in-scope in P</td>

<td>`v` is `term` or `v` is in-scope in `P`</td>

Not part of this PR, but "v is term" here seems really strange? Am I not meant to read "term" as indicating the use of the SERVICE IRI form (which is the only one that has evaluation semantics)?

I think the word "term" is misleading here. This part of the table should better be:

| SERVICE x { P } | v is x or v is in-scope in P |

Same issue for the case of GRAPH a bit earlier in the table.

TallTed · 2025-08-25T18:08:54Z

spec/index.html

+            There are two entry points into the grammar: `QueryUnit` for the SPARQL query language
+            and `UpdateUnit` for the SPARQL update language.


Suggested change

There are two entry points into the grammar: `QueryUnit` for the SPARQL query language

and `UpdateUnit` for the SPARQL update language.

There are two entry points into the grammar: `QueryUnit` for the SPARQL Query language

and `UpdateUnit` for the SPARQL Update language.

kasei · 2025-08-26T03:52:09Z

@kasei - you had some comments about text for scoping beyond just EXISTS.

This could be a good place to discuss those.

I find this change to be VERY confusing. The existing scoping rules are all based on syntax, and can be determined statically. The new rule is:

v is in-scope if it is in-scope for the solution mapping where the expression containing EXISTS or NOT EXISTS is applied.

If I'm reading this correctly (?), this is based on runtime information about the solution mapping being used in the FILTER (or BIND, etc.) expression evaluation, which would make this rule very different from all the others.

I think what we actually want is to say that v is in-scope anywhere inside of an EXISTS AST, with the understanding that this will be true because of the translation that injects the solution mapping by way of the initial empty BGP inside of GGPs. This would be very different than all the other scoping rules which are all bottom-up, but… 🤷‍♂️

Either way, the "EXISTS and NOT EXISTS" in the "Syntax Form" column of the scoping rules table probably needs expansion to provide the details that this isn't about causing v to be in-scope for patterns that use EXISTS P but instead for patterns inside of P.

Tpt · 2025-08-29T14:28:08Z

spec/index.html

+              <tr>
+                <td>`EXISTS` and `NOT EXISTS`</td>
+                <td>
+                  `v` is in-scope if it is in-scope for the


This formulation is a bit weird to me because it's not defining the set of in-scope variable in the pattern like the other cases but the variable in scopes inside of any sub-pattern of the pattern.

I would rephase the sentence to something like v is in-scope of all graph pattern contained in P if v is in-cope for a solution mapping where the expression containing EXISTS P or NOT EXISTS P is applied.

I find that weird as well. I would not include such a row in this table because the intended way to read this particular row would be very different from the way all the other rows are meant to be read.

TallTed · 2025-09-16T21:36:43Z

spec/index.html

+            `(expr AS v)` form. The scoping for `(expr AS v)`
+            applies immediately in `SELECT` expressions.
+          </p>
+          <p>In `BIND (expr AS v)` requires that the variable `v` is not


Suggested change

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

<p>`BIND (expr AS v)` requires that the variable `v` is not

or

Suggested change

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

<p>In `BIND (expr AS v)`, the variable `v` is required to not be

TallTed · 2025-09-16T21:40:42Z

spec/index.html

+            Keywords are matched in a case-insensitive manner with the exception of
+            the keyword '`a`'  which, in line with Turtle and N3, is used
+            in place of the IRI `rdf:type` (in full, 
+            <code><a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#type">http://www.w3.org/1999/02/22-rdf-syntax-ns#type</a></code>).


The boolean sugars -- true and false -- are also case sensitive.

(I hate that these exist. We're well and truly stuck with a, which I hate almost as much, but I truly wish that true and false were treated just like any other untyped literal -- and just like any other capitalization of those words would be. Talk about a foot-gun...)

afs force-pushed the exists-scoping-restrictions branch 3 times, most recently from 99d07fc to e87de02 Compare August 25, 2025 17:44

EXISTS: scoping restriction

b983250

afs force-pushed the exists-scoping-restrictions branch from e87de02 to b983250 Compare August 25, 2025 17:48

afs requested a review from kasei August 25, 2025 17:52

TallTed reviewed Aug 25, 2025

View reviewed changes

Tpt reviewed Aug 29, 2025

View reviewed changes

TallTed suggested changes Sep 16, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

EXISTS: scoping restriction #272

EXISTS: scoping restriction #272

Uh oh!

afs commented Aug 25, 2025 •

edited by pr-preview bot

Loading

Uh oh!

afs commented Aug 25, 2025

Uh oh!

TallTed Aug 25, 2025

Uh oh!

TallTed Aug 25, 2025

Uh oh!

TallTed Aug 25, 2025

Uh oh!

TallTed Aug 25, 2025

Uh oh!

TallTed Aug 25, 2025

Uh oh!

kasei Aug 26, 2025

Uh oh!

hartig Sep 13, 2025

Uh oh!

TallTed Aug 25, 2025

Uh oh!

kasei commented Aug 26, 2025

Uh oh!

Tpt Aug 29, 2025

Uh oh!

hartig Sep 13, 2025

Uh oh!

TallTed Sep 16, 2025

Uh oh!

TallTed Sep 16, 2025

Uh oh!

TallTed Sep 16, 2025

Uh oh!

Uh oh!

	<td>`v` is in-scope if it is in-scope in one or more of P1, P2, ...</td>
	<td>`v` is in-scope if it is in-scope in one or more of `P1`, `P2`, ...</td>

	<td>`v` is `term` or `v` is in-scope in P</td>
	<td>`v` is `term` or `v` is in-scope in `P`</td>

	<td>`v` is in-scope in P1 or in-scope in P2</td>
	<td>`v` is in-scope in `P1` or in-scope in `P2`</td>

	<td>`v` is in-scope in P</td>
	<td>`v` is in-scope in `P`</td>

		There are two entry points into the grammar: `QueryUnit` for the SPARQL query language
		and `UpdateUnit` for the SPARQL update language.

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

	<p>In `BIND (expr AS v)` requires that the variable `v` is not
	<p>In `BIND (expr AS v)`, the variable `v` is required to not be

EXISTS: scoping restriction #272

Are you sure you want to change the base?

EXISTS: scoping restriction #272

Uh oh!

Conversation

afs commented Aug 25, 2025 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

afs commented Aug 25, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kasei commented Aug 26, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

afs commented Aug 25, 2025 •

edited by pr-preview bot

Loading