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

Re: [PRD] Consensus of the PRD TF regarding refraction, conflict resolution and Modify

From: Sandro Hawke <sandro@w3.org>
Date: Mon, 01 Feb 2010 18:23:50 -0500
To: Christian De Sainte Marie <csma@fr.ibm.com>
cc: public-rif-wg@w3.org, jco2009@att.net, mdproctor@gmail.com
Message-ID: <29687.1265066630@waldron>

So, how confident are you all that this new design is the right one?
Which engines does it match?  Can we get test cases to demonstrate it?

How much text of PRD will be affected?  How soon can those changes be
done?   

(I think we'll need to know all that to decide about an LC2.)

FWIW, it all sounds fine to me, including adding RetractAll, but I don't
haven't followed this at a technical level.

      -- Sandro

> --=_alternative 00776570C12576BD_=
> Content-Type: text/plain; charset="ISO-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> All,
> 
> The PRD task force agreed, today, that the PRD spec could be repaired with =
> 
> the following changes :
> - for the purpose of refraction and recency, the states of the fact base=20
> after each atomic action must be taken into account, not only after each=20
> action block. That is, all the states of the fact base must be taken into=20
> account, not only the ones in which the conflict resolution strategy is=20
> applied. This can be considered the correction of a bug, since all the PR=20
> engines that we want to cover work that way;
> - the facts that Modify is not an atomic action, but a compound one, must=20
> be made explicit (currently, the spec says that it is atomic, but it=20
> follows from the formal definition in conjunction with taking intermediate =
> 
> steps into account, that it is not. Which is correct, since some of the PR =
> 
> engines that we want to follow do not have an atomic Modify action);
> - to make sure that all the cases are taken into account, rule instance=20
> must be defined with respect to the rules normalized in CLP form, that is, =
> 
> , with all the constants in the condition formula being replaced with=20
> universally quantified variables and the conjunction of a constraint=20
> equating the variable to the constant (one corner case that is not=20
> correctly taken into account with the current definition and that will be=20
> with the more precise one, for instance, is the case where the condition=20
> contains an disjunction of ground facts: "if ... (P(a) or Q(b)...=20
> then...", will be correctly processed under he current specification if=20
> normalized as: "forall ?x, if ...(  (p(a) and ?x=3Da) or (q(?x) and ?x=3Db)=
> =20
> ... then ..." - with some caveat wrt safeness).
> 
> More over, the PRD TFwould like to expose a new atomic action in the=20
> specifition, namely: RetractAll(frame) that retracts all the values of the =
> 
> "frame"'s attribute for the "frmae"'s object. The atomic action would be=20
> useful to make the semantics of Modify more easily intellegible (even if=20
> not exposed), and its exposition would make some implementations easier=20
> without harming others. However, the TF will not insist RetractAll being=20
> exposed if the cost was a 2nd last call.
> 
> Cheers,
> 
> Christian
> 
> IBM
> 9 rue de Verdun
> 94253 - Gentilly cedex - FRANCE
> Tel. +33 1 49 08 35 00
> Fax +33 1 49 08 35 10
> 
> 
> Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
> Compagnie IBM France
> Siege Social : 17 avenue de l'Europe, 92275 Bois-Colombes Cedex
> RCS Nanterre 552 118 465
> Forme Sociale : S.A.S.
> Capital Social : 611.451.766,20 ?
> SIREN/SIRET : 552 118 465 03644
> 
> 
> --=_alternative 00776570C12576BD_=
> Content-Type: text/html; charset="ISO-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> 
> <br><font size=3D2 face=3D"sans-serif">All,</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">The PRD task force agreed, today, th=
> at
> the PRD spec could be repaired with the following changes :</font>
> <br><font size=3D2 face=3D"sans-serif">- for the purpose of refraction and
> recency, the states of the fact base after each atomic action must be taken
> into account, not only after each action block. That is, all the states
> of the fact base must be taken into account, not only the ones in which
> the conflict resolution strategy is applied. This can be considered the
> correction of a bug, since all the PR engines that we want to cover work
> that way;</font>
> <br><font size=3D2 face=3D"sans-serif">- the facts that Modify is not an at=
> omic
> action, but a compound one, must be made explicit (currently, the spec
> says that it is atomic, but it follows from the formal definition in conjun=
> ction
> with taking intermediate steps into account, that it is not. Which is corre=
> ct,
> since some of the PR engines that we want to follow do not have an atomic
> Modify action);</font>
> <br><font size=3D2 face=3D"sans-serif">- to make sure that all the cases are
> taken into account, rule instance must be defined with respect to the rules
> normalized in CLP form, that is, , with all the constants in the condition
> formula being replaced with universally quantified variables and the conjun=
> ction
> of a constraint equating the variable to the constant (one corner case
> that is not correctly taken into account with the current definition and
> that will be with the more precise one, for instance, is the case where
> the condition contains an disjunction of ground facts: &quot;if ... (P(a)
> or Q(b)... then...&quot;, will be correctly processed under he current
> specification if normalized as: &quot;forall ?x, if ...( &nbsp;(p(a) and
> ?x=3Da) or (q(?x) and ?x=3Db) ... then ...&quot; - with some caveat wrt saf=
> eness).</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">More over, the PRD TFwould like to e=
> xpose
> a new atomic action in the specifition, namely: RetractAll(frame) that
> retracts all the values of the &quot;frame&quot;'s attribute for the &quot;=
> frmae&quot;'s
> object. The atomic action would be useful to make the semantics of Modify
> more easily intellegible (even if not exposed), and its exposition would
> make some implementations easier without harming others. However, the TF
> will not insist RetractAll being exposed if the cost was a 2nd last call.</=
> font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">Cheers,</font>
> <br><font size=3D2 face=3D"sans-serif"><br>
> Christian</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">IBM<br>
> 9 rue de Verdun<br>
> 94253 - Gentilly cedex - FRANCE<br>
> Tel. +33 1 49 08 35 00<br>
> Fax +33 1 49 08 35 10<br>
> <br>
> <br>
> Sauf indication contraire ci-dessus:/ Unless stated otherwise above:<br>
> Compagnie IBM France<br>
> Siege Social : 17 avenue de l'Europe, 92275 Bois-Colombes Cedex<br>
> RCS Nanterre 552 118 465<br>
> Forme Sociale : S.A.S.<br>
> Capital Social : 611.451.766,20 &#8364;<br>
> SIREN/SIRET : 552 118 465 03644<br>
> <br>
> </font>
> --=_alternative 00776570C12576BD_=--
> 
Received on Monday, 1 February 2010 23:23:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 1 February 2010 23:23:54 GMT