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

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:04:54 UTC