Re: ISSUE-66: Extended proposal for recursion

I do not view this as an acceptable stance for SHACL.

peter


On 07/10/2015 12:26 AM, Holger Knublauch wrote:
> This is outside of the core language and therefore the responsibility of the
> macro author.
> 
> Holger
> 
> 
> On 7/10/15 4:52 PM, Peter F. Patel-Schneider wrote:
>> Oh? What is the execution order of the two sh:hasShapes 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) ) .
>> }
>>
>>
>> peter
>>
>>
>> On 07/09/2015 11:01 PM, Holger Knublauch wrote:
>>> I had already made the execution order predictable: And, Or and Xor take an
>>> ordered rdf:List of shapes, and the engine executes them in-order. Where else
>>> could the order matter?
>>>
>>> Also note that the "fatal error" is only per (recursive) constraint, i.e.
>>> other constraints may still be evaluated if that's desired.
>>>
>>> Holger
>>>
>>>
>>> On 7/10/15 3:11 PM, Peter F. Patel-Schneider wrote:
>>>> "Throwing a fatal error whenever ..." brings in the notion of execution
>>>> order,
>>>> so I don't think that this can be counted on as "nothing [can] possibly go
>>>> wrong" without some analysis.
>>>>
>>>> peter
>>>>
>>>>
>>>> On 07/09/2015 09:49 PM, Holger Knublauch wrote:
>>>>> 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. The intention of this was to
>>>>> have a conservative, minimal base line, where nothing could possibly go
>>>>> wrong.
>>>>>
>>>>> As discussed today and suggested by Arthur, it is safe to extend this policy
>>>>> to also support the simple (but common) cases of direct recursion using
>>>>> sh:valueShape. I have modified my algorithm so that it now returns "true" as
>>>>> long as it stays inside the boundaries of sh:valueShape only. Any other
>>>>> use of
>>>>> recursion (including negation, xor and QCRs) remains as before, i.e. it will
>>>>> throw an error to indicate that it cannot process this request.
>>>>>
>>>>> Implementation detail: here, the sh:hasShape function takes another optional
>>>>> argument ?recursionIsError which is set to true when called from within a
>>>>> sh:NotConstraint, sh:XorConstraint etc. With this implementation, only the
>>>>> following test cases end with a fatal error: recursive-003, 005, 006,
>>>>> 007, 008
>>>>> but the others work fine, including the Polentoni example [1]
>>>>>
>>>>> With this I believe we can proceed with a design that generally allows
>>>>> recursion based on sh:valueShape, and throws "cannot handle" errors for the
>>>>> complex cases. I believe this is easy enough to explain and implement.
>>>>>
>>>>> Holger
>>>>>
>>>>> [1]
>>>>> https://github.com/w3c/data-shapes/blob/ISSUE-62/data-shapes-test-suite/tests/features/core/manifest.ttl
>>>>>
>>>>>
>>>>>
>>>>>
>>>
> 
>

Received on Friday, 10 July 2015 14:16:51 UTC