shapes-ISSUE-63 (sh:hasShape): Nested shapes: sh:hasShape function versus recursive SPARQL code generation [SHACL Spec]

shapes-ISSUE-63 (sh:hasShape): Nested shapes: sh:hasShape function versus recursive SPARQL code generation [SHACL Spec]

http://www.w3.org/2014/data-shapes/track/issues/63

Raised by: Holger Knublauch
On product: SHACL Spec

The SHACL spec currently relies on a SPARQL extension function sh:hasShape that can be used to verify that a given resource matches a given shape. This function is used in the SPARQL definitions of several core templates (e.g. sh:OrConstraint, sh:valueShape) but is also generally available for end users to write their own constraints. I believe this is very powerful and elegant.

Peter suggests to not rely on this function, I guess because it requires a non-standard extension.

We need to discuss whether the sh:hasShape function is sufficiently problematic that we cannot rely on it, and (if so) precisely define an alternative algorithm that can be used instead.

It may be helpful to hear from implementers whether they believe the sh:hasShape function is a problem. Note that even if sh:hasShape is used in the definition of the core language, actual implementations may optimize its execution to build recursive structures. My assumption is that if a database vendor implements SHACL support, then they will already have the relevant algorithms implemented, and sh:hasShape is just a trivial wrapper for them. Likewise, this function is no problem for generic graph APIs such as Jena or Sesame.

Received on Monday, 1 June 2015 05:59:34 UTC