Add sh:SPARQLFunction

[HolgerKnublauch]

SHACL-AF include vocabulary to declare new (SPARQL) functions: https://w3c.github.io/shacl/shacl-af/#functions

The SHACL-SPARQL 1.2 spec should include this feature. In TopBraid we have supported this for many years and it has proven to be very useful for encapsulating reusable query snippets.

[tpluscode]

I have been thinking about function expressions and their relation to SPARQL.

SHACL-AF also has the Function Expression and https://datashapes.org/sparql# exists which defines many sh:Function (not sh:SPARQLFunction, despite its name)

IMO, we should have a more generalised set of function expressions (as in the dash-sparql namespace) which can be implemented and executed both with and without SPARQL.

The role of SHACL-SPARQL would then be to defined how each such function is implemented with SPARQL (if supported)

[HolgerKnublauch]

I guess now that we will introduce a general extension mechanism for user-defined NEs, we no longer really need sh:SPARQLFunction. The remaining work items here would be to:

• define that any List Parameter Expressions (including user-defined ones from the shapes graph) need to get exposed as SPARQL functions. Do we agree to do that (e.g. @afs)?
• change sh:select and sh:eval so that they turn any variable from the scope into pre-bound variables. This will allow using them for user-defined NEs.

[afs]

I guess now that we will introduce a general extension mechanism for user-defined NEs, we no longer really need sh:SPARQLFunction. The remaining work items here would be to:

• define that any List Parameter Expressions (including user-defined ones from the shapes graph) need to get exposed as SPARQL functions. Do we agree to do that (e.g. @afs)?

+1

• change sh:select and sh:eval so that they turn any variable from the scope into pre-bound variables. This will allow using them for user-defined NEs.

+1

I'll put a comment on #328 about evalExpr.

The degree of compatibility with SHACL-AF in the wild is something this group needs to think about.

There should be some respect to the ease of transition to SHACL 1.2 - which might be legacy/deprecation while respecting the syntax (application investment).

In the case of sh:SPARQLFunction, my feeling is that this isn't desirable. We can come back later and revisit that, but NE are a big change and sh:SPARQLFunction shouldn't constrain the design.