RE: modules in RIF

Fascinating! Presumably the "ruleset stack" idea is JESS-specific. 
- Ilog and Blaze both use the concept of a "ruleflow" (c.f. process
flow, like BPMN) for graphically-modelled (conditional) ruleset
orchestration. 
- TIBCO, using rules for CEP which is a more continuous and less
transactional process, doesn't have an "orchestration" concept but
instead uses a state model (and rules can of course refer to something's
state).  
- OMG PRR steers clear of ruleset orchestration (this can be modelled
using activity diagrams or the aforementioned BPMN).

Cheers

Paul Vincent
TIBCO | Business Optimization | Business Rules & CEP
 

> -----Original Message-----
> From: public-rif-wg-request@w3.org
[mailto:public-rif-wg-request@w3.org]
> On Behalf Of Gary Hallmark
> Sent: 04 April 2008 19:59
> To: Michael Kifer
> Cc: RIF WG
> Subject: Re: modules in RIF
> 
> 
> Some PR systems, notably descendants of CLIPS like Jess and Oracle
> Business Rules, have a notion of an "orchestration" of multiple
modules
> (or rulesets) for the purpose of partitioning the rule base.  The
> details of the orchestration vary, but in several engines there is a
> notion of a "ruleset stack" that is a stack of ruleset names.  The
> ruleset on top of the stack is said to be "in focus", and only rules
in
> the in-focus ruleset are allowed to fire.  When no more rules can
fire,
> the engine pops the ruleset stack, thus changing focus and allowing
> other rules to run, until the ruleset stack is empty.  A Rule can be
> declared as "auto-focus", meaning that whenever its condition is true,
> the name of the containing ruleset is pushed on the ruleset stack.
> (Also, production rule actions can manipulate the stack.)
> 
> With this, one can express Michael's example in PR (simplified OBR
> syntax) as:
> 
>   ruleset Foo {
>     assert q(b,b);
>     assert q(c,d);
>     rule {
>       autoFocus = true;
>       if q(var x, var y) and Bar.r(y) then assert p(x);
>     }
>   }
>   ruleset Bar {
>     assert p(b);
>     assert s(d,b);
>     rule {
>       if p(var x) then assert r(x);
>     }
>     rule {
>       autoFocus = true;
>       if s(var x, var y) and Foo.p(y) then assert r(x);
>     }
>   }
> 
> After the run, working memory contents includes Foo.p(b), Foo.p(c),
> Bar.r(b), Bar.r(d)
> 
> 
> Michael Kifer wrote:
> > At today's telecon I was asked to briefly explain the idea of
modules.
> >
> > 1. Example
> >
> > A module is a KB (a ruleset) where some literals refer (query) some
> other
> > KB.  This reference process can be recursive. In the following
example I
> am
> > using the syntax of Flora-2. It shows two modules, Foo and Bar.
> >
> > ====================
> > module Foo contains:
> > --------------------
> > q(b,b).
> > q(c,d).
> > p(?X) :- q(?X,?Y), r(?Y)@Bar.
> >
> > ====================
> > module Bar contains:
> > --------------------
> > p(b).
> > s(d,b).
> > r(?X) :- p(?X).
> > r(?X) :- s(?X,?Y), p(?Y)@Foo.
> >
> >
> > In Flora-2, the query ?- p(?X) in module Foo would return ?X=b,c
> > and the query ?- r(?X) in module Bar would return ?X = b,d
> >
> > Someone may issue the query
> >
> > ?- p(?X)@Foo, r(?X)@Bar.
> >
> > in a third module, and the answer would be ?X=b.
> >
> > This mechanism is very general. It subsumes import and is much more
> useful
> > than import.
> >
> > 2. History
> >
> > Sometimes people say that these are modules "like in Flora-2",
because
> > Flora-2 has many interesting extensions to this idea. But what I
just
> > described is actually the usual ISO Prolog mechanism. (I have to
check
> if
> > it is actually in ISO, but several Prologs have it.) The syntax
there is
> > module::predicate.
> >
> > 3. Theory
> >
> > There is a very simple semantics to the modules, as described above:
> > simply rename the predicates that occur in the ruleheads of modules
> > in a unique way, and also do the corresponding changes to the
references
> > made from other modules. For instance, the above becomes something
like:
> >
> > Rules/facts that come from Foo:
> >
> > #$%^_Foo_q(b,b).
> > #$%^_Foo_q(c,d).
> > #$%^_Foo_p(?X) :- #$%^_Foo_q(?X,?Y), #$%^_Bar_r(?Y).
> >
> >
> > Rules/facts that come from Bar:
> >
> > #$%^_Bar_p(b).
> > #$%^_Bar_s(d,b).
> > #$%^_Bar_r(?X) :- #$%^_Bar_p(?X).
> > #$%^_Bar_r(?X) :- #$%^_Bar_s(?X,?Y), #$%^_Foo_p(?Y).
> >
> >
> > The "Romans" took this idea further and gave it model-theoretic
> semantics
> > for the cases when the different modules may have different
semantics.
> > They called it "peer-to-peer KBs" (while the term "module" comes
from
> > Prolog).
> >
> >
> > 4. Difficulties
> >
> > If we were to develop a module mechanism just for BLD, there would
be no
> > problem. It would be just a matter of a few days to carefully extend
> things.
> >
> > However, in RIF we are supposed to prepare an infrastructure for
rules
> on
> > the Web. If RIF is to take off, it will happen because other people
will
> > see a chance and develop different dialects. These rulesets will
have
> > different semantics, and RIF (specifically RIF-FLD) should address
> > this. Developing a semantic framework for this requires some
thought.
> > The "Romans" did not go far enough.
> >
> >
> > 5. Interim solution
> >
> > In many cases people just import rules because their applications
are
> > relatively simple. So, we can provide a simple mechanism for that.
> > It will work even in FLD because this mechanism imports things with
the
> > same syntax and semantics. Later on we might add modules, and import
> will
> > become a kind of shortcut for a special case of querying a module.
> >
> > For instance, even though Flora-2 has modules (even more powerful
than
> what
> > I just described), it has two other mechanisms in addition:
> >
> > #include
> > import
> >
> > #include is literal inclusion of rules (just like in C). In terms of
> RIF,
> > this would mean that everything is included and local symbols with
the
> same
> > name mean the same in the included and the including ruleset. I do
not
> > think RIF needs that (being an exchange language), but I may be
wrong.
> >
> > Import is analogous to what Jos mentioned during the telecon.
> > Rules are included, but the local symbols mean different things in
the
> > included and the including sets. You can think of the local symbols
as
> > "unexported" symbols. In fact, Prologs and Flora-2 have explicit
export
> > directives (in Flora-2 one can even export things for use in some
> specific
> > modules, but not in others).
> >
> >
> > Hope this brief note helps.
> >
> >
> > 	--michael
> >
> >
>

Received on Saturday, 5 April 2008 09:41:47 UTC