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

I don't see how that can work correctly.  I think that a full description is
needed for analysis by the working group.

peter


On 07/10/2015 07:12 PM, Holger Knublauch wrote:
> 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 04:38:14 UTC