Why not only SPARQL extension functions?

[hartig]

In PR apache/jena#2501, @namedgraph asks:

Is new SPARQL syntax really required for this? IMO that is a major drawback.
Couldn't extension functions suffice? As a GeoSPARQL-like approach? I think @SimonBin's work shows that it can be done.

There are two extensions to the SPARQL syntax that our approach makes:

The FOLD aggregate: To some extend this may be captured as an extension function. However, I don't see how the ORDER BY feature of FOLD may be the defined in this case. Note, to handle ORDER BY in FOLD, we have to extend the algebra and, thus, also the algorithm that translates an AST into an algebra expression.

The UNFOLD operator: The functionality of this operator cannot be captured as an extension function because evaluating this operator does not simply result in an RDF term. Instead, the operator extends every input solution mapping with bindings for new variables. In fact, the operator may even result in multiple output solution mappings for each input solution mapping.

While not as an extension function, I see that @SimonBin's approach uses magic properties instead (array:explode and json:explode). I don't see how exactly these magic properties are defined. Our UNFOLD operator has a definition and, very similar to the BIND operator, it comes with scoping-related constraints regarding the variables that the operator assigns. I am not sure at the moment how we may define such constraints for a magic property.

[rvesse]

May be worth mentioning some of the open issues in the SPARQL Working Group that are relevant to this discussion e.g. w3c/sparql-dev#6

[hartig]

Here is a related comment by @afs (copied from the PR for the Jena implementation of the approach):

While it may be possible within existing syntax, this area is fundamental and IMO would benefit with syntax. It is not a call-out extension like text query, geo or LLM's, though extensions call-out needs something more agreed than property functions or use of SERVICE. The SPARQL standard needs a multi-bind. At the moment, the optimizer needs to make them special cases.

We do have to be clear that this syntax proposal, and the future SEP, are evolving (as is LATERAL) and subject to change.