W3C home > Mailing lists > Public > public-rif-wg@w3.org > January 2010

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

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>


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




and 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. 







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]



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? 


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:57 UTC