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

On 9/04/2016 7:31, Peter F. Patel-Schneider wrote:
> 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.

I believe there is a fine line between useful feedback and pedantic 
feedback. The term "value type" is just meant in its intuitive English 
meaning here. Also, the term is already used in other parameter tables, 
and carries no implications whatsoever, but just to illustrate the 
expected type of nodes for those parameters or function arguments.

Anyway, I have added a sentence

     Note that the parameter tables in each of the following sections 
have a column
     called Value Type which indicates the expected type of the 
parameter values for
     documentation purposes, without enforcing any formal restrictions.

which hopefully satisfies your concerns.

>
> 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".

Re-reading the current state of ISSUE-22 I notice that we made a 
mistake. Luckily the ISSUE is still open so that we can fix this. The 
problem is that the current resolution even disallows "static" 
recursion, even if no instance in the data graph are ever recursive. I 
will argue in favor of changing this so that only run-time recursion is 
detected as an error. Otherwise, it becomes impossible to model acyclic 
tree structures, which are harmless but very common in practice.

My preference is to leave the current definition unchanged until we have 
clarified this. The comment about ISSUE-22 in the document allows this 
flexibility.

>
> 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.

The shapes graph MUST have a IRI. Only the data graph may be the default 
graph. I don't see how else to implement all this.

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

SPARQL functions may returns errors. I am not sure what the official 
term for these errors is, but the effect is that the resulting variable 
remains unbound. The SPARQL reference itself refers to

https://www.w3.org/TR/xquery/#dt-type-error

which also links to static errors and dynamic errors. Do you think we 
should use the term "error" instead of unbound/undefined?

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

Earlier we state that each row of a SELECT constraint query counts as a 
validation result, so this is hopefully clear (with a bit of good will).

>
> 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.

This should be clear:

     If a row in a SPARQL result set produces <code>true</code> as value 
for the variable
     <code>?failure</code> then a <span class="term">failure</span> must 
be reported.

Please suggest specific re-wording that satisfies your understanding.

Holger


>
>
> 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 Sunday, 10 April 2016 23:49:23 UTC