SHACL SPARQL cannot use SERVICE?

[JervenBolleman]

The pre-binding section mentions that SERVICE clauses are not allowed and that implementations must report a failure on finding one.

While introducing a second or multiple SERVICEs is of course risky for the normal issues regarding networks. However, I feel that this should be allowed, if discouraged. I think that SERVICE should be allowed, and failed SERVICE calls should be considered as a failed validation.

[HolgerKnublauch]

IIRC the reason was that pre-binding needed some kind of low-level access to the variables in the engine, while for SERVICE we would need to convert them into the query string using substitution. @afs knows this much better than I do and Jena has moved away from the old pre-binding algorithm to substitution semantics, but this whole section would then need to be rewritten if we want to migrate SHACL too.

[afs]

Jena has moved away from the old pre-binding algorithm to substitution semantics

To expand on that:

For parameterized queries, pre-binding is going away. That's because it does not work for remote queries, whether it is a client sending a query or a remote request inside a query i.e. SERVICE.

Parameterization by (logically) rewriting the query could be used by SHACL (it has to be for $PATH but $PATH isn't a real variable) if it is only the three defined variables, $this, $shapesGraph, $currentShape. But this also applies to application defined variables (sh:Parameter). All of SEP-0007 applies. It can be done by a rewrite algorithm but it not replacing variables by values.

The RDF and SPARQL Working Group (new name!) now has a task force looking at this area.

and failed SERVICE calls should be considered as a failed validation.

It's controllable - don't forget SERVICE SILENT.

Whether a networking problem should be a SHACL violation is, I think, up to the usage. "Failure to confirm" is not always "is incorrect".