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

sh:hasShape creates its own (nested) validation engine. This produces 
new constraint violations. If one of them is a sh:FatalError then 
sh:hasShape returns unbound, which in turn may lead to further 
sh:FatalErrors in the surrounding engine.

Holger


On 7/11/2015 12:05, Peter F. Patel-Schneider wrote:
> 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:12:56 UTC