Re: [PRD] Refraction Semantics may be WRONG!

Hi, Gary,

Gary wrote on 17/11/2009 01:36:06:
> 
> I've discovered that refraction in OBR and Jess do not conform to the 
> PRD spec. In particular, the
> http://www.w3.org/2005/rules/wiki/Modify_noloop test case will always 
> loop. The issue is that the PRD spec includes only the Forall variables 
> in the rule instance, but my system(s) also includes the Exists 
> variables in the rule instance.
>
> What do the other PR systems do? Can you please try the Modify_noloop 
test?

I am not sure if I understand where is the problem.

As Paul puts it, the default behaviour of some engines is "to place a rule 
back on the agenda if the action is updating a property in the rule 
condition. In some other rule engines, the condition state change (versus 
referenced rule variable state change) is what determines whether a rule 
is placed back on the agenda."

OBR/Jess and Tibco are in the first case, JRules is in the second case (as 
well as CLIPS, Drools and Blaze? I do not remember for sure).

So, any definition we might have chosen would reproduce the default 
behaviour of only half the field, anyway.

If I remember well, what saved us is that OBR/Jess can force the "no-loop" 
behaviour, and JRules can force the "loop" behaviour (and Drools, Blaze, 
CLIPS etc can force their non-default behaviour in that respect, whichever 
it is).

So, PRD provides a syntactic way to differentiate between the "loop" and 
"no-loop" cases, as exemplified by the modify_loop [1] and modify_no-loop 
[2] test cases: they represent the same rule, where the intended behaviour 
is to loop [1] or to refract [1].

And, so, there is no ambiguity. If we had included the existentially 
quantified variables (local to the condition) in the definition of 
refraction, we would have had no way to distinguish between the two cases 
anymore (not without an additional construct).

My understanding is that, given the same rule that says

If the count attribute of ?x is positive, then decrement that attribute by 
1

JRules will produce a RIF-PRD document that is equivalent to the "no-loop" 
example (forall x, if exists y etc), whereas OBR will produce a RIF-PRD 
document that is equivalent to the "loop" example (forall x, y, etc).

And JRules will deserialize OBR's document (that is meant to loop) into an 
rule where refraction is switched off on changing the "count" attribute, 
whereas OBR will deserialize ILOG's document (that is meant not to loop) 
into a rule where the "no-loop" attribute is forced to "on". 

Or did I miss something?

Btw, we discussed all this already, about one year ago, including whether 
we should have constructs to indicate repeatability at the rule, object 
and/or property level (e.g., [3]; in general, all the emails about "[PRD]" 
and "PICK specification" in the second half of October 2008). See, in 
particular my email summarizing our agreement in Orlando [4], based on the 
previous discussions (and resolution in the minutes of the 11 Nov. telecon 
[5], based on that email; notice that I did not influence that resolution 
directly, since I did not attend that telecon :-).

[1] http://www.w3.org/2005/rules/wiki/Modify_loop
[2] http://www.w3.org/2005/rules/wiki/Modify_noloop
[3] http://lists.w3.org/Archives/Public/public-rif-wg/2008Oct/0127.html
[4] http://lists.w3.org/Archives/Public/public-rif-wg/2008Oct/0135.html
[5] 
http://lists.w3.org/Archives/Public/public-rif-wg/2008Nov/att-0042/2008-11-11-rif-minutes.html

Cheers

Christian

IBM
9 rue de Verdun
94253 - Gentilly cedex - FRANCE
Tel. +33 1 49 08 35 00
Fax +33 1 49 08 35 10

Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siège Social : 17 avenue de l'Europe, 92275 Bois-Colombes Cedex
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 609.751.783,30 ?
SIREN/SIRET : 552 118 465 03644