#314: Made focusNode an explicit param of exprEval, SPARQL-based expressions now pre-bind all scope vars

[HolgerKnublauch]

Two changes in this PR:

• Instead of having focusNode as part of the scope, I have pulled it out into an explicit special variable. This is cleaner because this variable really has a special status (e.g. it's called this in SPARQL) and it usually has a value (except in sh:targetNode).
• The SPARQL-based node expressions now accept the scope vars as parameters. This makes it possible to define user-defined (SPARQL) functions through custom node expression types. For map-based NEe, these would be simple name-value pairs for the input parameters. For list-based NEs, these could be arg1, arg2, arg3 etc. The NE document can specify the details, but the SPARQL document does not need to change further to accommodate the use cases.

Closes #314

[afs]

Changes in

shacl12-core, section Node Expressions

shacl12-core, section sh:expessions

shacl12-sparql, section SPARQL expressions

[HolgerKnublauch]

Interestingly I was also trying to add links to the githack renderings, but they were (for me) still caching an earlier version, and didn't show the second commit. So I elected not to include the link. But it renders fine now...

[TallTed]

Tweaks for clarity. I feel strongly that SPARQL keywords (like SELECT) should be presented within <code> elements.

[afs]

Not sure where to put comment but if this is @HolgerKnublauch's active PR ...

sh:expression The node expression that must return true.

Node expressions return lists.

does not return true as one of its output nodes,

Is that the right behaviour? Wouldn't it be better to make it the conjunction of the list so any violation is a violation. That stops the case where an accidental mistake adding value when only one is expected can make it pass.

sh:expression is already being called multiple times for each value node so better would be to require a single valued expression.

[HolgerKnublauch]

I have no strong opinion on sh:expression. I believe in the original draft it had to return exactly [ true ]. However, I have the feeling that when a NE returns multiple values, the general interpretation should be "or". For example, sh:class ( ex:Class1 ex:Class2 ) should be satisfied if either class is present among the types.

One approach moving forward is to move this constraint component into the NE document and let it evolve there. So when people have more experience with NEs, we can adjust the semantics accordingly. It doesn't really need to be in Core.

[afs]

sh:class ( ex:Class1 ex:Class2 )

As in node expression [ sh:class ( ex:Class1 ex:Class2 ) ] or the property value of the result of a single node-expr returning a list for sh:class?

As a property shape, it's "and"-like [ sh:path ... ; sh:class ex:Class1 ; sh:class ex:Class2 ]

For sh:expression the safe choice is to define the requirement to be exactly [ true ].

Others are not naturally an "or":

• sh:targetNode is a foreach.
• aggregates
• sparql:lessThan - "and" is more natural
• sh:minInclusive, sh:minCount would be strange if an "or" because then one value overrides another

What would

[ sh:add ( 
    [ :function1 (...) ] 
    [ :function2 (...) ] 
    ) ]

be? a list of N*M results?

sh:add and the rest would need to be implemented,with defined error handling, and not simply be the same as sparql:add which is 2 numbers only.

Maybe nodes expression evaluation should be defined to return "node or list of nodes" and node-expr functions declare which they are.

[HolgerKnublauch]

Ok, this change to sh:expression is fine for me. Changed to [ true ] on the branch.