W3C home > Mailing lists > Public > public-rif-wg@w3.org > April 2008

Re: modules in RIF

From: Gary Hallmark <gary.hallmark@oracle.com>
Date: Fri, 04 Apr 2008 11:59:00 -0700
Message-ID: <47F67A74.9010803@oracle.com>
To: Michael Kifer <kifer@cs.sunysb.edu>
CC: RIF WG <public-rif-wg@w3.org>

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 Friday, 4 April 2008 19:01:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:48 GMT