Introduction
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 [1]. 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.[1] There is no simple explanation for this
nor is there a simple solution to the problem of rule-based system
quality [2]. 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 rule’s
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.
|
Criteria
|
Explanation
and Classes of Rules
|
|
Interface
|
What are the different styles of
the interface for calling a rule?
relational, functional, input-only. |
|
Control
|
What are the control structures
used in the rule body?
recursive (pure, backtracking, accumulator-based),
imperative |
|
Logical
|
Is the rule purely declarative or
does it use any non-logical features?
declarative, non-deterministic, meta-logical,
higher-order, extra-logical, extended
logical, DCG. |
|
Structural
|
Where does the rule fit in the call
graph of the rule-base?
top, intermediate, bottom, fact |
|
Functional
|
What is the function (task) performed
by the rule?
condition, search, traversal, generator,
random generator, decision, classification,
transformation, filter, map, action, query,
computational. |
|
Application-specific
|
What concept in the application
domain does the rule represent?
related to concepts in the application
domain. |
| Table 1. Criteria for classification of rules
and the associated rule-classes. |
|
