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

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

From: Christian De Sainte Marie <csma@fr.ibm.com>
Date: Tue, 19 Jan 2010 13:13:01 +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: <OFC516DB73.5268DA1B-ONC12576B0.0042885B-C12576B0.00431CBE@fr.ibm.com>
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 12:13:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 January 2010 12:13:45 GMT