Re: shapes-ISSUE-73 (sh:hasShape error handling): how do recursion errors from sh:hasShape interact with SPARQL [SHACL Spec]

So 'A while ago I had suggested a solution to the recursion question that
would throw a fatal error ("cannot handle") whenever it encounters a recursive
call to sh:hasShape with the same ?node/?shape pair.'
[https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jul/0033.html]
is not correct?  If sh:hasShape doesn't throw an error, how does the failure
get through SPARQL FILTER constructs, e.g., in the expansion of sh:valueShape?

peter


On 07/10/2015 06:48 PM, Holger Knublauch wrote:
> sh:hasShape doesn't throw a fatal error by itself, but reports "unbound".
> Every SPARQL function may return no binding, and queries can chose how to
> handle this, e.g.
> 
>     BIND (sh:hasShape(...) AS ?hasShape) .
>     FILTER bound(?hasShape) .
> 
> The "fatal error" (sh:FatalError) is created by the surrounding SHACL engine
> based on the results of the SELECT queries. The current convention in my draft
> is that sh:FatalError is triggered if a SELECT query returns a variable ?error
> = true. We can of course change this convention - maybe ?fatalError would be a
> better indicator.
> 
> This is all worked out on a branch, but I am not permitted to change the main
> document anymore without resolutions from the WG. You can see the current
> details in the shacl-ref document, e.g. at
> 
> http://w3c.github.io/data-shapes/shacl-ref/#AbstractValueShapePropertyConstraint
> 
> You can see there that the SELECT returns ?error=true if !bound(?hasShape)
> 
> The authors of custom constraints and macros using SPARQL can use the same
> mechanisms to take full control over how they want to treat unsupported
> recursion.
> 
> Please confirm if this resolves your issue.
> 
> HTH
> Holger
> 
> 
> On 7/11/15 12:32 AM, RDF Data Shapes Working Group Issue Tracker wrote:
>> shapes-ISSUE-73 (sh:hasShape error handling): how do recursion errors from
>> sh:hasShape interact with SPARQL [SHACL Spec]
>>
>> http://www.w3.org/2014/data-shapes/track/issues/73
>>
>> Raised by: Peter Patel-Schneider
>> On product: SHACL Spec
>>
>> If sh:hasShape can throw a fatal error, then there needs to be a
>> specification of how this error interacts with the rest of SPARQL.
>>
>> Otherwise the results of certain shape validations can depend on, for
>> example, the order of evaluation of constructs that SPARQL leaves open.
>>
>> In a macro defined as
>>
>> orproperties(?p,?q,?s)
>>
>> expanding to
>>
>> SELECT ?this (?this as ?subject)
>> WHERE {
>>     ?this ?p ?pv .
>>     ?this ?q ?qv .
>>     FILTER (sh:hasShape(?pv, ?s, ?shapesGraph)
>>          || sh:hasShape(?qv, ?s, ?shapesGraph) ) .
>> }
>>
>> the results of validation could depend on the order in which the two
>> sh:hasShapes are evaluated.
>>
>>
>>
> 
>

Received on Saturday, 11 July 2015 02:06:35 UTC