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

rule engines combined with Java objects (or other OOPL) will be 
compatible when
a. there is a specification of the semantics of the combination of 
rules+objects
b. the rule engines conform to the spec

RIF does not specify the semantics of rules+java objects, only of 
rules+frames/relations, rules+rdf/owl, and (in progress) rules+xml.

I think we are in agreement. RIF does not specify the semantics of 
rules+objects, including all the issues with slots,etc. that you mention.

The hope is that rules+frames are a useful approximation to 
rules+objects, and will be a basis for compatibility when "simple" 
(frame-like) objects are combined with rules.

On 8/4/2010 1:07 AM, Paul Vincent wrote:
> Hi Gary: surely dealing with XML rather than Java misses the point over
> rule engine compatibility - all the slot discussions below are relevant
> to any hierarchical data structure including XML and DB data AND any
> "BRE" (PRD engine). And we are interested in runtime semantics, surely?
>
> It may well be that PRDv1 covers all these... but for a "rule standard"
> it would be good to see what (1) current BRE (PRD engine) behaviours are
> in these cases, (2) how they vary, (3) what additional constructs (if
> any) are needed in PRD to cover.
>
> Unless I missed some large part of PRDv1!
>
> Paul Vincent
>
>    
>> -----Original Message-----
>> From: Gary Hallmark [mailto:gary.hallmark@oracle.com]
>> Sent: 03 August 2010 23:31
>> To: Paul Vincent
>> Cc: Mark Proctor; Christian De Sainte Marie; Neal Wyse; RIF WG
>> Subject: 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 Wednesday, 4 August 2010 16:50:52 UTC