#315: Added support for sh:eval to SHACL-SPARQL

[HolgerKnublauch]

No description provided.

[afs]

I don't think sh:eval is a good name here. "eval" is very general concept and not specific to SPARQL expressions.

Suggestion: sh:sparqlExpr which allows for other expression languages and makes it clear it is an expression.

We might have similar naming issues elsewhere in SHACL grows in SHACL 1.2 so adopting a naming convention (often applied, not always)

I'd like to reserve for eval for a general usage, maybe dynamic invocation:

[ sh:eval ( functionExpr arg1 arg2 ) ]

where functionExpr is a node expression to decide the function name to call.

[HolgerKnublauch]

Right, I had similar concerns about "eval". But sparqlExpr is quite a mouthful too, and will lead to awkward names because the term "expression" is already used in node expressions. So we would have sh:SelectExpression but sh:SPARQLExprExpression (?)

Also note that we use sh:select and sh:ask instead of sh:sparqlSelect and sh:sparqlAsk.

sh:eval is quite short to write for people who edit node expressions. But there may be a better stand-alone name from the SPARQL universe that doesn't need to be prefixed with "sparql"?

[ajnelson-nist]

Does the SPARQL Grammar provide any helpful hints for what could work instead of eval? E.g., is there something in the neighborhood of BuiltInCall (121)? (Note - 1.1 permalink cited in case of edits to 1.2.)

[tpluscode]

Given the hypothetical [ sh:eval "IRI($this)" ], one could interpret the object as argument to SPARQL BIND(IRI($this) as ?value)

So what if we called this a sh:BindExpression, used as [ sh:bind "IRI($this)" ]. And then when we adopt the sh:var, one could almost write SPARQL like [ sh:bind "IRI($this)"; sh:as "varName" ]

[HolgerKnublauch]

The "beauty" of sh:eval is the similarity to the JS eval method, which also takes a string and executes it as a sub-script. At least sh:sparqlEval should be better than sh:sparqlExpr to avoid the double use of "expression".

[afs]

JS eval is an "action". This use in SHACL is declaring the expression written in SPARQL.

We already have

The evaluation of a node expression is defined as a function eval(expr, activeGraph, scope)

and we are talking about the expr part.

Does the SPARQL Grammar provide any helpful hints for what could work instead of eval?

In SPARQL it is an expression so sh:expr.

Other:

sh:value
sh:valueOf (singular value).

[HolgerKnublauch]

JS eval is an "action". This use in SHACL is declaring the expression written in SPARQL.

I am in general not sure yet whether those node expressions should sound like verbs or nouns or a mix. Right now it's a mix. "select" and "ask" can be either a pointer to a SELECT query or be the verb "to select".

Any name is a compromise and language is always a bit ambiguous. We just need to pick something that we can reasonably live with.

In any case, I can of course replace eval(expr, activeGraph, scope) with evalExpr(expr, activeGraph, scope) in the specs as part of this PR in case we elect to stay with sh:eval.

[afs]

I think evaluation is going to be

   evalExpr(expr, activeGraph, positionalArgs, context)
   evalExpr(expr, activeGraph, namedArgs, context)

Whether this part of the NE document or in Core isn't clear to me.

Separating out the environment is cleaner to implement - the name parameter map is a stack across calls (and could even have named results), the environment is unchanging and maybe made immutable.

Use in SPARQL will be simple names so the use of URIs isn't going to so easy to keep things apart.

[HolgerKnublauch]

Closing this PR because it is also part of #340 and people have made suggestions there that actually affect sh:eval. Let's continue with the other PR in a streamlined manner.