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

I have just pushed an updated version

     http://w3c.github.io/data-shapes/shacl/index-2015-07-13.html

which includes all my latest changes:
- Removed Appendix in favor of shacl-ref document
- Cleaned up scopes/filter shape mechanism (ISSUE-62)
- Latest changes to sh:hasShape are in the Ref document:

     http://w3c.github.io/data-shapes/shacl-ref/

Since the sh:hasShape stuff is SPARQL-specific, it is currently only 
covered by the Ref document. It is used in the definitions of various 
built-in templates such as sh:valueShape and sh:NotConstraint. You can 
also look at the associated Turtle file. What else would you consider a 
"full description"? If you believe this cannot work correctly, maybe you 
can provide a counter-example.

Thanks,
Holger


On 7/11/2015 14:37, Peter F. Patel-Schneider wrote:
> 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 Monday, 13 July 2015 05:43:10 UTC