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

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 01:49:06 UTC