Re: ISSUE-76: Can errors be treated as false?

I have not modified my position on recursion.  However, I have not had
adequate time to work on this issue.  Therefore, so that other issues can be
discussed and possibly resolved, I have been careful to connect problems and
solutions only to particular kinds of recursion that are relevant to the issue
at hand.

peter


On 08/05/2015 05:04 PM, Holger Knublauch wrote:
> Hi Peter,
> 
> sometimes over the last few weeks you seem to have given up your preference
> towards disallowing recursion in general. (I also notice that none of the
> Recursion use cases on the corresponding Wiki page [1] have received a correct
> work-around). Unless I am again misunderstanding your position, I think this
> is a positive development towards a resolution of several tickets and we can
> focus on controlling the error handling.
> 
> If someone can come up with a definite response to the error handling
> questions that is implementable in SPARQL then I'd also be happy to shift away
> from my preference of executing the AND/OR operands in order.
> 
> Holger
> 
> [1]
> https://www.w3.org/2014/data-shapes/wiki/ISSUE-66:_SHACL_spec_ill-founded_due_to_non-convergence_on_data_loops
> 
> 
> On 8/5/2015 10:53, Peter F. Patel-Schneider wrote:
>> My comments at last week's teleconference during
>> http://www.w3.org/2015/07/30-shapes-minutes.html#item07 was not exactly to
>> suggest that errors should be treated as false, but to point out that SPARQL
>> has a solution for boolean operators that works with errors and does not
>> require ordered evaluation of conjuncts and disjuncts.  The solution is
>> detailed at http://www.w3.org/TR/sparql11-query/#evaluation
>>
>>
>> Does this work for SHACL?  It may depend on what constructs are permitted,
>> and thus what kinds of logical errors can be produced.
>>
>> For example, consider the following shape schema with all shapes totally
>> open
>>
>>    <NS> { :r ! <NS> }
>>    <E> { }
>>    <S> { :s ( <NS> or <E> ) }
>>
>> with graph
>>
>>    { :a :r :b .
>>      :b :r :a .
>>      :z :s :a . }
>>
>> Here there appears to be two possibilities for shape membership.  In one
>> possibility :a is in <NS> but :b is not and in the other the opposite is the
>> case.  It appears, however, that either way :z is in <S> and that the order
>> of the disjuncts in the definition of <S> shouldn't affect the answer.
>>
>> However, consider the same shape schema but with graph
>>
>>    { :a :r :b .
>>      :b :r :c .
>>      :c :r :a .
>>      :z :s :a . }
>>
>> Here there does not appear to be any possibilities.  If :a is in <NS> then
>> it shouldn't be.  However, if :a is not in <NS> then it should be.  So
>> should :z be in <S>?  Probably not, as there is something going
>> fundamentally wrong here.  Maybe this malaise should pollute all answers,
>> even to the point of generating errors instead of non-membership.  However,
>> again, the order of the disjuncts in the definition of <S> shouldn't affect
>> the answer.
>>
>> Maybe a more complex version of the SPARQL treatment of errors in boolean
>> operators will be the right solution if this construct is allowed in SHACL.
>> However, I do not know if I have enumerated all the possibilities that have
>> to be considered.
>>
>> peter
>>
>>
>> On 08/02/2015 09:13 PM, Holger Knublauch wrote:
>>> Peter, as far as I understood it, your proposal in the recent meeting was to
>>> treat (recursion) errors to mean "false". For example if a Shape would be
>>> defined as A OR B and A leads to infinite recursion while B evaluates to true
>>> then the overall Shape would still be true. Likewise, if S = A AND B and A
>>> leads to an infinite loop then the overall result will always be false,
>>> regardless of B.
>>>
>>> I have not made up my mind yet whether this interpretation makes sense. My
>>> understanding was that infinite recursion (or any other fatal error) means "I
>>> don't know"/"unknown", and that these fatal errors are always propagated up to
>>> the outside caller(s) to make sure that the user gets a meaningful error
>>> message. Your suggested interpretation basically says that infinite recursion
>>> means "false", and errors would not be propagated up.
>>>
>>> Are we sure this interpretation is desirable and well-defined? I have no
>>> strong opinion (others in the WG have thought more about recursion than I
>>> have) but I guess we should then apply the same changes to sh:valueShape, XOR
>>> and NOT.
>>>
>>> If nobody sees problems, then I'd appreciate a proposal so that we can move
>>> on. But as long as there are doubts that this alternative is well-defined, I'd
>>> prefer to play it safe and continue with the current design.
>>>
>>> Holger
>>>
>>> PS: Arthur asked about why an rdf:List is used instead of direct properties.
>>> Whatever we decide about the execution order, I still believe we need an
>>> rdf:List so that tools can display consistent expressions - if they are
>>> unordered triples, there is no way to have users enter "A OR B" and then
>>> always get "A OR B" in the display back. An alternative design would be to
>>> limit AND and OR to two operands, sh:left and sh:right, but that sounds rather
>>> ugly.
>>>
> 
>

Received on Thursday, 6 August 2015 00:36:13 UTC