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

The issue here is that a RIF frame differs quite a bit from a Java Object.
RIF semantics are quite clear and not at all vague when it comes to 
specifying exactly what happens to your frames.
The practical problem is that RIF says absolutely nothing about what 
happens to your Java Objects.
The good news is that many users don't care about Java Objects, they 
care about XML data. And we are working on that.

Paul Vincent wrote:
>
> Surely “slot specific” is itself a simplification from an OO 
> perspective... the possible events driving rule inferencing can include:
>
> - object change (i.e. some change to any slot associated with an object)
>
> - object change due to a change in a referred object (i.e. an object 
> referenced in a slot is changed)
>
> - slot change (i.e. an update operation was carried out on a slot)
>
> - slot value change (i.e. the value was updated AND the value was 
> different to what was before)
>
> - expression result change (i.e. the filter or join expression result 
> in some rule condition was changed)
>
> - overall expression result change (i.e. the overall condition 
> expression is changed)
>
> Etc
>
> Possible rule tests that need to be considered are:
>
> - existence of a member of a class
>
> - number of members of a class
>
> - member of a class with a property value X
>
> - member of a class with a property value that is a member of another 
> class
>
> Etc
>
> Unless all these are mapped out, with test cases and results for 
> participating engines, then we won’t know how to best define RIF PRD 
> default specifications and boundary cases will remain “vague”.
>
> Paul Vincent
>
> +1 650 206 2493 / mobile +44 781 493 7229
>
> *From:* public-rif-wg-request@w3.org 
> [mailto:public-rif-wg-request@w3.org] *On Behalf Of *Mark Proctor
> *Sent:* 03 August 2010 10:37
> *To:* Christian De Sainte Marie
> *Cc:* Gary Hallmark; Neal Wyse; RIF WG
> *Subject:* 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
>

Received on Tuesday, 3 August 2010 22:34:13 UTC