[Fwd: Fwd: comment on RIF-PRD]

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


-- 
Dr. Christopher A. Welty                    IBM Watson Research Center
+1.914.784.7055                             19 Skyline Dr.
cawelty@gmail.com                           Hawthorne, NY 10532
http://www.research.ibm.com/people/w/welty

Received on Thursday, 15 April 2010 21:05:47 UTC