modules in RIF

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 Tuesday, 1 April 2008 21:06:35 UTC