Re: ISSUE-66: Extended proposal for recursion

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 07:27:11 UTC