Re: ISSUE-131: Cleaned up definition of sh:hasShape

The definition is looking better.  The extraneous argument has been removed
and its incorrect use in the examples have also been removed.

However, some of the problems that I had identified remain.

The section still uses the undefined notion "Value Type" in the argument table.

A SHACL shape that recursively refers to itself is currently syntactically
illegal in SHACL.  The definition of sh:hasShape still does not detect such
constructs and when encountering them will sometimes return true, sometimes
false, and sometimes "undefined".

The passing of a graph has been removed.  However, the replacement is to use
"the IRI of the current shapes graph", which may not exist.


As well, as far as I know undefined is not a permissable return value for a
SPARQL function.

It is also unclear as to what counts as the production of a validation
result.

The treatment of failures is quite complex.  There is disagreement between
text and SPARQL code on how they are to be treated in core constraint
components.  There is no discussion of what a failure means.  Without some
notion of what it supposed to be happening there is no way to determine
whether the description of sh:hasShape is correct or even that using
sh:hasShape can support failures.


On 04/07/2016 04:52 PM, Holger Knublauch wrote:
> 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 Friday, 8 April 2016 21:32:15 UTC