Re: [Fwd: Fwd: comment on RIF-PRD]

I would say this:

1. About no-loop -- It is interesting that Jess and Drools agree that 
this should be defined as "inhibit the creation of an activation 
A:<R,F1,F2,...> during the execution of R's consequence". However, 
JRules does not agree, and we could not find a suitable definition that 
was shared by all the production rule systems we looked at. Note that 
the Jess/Drools definition does not prevent looping should R activate R' 
and then R' activate R.

2. About "forall" -- there is a non-trivial intersection of production 
rules and logic rules - called RIF Core - where the syntax and semantics 
of the 2 kinds of rules coincide. Clearly for Core, 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.

Chris Welty wrote:
>
> Can someone take a look at this and respond? 
> -Chris
>
> -------- Original Message --------
> Subject: Fwd: comment on RIF-PRD
> Resent-Date: Thu, 15 Apr 2010 07:01:37 +0000
> Resent-From: public-rif-comments@w3.org
> Date: Thu, 15 Apr 2010 09:00:56 +0200
> From: Wolfgang Laun <wolfgang.laun@gmail.com>
> To: public-rif-comments@w3.org
> References: 
> <OF67169372.7BE7F07B-ON88257687.00837018-88257688.00000218@fr.ibm.com>     
> <17de7ee80912100438g2d93843am82767dd595d4f45e@mail.gmail.com>
>
> Hello,
>
> I replied to Christian's statement in December, but it seems that this
> didn't make it into the "works".
>
> Best
> Wolfgang
>
> ---------- Forwarded message ----------
> From: Wolfgang Laun <wolfgang.laun@gmail.com>
> Date: Thu, Dec 10, 2009 at 2:38 PM
> Subject: Re: comment on RIF-PRD
> To: Christian De Sainte Marie <csma@fr.ibm.com>
>
>
> Dear Christian,
>
> thank you very much for your reply. to summarize:
> - your argument against "no-loop" is not well substantiated;
> - I'm still not convinced that "forall" is a well-chosen keyword;
> - we seem to agree on the importance of being able to define "class
> [relationship] assertions".
>
> See inline comments for details.
>
>
> On Thu, Dec 10, 2009 at 1:00 AM, Christian De Sainte Marie
> <csma@fr.ibm.com>wrote:
>
>>
>> Dear Wolfgang,
>>
>> Wolfgang Laun wrote on 6 September 2009:
>> >
>> > Jess and Drools appear to agree on the semantics of no-loop.
>>
>> Here is a test case (in rif-like presentation language)
>>
>> eg:P(1)
>> eg:Q(1)
>> eg:Q(2)
>> no-loop rule:
>>  if eg:P(1) and eg:Q(?x)
>>  then do
>>   retract eg:P(1)
>>   retract eg:Q(?x)
>>   assert eg:P(1)
>>   assert eg:Q(?x + 10)
>>
>> in Jess, this will yield
>>
>> eg:P(1)
>> eg:Q(11)
>> eg:Q(2)
>>
>> or, depending upon ordering,
>>
>> eg:P(1)
>> eg:Q(1)
>> eg:Q(12)
>>
>> but note it will never yield (because of the no-loop)
>>
>> eg:P(1)
>> eg:Q(11)
>> eg:Q(12)
>>
>> This is not what I would expect, nor is it particularly nice to specify.
>
>
> The effect you are demonstrating here is not resulting from the 
> no-loop rule
> property. You are merely demonstrating the default conflict resolution
> strategy in combination with the side effect the consequence has on the
> activation set. (This might manifest itself in any number of ways, see
> below.)
>
> Initially (with f-1: P(1), f-2:Q(1), f-3: Q(2)) you have two activations,
> A1: <rule, f-1, f-2> and A2: <rule, f-1, f-3>. Firing is (apparently)
> indeterministic, but whichever activation comes first, its consequence
> "kills" the other activation by retracting f-1. Then, the no-loop 
> kicks in,
> and its effect is to avoid putting A3:<rule, f-4, f-5> on the agenda.
>
> Omitting the "evil" retract of fact P(1) will not inhibit the 
> execution of
> A2, so that you'll actually get this output from Jess:
> f-1   (MAIN::P (val 1))
> f-4   (MAIN::Q (val 12))
> f-5   (MAIN::Q (val 11))
> which is what you expect. (Using modify instead of retract-assert retains
> the original fact numbers, but essentially the same values.)
>
> For another demo of indeterminism, omit no-loop, retract/insert P, and do
> not update Q but create another fact R(?x+10). You'll get either R(12) or
> R(11).
>
> The effect of no-loop for a rule R with a fact signature (F1,F2,...) 
> can be
> defined as: inhibit the creation of an activation A:<R,F1,F2,...> 
> during the
> execution of R's consequence.
>
>
>> > Apparently we agree that "Forall ?var such that..." is different from
>> > Jess' or Drools' forall CE. - My point is that RIF-PRD's 
>> introduction of
>> > forall in a place where it is implied by systems like Jess or 
>> Drools is
>> > apt to confuse.
>>
>> > I guess it would help readers if there were a clarifying statement
>> > such as that RIF-PRD is representing both FOP quantifiers 
>> *explicitly*,
>> > and in a uniform way, close to the usual FOP notation. Practitioners
>> > with Jess or Drools are constantly having troubles with relating
>> > FOP expressions to either language's constructs. (That's why
>> > there is now http://www.jessrules.com/jess/docs/PropPred.pdf.)
>>
>> It seems the confusion may arise because these 2 FOL statements are not
>> equivalent:
>>
>> 1. Forall ?X (If P(?X) Then Q(1))
>> 2. If Forall ?X (P(?X)) Then Q(1)
>>
>> The former is intended by RIF's Forall. The latter is (more or less)
>> intended by the forall CE. Possibly it is the job of the Jess and Drools
>> documentation to note that they intend the second meaning of forall. 
>> [As an
>> aside, I am a bit confused by the material in PropPred.pdf because I 
>> don't
>> see the FOL implication symbol, often "->", in the FOL translation of 
>> Jess
>> rules.]
>>
>
> I agree with the distinction you have concisely laid down in the above
> comparison 1./2. But given that the symbolic logic symbol "inverse A" is
> used to write a statement which is either true or false, then what is 
> one to
> assume that this apparent RIF transliteration according to item 1. above
> yields? If it is not meant to yield a truth value, then it is a 
> misnomer -
> it will even confuse people who know their symbolic logic. (I think 
> what you
> mean here is *very much* like "for*each*", as used in some programming
> language to introduce a binding in an iteration over a data structure, 
> e.g.,
> foreach scalarEl in arrayA do sum += scalarEl. Or perhaps even a 
> completely
> different keyword such as "lambda" would be better.)
>
> Both Jess and Drools document clearly that their "forall" is just the FOL
> predicate conjunction operator.
>
>
>> > Quite so, but given a set of such rules: how do you make sure that
>> > Forall ?v If ?v#Vehicle will catch all Buses, Cars, Trucks, etc.?
>> > How are these relations x##Vehicle established in the first place?
>>
>> Membership '#' can be asserted for new objects and for unconditional
>> actions (i.e. ground facts). Subclass '##' cannot be asserted because 
>> many
>> PRD systems simply reflect some host lanaguage type system such as 
>> Java. We
>> could make subclass assertions legal for unconditional actions. Do 
>> you feel
>> strongly that we should do this?
>
>
> The combination of "subclass" and "assertion" surprises me, but this 
> may be
> my narrow field of vision ;-)
>
> However, I do feel that any system dealing with the notation of facts
> associated with classes (or types) and conditions of their properties is
> better off if it uses some concept of establishing relations on these 
> types.
> I have been developing rule sets based on class hierarchies where two (or
> more) different hierarchies were defined (using Java's interfaces), 
> and the
> result was a much more compact  (by approx. 50%) rule set than would
> otherwise have been possible.
>
> We expect that PRD systems will import membership and subclass relations
>> from XML or from an object-oriented language such as Java. We are 
>> nearing a
>> first public working draft of an XML import proposal. See
>> http://www.w3.org/2005/rules/wiki/RIF%2BXML_data-schema.
>>
>
> Interesting. I have been using XML heavily for establishing my fact
> databases, using JAXB for mapping XML to Java, with the unmarshalled 
> objects
> being used as facts.
>
> Best regards
> Wolfgang Laun
> ---
> Specialist Software Technology
> Thales Rail Signalling Solutions GesmbH
> Scheydgasse 41
> A-1210 Wien
> Austria
>
>
>>
>> Please acknowledge receipt of this email to <
>> mailto:public-rif-comments@w3.org <public-rif-comments@w3.org>> 
>> (replying
>> to this email should suffice). In your acknowledgment please let us know
>> whether or not you are satisfied with the working group's response to 
>> your
>> comment.
>>
>> -The RIF WG
>>
>> ------------------------------------------------
>> Christian de Sainte Marie
>>
>> 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
>>
>>
>
>

Received on Tuesday, 20 April 2010 19:13:47 UTC