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

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 Wednesday, 5 August 2015 00:54:07 UTC