Industrial applications of
artificial intelligence, which generally involve large and complex
knowledge-bases, are often expensive in terms of time and cost to
develop and maintain . These knowledge-bases typically consist
of rules, each rule encoding a valuable and reusable piece of domain
knowledge or expertise. Although knowledge representation mechanisms
other than rules exist e.g., cognitive maps, Bayesian networks
etc. this article is only concerned with rule-bases. The
effectiveness of these real-life systems depends on the nature and
contents of these rule-bases.
Knowledge-based systems follow
a special development life-cycle that is distinct from typical software
development models and historically they have been more expensive
to develop and maintain. There is no simple explanation for this
nor is there a simple solution to the problem of rule-based system
quality . This article explores rule structures and complexities
by proposing alternate (but related) rule classifications from different
points of view. We propose a thesis, and illustrate through examples,
that a rule belonging to a specific and single class is simple and
easy to understand while conversely, a rule that cannot be classified
cleanly is difficult to understand and maintain. We also present
simple programming guidelines for each rule class, that
||identify some similarity
of appearance, interfaces, use, style and that assist each rules
comprehension. We use Prolog as the rule-language, although this
general approach is usable by other rule-base engines.
Classification of Rules
It is possible to classify
Rules in a Prolog program from various points of view (Table 1).
Although many of these classes are already described in the literature
[3, 4] and are known to individual Prolog programmers, there are
advantages to classifying each rule in a given rule-based system
application. We first identify simple programming guidelines for
each rule class, ensuring that each rule in a class has some similarity
in appearance, interface, use and style, to help in its comprehension.
and Classes of Rules
|What are the different styles of
the interface for calling a rule?
relational, functional, input-only.
|What are the control structures
used in the rule body?
recursive (pure, backtracking, accumulator-based),
|Is the rule purely declarative or
does it use any non-logical features?
declarative, non-deterministic, meta-logical,
higher-order, extra-logical, extended
|Where does the rule fit in the call
graph of the rule-base?
top, intermediate, bottom, fact
|What is the function (task) performed
by the rule?
condition, search, traversal, generator,
random generator, decision, classification,
transformation, filter, map, action, query,
|What concept in the application
domain does the rule represent?
related to concepts in the application
|Table 1. Criteria for classification of rules
and the associated rule-classes.