Re: ISSUE-66: Extended proposal for recursion

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 06:53:24 UTC