Re: Proposal to close ISSUE-76 stating that execution order matters

On 7/30/15 12:13 AM, Peter F. Patel-Schneider wrote:
> I raised this issue because I believe that there are excellent reasons for not
> requiring a particular order for the execution of the operands of the boolean
> operators.  Some of these reasons are even independent of the treatment of
> constraint violations that produce non-boolean results, although such results
> do make it more difficult to come up with a good solution.
>
> To me this is not a pseudo argument in any way, shape, or form nor do I
> believe that I have been dishonest at all here.
Of course you would say that, and of course the chair would chime in and 
follow his duty of pointing at the usual etiquette on such groups. I 
urge the members of this group to apply their own judgement. You have 
raised this issue a couple of days after I published my proposal to 
implement recursion with error handling. The description of your ticket 
states

"Should AND and OR be commutative?

If errors are permitted to propagate upwards reordering disjuncts or 
conjuncts can result in different violations if care is not taken in how 
the disjuncts and conjuncts are evaluated."

I have pointed out that this is likely the main driver for opening the 
ticket, not the ability of SHACL engines to optimize the execution order 
as you stated later. It is easy to come up with arguments both ways - as 
I have pointed out many programming languages do this commutatively. The 
term "pseudo argument" was probably not ideal - not sure how else to get 
this message across though.

I could now start a long rant about why I believe that W3C processes are 
fundamentally flawed. The fact that a single person (including myself) 
can block progress for any length of time, draw the whole attention to 
issues and then create endless theoretical discussions is one of the 
problems here. It is easy to fall into this trap - and we are all guilty 
of this sometimes - because the process is designed to allow and even 
encourage such things. Yet from time to time I believe we should remind 
ourselves that on reflection it would be more helpful to talk straight 
and look at the big picture instead of getting sidetracked by minuscule 
problems.

This is my personal impression at least. Of course I may be wrong. Fact 
is that we are one month behind the scheduled Last Call date and have 
not even produced a FPWD. In a commercial environment such a team 
performance would have lead to project cancellation long ago.

Holger


>
> Peter F. Patel-Schneider
> Nuance Communications
>
> On 07/28/2015 04:18 PM, Holger Knublauch wrote:
>> On 7/29/2015 9:02, Peter F. Patel-Schneider wrote:
>>> I would say instead that the *most relevant* computer languages, e.g., SQL and
>>> SPARQL, do not work this way.  I believe that most users of SHACL will not see
>>> that the connection to programming languages is so strong as to dictate how
>>> SHACL works.
>>>
>>> In general, users cannot tell which constraint is most restrictive.
>> In many cases they can. Why else do languages like SPARQL have ( ... )
>> brackets to control the execution order. According to your logic, those should
>> be removed from SPARQL too.
>>
>> Frankly, I believe the whole point of opening this ticket was to try to make
>> it as hard as possible for us to make recursion work - the execution order is
>> needed for error handling there. I would prefer an honest discussion instead
>> of hiding behind pseudo arguments.
>>
>> Thanks,
>> Holger
>>
>>
>>>     This is a
>>> job better done by the analog of query optimizers.  Requiring a particular
>>> order of evaluation will inhibit such optimiizations.
>>>
>>> peter
>>>
>>>
>>> On 07/27/2015 05:27 PM, Holger Knublauch wrote:
>>>> ISSUE-76 [1] is about whether the order of AND and OR operands should matter.
>>>> I believe the order should matter, because this is how most computer languages
>>>> work and therefore matches the expectation that users can put the most
>>>> restrictive operands first to avoid unnecessary evaluations. It also helps
>>>> produce consistent results in the face of errors. sh:AndConstraint and
>>>> sh:OrConstraint use rdf:Lists for that reason.
>>>>
>>>> Holger
>>>>
>>>> [1] http://www.w3.org/2014/data-shapes/track/issues/76
>>>>
>>

Received on Wednesday, 29 July 2015 20:14:08 UTC