ISSUE-131: Cleaned up definition of sh:hasShape

Peter,

last month you raised ISSUE-131 on the sh:hasShape function. I have 
tried to address your concerns here:

https://github.com/w3c/data-shapes/commit/e5f6a0a84f6f9cc58c07e16863c7bfa7bd7777f9
https://github.com/w3c/data-shapes/commit/d979121751c86004174ccfd26b0de1cbcd13aea9

See

     http://w3c.github.io/data-shapes/shacl/#hasShape

Responses inline:

> There are several problems with this definition.
>
> First, it uses type in a way different from the rest of the document. 
> This
> is not just a case where SHACL typing changed---literals never had 
> types in
> SHACL. (This is a good argument to use a qualifier wherever SHACL 
> typing is
> meant.)

The only use of the term "type" that I found was in "Value type". I have 
changed them all to rdfs:Resource (one of them was sh:Shape). Is this 
what you are referring to?

>
> Second, dependency loops are currently invalid in SHACL. The precise
> meaning of what is a dependency loop is is a bit uncertain, but it is
> certainly the case that recursively running the same shape on the same
> resource counts as a dependency loop. sh:hasShape needs to be defined in
> such a way to signal that an invalid situation has occured.

I have adjusted the definition so that it reports a failure 
("undefined") when the function was called with the same parameters 
recursively. Could you verify whether this is sufficiently precise and 
correct now?

>
> Third, some constraints need to have bindings passed through the
> sh:hasShape, or they cannot correctly compute validation results. 
> However,
> SPARQL is silent on the variable environment available inside 
> functions so
> any information has to be passed via arguments.

I don't see why bindings have to be passed through the function. A 
function takes parameters and then operates on those parameters and the 
current dataset (which it inherits from the surrounding call). Could you 
clarify where you see problems? To clarify that there are no bindings 
involved, I changed from <code>$shape</code> to <code>shape</code>.

>
> Fourth, arguments to SPARQL functions are RDF terms and thus are not 
> graphs.

I clarified that shapesGraph is the IRI of a graph, not a graph by itself.

Holger

Received on Thursday, 7 April 2016 23:52:41 UTC