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

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