Clarify the use of $PATH, or string interpolation of SHACL paths

[VladimirAlexiev]

Sec 5.2 Syntax of SPARQL-based Constraints:

SELECT queries used in the context of property shapes use a special variable named PATH as a placeholder for the path used by the shape.

The only legal use of the variable PATH in the SPARQL queries of SPARQL-based constraints and SELECT-based validators is in the predicate position of a triple pattern.

But if sh:path is complex (not a predicate), it cannot be used in this way.

So I suggest adding two clarifications:

• "(spelled in UPPERCASE)" because SPARQL var names are case-sensitive
• "This can only be used with simple sh:path that consists of a single predicate. For complex sh:path, write the property path in SPARQL syntax in the query."

[afs]

If the sh:path is complex, and $PATH is correctly used (predicate position of a triple pattern), then it converting a SHACL path to SPARQL string syntax, and then doing string substitution should work.

That said, such string substitution can be an injection attack vector and that would be a principled reason to not allow complex paths. (Value injection is a safe mechanism for injecting into a query.)

[VladimirAlexiev]

I agree that converting a SHACL path to SPARQL string syntax would be a very useful feature, and it would enable the use of a lot more general SPARQL templates.
Changed the title of this issue accordingly.

I'm not very worried about SPARQL injection because we're not talking random strings here. An engine should check that sh:path corresponds to the syntax for SHACL paths and if not, then it can emit eg "BAD-PATH" or something similar.

So what do others think, should the new spec require it from engines? https://www.w3.org/TR/shacl/#dfn-path-mapping is already defined, what we're talking about is taking the mapping result and interpolating it in sh:select

[VladimirAlexiev]

A bit related: #165