W3C home > Mailing lists > Public > public-rif-comments@w3.org > April 2010

Re: comment on RIF-PRD

From: Wolfgang Laun <wolfgang.laun@gmail.com>
Date: Sat, 24 Apr 2010 14:06:52 +0200
Message-ID: <j2p17de7ee81004240506icd56216bk325f2a55bb8190e0@mail.gmail.com>
To: Christian De Sainte Marie <csma@fr.ibm.com>
Cc: public-rif-comments@w3.org
On Wed, Apr 21, 2010 at 7:13 PM, Christian De Sainte Marie
<csma@fr.ibm.com> wrote:
> Dear Wolfgang,
> Wolfgang Laun <wolfgang.laun@gmail.com> wrote on 10/12/2009 13:38:00:
>> thank you very much for your reply. to summarize:
>> - your argument against "no-loop" is not well substantiated;
> It is, indeed, interesting that Jess and Drools agree that "no-loop" should
> be defined as "inhibit the creation of an activation A:<R,F1,F2,...> during
> the execution of R's consequence". (Note that the Jess/Drools definition
> does not prevent looping should R activate R' and then R' activate R.)

Loops over n > 1 rules are a problem that cannot be addressed very well,
as there is no telling whether the activation cycle of R1 -> R2 -> R1 ->...
is truly a cycle or not. In fact, even when n = 1 the cycle may terminate.

> However, JRules and other major engines do not agree, and we could not find
> a suitable definition that was shared by all the production rule systems we
> looked at. As a consequence, we made two changes in the specification:
> * Modify is now a compound action, that can always be replaced by one or
> more Retract followed by an Assert;


> * The default conflict resolution strategy rif:forwardChaining takes now
> into account the intermediate states of the fact base after each atomic
> action (rather than only after the complete execution of each rule
> instance).

I don't see why this is important, but never mind.

> As a consequence, to answer to your initial question (in [1]), the
> rif:forwardChaining strategy, that is defined as the minimal conflict
> resolution strategy that any RIF-PRD implementation must support, does not
> support the no-loop feature.
> However, the RIF dialects are meant to be extended, and we expect that more
> elaborate conflict resolution strategies will be specified. Discussions
> regarding proposed extensions are welcome on the RIF developers mailing list
> (mailto:public-rif-dev@w3.org).
> [1]
> http://lists.w3.org/Archives/Public/public-rif-comments/2009Aug/0000.html

Given the argument that "JRules and ... do not agree", and other arguments you
have presented, I'm content with the state as it is.

>> - I'm still not convinced that "forall" is a well-chosen keyword;
> We certainly agree, regarding RIF-PRD alone.
> However, there is a non-trivial intersection of production rules and logic
> rules - called RIF Core - where the syntax and semantics of the two kinds of
> rules coincide.
> Clearly for Core (and for the dialects that extend it on the logic side,
> like RIF-BLD), use of "forall" makes logical sense. We chose not to
> introduce a different keyword for the non-Core production rules, even if
> "forall" makes less intuitive sense in some cases.

To conclude this exchange, please just note that "forall" as it stands
now in RIF-PRD
might create a problem if a further extension intends to add a
LHS term "forall" expressing the truth of a proposition for a constrained set
of facts. As an example:
   rule "all English busses are red"
       forall( b : Bus( country == "England" )  # constrained set of
English Buses
                 Bus( b == this, colour == red ) )
       # fire ONCE (!) iff all English buses are red
This is definitely distinct from a rule which should fire for each red
English Bus,
which I have written in a roundabout way to better exhibit the difference:
   rule "a red English Bus"
      b : Bus( country == "England")
           Bus( this == b, colour == red )
      print( b.id + " is yet another red English bus" );

Whether such an extension as shown in rule "all English busses are
red" will ever
be proposed to RIF-PRD is, of course, not predictable. [I should like to discuss
my general view of these matters but here is definitely not the place for that.]

>> - we seem to agree on the importance of being able to define "class
>> [relationship] assertions".
> The working group has published a first public working draft of a document
> that specifies how RIF can be combined with XML (data and or schema) [2]. We
> would welcome your comments on that draft.
> [2] http://www.w3.org/TR/rif-xml-data/

OK, thanks.

> Please acknowledge receipt of this email to
> <mailto:public-rif-comments@w3.org>. In your acknowledgment please let us
> know whether or not you are satisfied with the working group's response to
> your comment.

I guess my "dissenting view" has been noted and filed away, so: hmm, yes,
not blissfully, but I'm satisfied.

Wolfgang Laun

> Cheers,
> The RIF WG
> --------------------
> Christian de Sainte Marie
> 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
Received on Saturday, 24 April 2010 12:07:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:07:00 UTC