- From: Adrian Paschke <adrian.paschke@gmx.de>
- Date: Tue, 19 Jan 2010 17:19:37 +0100
- To: "'Christian De Sainte Marie'" <csma@fr.ibm.com>
- Cc: "'Gary Hallmark'" <gary.hallmark@oracle.com>, "'Neal Wyse'" <neal.wyse@oracle.com>, "'RIF WG'" <public-rif-wg@w3.org>
- Message-ID: <009a01ca9923$32533760$96f9a620$@paschke@gmx.de>
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
Received on Tuesday, 19 January 2010 16:20:15 UTC