Re: comment on RIF-PRD

I will look at that.

Christian

ILOG, an IBM Company
9 rue de Verdun
94253 - Gentilly cedex - FRANCE
Tel. +33 1 49 08 35 00
Fax +33 1 49 08 35 10




From:
Chris Welty <cawelty@gmail.com>
To:
"Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
Date:
08/09/2009 18:58
Subject:
Re: comment on RIF-PRD
Sent by:
public-rif-wg-request@w3.org





Does one of the RIF editors want to make a small editorial change to PRD 
according to the suggestion of Wolfgang?

-Chris

Wolfgang Laun wrote:
> Dear Chris,
> 
> thanks for your patience while answering my questions. Below, inline,
> are the few comment I feel I have to make to your explanations.
> 
> On 8/28/09, Chris Welty <cawelty@gmail.com> wrote:
>>  > Wolfgang Laun wrote:
>>
>>  > How can one express the "no-loop" feature for upholding
>>  > refraction in spite of an update of a contributing fact in the 
rule's
> action
>>  > part?)
>>
>> Although this feature appears in several rule engines, we could not 
find a
> clear
>> common semantic description (in terms of our model). Some systems
> interpret
>> no-loop to mean that a rule may only fire once, others that at most 1
> instance
>> of a rule may be active at a time, others that a rule instance's 
actions
> may not
>> directly re-instantiate the same rule, etc.
>>
> 
> Jess and Drools appear to agree on the semantics of no-loop. I find 
that,
> when needed, it is difficult to mimic, e.g., by introducing artificial
> facts. The alternative semantics you cite: It would be interesting to
> explore whether the second and the third definitions aren't just 
(verbally)
> different definitions of the same thing.
> 
>>  > More specifically, in reference to the "running example", there are
> several
>>  > points that appear unusual when compared with some existing 
real-world
>>  > systems.
>>  >
>>  >    - Rules that require binding of facts to variables to be used in 
the
>>  >    action part have to be represented by "Forall ?var such that 
...",
> where the
>>  >    natural domain of the ?var, i.e., all facts of some class, is
> defined by a
>>  >    term (?var # class) of the following condition. Forall is also 
used
> where a
>>  >    condition's term will match at most once. While this is
> (FOP-)technically
>>  >    correct, it seems to make the addition of a "forall" pattern 
where
> the range
>>  >    is defined by a condition impossible? (Cf. "forall" in Jess or
> Drools.)
>> In PRD, the "such that ..." is syntactic sugar. I.e., Forall ?var such
> that
>> <cond1> if <cond2> then ... is equivalent to Forall ?var If And(<cond1>
> <cond2>)
>> then ... This gives compatibility with BLD. A forall pattern in Drools
> such as
>> If forall(Bus(color=="red")) then ... (as I understand the semantics)
> would be
>> translated to PRD as If Not(Exists ?bus And(?bus#Bus
> Not(?bus[color->"red"])))
>> then ... Finally, note that the Jess forall CE is somewhat different 
from
>> Drools  but can also be translated to PRD.
>>
> 
> 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. (But see (x), below.)
> 
> 
>>  >    - Similarly, Exists must apparently be used to introduce 
variables
> to be
>>  >    bound to facts, for matching arbitrary values. Again, the 
"exists"
> (as in
>>  >    Jess or Drools) appears to be barred (but this can still be
> expressed using
>>  >    double negation).
>>
>> No, the meaning of Exists in PRD and typical PR languages should be 
quite
> close.
>> E.g. the Drools rule If exists(Bus(color=="red")) then ... can be
> translated to
>> PRD as If Exists ?bus And(?bus#Bus ?bus[color->"red"]) then ...
>>
> 
> Well, all right.
> 
> (x) 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 is surprising that the notation does not include any (explicit)
>>  > definition of fact classes. While much of the structure is implied 
by
> the
>>  > terms in the rules (e.g., ?customer[ex1:status->",,,"]) there seems 
to
> be no
>>  > way to express class hierarchies, let alone projections (such as 
Java's
>>  > interfaces).
>>
>> Frames support the notion of subclass (##). E.g. if we are given that
>> Bus##Vehicle and Car##Vehicle then a rule such as Forall ?v If 
?v#Vehicle
> Then
>> ... will match all Cars and Buses.
> 
> 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?
> 
> ---
> 
> You are aware that the document isn't an easy read. Some sort of
> tutorial (as there is, for instance, for W3C XML Schema), showing
> the relation between PRD and existing RBS for the basic constructs
> would be great.
> 
> Kind regards
> Wolfgang Laun
> 

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





Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5, 92400 
Courbevoie
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 609.751.783,30 ?
SIREN/SIRET : 552 118 465 02430