           A FAST PROLOG-BASED PRODUCTION SYSTEM KORE/IE



     (C)1992 Institute for New Generation Computer Technology
             (Read COPYRIGHT for detailed information)


1. Introduction

      Prolog programming is superior to LISP programming in the
productivity of developing expert systems.  On the other hand, it is
pointed out that executing application programs on Prolog systems is
not efficient.  However, it is possible to construct a production
system on Prolog more simply and effectively than a system on Lisp by
using the Prolog system as an inference system.  The motivation of
this research is to clarify a Prolog based architecture of a
production system which is fast enough for practical use.  A target of
the efficiency and functions are those of OPS5[Forgy 1981].  The
reasons can be described as follows;

          (l)OPS5 is the fastest system on an interpretive language; 
          (2)Many techniques for rule programming have been accumulated: 
          (3)OPS5 provides flexible rule expressions; and 
          (4)There are many application systems on OPS5. 

      In practice, it seems that OPS5 comes up to the standard of
production systems on interpretive languages.  In order to implement a
production system and reassess capabilities of a Prolog system, we
dared to use C-Prolog, since C-Prolog is one of the slowest Prolog
systems.  The production system we implemented is called KORE/IE. The
basic functions of KORE/IE are based on those of OPS5 and the system
provides a rule-oriented programming environment (i.e. a tracer for
rules, a stepper for inferences, and so on) in a similar manner as
OPS5. Furthermore, its functions are extended by using the advantages
of Prolog systems.

      A Prolog system provides powerful pattern matching (that is,
unification) and a flexible backtracking mechanism for constructing
inference engines. Furthermore, the system itself can be utilized as a
powerful inference engine based on a refutation mechanism[6]. 
Generally, in order to realize an inference system. we must construct
an interpreter for executing inference rules. It is well known that we
can realize such a system simply by using a Prolog system as an
inference engine in which non-unit Prolog clauses are considered to be
rules of the system and the rules are executed directly by the Prolog
system. These clauses can be easily obtained by transforming the rules
Into a Prolog program. In logic programming, as a very straightforward
method, this method is usually adopted to realize inference systems
(e.g.BUP[Matsumoto 1983] ).

       There is an alternative method based on partial evaluation
[Futamura 1983] of Prolog programs.  In this method. an inference
engine is partially evaluated with respect to inference rules and the
result generates a specialized Prolog program for the rules.  Then the
inferences are realized by executing the program.  This method is
adopted in order to utilize advantages of an interpreter for the
rules. This program can execute rules efficiently[Takeuchi 1985].  The
main advantage is easy maintenance of the rules. Its efficiency is due
to the fast refutation mechanism of Prolog systems.

      The above two methods for constructing inference systems do not
actively exploit the internal mechanism (e.g. matching, making and
modifying WM(working memory), conflict resolution) of the system.  In
a production system, the mechanism is called recognize-act cycle. 
Inference is attained by performing a sequence of the recognize-act
cycle:

     (1) Matching process: Determine a CS(conflict set) which includes
        rules whose LHSs (left-hand sides) have matched the contents of
        working memory.
     (2) Conflict resolution process: Select one rule from CS; if CS is 
        empty, halt the recognize-act cycle .
     (3) Act process: Perform the actions in the RHS (right-hand side) of 
        the selected rule.
     (4) Go to (1).

We can speed up the system by making the internal mechanisms faster.

      We propose a new method for constructing a fast production
system based on the techniques of the existing two methods mentioned
above.  In order to speed up the inference and realize the flexible
rule expressions, we take advantage of features of Prolog systems,
such as a speedy refutation mechanism, partial evaluation techniques
and speedy searching for heads of clauses.  The two existing methods
directly transform rules into Prolog clauses (that is, non-unit
clauses).  The main feature of our approach corresponds to speeding up
the internal mechanism of the inference.  In the approach. by using a
rule compiler, rules are transformed into Prolog clauses which are
specialized programs for speeding up the internal mechanism.  At
present, using the new method, KORE/IE is implemented on C-Prolog and
Quintus Prolog, and its speed of the inference is comparable with that
of OPS5 on Franz Lisp.


2. The rule description

       KORE, IE functions as a production system like OPS5.  KORE/IE
realizes a flexible and readable rule description by adopting the
syntax of a term description in Prolog.  A rule consists of

          (l)the name of the rule, 
          (2)the symbol ":", 
          (3)the symbol "if", 
          (4)the LHS of the rule, 
          (5)the symbol "then", 
          (6)the RHS of the rule, and 
          (7)the symbol " ." .    

    The rule is expressed as follows;

      Rule_name: if Conditionsl & Conditions2 ... then Actionl & Action2 ... .

where the Rule_name is the name of the rule.  ConditionN is a
condition element of the rule. It is called an LHS pattern.  ActionN
is a rule action, which is used to change WM, to execute Prolog
programs, and so on.  It is called an RHS action.  The symbol "&" is a
delimiter.  For example, a rule can be expressed as follows:

on_Floor:
    if
       goal(status = active, type = (on;move), object_name = X) &      
       monkey(on \== floor) 
    then 
       modify(2, on = floor) & modify(1, status = satisfied).

As shown in the example, the LHS is composed of LHS patterns which
correspond to compound terms of Prolog.  An LHS pattern consists of

    (l)a class name (which corresponds to a functor name of a term 
      in Prolog) and 
    (2)its arguments. 

       The arguments are a sequence of one or more slot-value pairs.
The pairs correspond to terms which have functors of arity 2 (e.g. =,
==, \==, =<, >=).  The arguments are called slot descriptions.  The
slot descriptions are used in the same manner as the basic predicates
for comparison of terms in Prolog. For example, "on \==, floor" in the
above example tests if the value of the slot "on" obtained from the
current contents of WM and the value "floor" are not literally
identical.  In Prolog programs. the goals in the body of a clause are
linked by the operator "," and the operator ";" which can be
interpreted as conjunction ("and" and disjunction ("or") respectively.
In the same manner, we can also use a conjunctive and a disjunctive
slot description in the slot description as follows:

  Conjunctive slot description:
          Siot = (Restriction1, Restriction2, ..., RestrictionN)

  Disjunctive slot description:
          Slot = (Valuel; Value2; ...; ValueN)

      The right hand side of a conjunctive slot description consists
of some restrictions (or Prolog goals) which are used to indicate that
the slot value in a WM element must satisfy the restrictions
simultaneously. The right hand side of a disjunctive slot description
consists of some values (or Prolog goals) which are used to specify
that any of the contained values is acceptable as a match. Thus, "type
= (on;move)" in the above example will match either "on" or "move".

In a rule, we can use a functional notation to enhance the readability
of the rule.  For example, the following is a predicate definition
which returns the result to the first argument "Result":

          add_one(Result, Number) :- Result is Number + 1.

This definition can be used as a function in a slot description as 
follows;

          slot = add_one(X).

The functional notation can be executed as a normal Prolog program
since a rule containing functional notations is compiled into Prolog
programs.



3. The Inference Mechanism

   In KORE/IE, the inference mechanism can be realized as basic Prolog
computations, because a rule compiler translates rules into a uniform
Prolog program.  The program consists of LHS clauses for the LHS and
RHS clauses for the RHS .  A change in WM is transformed to a Prolog
query for the LHS clauses.  Applying the query by using the Prolog
refutation mechanism corresponds to executing the matching process of
the recognize-act cycle and generates instantiations as a result of
the query.  An instantiation is an element in a conflict set which is
an ordered pair of a rule name and a list of WM elements satisfying
the rule's LHS.  Then a new conflict set is constructed for every rule
base.  A unique conflict resolution strategy is applied to the
conflict set .  After a conflict resolution, one instantiation is
selected for executing an RHS clause.  Execution of the RHS clause is
achieved by applying a Prolog query for RHS clauses. The query is
generated by transforming the selected instantiation. Applying the
query in Prolog corresponds to performing an act process of the
recognize-act cycle.



4. Syntax of KORE/IE

       The following is a simplified BNF description of the syntax of
KORE/IE.  Several terms have been left undefined: <Prolog constant
atom>, <Prolog variable>, <Prolog term>, < Prolog predicate>.  These
indicate a constant atom, a variable, a term, and a predicate in
Prolog, respectively.

       <production> ::=  <rule_name> : if <lhs> then <rhs> .
        <rule_name> ::=  <symbolic_atom>
    <symbolic_atom> ::=  <Prolog constant atom>
              <lhs> ::=  <ce> | <ce> & <lhs>
               <ce> ::=  <positive_ce> | <negative_ce>
      <positive_ce> ::=  <form> |  <designator> <form>
       <designator> ::=  <symbolic_atom>
      <negative_ce> ::=  - <form> 
             <form> ::=  <lhs_term>
         <lhs_term> ::=  <class_name>(<slot_values>)
       <class_name> ::=  <symbolic_atom>
      <slot_values> ::=  <sv> | <sv>,<slot_values>
               <sv> ::=  <slot_name><predicate><value>
        <slot_name> ::=  <symbolic_atom>
            <value> ::=  <symbolic_atom> | <Prolog variable> | <Prolog term>
        <predicate> ::=  =| \== | > | >= | < | =< |
              <rhs> ::=  <action> | <action> & <rhs>
           <action> ::=  make(<class_name>,<slot_values>) |
                         modify(<designator>,<slot_values>) |
                         remove(<designator>) |
                         < Prolog predicate> 


References
[Forgy 1981] Forgy,C.L.: " OPS5 User's Manual", CMU-CS-81-135, July(1981).
[Futamura 1983] Futamura,Y. : "Partial Computation of Programs", Lecture 
     Notes in Computer Science 147, Springer-Verlag,(1983).
[Matsumoto 1983] Matsumoto,Y., Tanaka,H., and Kiyono,M. : "BUP: A Bottom-up
     Parser Embedded in Prolog", New Generation Computing 1, No.2, 1983.
[Shintani 1986] T.Shintani, Y.Katayama, K.Hiraishi, and M.Toda : "KORE: A 
     Hybrid Knowledge Programming Environment for Decision Support based
     on a Logic Programming",  Logic Programming'86,  Lecture Notes in
     Computer Science,  No.264,  Springer-Verlag,  pp.22-33, (1986).
[Shintani 1988] T.Shintani : "A Fast Prolog-Based Production System KORE/IE", 
     Logic Programming: Proceedings of the Fifth International Conference 
     and Symposium(edited by R.A.Kowalski and K.A.Bowen), MIT Press, pp26-41, 
     (1988).
[Shintani 1990a] T.Shintani : "A Rule based Consistency Maintenance for 
     Subjective Judgments", Proceedings of International Conference on
     Information Technology, Commemorating the 30th Anniversary of The
     Information Processing Society of Japan, Part:2, pp.179-186,(1990).
