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

Hi,

 

We had test cases which point out this semantic difference between an atomic
modify and an assert+retract combination.

 

http://www.w3.org/2005/rules/wiki/AssertRetract

 

and modify

 

http://www.w3.org/2005/rules/wiki/Modify

 

If modify is not considered as atomic transaction and triggers negated rules
we need to adapt the semantics to avoid loops. However then it does not make
sense to have a "syntactic sugar" construct such as modify. 

 

http://www.w3.org/2005/rules/wiki/AssertRetract2

 

-Adrian

 

 

Von: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] Im
Auftrag von Christian De Sainte Marie
Gesendet: Dienstag, 19. Januar 2010 13:13
An: Christian De Sainte Marie
Cc: Gary Hallmark; Neal Wyse; RIF WG
Betreff: Re: [PRD] Rule instances, refraction and Modify [Was: Re: Fwd:
Clips behavior]

 


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? 

Christian 

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