Skip to content

#650: Added link to VarExpression to clarify what "variable" means here #655

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
HolgerKnublauch merged 5 commits into from
Dec 9, 2025
+9 −9
Merged

#650: Added link to VarExpression to clarify what "variable" means here #655

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
13bb166
#650: Added link to VarExpression to clarify what "variable" means here
HolgerKnublauch Nov 17, 2025
8ef6833
Merge branch 'gh-pages' into issue-650
HolgerKnublauch Nov 24, 2025
9ba7d4c
Removed link again, and the redundant mention of focusNode, also fixe…
HolgerKnublauch Nov 24, 2025
5b9ee66
Switched from using 'node' to 'term', fixed indentation
HolgerKnublauch Nov 24, 2025
6a53e19
Merge branch 'gh-pages' into issue-650
HolgerKnublauch Dec 9, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion shacl12-node-expr/index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2256,7 +2256,7 @@ <h3>sh:expression</h3>
</div>
<p><em>The remainder of this section is informative.</em></p>
<p>
Note that the scope in the evaluation of expression constraints contains the variable <code>value</code>
Note that the scope in the evaluation of expression constraints contains the <a href="#VarExpression">variable</a> <code>value</code>
Copy link
Contributor

@afs afs Nov 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least:

Suggested change
Note that the scope in the evaluation of expression constraints contains the <a href="#VarExpression">variable</a> <code>value</code>
Note that the scope in the evaluation of expression constraints contains the <a href="#dfn-var-expression">variable</a> <code>value</code>

although this called a "var expression" not "a variable" so that seems to make it:

Suggested change
Note that the scope in the evaluation of expression constraints contains the <a href="#VarExpression">variable</a> <code>value</code>
Note that the scope in the evaluation of expression constraints contains the <a href="#VarExpression">var expression</a> <code>value</code>

The definition:

A blank node that is the subject of the following properties is called a var expression with the function name shnex:VarExpression:

says the blank node is the var expression and is an RDF term.

If you want to keep it as the current design, please keep using "var expression" and then shacl12-rules can define variable. (There are only two other uses of "variable" in the node expressions doc at the moment.)

Copy link
Contributor Author

@HolgerKnublauch HolgerKnublauch Nov 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't even need to talk VarExpressions at all here. The key is the term "scope". And scope is defined in SHACL 1.2 core as

				<li><code>scope</code> is a map from (key) <a>nodes</a> to individual (value) <a>nodes</a>.
				The empty map is written as <code>{}</code>.

So I think we can avoid the term variable in that definition and just refer to mappings in the scope, where the key in the map is the value of shnex:var of the var expression.

I guess the proper fix is then to create a deep link to the scope definition and reference that from node expressions.

Copy link
Contributor

@afs afs Nov 18, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The map is from a string (taken from shnex:var) to RDF term.

If it is a node (RDF Term), then

[ shnex:var "foo" ] .
[ shnex:var "foo" ] .

is two different scope entries.

If there is no varExpression, how does a node expression work

  [ sparql:plus ( [ shnex:var foo" ] 1 ) ]

Something has to define

   exprEval([ shnex:var "foo" ])

and that to be an error if "foo" is not in the scope, which is returning an empty list from scope lookup.

Copy link
Contributor Author

@HolgerKnublauch HolgerKnublauch Nov 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I struggle to parse your response.

[ shnex:var "foo" ] .
[ shnex:var "foo" ] .

are two times the same expression. Why should those be "different scope entries"?

The sentence above the sparql:plus example seems unfinished. What do you mean?

We could change the handling of undefined variables but then how could we distinguish unbound (optional) parameters from those called by accident in a node expression? There is no "null" value here like in JavaScript.

Anyway, I made further adjustments to the PR and believe external documents can refer to the variable scope by name when they refer to evalExpr.

Copy link
Contributor

@afs afs Nov 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I struggle to parse your response.

[ shnex:var "foo" ] .
[ shnex:var "foo" ] .

are two times the same expression.

And what RDF term do they evaluate to? That's necessary because:

scope is a map from (key) nodes to individual (value) nodes.

(PS better to say "RDF term", not "nodes" which are the existing subject/objects of a graph)

Copy link
Contributor

@afs afs Nov 25, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why can't you say that the subject of [ shnex:var "foo" ] is (as in "describes", "represents" or "denotes", not in the RDF syntax where is a blank node) a variable with name "foo"?

After all:

shnex:var	sh:datatype xsd:string       The variable name, e.g. "focusNode".
            sh:minLength 1

Var expressions are expressions. They yield an RDF term when evaluated.
Here, they are the use of a variable in a role.

Copy link
Contributor Author

@HolgerKnublauch HolgerKnublauch Dec 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to avoid the (formal) term variable because it is overloaded and in #650 you complain that there is no formal definition of variable. At this stage I am really not sure what you want here. Would you like to produce a PR or specific suggestion yourself instead of me guessing?

Copy link
Contributor

@afs afs Dec 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed #650 is a request have a definition or at least an anchor for "variable".

How can rules say "treat [ shnex:var "foo" ] as a (SPARQL) variable in filter expressions?
How can node expressions say "The variable name" in defining shnex:var without the domain being a variable?

Copy link
Contributor Author

@HolgerKnublauch HolgerKnublauch Dec 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The anchor is for "var expression" https://w3c.github.io/data-shapes/shacl12-node-expr/#dfn-var-expression and you can then refer to the variable name as

the <a>value</a> of <code>shnex:var</code> of the <a>var expression</a>.

this avoids me having to introduce a formal term for "variable" and other documents can freely redefine it.

If that's acceptable, please still approve this PR because it does some clean up.

Copy link
Contributor

@afs afs Dec 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this avoids me having to introduce a formal term for "variable" and other documents can freely redefine it.

Rules will now have to define evaluating node expressions because the input is a variable from earlier in the rule pattern.

Since we aren't defining a common evaluation model anymore, go ahead and merge this.
I'm not an editor of "Node Expression" so I will approve it this once.

for the current <a>value node</a> while the variable <code>focusNode</code> is the <a>focus node</a>.
</p>
<p>
Expand Down