Re: [PRD] Rule instances, refraction and Modify [Was: Re: Fwd: Clips behavior]

  On 19/01/2010 12:13, Christian De Sainte Marie wrote:
>
> All,
>
> csma wrote on 18/01/2010 15:43:48:
> >
> > 2. in CLIPS, the Modify is, really, a Retract followed by an Assert,
> > [..]
> >
> > That point is not really a problem, as far as regards CR etc,
> > because this, is, really, what the spec says it does, already.
>
> I meant that the spec says that the to-be-modified Frames are removed 
> from the fact base before the modified one is added.
>
> Unfortunately, that is not enough: we need the modified frame to be 
> considered a new fact wrt refraction. That means that we need to take 
> into account the transition state after the to-be-modified facts have 
> been removed, and before the modified frame is added.
>
> In other words, Modify cannot an atomic action, from the conflict 
> resolution viewpoint :-(
>
> Of course, we can specify around that problem, and make Modify atomic 
> from a transactional point of view, but not from a semantical one. 
> That would be rather kludgy, but that is feasible.
>
> Another solution is to remove Modify altogether: if it is not atomic 
> wrt the operational semantics, it does not really serve a purpose 
> anymore in PRD (it was already kludgy, anyway, because it is hard to 
> make good sense of Modify for multi-valued slots).
>
> From a design point of view, that seems the right solution (a Modify 
> action can be added back, with the appropriate semantics, if and when 
> we specify an object-oriented dialec).
>
> What shall we do?
I'm a little confused over what the problem is here. I feel we are 
mixing implementation details up with execution behaviour. If we are 
talking about the issue of refraction, this isn't related to modify 
being atomic. I don't see how modify with a retract+assert or a single 
propagation should matter. In either the fact still has the same 
timestamp on it when it was first inserted. Or are we discussing whether 
whether a modification is a propagation of the field changes as triples 
compared to the entire fact object? for the changes as tripples versus 
entire object, I think the implementation there isn't important what is 
important is the resulting behaviour; i.e. slot-specific or not. 
Slot-specific means a pattern only reacts to changes to fields it 
constrains on. With regards to refraction being a part of the spec or 
not; having it as mandatory isn't possible as some engines don't 
implement it; modify does not need to be atomic for refraction, it 
wasn't for OPS5.

Drools, Clips (not Clips COOL) and Jess (not slot-specific) treat modify 
as an update to the entire fact; because it retracts+asserts the entire 
fact, not the field+value that was modified. Clips COOL implements it's 
Objects as triples, thus a modify is actually a retract+assert of a set 
of triples not the entire object; providing slot-specific type 
behaviour.  Drools 5.1 does a single proapgation (of the entire fact), 
instead of retract+assert, this has no behavioural impact apart from on 
the TMS and agenda events.

My suggestions are:
1) Add refraction as engine behaviour configuration.
Refraction on/off
-Drools, Clips and Jess cannot have refraction on. JRules and OPSJ 
(fico) can. JRules can generate rules using refresh after every modify 
if refraction is off . Drools will add refraction for it's next release 
to bring inline with jrules and opsj.

2) Modify should be defined as a single action that includes the fields 
being modified. Whether the engine implements this as retract+assert or 
as a single propagation should be an engine implementation detail; 
likewise whether it's a propagation of triples or the entire fact is 
engine implementation detail.
-Timestamp on the fact does not change for a modify, it is the same as 
when the fact was inserted.
-We may however want to keep a recency timestamp that is updated for the 
modify. I don't know what other engines do here.
-Later we may need to address the characteristics of TMS, as that is 
impacted by the retract+assert. Likewise if we ever decicide to define 
event models, i.e activation created, cancelled, modified.
-Later we may want to allow the modification as a propagation of triples 
to give slot-specific behaviour. Jess allows both behaviours, by 
supporting an attribute controlloing the behaviour of a field; Clips 
does not. For Clips deftemplates work with a modify being for the entire 
fact and COOL as modification just for that tripple.

3) Add no-loop behaviour as engine configuration. There are three 
options here off (no-loop not supported), on such that a rule cannot add 
itself to the agenda (rule specific) regardless of the data, on such 
that a rule cannot add itself to the agenda for the current set of 
firing data but it can add itself for other new sets of data 
(data-specific).
-off/rule-specific/data-specific."off" indicates the no-loop is not 
supported.
-If refraction is on then only no-loop off or rule-specific is relevant. 
data-specific while allowed would be ignored, as it has no impact as 
that is already part of the refraction behaviour. That does not mean 
that refraction == no-loop (data-specific), refraction is that plus a 
lot more.

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