RULE VALIDATION
IN
OBJECTORIENTED KNOWLEDGE BASES
By
PING WU
A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY
UNIVERSITY OF FLORIDA
1993
ACKNOWLEDGMENTS
I wish to acknowledge several professors who have helped me during the devel
opment of this dissertation. First, I would like to express my deepest appreciation
to my major advisor Dr. Stanley Y. W. Su who presented me with the challenging
research topic and provided me with his continuous encouragement, guidance, and
support through the course of this research work. I am grateful to Dr. Nabil Kamel
who helped me get this research started by defining some fundamental concepts. I
am indebted to Dr. Sharma Chakravarthy who taught me deductive databases and
gave me constant technical assistance. Thanks are also due to Dr. Herman Lam and
Dr. John Staudhammer for their enthusiastic participation in my supervisory com
mittee and their careful review of my dissertation. The discussions with Dr. Louiqa
Raschid from the University of Maryland and her suggestions on my research are
very helpful and are greatly appreciated.
My special gratitude goes to Fernando R. D. Remedios, a master's student, for
his tremendous efforts in implementing the two versions of the system. I also thank
our secretary Sharon Grant for her efficient and constant help.
My great appreciation goes to my fellow Ph.D. candidates: SueyChyun Fang,
YawHuei Chen, and HsinHsing Chen; we formed an "underground" academic group,
and each member was committed to taking turns in presenting a seminar once a week
on the most current and advanced research topics. This practice has prepared us
much better for our future careers.
Finally, and most importantly, I would like to thank my parents and my wife's
parents for their encouragement and financial support. Also, my sincere thanks go
to my wife Peggy Siu and my daughter Amy for their understanding, patience, and
endurance during the period of my Ph.D. study.
This research is supported by an NSF grant #CCR9200756.
TABLE OF CONTENTS
ACKNOWLEDGEMENTS ..............................
ABSTRACT .. .. . .. .. .. .... ..... .. . .. .. ... .. ...
CHAPTERS
1 INTRODUCTION ...............................
2 SURVEY OF RELATED WORKS ...........
2.1 Knowledge Representation ............
2.2 Validation of RuleBased Expert Systems .....
2.2.1 Overview ..................
2.2.2 Verification and Validation Tools ....
3 A PATTERNBASED OBJECT CALCULUS .....
page
ii
vi
3.1 Introduction .. ... .. ...... ... .. ... .. 
3.2 Alternative Views of a Database: ObjectOriented vs. Relational .
3.3 Object Calculus ...........................
3.3.1 The Basic Features of the Object Calculus . . . . . .
3.3.2 Grammar ....................... ....
3.3.3 Object Variables .................. .... ...
3.3.4 Wff Involving Association Patterns . . . . . . . .
3.3.5 Expressions .. ................ . .
3.4 Using Object Calculus to Express Queries . . . . . . . .
3.5 Using Object Calculus to Express Semantic Constraints . . . .
3.5.1 Constraints on Attribute Values . . . . . . . . .
3.5.2 Constraints on Association Patterns . . . . . . . .
3.6 Sum m ary .. ... .... ..... ... .. . .. .
4 RULE VALIDATION ......................... . .
4.1 Introduction . . . ... . .. . . . . . . .. .
4.2 Background of Resolution Principle and Rule Validation . . . .
4.2.1 Rule Base and Its Inconsistency . . . . . . . . .
4.2.2 Resolution Principle ......................
. . . . i9
. . . . 11
. . . . 11
. . . . 12
. . . . 16
4.2.3 Alternative Approaches to Rule Validation . . . . . .
4.3 Rule Validation Technique . . . . . . . . . . . .
4.4 Comparison of the Different Resolution Methods . . . . . .
5 RULE REFINEMENT . . . . . . . . . . . . . .
Introduction . . . . . . . . . . .
Rule Base Redundancy . . . . . . . .
Redundancy Detection and Removal Procedure and
Circular Rules Detection . . . . . . . .
Discussions on NonHorn Clauses . . . . .
Its Completeness
6 SYSTEM IMPLEMENTATION AND PERFORMANCE EVALUATION 87
6.1 Introduction ... ............... ............. 87
6.2 Overall System Description ....................... 87
6.3 Techniques for Improving System Efficiency ............ 90
6.3.1 The Unified Framework . . . . . . . . . ... 91
6.3.2 The Reversed Subsumption Deletion Strategy . . . ... 92
6.4 System Performance Evaluation ...... . . . . . . 98
7 CONCLUSION AND FUTURE RESEARCH . . . . . . . . 110
REFERENCES ..................................... 114
BIOGRAPHICAL SKETCH .............................. 120
Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy
RULE VALIDATION
IN
OBJECTORIENTED KNOWLEDGE BASES
By
Ping Wu
August 1993
Chairman: Dr. Stanley Y. W. Su
Cochairman: Dr. Nabil N. Kamel
Major Department: Electrical Engineering
A knowledgebased system, such as an expert system or a deductive database
system, is a deduction system which consists of a finite body of knowledge and an
inference engine. Such system has the capabilities of storing and processing data and
knowledge rules, and performing logical deductions. In realworld applications, a
knowledge base can contain a large number of rules which pose problems in terms of
their consistency and efficiency. Thus, some automatic knowledge base validation and
refinement procedures are necessary for building a reliable and efficient knowledge
based system. This research aims to develop methodologies, theories, and techniques
for validating and refining a knowledge base.
We first propose to use the objectoriented approach to represent knowledge. An
object calculus, a formalism based on firstorder logic, has been developed for the
knowledge representation and for providing a theoretical foundation for the rule val
idation research. Then, we develop a unified framework for rule validation (i.e., the
vi
detection of inconsistencies) and rule refinement (i.e., the improvement of efficiency).
This framework utilizes theories and techniques introduced in mathematical logic and
mechanical theorem proving. In particular, we formally define the concept of rule
base inconsistency and show its relationship with the concept of unsatisfiability in
formal logic. We also define the completeness of a rule validation algorithm and show
that our rule validation method is complete in the sense that it can not only identify
all the input facts causing the system to deduce contradictions but also determine the
specific subset of rules involved in the deductions of the contradictions. In addition,
we formally define rule base redundancies in general. The rule refinement procedure
can detect redundancies and circular chains in a rule base. Its completeness is defined
and proved in this work. Finally, we implement (in Prolog) a rule validation and re
finement system to verify the theories and to evaluate the techniques. For achieving
better system efficiency, we use two techniques in the implementation: the unified
framework for both rule validation and rule refinement, and the reversed subsump
tion deletion strategy. The performance evaluation shows that combining these two
techniques can significantly improve the system performance.
Key Words: knowledgebased systems, logical deduction, objectoriented approach,
resolution principle and theorem proving, rule refinement, rule validation.
CHAPTER 1
INTRODUCTION
A knowledgebased system is a deduction system which consists of a finite body of
knowledge (the knowledge base) and an inference engine. A knowledge base consists of
a set of facts and/or rules. Each element in the set (i.e., a fact or a rule) is a statement.
An inference engine is the mechanism which implements a finite set of mappings,
called rules of inference; each rule of inference maps one or more valid statements
into a valid statement. A set of inference rules in a knowledgebased system can be
regarded as a metainterpreter which manipulates statements (information) in the
knowledge base. A knowledgebased system can accept some input facts and, based
on these facts together with other facts and rules stored in the knowledge base, infer
new facts which are not explicitly stored in the knowledge base. This behavior of a
knowledgebased system is called derivation. In other words, new information can
be derived by a knowledgebased system. This abstract model of a knowledgebased
system is illustrated in Figure 1.1.
Based on this abstract knowledgebased system model, we can examine the fun
damental components of a database management system (DBMS), an expert system,
and a deductive database system, and gain a better understanding of the relationships
between these systems and the socalled knowledgebased system. In a DBMS, the
knowledge base consists of only facts, and there is no inference engine; one essential
data manipulation operation is the retrieval operation which maps a set of facts to
a subset of the facts according to the data constraints specified in a query. Since all
Knowledgebased System
Knowledge Base
input facts facs Inference output facts
rulesEngine (derived information)
Figure 1.1. The abstract model of a knowledge base system.
the facts are (assumed) valid, a subset of the facts is, of course, also valid. In an ex
pert system, the knowledge base consists of facts and rules, and the inference engine
implements one inference rulemodus ponens; usually the system does not support
data retrieval functions. In a deductive database system, the knowledge base consists
of facts, also called extensional database (EDB) and rules, also called intensional
database (IDB) and the inference engine implements two inference rulesmodus
ponens and generalization. In addition, an IDB is further divided into integrity con
straints and user constraints, and the knowledge base is also called logic programs
[Gran92]. A deductive database system only gives deductive answers based on the
facts initially stored in the knowledge base whereas an expert system gives deductive
answers based on some input facts.
In recent years, there has been a considerable amount of research on knowledge
based systems having both database functionalities and deduction capabilities [Mink88].
Two general approaches have been taken to achieve the integration of database
functionalities and deduction capabilities: expert systems approach and deductive
databases approach. In the first approach, starting from its deduction capability,
an expert system can be extended to incorporate and manage a large amount of
data, thus becoming a fullfledged knowledgebased system. In the second approach,
starting from its database storage and management capability, a database system
can be extended by adding rules for logical deduction leading to the socalled De
ductive Database Systems [Gall84, Gran92]. Knowledge is commonly represented as
rules in expert systems and as logic programs in deductive database systems. Since
the common ground for the knowledge representation of both expert systems and
deductive database systems is a firstorder language, knowledge can be expressed by
a set of rules, without further distinguishing rules from logic programs. In both ex
pert systems and deductive databases, a common assumption is that the knowledge
defined by the user is consistent; i.e., no contradictory facts can be inferred from the
knowledge base.
We use some examples to illustrate the problem of inconsistency in rules as well
as constraints. The following set of rules is consistent:
r1: All the PhD students of the Database Center at UF have worked on
OSAM* model.
r2: Whoever has worked on OSAM* works on databases.
r3: P.W. is a PhD student of the Database Center at UF.
r4: P.W. works on VLSI design.
Since P.W. may well be working on both database systems and VLSI design, the
above set of rules does not lead to a contradiction. On the contrary, the set of rules
shown below is not consistent.
rs: All the PhD Students of the Database Center at UF have worked on
OSAM* model.
r6: Whoever has worked on OSAM* works ONLY on databases.
r7: P.W. is a PhD student of the Database Center at UF.
rs: P.W. works ONLY on VLSI design.
This is because the system is able to deduce the contradictory facts that P.W. works
only on database systems and P.W. works only on VLSI design.
Integrity constraints in a deductive database system [Gran92] can be in conflict
as well. For example, the following two rules, r9 and rio, are integrity constraints.
r9: If a faculty member is not advising any student, then he must teach at
least one course.
rio: A department chairman does not have to advise any student nor teach
any course.
According to the second integrity constraint r10, a department chairman who neither
advises a student nor teaches a course is a valid database status. However, given the
fact that a department chairman is a faculty member, based on the first integrity
constraint rg, he must teach at least one course if he is not advising any student. In
this case, the department chairman violates the first integrity constraint.
The inconsistency problem of a knowledge base exists not only in the conventional
knowledgebased systems (i.e., expert systems and deductive database systems) but
also in objectoriented (00) knowledgebased systems. Our research on rule valida
tion is mainly motivated by the existence of potential conflicts in an 00 knowledge
base. Objectoriented databases and knowledgebased systems have become popu
lar research topics recently [Bane87, Hull87, Lam89, Su89a, Chak89, Shyy91]. The
primary advantage of the 00 approach is that, unlike the conventional DBMS (e.g.,
relational DBMS), it allows the user to model an application using a rich set of struc
tural properties (e.g., the semantic constructs of generalization, aggregation and other
association types), behavioral properties (i.e., the operations (or methods) defined for
each object class), and, in some 00 systems, userdefined semantic constraints. These
properties and constraints provide the expressiveness needed for modeling data used
in advanced applications, such as CAD/CAM, office automation, and multimedia
databases. A database or knowledge base defined in terms of these three types of
semantic abstractions may have semantic conflicts. For example, userdefined con
straints may conflict with the semantics represented by the structural constructs used
and they may also conflict with the semantics embedded in the program code of the
methods. In order to detect and correct the inconsistencies, it is necessary to repre
sent these three types of semantic properties in a uniform way using, for example, a
knowledge rule specification language. The structural properties and constraints of a
database can be explicitly defined by rules which govern the operations of a DBMS
or KBMS. Some semantics (certainly not all) which are buried in the program code
of methods can also be explicitly and declaratively defined by rules. Thus, the val
idation of an objectoriented knowledge base can be done by processing the set of
rules that captures the semantics of an 00 database or knowledge base.
In our research, we address the problem of rule validation: i.e., detecting incon
sistencies of a rule base. Informally, a rule base is inconsistent if a contradiction
can be deduced from the rule base, with or without some input facts. The goal of
our rule validation is to answer the following three questions concerning a rule base:
(1) Is the rule base inconsistent? (2) If the rule base is inconsistent, then what are
the rules which cause the inconsistencies? (3) If the rule base is inconsistent, under
what conditions (i.e., what input facts) will the rule base deduce contradictory facts?
Most "rule verification and validation tools" in expert systems rely on running test
cases to test the reliability of a system in a limited way. The proposed rule validation
procedure can provide more useful information concerning a knowledge base. More
specifically, by answering the first question, it can assure the knowledge base designer
whether the knowledgebased system has been designed "correctly," i.e., determining
the system's reliability. It gives the users of a knowledgebased system confidence in
the system. The answer to the second question can help the knowledgebased sys
tem designer find the potential "bugs" in a system that was not designed correctly.
Finally and most importantly, the answer to the third question can give the system
designer the complete information concerning what input facts can cause the system
to deduce contradictory facts. This can eliminate the uncertainty associated with the
testing of a knowledgebased system in the conventional system design practice which
is based on a limited number of test cases constructed by experts. The information
provided by the rule validation procedure can basically identify all the test cases (i.e.,
the input facts) which can cause the system to infer contradictions. Additionally, the
system designer can further determine whether the identified input facts can possi
bly exist in a specific application environment and decide whether it is necessary to
revise the set of rules. If some input facts (or test cases) which can cause a system
to infer contradictory facts do not exist in a realworld application, then it may not
be necessary to revise the rules and the system can still be considered "consistent"
from the user's point of view.
In addition to the inconsistency problem, we also address the inefficiency problem
with respect to a knowledge base and we call the process rule refinement. The
efficiency of a knowledgebased system may be affected by redundancies of rules and
circular chains of rules in the knowledge base. Informally, a rule base is redundant
if the removal of a rule and/or a part of a rule from the rule base will not change
its deductive behavior. Redundancies in rules may cause the system to perform
unnecessary deductions. In other words, the same results can be deduced in a shorter
time if the redundancies were removed. A circular chain of rules can cause the system
to get into an infinite deduction loop. These problems call for techniques and tools
for detecting rule redundancies and circular chains.
In any knowledgebased system, knowledge representation is an immediate issue
that needs to be considered. There have been several schemes proposed for repre
senting knowledge, such as semantic network [Wood75], frame [Wino75], production
rules [Davi77], and logicbased method [Moor85]. Most implemented expert systems
use rules (i.e., logicbased method) as the knowledge representation because it is
simple and close to human perception [Tami89]. It has been shown that object
oriented paradigm can be utilized for modeling knowledge base system applications
[Lam89, Su89a, Chak89, Shyy91]. We propose to use the objectoriented approach
to model knowledge bases. This approach requires a formal knowledge representa
tion scheme which can capture the semantics of the modeling constructs as well as
system and userdefined constraints and represent them in terms of rules. Also, such
a rule representation formalism is necessary to provide our rule validation research
with a sound theoretical foundation. For this purpose, we have developed an object
calculusa logicbased formalismfor describing and interpreting the essential se
mantics in the 00 paradigm. This object calculus is also used to precisely interpret
the semantics of all rules used in the knowledge base.
This research proceeds as follows: First, we develop a knowledge rule specification
language for defining the various types of semantic properties of an 00 knowledge
base. Second, we formally define the problem of inconsistency of a knowledge base
and relate it to the concept of unsatisfiability in formal logic so that we can make
use of the solid theoretical foundation established in logic for rule validation. In the
same manner, we formally define the inefficiency problem of a knowledge base. Third,
we develop a rule validation technique and a rule refinement technique for detecting
inconsistencies and for removing inefficiencies of a knowledge base, respectively. Last,
we implement a rule validation and rule refinement system to verify the theories and
to evaluate the techniques.
Knowledge validation (or rule validation) has not received much attention in
the fields of knowledge representation, knowledge acquisition, and expert systems
[Hopp90]. Not much research work has been done with respect to the rule validation
problem as defined above. In Chapter 2, we survey some of the related works done
in knowledge representation and in expert systems validation. Chapter 3 describes
our knowledge representation schemea patternbased object calculus. Chapter 4
and Chapter 5 describe a unified frameworkbased on mathematical logic and me
chanical theorem provingfor both rule validation and rule refinement. In these two
chapters, both the theories and the techniques for rule validation and rule refine
ment are presented, respectively. The system implementation and its performance
evaluation are discussed in Chapter 6. Finally, some concluding remarks and future
research are given in Chapter 7.
CHAPTER 2
SURVEY OF RELATED WORKS
There have been some research works done in expert systems with respect to
system verification, validation, testing and evaluation. As in any knowledgebased
system design, the immediate issue for an expert system design is to decide an ap
propriate knowledge representation scheme. In this chapter, we shall first survey
the existing works on knowledge representation in the field of artificial intelligence.
Another very important issue for a knowledgebased system design is to test the re
liability or correctness for the designed system. We thus also survey some related
works on expert systems validation. Some commonly used and somehow ambiguous
terms related to validation in the literature are also discussed here.
2.1 Knowledge Representation
Knowledge representation has been regarded as the most central problem in artifi
cial intelligence (AI). Every system intended for any kind of intelligent activity has to
deal with knowledge. It was not until the late 1960's and early 1970's that knowledge
representation was seen as a separate area of study in its own right [Way91]. Since
then, many representation schemes have been proposed including logic, semantic net
works, frames and scripts, and conceptual dependency [McCa69, Mins81, Scha72].
There has been much philosophical debate on "what form knowledge should be
represented in." The controversy is mainly over the division between what has been
called the scruffies and the neats [Way91]. Formal logic was considered a natural
candidate as a neat knowledge representation scheme. In AI, the predicate calculus
is a widely accepted formal system which has a solid theoretical foundation. Besides
having a precise syntax and semantics, predicate calculus also has a set of well
defined inference rules, which gives us proofs about the properties and power of the
system. For example, firstorder logic has been shown to be both sound and complete.
Another advantage of a predicate calculuslike knowledge scheme is that formal logic
is based on the logical structure of our language; it was developed as a calculus
for capturing intuitively valid patterns of reasoning. However, the role of logic in
knowledge representation has been debated in the field of AI.
As summarized in [Way91], the opponents of logiclike representation claim that
logic does not, in fact, capture human reasoning processes. The assumption that
a significant amount of thought is deductive is simply wrong. Furthermore, the
difficulties encountered in translating natural language to logic will impose severe
limitations on the power of knowledge representations. Some researchers, like Roger
Schank and Ed Feigenbaum, feel that intelligence is a mixture of so many ad hoc
approaches to so many diverse activities that there are no universal principles to
be found. Therefore, some scruffy approaches were proposed including semantic
hierarchies [Wood75], conceptual dependencies and frames [Wino75]. Of course, the
major criticisms of the scruffy approaches have been the lack of a solid semantics
for their representations. There has been a great deal of work done by logicians to
give an interpretation of these various schemes in terms of the firstorder predicate
calculus.
Despite the debate on the adequacy of logic for knowledge representation, we
believe that a formal representation of knowledge is essential for a system validation
which has to be based on a sound theoretical foundation. Predicate calculus, first
order logic in particular, is a formal system which has a precise syntax and semantics
for the representation. It can provide us with a solid theoretical foundation for
theorem proving. For this reason, we take the formal approach to use logicbased
formalism as our knowledge representation.
2.2 Validation of RuleBased Expert Systems
Rulebased expert systems define knowledge by a set of rules, often called the rule
base. Validating the set of rules is the major task of validating an expert system.
2.2.1 Overview
Expert system validation is a relatively new topic of research. Up to now, no
complete theory, algorithm, or list of the conditions have been developed that are
sufficient for demonstrating the validity of an expert system. Furthermore, there
is still some ambiguity regarding the ways that some terms related to validation
are defined in the literature, i.e., no standard notations and terminologies [Deut82].
For example, the exact difference between validation, verification, and testing is not
always clear. Actually, in the context of computer programs, validation is defined as
the process of proving that the system is sound and complete [Tami89]. A system is
sound if every statement derived by the system holds in its model. That is, given
an interpretation for the system, every statement derived by the system is true in
the interpretation. A system is complete if every statement that holds in the model
can be derived by the system. However, in many cases, it is not possible to prove
both soundness and completeness of such a formal system. This is known as the
"undecidable" problem stated as a theorem by G6del in 1931 [Gode65].
Validation of a rulebased expert system consists of, ideally, the logical proof that
the system is sound and complete. However, if the model is complicated, then it is
very difficult or even impossible to construct a sound and complete formal system. In
an expert system, the model is the expertise of human experts and, in most cases, is
complicated. Therefore, it is not feasible to guarantee its soundness and completeness.
For this reason, in the context of expert system validation, proving soundness and
completeness is not practical. Instead, expert system validation should be considered
as a process of testing, verifying, and restrictively demonstrating the soundness and
completeness of the system. This is referred to as practical validation; it coincides
with the definitions of validation given in the literature [O'Ke87]. The works surveyed
below are of this category.
2.2.2 Verification and Validation Tools
The terms verification, validation and testing are used differently in the literature
[Suwa82, Grag87, Stac87]. We first give definitions of these terms used in the field of
expert systems based on [Bahi91]. Verification means building the system right: i.e.,
ensuring that the system correctly implements the specifications. It determines the
conformance of the knowledge base to its design requirements and with the software
syntax from which it was built. Validation means building the right system: i.e., writ
ing specifications and checking performance to make sure that the system does what
it is supposed to do. It determines the correctness of an end product, conformance
of the output with the customer's established requirements, and completeness of the
system. Final testing or evaluation means running as many test cases as possible
and watching the inputoutput behavior of the system to determine if it performs
correctly.
Most existing "verification and validation" tools for expert systems are for the pur
pose of practical validation. They are usually debuggers as well as highlevel tools
designed to help knowledge engineers verify and validate a program. Some examples
are Teiresias [Davi82], EMYCIN [Mell80], ONCOCIN [Shor81], CHECK [Nguy85,
Nguy87b, Nguy87a], EVA [Stac87], and ESC [Grag87]. Teiresias and EMYCIN are
basically automatic knowledge acquisition tools and do only small amount of veri
fication and validation. Their main objective is to get the knowledge engineer out
of the loop and to allow the system to communicate directly with the expert. ON
COCIN, CHECK, EVA, and ESC are verification and validation tools. They are
supposed to help the knowledge engineer debug and check the syntax and semantics
of a knowledge base to ensure its correctness and completeness.
CHECKER [Suwa82] is a program that has been developed and tested within the
ONCOCIN system to ensure its consistency, effectiveness, and completeness. The
program examines a set of rules and partitions them into disjoint sets based on their
conclusions. It also makes a table of all possible combinations of attributes used in
the condition parts of rules and assumes a rule for each possible combination. The
system also checks for redundant rules, conflicting rules, and subsumed rules. The
conclusions and conditions of two rules are examined. If both rules succeed in the
same situations and have the same conclusions, they are considered to be redundant;
if they conclude different values for the same set of parameters, they are considered
to be in conflict. If two rules have the same conclusion, but one of them contains
extra condition clauses, then one rule subsumes the other. In their work, checking for
completeness is done by looking for missing rules, i.e., for each attribute combination,
there must be a rule whose conditions include the combination. In other words, in the
ONCOCIN system, the rule CHECKER assumes that there should be a rule for each
possible combination of values of attributes that appear in the condition; otherwise,
it is considered to be missing rules) and the expert system is incomplete. This
assumption, however, is not realistic because an arbitrary combination of attributes
as the rule premise may not make sense.
CHECK, which is based on CHECKER in ONCOCIN, is a program that verifies
the consistency and completeness of expert systems built with the Lockheed Expert
System Shell. Some of its "inconsistency" problems [Nguy87a] are defined as follows:
Conflicting Rules: Two rules are conflicting if they succeed in the same
situation but with conflicting conclusions (e.g., p(x)  q(x) and p(x) +
q(x)).
Subsumed Rules: One rule is subsumed by another if the two rules have
the same conclusions, but one contains additional constraints on the situ
ations in which it will succeed (e.g., p(x) A q(y) + r(z) and p(x)  r(z)).
Unnecessary IF conditions: Two rules contain unnecessary IF conditions
if the rules have the same conclusions, an IF condition in one rule is in
conflict with an IF condition in the other rule, and all other IF conditions
in these two rules are equivalent (e.g., p(x) A q(y) + r(z) and p(x) A
,q(y) + r(z)).
Besides checking for redundant and conflicting rules like in CHECKER, it also checks
for unreachable and missing clauses, and dead end rules. The system compares (1) the
conditions of different rules to check for conflicts, (2) the conclusions and conditions of
different rules to check for circular chain, and (3) the conclusions of different rules to
check for subsumed rules and unnecessary clauses. The system produces dependency
charts which show rule interactions. The dependency charts are helpful both during
the development process and later when knowledge engineers update a knowledge
base.
EVA is a metaknowledgebased system shell that provides verification and val
idation capabilities for knowledgebased systems in use at the Lockheed Artificial
Intelligence Center in Austin, Texas. It is written in QUANTAS PROLOG and cov
ers ART and LISP knowledgebased systems. ESC is a decisiontablebased processor
for checking the completeness and consistency of a rulebased expert system. Deci
sion tables are created based on similarities in logic between the rules. They are then
checked for ambiguities and redundancies between the rules and for the completeness
of the knowledge base. Their functionalities are basically similar to that of the two
systems mentioned above.
There are, however, some common shortcomings and unsolved problems with
these verification and validation tools. First, all these tools were built for their own
specific expert system shells; they detect the errors by dealing with their own specific
rule formats. The techniques cannot be easily generalized for validating knowledge
bases with different rule representation formats. Second, the concepts of conflict,
redundancy, and subsumption are not general and they are defined for very limited
and specific cases. For example, conflict is only defined for two rules having the same
condition but with contradictory conclusions. This is only a special case in which
two contradictory facts can be generated, and the definition does not cover other
cases. For instance, a contradiction can be generated by a conflict between one rule's
condition and another rule's conclusion (e.g., propositions A  B and B + A), or
by more than two rules collectively. Consequently, the rule inconsistency checking
is not complete. Third, for CHECKER and CHECK systems, the conflicting rules,
redundant rules, and subsumed rules are detected only in pairs. Many other possible
conflicts and redundancies among a set of rules can remain undetected. Thus, in this
sense, the detection is also not complete.
CHAPTER 3
A PATTERNBASED OBJECT CALCULUS
3.1 Introduction
Many objectoriented (00) database models [Bato85, Bane87, Fish87, Hull87,
Su89b] and 00 database management systems like Vbase [Onto88], Iris [Fish87],
GemStone [Maie86b], ORION [Bane87], 02 [Lecl88], and ObjectStore [Obje90] have
emerged recently for supporting advanced application areas such as CAD/CAM, office
automation, and multimedia databases. Unlike the relational approach to databases
which was based on a firm theoretical foundation, i.e., the mathematical notion of
relations and the accompanying relational algebra and relational calculus, object
oriented databases and objectoriented database management systems (DBMSs) are
primarily founded on ideas adopted from objectoriented programming languages.
Implementations of objectoriented DBMSs have been carried out without the ac
companying theoretical foundation. As a result, three major problems have surfaced
in 00 database applications.
First, there is no uniform formalism based on which query languages for existing
00 database systems were designed. Most of the existing 00 systems provide their
own query languages to manipulate the objects in the database [Zani83, Ship81,
Care88, Scha86, Fish87].
Second, most of the reported 00 data models do not provide formal constraint
languages for declaratively specifying various semantic constraints found in different
application domains. Like relational databases [Ullm82], objectoriented databases
need such languages to define security and integrity constraints so that an application
world can be modeled accurately. In most of the implemented 00 DBMSs, a rudi
mentary set of constraints is "hardcoded" to represent the semantics of a data model.
Constraints not captured by the data model have to be implemented as procedures in
application programs. Several researchers have introduced different constraint repre
sentations such as Horn logic clauses in [Urba89], constraint equations in [Morg84],
and rules based on an associative net in [Shep84]. However, no uniform constraint
representation is established for interrelating constraints captured by different data
models.
Third, the existing implementations of query processors and query optimizers are
not guided by a welldefined mathematical formalism. Efficiency in objectoriented
DBMS implementations is difficult to achieve without a solid theoretical foundation.
Several research efforts including that of our own have been undertaken to estab
lish a theoretical foundation for processing 00 databases. Two general approaches
have been taken: the algebraic approach and the logic approach. The first ap
proach defines the formal semantics of an 00 query model based on object algebras
[Mano86, Osbo88, Osbo89, Stra91, Shaw89, Guo91]. Among them, only the algebra
in [Stra91] has an accompanying calculus. The second approach uses logic to formally
specify the semantics of the 00 paradigm [Maie86a, Chen89, Kife89b, Kife89a]. The
most complete work of this approach is represented by Flogic [Kife89a]. Flogic is a
database logic formalism which provides a clean declaration for most of the "object
oriented" features such as object identity, complex objects, inheritance, methods,
etc. In Flogic, the database schema is incorporated as part of the language. Its
computation model is a resolutionbased proof procedure. Unlike the approach taken
in Flogic, our proposed formalism of 00 databases does not assume a specific data
model. That is, the database schema is not part of the language. Therefore, it allows
all the different 00 databases to be formulated in a very general manner.
In this chapter, we present a patternbased object calculus for formally describing
and manipulating objects and object association patterns in 00 databases. This
object calculus is based on firstorder logic. It is the accompanying formalism to
the association algebra reported in [Guo91, Su93]. Its main feature is the concise
yet semantically powerful expressions for specifying queries and constraints in terms
of patterns of object associations. It captures the semantics of "association" and
"nonassociation" relationships explicitly, i.e., to identify respectively the related and
unrelated objects among classes which are associated with one another in the in
tensional database. The semantics of nonassociation cannot be easily expressed in
other calculusbased languages. This calculus can also express set operations on both
homogeneous and heterogeneous object association patterns whereas set operations
expressible in the relational calculus can only be performed on unioncompatible (i.e.,
homogeneous) relations. A calculus expression specifies a subdatabase that satisfies
the expression and the calculus preserves the closure property, i.e, the output of an
expression are association patterns which can be operated on by another expression.
Because of its uniform object association pattern representation, the object calculus
can be used to express formally both search queries and semantic constraints. There
fore, unlike some implemented systems in which the query processing subsystem is
separated and different from the constraint enforcement subsystem, a DBMS can be
built to use the same semantic constructs expressed in the calculus for both query
and constraint processing. It is also shown later in the chapter that the calculus can
provide a formal basis for the design of highlevel 00 query and constraint languages.
The rest of the chapter is organized as follows. In Section 3.2, an 00 view of
databases based on objects, classes, and associations is first described and compared
with the relational view of databases. Section 3.3 presents the main features of
the object calculus including its syntax and formal semantics. The object calculus'
expressive power in formulating queries is presented in Section 3.4 by examples. Sec
tion 3.5 shows an application of the object calculus for defining semantic constraints.
Finally, some concluding remarks are given in Section 3.6.
3.2 Alternative Views of a Database: ObjectOriented vs. Relational
In this section, we shall point out the main differences between the relational
and objectoriented data modeling paradigms as a justification for introducing two
important semantic constructs: the association and the nonassociation operators, in
the object calculus.
In the relational model, relations are used to represent entities and associations
in the real world. An entity or association instance (or an object) is represented by a
tuple, and it is distinguished from others by its unique primary key value. The entity
integrity enforces that null values cannot be accepted as the primary key values. To
relate one instance of one relation to an instance in a second relation, an attribute,
called foreign key, is used in the second relation. Foreigntoprimarykey matching
is used in query processing to identify relationships between tuples. It is carried
out by the expensive (i.e., computationally costly) join operation between relations.
Referential integrity guarantees that there exists such a match between a foreign key
value and a primary key value. In a relational query, the matching of keys and
foreign keys must be explicitly specified when traversing a number of relations. We
shall call this type of query specification and processing as attributebased.
Unlike the relational view, our objectoriented view of a database is based on
the essential characteristics of the objectoriented paradigm. First, an object in the
database is the representation of a real world entity, such as a physical object, an
abstract thing, an event, a process, or whatever of interest in an application, and
each object is assigned a systemdefined unique object identifier (OID). The OID
allows an object to be distinguished from other objects. Second, objects having the
same structural and behavioral properties are grouped together to form an object
class. Third, a class can associate (interrelate) with other classes to represent the
relationships among the real world entities. As a result, objects in a class can associate
with objects in other classes. Different associationtypes between or among object
classes have been recognized in different 00 data models. Two of the most commonly
recognized association types are Aggregation and Generalization associations. The
aggregation association captures the semantics of "is part of," "is composed of,"
or "has properties of" relationship. It allows an object to be defined in terms of
other objects. For example, in Figure 3.1, a Section object can be associated with
(or semantically is composed of) a Teacher object, a (set of) Student objects) (the
cardinality mapping between Section and Student can be specified), and a Course
object. The generalization association captures the semantics of "is a" or "is a kind
of" relationship. Objects in the subclass inherit the structural and the behavioral
properties (operations and rules) from one or more superclasses. In our discussion, an
object is represented using its OID and it encapsulates all its structural and behavioral
properties, such as its inherited attributes, its associations with other objects, and
so on.
A: Aggregation
G: generalization
/0 section#
Section A room#
A 0 textBook
j J /A
0o ^ s
books degree specialty 0
name college
Figure 3.1. The university database schema.
An association between two objects is represented by bidirectionally linking these
two objects using OID references which can be easily mapped to some physical point
ers for locating these objects. For this reason, we can simply use the association
operator "*" to specify the existence of an association between two objects. For ex
ample, we use the expression obji obj2 to denote that an object which is bound to
the object variable obj1 is associated with another object which is bound to the ob
ject variable obj2. Similarly we can use the nonassociation operator "!" to explicitly
specify the absence of an association between two objects, e.g., obji!obj2. The notion
of nonassociation is not included explicitly in the existing relational languages. It
has to be expressed in a roundabout way by a number of other operators.
Different 00 data models may capture different association types such as aggre
gation, generalization, using, composition, etc. The semantics of these association
types in a database can be represented by a set of constraints which govern the pro
cessing of objects having the association types in an objectobjected DBMS. For this
reason, their semantics do not have to be restated in the expressions of the object cal
culus. The object calculus presented in this chapter is developed for expressing and
processing the common primitives found in most 00 models, i.e., objects, classes,
and association between objects and classes. The semantics of association types are
handled by the underlying DBMS.
To conclude our discussion on the 00 view of databases, we consider an exam
ple database in a university environment. Figure 3.1 is a schema for the university
database, which is modeled using the Objectoriented Semantic Association Model
(OSAM*) [Su89b]. The OSAM* data model provides five types of systemdefined
semantic associations, though only two types appear in the schema, namely, Ag
gregation (denoted by A) and Generalization (denoted by G). In the schema, class
Section has six attributes which are represented by "A" links to domain classes (sec
tion#, room#, and textbook) and entity classes (Teacher, Student, and Course).
That is, a Section object instance is composed of a section number, a room number,
a text book and references to objects of Teacher, Student and Course. Class Person is
defined as the superclass of Teacher and Student. An 00 view of a subdatabase con
sisting of Teacher, Section, and Course classes is shown in Figure 3.2. Figure 3.2(a)
is the intensional (i.e., schema) view of the subdatabase which shows the classes and
their interconnections. Figure 3.2(b) is the extensional (i.e., instance) view which
shows the objects (represented by OID's) in different classes and their associations
(represented by edges). Since the nonassociations among objects are the complement
of associations among the objects, they are not drawn explicitly in the figure. From
the extensional pattern we know that Teacher tl teaches Section sl, which is opened
for Course cl. We also know that Teacher ti does not teach Section s2.
Teacher  Section Course
(a) The intentional view of a subdatabase
Teacher Section Course
ti Sl ci
12 c2
s2
t3 0 0 c3
t4o Oc4
s4
(b) The extensional view of a subdatabase
Figure 3.2. The objectoriented view of a subdatabase.
3.3 Object Calculus
In this section, we shall first introduce the basic features of the object calculus
then describe its syntax and semantics in detail.
3.3.1 The Basic Features of the Object Calculus
The underlying philosophy of the object calculus is to provide a formalism for
describing and manipulating objects and object associations. Objects and object
associations are the basic constituent elements used to express the object associa
tion patterns which may have linear, tree, or general network structures. The object
calculus allows object association patterns to be specified by the user as search con
ditions which are to be matched against the extensional representation of an 00
database.
Database objects are referenced by object variables. An object variable is defined
for a class so that it can be bound to any object in the class. For example, if variable
sect is defined for class Section and we assume the extension of the database is as
shown in Figure 3.2(b), then sect can be bound to any one of the objects, si, s2, s3,
or s4, in class Section.
At the primitive level of 00 database representation, two objects can be either
associated or not associated with each other. Suppose variables tchr and sect are
defined for classes Teacher and Section, respectively. If a user is interested in those
teachers who teach some sections, i.e., the associations between the Teacher instances
and the Section instances, then he/she can use the expression tchr sect to represent
the intended semantics. Here, tchr sect is a predicate which is an expression that
returns "true" or "false." What the expression means is to: (1) bind the variables to
two objects in their respective classes, (2) return "true" if the bound objects satisfy
the relationship specified by the association operator in the predicate, (3) return
"false" if the bound objects do not satisfy the relationship as specified. Again, we
assume the database of Figure 3.2(b), object pairs (ti, si), (t2, S2), and (t3, 53) satisfy
the predicate since there are associations between the paired objects in the database,
and all other object pairs make the predicate evaluate to false. On the other hand,
predicate tchr!sect evaluates to true when the object bound to tchr is not associated
with the object bound to sect in the database. For example, the following pairs of
objects satisfy the above predicate: (t1, 2), (t, s3)), (ti1,4), (t2, sl), etc. Only three
pairs of objects make the predicate evaluate to false: (ti, sl), (t2, 2), and (t3, 33).
When bound to the same pair of objects, the predicates var1 var2 and varl!var2
are complements of each other. That is, if the first predicate is true, the second is
false; and vice versa. A userissued query is interpreted as a request to output those
database objects that satisfy the specified predicate. In the rest of this section, we
present the detailed syntax and semantics of the object calculus.
3.3.2 Grammar
We first introduce a concrete syntax for the object calculus. This syntax is similar
to the tupleoriented relational calculus with the exception of the introduction of
association pattern into the wff and the binding of variables to objects. The BNF of
the language is given in Figure 3.3
Several points about the BNF are noted below:
1. The categories "class," "variable," "attribute," and "assoname" are defined
to be identifiers (a terminal category with respect to this grammar). They
represent a class name, an object variable name, an attribute name, and an
association name, respectively.
rangedefinition
::= RANGE OF variable IS rangeitem
rangeitem
::= class I ( expression )
expression
::= targetitemcommalist [ WHERE wff ]
targetitemcommalist
::= targetitem I targetitem targetitemcommalist
targetitem
::= variable attribute I variable
wff
::= associationpattern
comparison
( wff )
NOT wff
wff AND wff
wff OR wff
EXISTS variable ( wff )
FORALL variable ( wff )
IF wff THEN wff
associationpattern
::= class
I class *[asso_name] associationpattern
I class ![asso_name] associationpattern
comparison
::= targetitem op targetitem
op
::=< I > I <= I >= 1 = I <>
Figure 3.3. A BNF grammar for the object calculus.
2. The category "comparison" represents either a simple scalar comparison oper
ation (=, <>, >=, etc.) between two scalar values or an object comparison
operation (=, <>) between two object variables. A scalar value, in turn, con
sists of either an attribute value represented by an attribute reference of the
form "variable.attribute" or a scalar literal.
3. The category "associationpattern" represents either an object of the form
"class" or an association pattern of the form class1 op class2 op... op class,,"
where "op" can be either "*[assoname]" or "![assoname]", and classic is an
object variable for the class. In general, we use the "assoname" to designate
a specific association between two classes when there are multiple associations
between the classes. To simplify the presentation, we shall assume that there is
only one association between two classes and omit the "assoname" in the rest
of this chapter. An expression of class, class2!class3 is the shorthand for the
expression class1 class2) AND (class2!class3).
4. The category wff represents a "wellformed formula." Wffs are discussed in
detail in the following subsections.
5. For simplicity of descriptions, the following abbreviations are usedNOT (1),
AND (A), OR (V), <> (#), EXISTS (3), NOT EXISTS (p ), and FORALL
(V). The logical implication operator IF f THEN g is represented by f  g.
3.3.3 Object Variables
An object variable is defined by means of a statement of the form
RANGE OF x IS X
where x is the name of an object variable which ranges over class X Hence, the object
variable x represents an object of class X in the database. When there is no explicit
range definition, the default is that if a class name is used as an object variable name,
then the object variable represents an object of the class. Multiple object variables
can be defined for a class as illustrated by the following example.
RANGE OF el IS Employee
RANGE OF e2 IS Employee
Each variable represents a separate scan of instances of Employee class.
3.3.4 Wff Involving Association Patterns
Based on the BNF grammar, a wff takes one of the following forms: a simple
comparison, an association pattern, logical operations (i.e., with NOT, AND, OR),
quantified expressions (i.e., with the existential quantifier EXISTS and the universal
quantifier FORALL), and the logical implication operation (i.e., IF f THEN g).
A wff is a predicate. As defined in the predicate calculus, a predicate is an
expression that returns a truth value (true or false). When a wif takes the basic form
of a simple comparison, its meaning is apparent. Now we discuss the semantics of a
wff when its basic form is the association pattern.
The meaning of a wff that takes the form of an association pattern is decided by
its domain and interpretation. The domain of an association pattern is the underlying
database, which includes the objects of different classes and the object associations.
The domain of an object variable defined for a class is all the object instances of the
class. An interpretation of a wff is the objects bound to the variable occurrences in
the wff and the associations among these objects. An object variable occurrence can
be bound to any object in its domain. In general, for a given wff, it may have many
different interpretations, thus, resulting in different truth values. A wff is said to be
valid if it yields the value true for every interpretation. Thus, a wff is nonvalid if and
only if there exists some interpretation for which the wff yields the value false. A wff
is said to be unsatisfiable if it yields the value false for every interpretation.
Assume that two classes classic and class1 have been defined in the database
schema and there exists an association between these two classes. Also assume
that object variable objvari and objvarj range over classic and class, respectively.
The basic association patterns for the two given classes are objvari objvarj and
objvar;!objvarj The notions "*" and "!" can be viewed as the two binary predicates,
Association(x, y) and Nonassociation(x, y) respectively, where x and y are object
variables. Therefore, we have the following equivalent expressions:
objvari objvarj Association(objvari, objvarj)
objvari objvarj Nonassociation(objvari, objvarj)
As an example, let us consider a simple database whose extensional view is shown
in Figure 3.4(a). The domains of objvarl and objvar2 are {s1,52} and {t1,t2}, re
spectively. The truth values of objvar, objvar2 and objvarl!objvar2 under different
interpretations are shown in the table in Figure 3.4(b).
A quantified wff is evaluated by applying the object variables in the wff to all the
objects in their domains. If the database objects satisfy the semantics of a quantified
wff, then this wff is evaluated to true, otherwise evaluated to false.
(a) The quantifier FORALL (universal quantifier) stands for the words "for all ... is
true." The value of Vobjvar(wf f(objvar)) is true if for all objects over objvar's
domain, the value of wff(objvar) (with the object bound to all occurrences
Class Class2
(a) A simple database for the basic association patterns.
(a) A simple database for the basic association patterns.
Value of the wff
interpretation objvarl objvar2 objvarl objvar2
(sl, ti) true false
(sl, t2) false true
(s2, ti) false true
(s2, t2) true false
(b) The values of the wffs under different interpretation.
Figure 3.4. The evaluation of wff expressions.
of objvar) is true; otherwise, the value of Vobjvar(wff(objvar)) is false. The
expression wff(objvar) means that the wff has free variable objvar.
(b) The quantifier EXISTS (existential quantifier) stands for the words "there exists
... such that ... is true." The value of 3objvar(wff(objvar)) is true if there
exists an object over objvar's domain, such that the value of wff(objvar) (with
the object bound to all occurrences of objvar) is true; otherwise, the value of
3objvar(wff(objvar)) is false.
We introduce an explicit syntactic form for the logical implication operator. If f
and g are wff's, then the logical implication expression "IF f THEN g" is also defined
to be a wff. As we will see later, this logical implication expression as a wff can be
widely used to express various kinds of constraint rules in knowledge bases.
3.3.5 Expressions
An object calculus expression has the following form:
targetlist [ WHERE f ]
A target list consists of a list of "target items" separated by commas, in which each
item is either a simple object variable name such as 0 or an attribute expression
of the form O.a. The value of the object calculus expression is defined to be all
sets of objects in the targetlist and the associations among these objects for which f
evaluates to true. In other words, an object calculus expression returns both database
objects and associations among them.
Objects returned by an object calculus expression may be different from the orig
inal objects in the database dependent on the form of the target item. When the
target item is in the form of an object variable name such as 0, then the qualifying
objects are returned as original database objects. When the target item is in the form
of an attribute expression such as O.a, then all attributes of the returned objects are
stripped from them except for the specified attribute. If more than one attribute is
specified with the same object variable in different target items, say O.a, O.b, then
all these specified attributes are retained for the returned objects. Since in our 00
view of databases, an object encapsulates its structural and behavioral properties,
the object's inherited attributes can also be specified in target items.
The value of an object calculus expression is viewed as a subdatabase constructed
from the original database according to the expression's semantics. Under this con
ception, the object calculus preserves the closure property of the 00 database. That
is, the result of an object calculus expression can be used as an input operand to
another expression.
It is necessary to emphasize that all object calculus expressions are safe [Ullm82];
i.e., each of them is meaningful under the domain of the 00 database. The safety
of expressions is guaranteed by the definition of the object calculus. In the object
calculus, each object variable ranges over a class and it represents only the objects
of that class in a given database. In addition, the domain of the object calculus is
an 00 database and the database always has finite number of objects. Therefore,
the object calculus as we have defined it will never allow us to define an expression
which yields an infinite result size.
3.4 Using Object Calculus to Express Queries
The objectoriented view of an application world can be represented in the form
of a network of classes and associations among these classes. Since an application
is modeled in such an objectoriented fashion, the information about the application
is therefore stored as objects and associations among objects in the database. Users
can query the database by specifying the desired object association patterns in their
queries.
The object calculus provides a formalism to formally express queries that are to
be processed against an objectoriented database. A query expression specified by a
predicate is interpreted as identifying those database objects that satisfy the specified
predicate. The subdatabase formed by the qualified database objects can be output
to a user or subject to other systemdefined or userdefined database operations as
desired.
In this section, we present several examples on the use of the object calculus in
formulating queries. The basic features of the object calculus are shown through these
examples. All example queries [Alas89] are issued against the university database
modeled in Figure 3.1. Unless specified otherwise, all object variables share the same
names as the class names on which they range.
Query 1. Display all persons' names.
Person.name
WHERE Person
This is a simple query. Since there is only one object variable Person in the WHERE
clause, all the objects of class Person are qualified for the query. The target list,
Person.name, specifies that only the names of the Person objects are output.
Query 2. Display the names of those teachers who teach some sections and the
section's for these sections.
Teacher.name, Section.section#
WHERE Teacher Section
In this query the association operator is used in the WHERE clause. The wff predi
cate Teacher Section evaluates to True for each pair of Teacher object and Section
object that are associated with each other. The calculus expression returns the names
of the qualified Teacher objects and the section# of the qualified Section objects.
Query 3. Display the department names for all departments that offer 6000 level
courses that have current offerings (sections). Also, display the titles of these courses
and the textbooks used in each section.
Department .name, Course.title, Section.textbook
WHERE Department Course Section
AND Course.course# >= 6000 AND Course.course# < 7000
In this calculus expression, the wff specifies those objects in classes Department,
Course, and Section that are associated with one another in the manner that a
Department object is associated with a Course object which is in turn associated
with a Section object; also, the Course objects' attribute values of course# must be
in the range between 6000 and 7000. The calculus expression returns the attribute
values of those database objects that satisfy the wff.
Query 4. Display the names of those graduate students who are TA's but not
RA's.
Grad.name
WHERE (Grad TA) AND (FORALL RA (Grad!RA))
This query shows the use of nonassociation between objects and the universal quan
tifier. The wff in the WHERE clause identifies those objects in the classes Grad, TA
and RA satisfying the condition that those Grad objects associated with TA objects
are not associated with any RA object.
Query 5. Display the ssn's of all graduate students (whether they have advisors
or not) and for those graduate students who have advisors, display their advisors'
names.
Grad.ssn, Faculty.name
WHERE Grad Advising Faculty OR Grad
This query illustrates the calculus' capability in specifying heterogeneous association
patterns in an expression. The wff in the WHERE clause specifies two different
association patterns: Grad Advising Faculty and Grad. These two association
patterns are connected by the logical OR operator to capture the semantics of the
outerjoin concept introduced in [Codd79] The calculus allows heterogeneous patterns
of object associations to be unioned to retain all Grad objects no matter whether
they are advised by faculty members or not. This is different from the relational set
operations which operate only on unioncompatible relations. The logical OR and
AND operators can operate on potentially very complex heterogeneous patterns.
Query 6. Find the faculty members) in the Electrical Engineering department
who advises all the EE department's graduate students.
RANGE OF Gradi IS
(Grad WHERE Grad Student Department AND Department.name = "EE")
Faculty WHERE FORALL Gradi (Faculty Advising Gradi)
This query first defines a variable that ranges over a set of graduate students whose
major department is the Electrical Engineering department. Then, it searches for the
faculty members) who advises all the graduate students in that set. To express the
semantics of this query in the calculus, object variable Gradl is ranged over the class
Grad to represent the subset of graduate students who are in the EE department. In
addition, the universal quantifier is applied to Gradl to represent the semantics of one
faculty member advising all the graduate students in Gradl. This example illustrates
the closure property of the object calculus in which Gradl identifies a subdatabase
which in turn becomes an operand of the expression in the second WHERE clause.
The object calculus can also be used to specify complex nonlinear association
patterns (i.e., tree or lattice structures) in a database by using the logical AND
and OR constructs. For example in Figure 3.5(a), a complex association pattern is
specified in the database schema level. In the figure, the logical AND branching from
class B specifies that any object in class B must associate with an object in class C
and with an object in class D as well. Likewise, the logical OR branching from class
C specifies that any object in class C must associate with either an object in class E
or an object in class F. Figure 3.5(b) further illustrates this association pattern with
instantiated objects in the database. For such a complex pattern, it can be expressed
E
A B
F
G
(b)
Figure 3.5. A complex association pattern in the database.
in the object calculus as
(A*B*C*EVA*B*C*F)A (A*B*D*G)
We should clarify one very important point. The primary purpose of the cal
culus is not merely for data retrieval, though the previous examples may suggest
so. The fundamental intent of the calculus is to allow the writing of expressions
which identify objects satisfying specified patterns of object associations and perform
systemdefined and/or userdefined database operations (e.g., DELETE, UPDATE,
ASSIGNPROJECT, etc.) on these objects. Therefore, the object calculus provides
a theoretical foundation for writing 00 query expressions. It can serve as a template
when we come to the issue of designing 00 query languages. To demonstrate this
point, we give the following example to show how an (pseudo) 00 query language
can be designed based on the object calculus.
In the (pseudo) query language, structurally, it has two parts: subdatabase def
inition part and operation part. In the subdatabase part, by using object calculus
expressions, we specify a subdatabase which satisfies the userdefined semantics. In
the operation part we can specify systemdefined or userdefined operations which
are performed on the specified subdatabase. Consider two examples which employ
respectively a systemdefined operation and a userdefined operation with respect to
the database schema of Figure 3.1.
Example 1. Delete those Faculty members who are not currently teaching any
section of a course.
DELETE
Faculty WHERE FORALL Section (Faculty Teacher Section)
In this query, the subdatabase is specified by the object calculus expression:
Faculty WHERE FORALL Section (Faculty Teacher Section)
and the systemdefined operation DELETE is performed on the Faculty objects
which constitute the subdatabase returned by the calculus expression.
Example 2. Assign projects to those students who are in EE department.
ASSIGN.PROJECT
Student WHERE (Student Department) AND (Department.name = "EE")
In this query, the object calculus expression:
Student WHERE (Student Department) AND (Department.name = "EE")
specifies the Student objects as the subdatabase, and the userdefined operation
ASSIGNPROJECT is performed on these objects in the subdatabase. Here, we
assume that the userdefined operation ASSIGNPROJECT is implemented as a
method of the class Student.
3.5 Using Object Calculus to Express Semantic Constraints
For a database to be an accurate model of an application world, semantic con
straints that identify the invalid or illegal states pertaining to the real world entities
and their relationships need to be captured in the database. Commonly, database
constraints are specified as integrity and security rules. The semantics of these rules
are enforced by the DBMS at all time. If any database object violates a rule, then
the database enters into an illegal state.
We can use object calculus wff's to represent rules. However, the semantics of a
wff used as a rule is somewhat different from that of a wff used as a search query. In
a query expression, a wff is used to identify those database objects which evaluate
the wff to true. In a rule expression, it is used to express a constraint such that all
database objects comply with the constraint. That is, all the concerned database
objects must satisfy the rule. We now give the formal definition. A rule is said to be
satisfied if and only if its object calculus wff expression is evaluated to true under all
interpretations in its database domain. A rule is said to be violated if and only if its
object calculus wff expression is evaluated to false under some interpretation in its
database domain.
A database needs to maintain not only the conventional integrity constraints
supported by existing commercial systems but also many other applicationoriented
constraints which can be represented in an objectoriented database by patterns of
object associations [Su91]. Certain association patterns among objects may need to
be maintained in a database all the time. In addition, the existence/nonexistence
of some association patterns may depend on the existence/nonexistence of other
association patterns. In the following subsections, we shall describe various types of
constraints that may exist in objectoriented databases and formally specify these
constraints by rules using object calculus expressions. The usage of object variables
is selfexplanatory in the following examples, thus the definitions of these variables
are omitted.
3.5.1 Constraints on Attribute Values
This type of constraints is like the ones in the relational model in that restrictions
are specified on the attribute values. They can be simply represented by firstorder
predicates of the object calculus.
Example 1 (unconditional constraint). Every employee's salary must be higher
than $25K.
Rule 1: Employee.salary > 25K
Note that this rule is expressed as a wff with a free object variable (i.e., Employee).
The number of interpretations for this wff is equal to the number of Employee object
instances in a given database. For this rule to be satisfied, the wff must be true in all
the interpretations. On the other hand, if the wff is false in any of its interpretations,
then the rule is violated. The semantics of this rule can also be expressed by the
following logically equivalent wff with a universal quantifier:
VEmployee(Employee.salary > 25K)
That is, given a database, these two rules have the same truth value. Their difference
is that the second expression does not have a free object variable. In the constraint
rules given below, we shall not use quantifiers if they are not necessary.
Example 2 (conditional constraint). Employees whose ages are over 45 must have
salaries higher than $35K.
Rule 2: IF Employee.age > 45 THEN Employee.salary > 35K
or equivalently
'(Employee.age > 45) V (Employee.salary > 35K)
3.5.2 Constraints on Association Patterns
Some constraints can be specified in terms of the object association patterns.
These constraints can be classified into two categories. The first category is con
straints that specify nonpermissible extensional patterns) of object associations.
That is, the constraints enforce the restrictions that certain association patterns
of objects in some specified classes are not allowed to exist in the database at any
point in time. The second category is constraints which specify that certain object
patterns must (or must not) exist if some other object patterns do (or do not) exist.
These two categories of constraints are illustrated by the following examples using
the university database schema in Figure 3.1.
Nonpermissible extensional patterns
This type of constraints states that, if a database operation results in the forma
tion of nonpermissible extensional pattern, then the stated constraint is violated.
Example 3. A faculty member must have a Ph.D. degree.
Rule 3: Faculty(Faculty.degree = "Ph.D.")
or equivalently
VFaculty(Faculty.degree = "Ph.D.")
If a Faculty instance in the database is updated and the attribute degree has a value
other than "Ph.D." or a new instance is created with that value, this rule is violated
and some action should be taken by the DBMS to correct the situation.
Example 4. An undergraduate student cannot register in a graduate course, i.e.,
the one with the course number greater than 5000.
Rule 4: '(Undergrad Section Course A Course.course# > 5000)
This rule prohibits the existence of the object association pattern specifying that an
Undergrad instance is associated with a Section instance and the Section instance is
associated with a Course instance whose course# is greater than 5000.
Conditional constraints
This type of constraints explicitly enforces the relationship between object associ
ation patterns. That is, the existence of one association pattern implies the existence
of another association pattern in the database. The implication construct in the
object calculus
IF wff THEN wff
represents precisely the semantics of this kind of constraints, where each wff specifies
an object association pattern. The following examples are constraints of this type.
Example 5. A graduate student who is an RA must have an advisor, i.e., if a
Grad instance is associated with an RA instance, it must also be associated with an
Advising instance.
Rule 5: IF Grad RA THEN 3Advising(Grad Advising)
or equivalently
'(Grad RA) V 3Advising(Grad Advising)
Example 6. TA's who are majoring in the department of Electrical Engineering
cannot teach courses that belong to other departments.
Rule 6:
RANGE OF Dept1 IS Department
RANGE OF Dept2 IS Department
IF TA Depti1 A Deptl.name = "EE"
THEN
'(TA Teacher Section Course Dept2 A Dept2.name # "EE")
In this example, we use the alias variables Dept1 and Dept2 for class Department
so that these two variables can both represent objects of the same class. We also
assume that the underlying data model captures the generalization or superclass
subclass semantics. Therefore, the TA instances inherit the properties (specifically,
the associations) of the Student instances. The expression, TA Dept1, is a short
hand for TA Grad Student Dept1.
Example 7. A faculty member who is not an advisor of any graduate student
must teach at least one section.
Rule 7: IF Advising(Faculty Advising) THEN 3Section(Faculty Section)
or equivalently
3Advising(Faculty Advising) V 3Section(Faculty Section)
This rule will be violated if there is a Faculty instance that is associated with neither
an Advising instance nor a Section instance. In other words, the pattern of an isolated
Faculty instance is not allowed to exist in the consistent database.
From the above examples, one can see that the object calculus can express many
types of constraints for 00 databases. It can serve as a theoretical basis for the design
of highlevel constraint languages in 00 databases with various syntactic sugar.
A constraint language defines a complete rule structure which usually includes
the trigger condition, constraint rule body, and/or corrective action [Date81, Ston87,
Su91]. The rule body is the most important part of a constraint language; it specifies
the constraint that the database must comply with. As shown in the above examples,
our object calculus can well be used to express the constraint rules in the rule body.
Since not all the systemdefined and userdefined operations will change a database
from a legal status to an illegal status, the constraint rules need not to be checked
and fired all the time. The trigger condition specifies when the rule should be checked
and enforced. In addition, some corrective actions can be specified in a rule to cause
actions to be taken if a constraint rule (i.e., the rule body) is violated. As a result, a
complete structure of a rule in a constraint language can have the following structure:
Trigger.condition ( pairs)
Rule.body (the object calculus wff)
Corrective_action (procedures/methods)
An example of a complete rule is given below:
Constraint Rule: After update Grad, TA, or RA, a graduate student cannot be both
a TA and an RA at the same time. If the rule is violated, print a message to warn
the user.
Triggercondition (After update(Grad), After update(TA), After update(RA))
(IF Grad TA THEN VRA(Grad! RA))A
(IF Grad RA THEN VTA(Grad! TA))
Correctiveaction (Message: ("A graduate student cannot be both a TA
and an RA"))
3.6 Summary
In this chapter, we have introduced a patternbased object calculus which incor
porates the concept of association pattern specification into the firstorder predicate
calculus. This incorporation allows complex patterns of object associations to be
specified in wff's, thus greatly increases the expressive power of the calculus. Specif
ically, the greater expressive power of the object calculus over that of the relational
calculus can be shown in three aspects. First, based on our 00 view of databases,
relationships between objects (or tuples, in the relational model) are expressed ex
plicitly in the database. It does not require the matching of keys and foreign keys
in calculus expressions and, thus simplifies the expressions for complex queries. Sec
ond, the "nonassociation" operator, whose semantics are not easily expressible in
relational calculus or other languages, is included explicitly in the object calculus.
Third, this calculus allows setoriented operations to be performed on both homoge
neous and heterogeneous object association patterns, whereas, set operations in the
relational model can only be performed on unioncompatible (i.e., homogeneous) re
lations. Furthermore, the object calculus can be used in a uniform fashion to express
search queries involving complex object association patterns, to express various kinds
of semantic constraints and deductive rules in 00 databases. Expressions of this ob
ject calculus are safe. The closure property is also preserved in the calculus. One of
the potential applications of the proposed formalism is that its precise interpretive
semantics can serve as the theoretical foundation for designing highlevel 00 query
languages and constraint languages. More importantly, this object calculus has also
laid a solid theoretical foundation for our research works on rule validation and rule
refinement discussed in the following chapters.
CHAPTER 4
RULE VALIDATION
4.1 Introduction
In this chapter, we address the problem of rule validation: i.e., detecting in
consistencies of a rule base. To the author's knowledge, no formal notion on the
inconsistency of a rule base has been defined and generally accepted by the knowl
edge base community. Most rule base inconsistencies were definedbased on rule
syntax, not semanticsto reflect a specific problem in an expert system's rule base
[Nguy87a, Gins88]. In our work, we shall formally define the concept of rule base
inconsistency which can be generally applied to a broad spectrum of knowledgebased
system applications. We shall also show its relationship with the concept of unsatis
fiability in formal logic.
Informally, a rule base is inconsistent if a contradiction can be deduced from
the rule base, with or without some input facts. The goal of our rule validation
is to answer the following three questions concerning a rule base: (1) Is the rule
base inconsistent? (2) If the rule base is inconsistent, then what are the rules which
cause the inconsistencies? (3) If the rule base is inconsistent, under what conditions
(i.e., what input facts) will the rule base deduce contradictory facts? The answers
to these three questions can (1) assure the knowledge base designer whether the
knowledge base system has been designed "correctly," (2) help the knowledge base
system designer to find the potential "bugs" when the system was not designed
correctly, and (3) give the system designer the complete information concerning what
input facts can potentially trigger the system to deduce contradictory facts. The
significance of the information provided by the rule validation procedure has been
stated in Chapter 1.
This chapter proceeds as follows. Since our approach to rule validation and rule
refinement is based on the resolution principle, which has been widely used in au
tomatic theorem proving but may not be so familiar to the database community,
some background information on the resolution principle as well as alternative rule
validation methods are presented in Section 4.2. Section 4.3 describes the details
of our rule validation technique. Finally in Section 4.4, we discuss how the use of
efficient resolution methods in an inconsistency detection procedure can affect the
completeness of the procedure.
4.2 Background of Resolution Principle and Rule Validation
We make use of the resolution principle in the field of mechanical theorem proving
for performing logical deductions in order to validate a rule base. In this section, we
first give the assumption about a rule base and define the inconsistency of a rule base.
Then we briefly describe some concepts related to the resolution principle. Finally,
we discuss several approaches to rule validation.
4.2.1 Rule Base and Its Inconsistency
A rule base (or knowledge base) consists of a set of rules. The general form of
rules that are used to represent facts and deductive laws is
P1A P2 A . A P  RI V R2 V .. .V Rm
It is equivalent to the clause
Pi V P2 V... V Pn V Ri V R2 V... V Rm
All the rules in the existing expert systems and deductive databases can be rep
resented as or transformed into this general form. The conjunction of the Pi's is
referred to as the lefthand side (LHS) of the clause and the disjunction of the Rj's
as the righthand side (RHS). The clauses that we consider are function free and
terms served as arguments of Pi and Rj are either constants or variables. The Pi and
Rj are all literals which can be either positive or negative. We discuss two types of
clauses depending on the respective values of n and m, as in [Gall84].
Type 1: n = 0 m = 1. Clauses have the form
 R(ti,...,tk)
a. If ti's are constants, then the clause represents an assertion or a fact in the
knowledge base.
b. When some, or all, of the ti's are variables, the clause corresponds to a general
statement in the knowledge base. The arrow preceding an assertion can be
omitted.
Type 2: n > 1, m = 1. Clauses have the form
P1 A P2 A ... A Pn + R1
The clause can be considered as either an integrity constraint or the def
inition of a deductive law. It can be read as: If Pi and P2 ... and P" are
true, then R1 is true.
While a knowledgebased system's inference model is intended to reflect the formal
logical inference, it is important to point out the difference between the notion of
consistency/inconsistency as employed in formal logic and that of the rulebased
paradigm. In formal logic, we say that a set of propositions S is consistent if there
is an interpretation of S which is a model for S. In other words, S is consistent
if and only if there is some way of interpreting the propositional symbols of S so
that no contradiction is entailed (i.e., under that interpretation, every formula in S
is satisfied). Thus, in formal logic, the set of propositions
rn1: P + Q
r12: P A R + Q
is consistent because if P is false, both propositions are true and no contradiction
exists. That is, {'p} is a model for the set of propositions.
A knowledge base containing the preceding propositions as rules is clearly unde
sirable since, if P and R were to be given as an input to a knowledgebased system,
the system would be ready to assert both Q and 'Q. A knowledge base should not
be considered consistent if from which a contradiction can be derived. Through this
example, we see that a set of rules consistent from a formal logic point of view may
not be consistent in the knowledge base paradigm. Thus, the consistency of a knowl
edge base is a more stringent requirement than the notion of consistency in formal
logic.
In the above example, we notice that the contradiction (i.e., Q and Q) will
not be inferred from the rule base unless some input facts (i.e., P and R) are given
to the knowledgebased system. Therefore, we need a different definition of consis
tency/inconsistency in the context of rule validation, which takes the input facts of
a knowledgebased system into consideration. We now define the inconsistency of a
rule base.
Definition 1. A rule base which consists of a set of rules (including facts) is said to
be inconsistent with respect to some input facts {a} if and only if, when given the
input facts {a}, a contradiction (i.e., a fact and its negation) can be derived from
the rule base.
A rule base is said to be consistent if and only if it is not inconsistent.
Based on the above definition, we say that the set of rules {rn, r12} in the previous
example is inconsistent with respect to the input facts {P, R}. It is necessary to
mention that the set {a} can be an empty set for some inconsistent set of rules. In
that case, a contradiction can be derived from the set of rules itself without any input
fact. We also need to point out that knowledge/rule bases under our consideration
are defined in firstorder logic, although the example we used is in propositional
logic. We shall see in the next section, after we introduce the resolution principle,
the relationship between the inconsistency of a rule base and the unsatisfiability in
formal logic.
4.2.2 Resolution Principle
The resolution principle [Robi65] is an inference rule which is suitable for machine
oriented deductions. We assume that the reader has basic understanding of automatic
theorem proving [Mann74, Chan73]. For the details about the resolution principle
and linear resolution (including input resolution and unit resolution), the reader is
referred to [Chan73], and for SLDresolution, the reader is referred to [Lloy87]. In
this section, we first briefly introduce the levelsaturation resolution method and
tautology and subsumption deletion strategy which are the basic concepts used in
the rule validation algorithm. Then, we show the relationship between the concept
of inconsistency of a rule base and that of unsatisfiability in formal logic.
Let us first review the resolution principle [Chan73]. The resolution principle for
the propositional logic is simple.
Definition 2 (Resolution Principle for Propositional Logic). For any two clauses C1
and C2, if there is a literal L1 in C1 that is complementary to a literal L2 in C2, then
delete L1 and L2 from C1 and C2, respectively, and construct the disjunction of the
remaining clauses. The constructed clause is a resolvent of C\ and C2.
The resolution principle for the first order logic is similar, but it requires substi
tution and unification for handling variables in clauses.
Definition 3 (Resolution Principle for First Order Logic). Let C1 and C2 be two clauses
(called parent clauses) with no variables in common. Let L1 and L2 be two literals
in C1 and C2, respectively. Let L1 and 'L2 have a most general unifier cr, then the
clause
(Cior Liu) U (C20 L20)
is called a binary resolvent of C1 and C2. The literals L1 and L2 are called the literals
resolvent upon.
Two important properties of the resolution principle are stated as the following
two theorems whose proofs can be found in the book by Chang and Lee [Chan73].
Theorem 1. Given two clauses C1 and C2 a resolvent C of C1 and C2 is a logical
consequence of C, and C2
Theorem 2 (Completeness of the Resolution Principle). A set of clauses S is unsat
isfiable if and only if there is a deduction of the empty clause 0 from S .
Theorem 1 states that a resolvent of two clauses is a deduction from the two
clauses. Theorem 2 indicates that a set S of clauses can be proved to be unsatisfiable
by resolution if it is indeed unsatisfiable.
As stated in [Chan73], a straightforward way of carrying out resolution on the set
S is to compute all resolvents of pairs of clauses in S, add these resolvents to the set
S, compute all further resolvents, and repeat the above process until an empty clause
(denoted as 0) is found. That is, we generate the sequence, So, S1, 52,..., where
SO =S,
S" = resolventss of C, and C211 E (S U ... U Sn1) and C2 E Sn1 },
n = 1, 2, 3,...
This procedure is called the levelsaturation (resolution) method. This method guar
antees that every pair of clauses in the current set Sn of clauses is used to compute
a resolvent. Therefore, all the possible intermediate deductions in each level (i.e.,
S, S1, S2,...) are completely generated before reaching the final level where a [ is
deduced. However, the drawback of this procedure is that repeated applications of
resolution may cause many irrelevant and redundant clauses to be generated. For
example, a tautology may be generated. Since a tautology is true in any interpreta
tion, if we delete a tautology from an unsatisfiable set of clauses, the remaining set
is still unsatisfiable. Therefore, a tautology is an irrelevant clause and should not be
generated. Furthermore, a repeated or redundant clause may also be generated. To
solve this redundancy problem, a deletion strategy is used. Before describing it, we
introduce the concept of subsumption.
Definition 4. A clause C subsumes a clause D if and only if there is a substitution oa
such that Cor C D; D is called a subsumed clause.
The tautology and subsumption deletion strategy is the deletion of any tautology
and any subsumed clause whenever possible. It has been shown that the deletion
strategy is complete if it is used with the levelsaturation method'; i.e., if a set of
clauses is unsatisfiable, an empty clause O will be generated by using this deletion
strategy.
We now discuss the relationship between the inconsistency of a rule base and the
unsatisfiability in formal logic. Based on the completeness theorem of the resolution
principle, we can easily prove the following theorem.
Theorem 3 (Inconsistency Theorem). A rule base which consists of a set of rules is
inconsistent with respect to some input facts {a} if and only if this set of rules
together with the input facts {a} comprise an unsatisfiable set of clauses.
Proof: (=:) Since a rule base which consists of a set of rules, say {ri}, is inconsis
tent with respect to some input facts {a}, there exists a deduction from {rj} U {a}
of some facts /3 and #/3. Based on the resolution principle, when facts /3 and '/3
are deduced/resolved, an empty clause l can be resolved. Therefore, according to
Theorem 2, {ri} U {a}, when represented as a set of clauses, is unsatisfiable.
(4=) If {r.} U {a} is unsatisfiable, according to theorem 2, an empty clause 0
must be resolved, say from clauses #/ and 0/3. That is, from the rule base {rj} and
'The completeness of the deletion strategy depends upon how tautologies and subsumed clauses
are deleted. (See [Kowa70] and [Chan73].)
the input facts {a} both 3 and /3 can be deduced. Therefore, the rule base {r } is
inconsistent with respect to the input facts {a}. U
With this theorem, we can see the relationship between the inconsistency of a
rule base and the unsatisfiability of formal logic with regard to the set of rules in
the rule base. Very often, in rulebased applications, even if a rule base {ri} is
inconsistent with respect to some input facts {a}, the rule base {r,} itself can be
satisfiable (consistent) from the formal logic point of view. Consider the example
rule base consisting of rules {rn, r12} in the previous section. This set of rules is
satisfiable from the formal logic point of view. But if the rule base {rj} is augmented
with the input facts {a} = {P, R}, the union {ri} U {a} becomes an unsatisfiable set
of clauses (rules) from the formal logic point of view. In other words, the rule base
{ri} is inconsistent with respect to the facts {P, R}. Generally, in formal logic, if two
sets of clausesfor example, one considered as the rule base and the other as the
fact baseare satisfiable separately, there is no guarantee that the union of the two
sets of clauses is satisfiable. Also, a rule base {ri} can be inconsistent with respect to
more than one set of facts, {al}, {02}, and so on. If the rule base is monotonic, the
potential number of sets of facts {ai} (i = 1, 2, ..., n) can be infinite, i.e., n + oo .
Based on the discussion above, we can see that the rule validation problem has
become a theorem proving problem. In other words, showing that a set of rules {ri} is
inconsistent with respect to some facts {a} is equivalent to proving the unsatisfiability
of {ri} U {a}.
4.2.3 Alternative Approaches to Rule Validation
With the above understanding of the relationship between the inconsistency of a
rule base and the unsatisfiability of formal logic, we are ready to tackle our rule vali
dation problem. Recalling the goal that we are trying to achieve in a rule validation,
as stated in the beginning of the chapter, we want to know (1) whether a rule base
{ri} is inconsistent with respect to some input facts {a}; (2) if it is inconsistent, what
is {a}; (3) if {ri} is inconsistent with respect to a given {a}, what is the smallest
subset of {rj} that is inconsistent with respect to {a}, i.e., what are the rules that
are involved in the deduction of the contradiction.
There are several alternative ways to answer all or some of these questions from
the viewpoint of mechanical theorem proving. First, for a knowledge base {ri},
we can construct a set of facts {a} and try to prove the unsatisfiability of the union
{rj}U{a}. The facts {a} that we are interested in are not arbitrary facts; they should
be related to the knowledge base {ri} and should not be facts that are derivable from
{rj}. Therefore, for example, we can construct a set of facts {a} by including all
the lefthand sides of the rules in {ri}, i.e., the facts that satisfy the conditions of
the rules. A requirement for constructing such set of facts {a} is that {a} must be
consistent; otherwise, we would have introduced an inconsistency (from {a}) into a
consistent knowledge base {rj} during the process of validating the knowledge base.
We can form a theory by combining such constructed consistent set of facts {a} with
the knowledge base {rj}. Using a mechanical theorem prover, if we can prove that
the theory is indeed a theorem, then we have answered the first question, i.e., the
knowledge base is inconsistent with respect to {a}. However, this approach cannot
answer the other two questions since we are not sure if {a} is the only set of facts
that will cause the knowledge base system to deduce contradictory facts and which
rules in {rj} are involved in the deduction of the contradictory facts.
Second, we can form many sets of input facts {ai}, {02}, ..., {an} from the LHS
of {rj} and try to prove the theories constructed from {rj} and one of {aj} (j = 1, 2,
..., n), respectively. However, this approach does not provide us a guideline on how
to form a specific {aj}. The other disadvantage for this approach is that we have to
run the theorem prover many times, one for each {aj}, j = 1, 2, ..., n. Also, it is
very difficult to identify the specific subset of rules in {ri} which contributes to the
deduction of the contradictory facts.
The above two approaches do not meet our objectives of rule base validation.
The essential problem with them is that we cannot predetermine exactly the input
facts {a} which can cause the knowledgebased system to deduce contradictions. In
other words, from the mechanical theorem proving point of view, we are unable to
know in advance how to construct a theory for a theorem prover. As a result, any
approach that tries to form a theory by constructing a set of input facts {a} and
combining them with the rule base before proving the theory is doomed to failure.
In the following section, we describe a rule validation procedure which can determine
exactly what input facts {a} can potentially cause a contradiction and which rules
in {ri} lead to the deduction of the contradictory facts.
4.3 Rule Validation Technique
The basic idea of the rule validation procedure is the following: (1) take a rule
base {ri} which needs to be validated as a theory, (2) try to prove the theory by
performing deductions based on the resolution principle until no new deduction can
be inferred, (3) construct a theorem using the deduced theory as the basis. During
the process of constructing the theorem, we can decide exactly what input facts {a}
can lead to a potential contradiction. Moreover, by tracing all the deductions, we can
determine which rules are involved in deducing the contradiction. If the rule base
{ri} itself (without input facts {a}) is inconsistent, this procedure will also report
this fact. In our procedure, we use the levelsaturation resolution method and the
deletion strategy to generate deductions. The deductions generated at any point are
called partial deductions.
We are in a position to describe our rule validation procedure. A partial deduction
set (PDS) is a set of clauses which are the deduced intermediate results, i.e., the
resolvents of other parent clauses. The rule validation algorithm for detecting the
inconsistency of a set of rules {ri} is as follows:
1. PDS = q.
2. Perform levelsaturation resolution to the set of rules {ri} using the tautology
and subsumption deletion strategy until no further resolvent can be generated;
at the same time, record the list of the parent clauses for each resolvent.
3. If an empty clause is generated, then {ri} is inconsistent by itself, stop; other
wise do the next step.
4. Put all the unit clauses whose literals appear in the LHS of some rules in {ri}
into the PDS.
5. Put every multiliteral clause that satisfies the following conditions into the
PDS as well:
a. all literals in the clause appear in the LHS of some rules in {ri},
b. the clause is not subsumed by any clause kept in the PDS.
6. For each clause in the PDS, construct a "resolution complement formula" which
is a formula in conjunctive form and can resolve to an empty clause with the
clause selected from the PDS. Put all the resolution complement formulas into
a set called "potentially contradictioncausing input set."
From this procedure, we can obtain a PDS and a potentially contradictioncausing
input set. If the latter is an empty set and no empty clause is generated, then the
rule base is consistent. Each clause in the PDS represents a potential contradiction
which can be deduced from the set of rules {ri}. The resolution complement formula
corresponding to a clause in the PDS represents the input fact combination that will
cause the contradiction. By looking into the list of parent clauses which derived
a clause in the PDS, we can determine which rules in the {r,} contribute to the
contradiction. Therefore, all the three questions with respect to rule validation can
be answered after this inconsistency detection procedure has been executed.
We now show a rule validation example of this procedure using a rule base which
consists of propositions.
Example: (1) A + B
(2) B C
(3) C B
1. PDS = 0
2. Perform levelsaturation resolution
(1)A V B
(2)BVC
(3)C V B So
(4)A V C (1)+(2)
(5)AV C (1)+(3)
(6)B (2)+(3) S1
(7)iA (1)+(6)
A V B (2)+(5), subsumed by (7)
A V B (3)+(4), subsumed by (7)
1A (4)+(5), subsumed by (7) S2
Terminated
Here, S' represents the ith level of the resolutions.
3. No empty clause is generated, so go to next step
4. PDS = {A,'B}
5. No multiliteral clause can be put into PDS; therefore, PDS = {A, B}
6. Potentially contradictioncausing input set = {A, B}
From the potentially contradictioncausing input set, we know that when the
input fact A or B is given, some contradiction will be deduced from the set of rules.
We can trace back to see which rules will be involved to deduce the contradiction.
The first clause in PDS is A, i.e., resolvent (7) in the partial deduction. Tracing
back the partial deduction, we know that
(7) < (1) + (6) + (1) + (2) + (3)
where "<" is read as "resolved from." Thus, we see that when the fact A is given, a
contradiction can be deduced using all the three rules in the rule base. Let us verify
this result: when the fact A is given, the following facts will be deduced.
given input fact
* B from (1)
+ C from (2)
* "B from (3)
Therefore, we have deduced the contradiction B and 'B.
The second clause in the PDS is 'B, i.e., resolvent (6) in the partial deduction.
Tracing back the partial deduction, we have
(6) * (2) + (3)
It shows that when the fact B is given, a contradiction can be deduced from only the
last two rules of the rule base. This result is verified as follows.
B given input fact
 C from (2)
SB from (3)
Therefore, the contradiction, B and 'B, has been deduced. In summary, we have
proved that the rule base {A + B, B + C, C 'B} is inconsistent with respect to
the fact A; moreover, its subset {B  C, C 'B} is inconsistent with respect to
the fact B.
Based on the established result of mechanical theorem proving, we know that, in
general, a theorem prover will not reach a successful termination if the given theory
is not a theorem, i.e., the given set of clauses is not unsatisfiable. For instance, the
theorem prover may loop forever not being able to reach an empty clause. However,
it can be guaranteed that our rule validation procedure will terminate. The proof is
given below:
Proof: Since the given set of rules is a finite set the number of all the literals
appearing in the rules is also finite. Suppose the total number of all the different
atoms in the set of rules is N, here both literals L and L together count as one atom
L. By using the tautology and subsumption deletion strategy, the number of atoms
in each resolvent will not exceed N. As the resolution proceeds, those literals that
are resolved upon are removed and the resolvent will have fewer and fewer number
of literals in it due also to the deletion strategy. Finally, either an empty clause is
resolved or no more resolvent which is not subsumed by previous resolvent can be
generated. Either case terminates the procedure. U
Because we use the levelsaturation resolution method in our procedure, the incon
sistencies of a rule base can be completely detected by the procedure. The resolution
method guarantees that every possible pair of clauses from the rule base and pre
viously derived resolvents is used to compute a new resolvent; consequently, all the
possible intermediate deductions are completely generated. As a result, the clauses
in the final PDS are the only clauses that can potentially resolve to empty clauses
with certain input facts.Of course, if the final PDS is empty, then the rule base is
consistent. Furthermore, because the procedure records all the parent clauses of a
resolvent, it can uniquely identify those rules in the rule base that are involved in the
deduction of a contradiction. Therefore, the procedure can detect all the inconsisten
cies of a rule base by identifying all the possible input facts and the corresponding
set of rules from which a contradiction can be derived; in the sense, it is complete.
We shall discuss the completeness of a rule validation algorithm in next section.
4.4 Comparison of the Different Resolution Methods
Our rule validation procedure is based on the levelsaturation resolution method.
We know that in mechanical theorem proving, there are more efficient resolution
methods than the levelsaturation resolution method, such as linear resolution, input
resolution, unit resolution, SLDresolution, and so on. However, the levelsaturation
resolution method has its advantage over the other resolution methods with respect
to the completeness of a rule validation algorithm. We introduce the concept of
completeness of a rule validation algorithm below:
Definition 5. A rule validation algorithm is complete if it can detect all different input
fact combinations and the corresponding set of rules from which contradictions can
be deduced.
According to this definition, if a set of rules is inconsistent with respect to input facts
{fa1}, {02}, ..., {an}, and a rule validation algorithm can identify only a subset of
the {ai}, then the algorithm is incomplete.
We show through examples that if a linear resolution (including input and unit
resolutions) or SLDresolution is used for the rule validation procedure, the algorithm
will not be complete. We will use as our rule base the same set of rules, S, used in
Section 4.3.
In Figure 4.1, each tree is one of the possible proof trees. In the trees, rules
are represented in the clausal form. The number in parentheses next to a clause
denotes a specific rule in the rule base. The dotted lines in each tree represent the
possible resolution which with some input fact, can resolve to an empty clause. The
final resolvent (i.e., the failure node) of a proof tree constitutes an element in our
final PDS. The clause which can resolve to an empty clause with the final resolvent
constitutes the potentially contradictioncausing input set. The major shortcomings
of the linearresolutionbased approach are that (1) it is difficult to determine how to
select parent clauses that eventually lead to a final resolvent whose literals all appear
in the LHS of some rules in the rule base; (2) it is necessary to generate different proof
Rule base S: (1) A > B, (2) B > C, (3) C > B
A, B (1) B, C (2) C, B (3) A, B (1) B, C (2) C, B (3)
A, C C, B (3) C, A B, C (2) B B
A, B A, B (1) A, B A, B (1)
A A A A
I " 
o U
(a) (b) (c)
Figure 4.1. Linear resolutions in the rule validation procedure.
trees in order to derive different final resolventssome of the proof trees may deduce
the same final resolvent as in the cases of (a) and (b) above; (3) it is impossible to
decide how many proof trees need to be generated in order to determine all possible
input fact combinations that can lead to contradictions. Due to the above limitations,
especially (3), in no way can we guarantee that the generated proof trees will contain
all the possible input facts which can cause a contradiction to be deduced. Thus,
we can conclude that a rule validation algorithm based on linear resolution is not
complete. Intuitively, this is because it cannot generate all intermediate deductions,
some of which may resolve to an empty clause with certain input facts.
A rule validation algorithm based on SLDresolution (which is commonly used
in Prolog language) has the same problems as the ones mentioned above because
SLDresolution is a special case of linear resolution. In addition, we cannot decide
which clause should be selected as the top clause of a proof tree, unlike a deductive
queryanswering system in which the query is always selected as the top clause.
64
In summary, the rule validation algorithm based on levelsaturation resolution is
complete, while the algorithm based on more efficient linear resolution or its spe
cial cases is not. In selecting a particular resolution method for a rule validation
algorithm, both the algorithm's efficiency and its completeness must be considered.
CHAPTER 5
RULE REFINEMENT
5.1 Introduction
Even if a knowledge base is consistent, it may still contain certain inefficiency
factors that will prolong the processing of an inference engine. Rule refinement is
the process of detecting and eliminating the inefficiency factors in a knowledge base.
Some of the inefficiency factors have been recognized in expert systems verification
[Nguy85, Nguy87b, Nguy87a], such as the problems of "unnecessary IF condition,"
"subsumed rules," and "circular rules." Two rules contain unnecessary IF conditions
[Nguy87a] if (1) the rules have the same conclusion, (2) an IF condition in one rule
is in conflict with an IF condition in another rule, and (3) all other IF conditions in
the two rules are equivalent. For example in the following two rules (where A, B,
and C are predicates):
r : AAB C
r2: AA B C
the conditions specified in B are unnecessary. These two rules can be reduced to a
single rule A  C. If two rules have the same consequent but one contains additional
constraints in situations in which the rule can succeed, then it is said that the rule
with more constraints is subsumed by the rule with less constraints. For example in
the following two rules:
r A : AAB C
r2: B C
rule ri is subsumed by rule r2. This is because, intuitively, if a more restrictive rule
succeeds, the less restrictive rule must also succeed, but not vice versa. The subsumed
rule is not necessary and is in a way redundant.
On the other hand, circular rules may also exist in a knowledge base. In that
case, cycles need to be detected and removed in order to avoid causing the system to
perform inferencing indefinitely. These problems call for techniques and tools which
can be used to analyze a knowledge base and provide its designers with some input
on the existence of inefficiency factors in a knowledge base.
Existing tools [Nguy85, Nguy87b, Nguy87a] which use the syntaxbased defini
tions of rules to detect a small amount of redundancies in a knowledge base is not
enough; a more general technique which uses semanticsbased definitions is necessary
in order to detect a variety of redundancies.
Knowledge base redundancies can be generally divided into two categories. The
first category of redundancies can be removed by reducing the number of rules in the
knowledge base without changing its deductive behavior. For example, in the case
of "subsumed rules," the removal of the subsumed rule will not alter the knowledge
base's deductive behavior. In the case of "unnecessary IF conditions," two rules (e.g.,
A A B  C and A A B + C) can be reduced to one rule (i.e., A C).
The second category of redundancies can be eliminated by removing part of a rule
in a knowledge base without changing its deductive behavior. This is illustrated by
the following rules:
r : AAB +C
r2 : ,B C
It can be easily proved that these two rules are logically equivalent to the following
two rules:
r': A C
r2: B C
That is, the knowledge base {ri, r2} is equivalent to the knowledge base {r', r2}.
We proceed our discussion on rule refinement as follows. First, in Section 5.2, we
introduce two propositions which identify separately two general categories of knowl
edge base redundancies. Second, in Section 5.3, we present a procedure for detecting
and removing the two categories of redundancies and further prove its completeness
in the sense that it can detect all redundancies. We then devote Section 5.4 to circu
lar rules detection. Finally, we discuss some results when the rule refinement theory
is applied to rules represented as nonHorn clauses.
5.2 Rule Base Redundancy
Before we give a formal definition of rule base redundancy, we first define the
deductive behavior of a rule base.
Definition 6 (Deductive Behavior). The deductive behavior of a set of consistent rules
is the relationship between the set of input facts given to the rules and the set of
output facts derived from the rules. Two sets of rules have the same deductive
behavior if, given the same set of input facts, they derive the same set of output
facts.
We now formally define rule base redundancy.
Definition 7. A set of rules which forms a rule base is redundant if the removal of a
rule and/or part of a rule from the set will not change its deductive behavior.
We are now in a position to prove two propositions on rule base redundancy.
These two propositions essentially identify two basic redundancies in a rule base. In
our proofs, we shall assume that rules can be represented as Hornclauses. In the
final section, we shall discuss how the developed theory can be applied to a set of
rules represented as nonHorn clauses.
Proposition 1. The deductive behavior of a set of rules will not change if a subsumed
rule is removed from the set. (That is, some redundancy exists in a set of rules when
a rule in the set is subsumed by another rule in the same set.)
Proof: Suppose S is a given set of rules and S' is the remaining set of rules
obtained by removing a subsumed rule from S. That is
S = {ri,r2,...,r, ...,r,,...,rn}
S' = {rl,r2,...,r.i,r+ ,.... ,rj,...,r,}
Here, we assume that rule ri is subsumed by another rule rj, i j. Let Fj be a set
of input facts and FTo be a set of output facts. If ro is derived by applying S on rI,
i.e.,
Fr U S Fo
then we want to show the following holds
r U 5', o Po
Since r, is subsumed by ri and both rules are Hornclauses, we can assume that they
have the following forms.
ri = P A P2 A ... A Pk Pm
r, = Pi A P2 A ... A Pi * Pm
where I < k, Pi's are predicates, and both rules have the same righthandside pred
icate.
Since S = S'U {ri}, the deductive behavior of S' and S will be the same if r, is not
involved in the deduction. What we need to show is that their deductive behaviors
will still be the same if ri is involved in the deduction.
First, consider the deductive behavior of S. Since r, = Pi A P2 A ... A Pk Pm,
the only output fact that can be deduced from r, is Pm when P1 A P2 A ... A Pk is
satisfied, i.e.,
{Pl,P2,...,Pk,ri} Pm
Now, consider the deductive behavior of S'. We know that rj = P1 A P2 A.. .A P
Pm and {Pi, P2,. ..,P} C {P1, P2,..., Pk}. When the conditions of r, are satisfied,
the conditions of rj must be satisfied also. Thus, Pm can be deduced from rj, i.e.,
{P, P2,... Pl, rj} Pm
Obviously, if given more input facts, Pm can still be deduced, i.e.,
{P1,P2,...,P,...,Pk,r} F Pm
In other words, based on the same set of input facts {PI, P2,..., Pk} (as given to S),
the same output fact Pm can be deduced from the set S' as well. Therefore, the two
sets of rules S and S' have the same deductive behavior. E
Before we prove the second proposition, we first introduce a lemma and its corol
lary.
Lemma 1. The deductive behavior of a set of rules S is the same as that of S U {r;},
where ri is a rule derivable from S.
Proof: This is obvious because the derived rule cannot produce new output facts
different from that of the original set of rules. U
If we continuously apply this lemma many times, we obtain the following corollary.
Corollary 1. The deductive behavior of a set of rules S is the same as that of S U S',
where S' is a set of rules derivable from S.
Proposition 2. The deductive behavior of a set of rules will not change if a rule in the
set is replaced by its subsuming rule which is derivable from the set of rules. (That
is, some redundancy exists in a set of rules if a rule in the set can be subsumed by a
derived rule.)
Proof: Suppose S is a given set of rules and S' is the resulting set of rules obtained
by replacing a rule in S with the rule's subsuming rule which is derived from S. That
IS,
S = {ri,r2,... ,ri_,r1,ri+1,...,rn}
S' = {r,r2,.. ,r,,rr ,rn}
Here, we assume that rule ri is subsumed by another rule r,, and S I r.
Now, we prove that S and S' have the same deductive behavior. Since S F {rj},
according to Lemma 1, SU {r} has the same deductive behavior as S. Thus, it yields
that
The deductive behavior of {rj, r2,..., ri1, ri, rzi+,, r* }
= The deductive behavior of {ri, r2,..., ri1, ri, ri+i,.. ., rn, r'}
= The deductive behavior of {ri, r2,..., i1 r, r, i+1,..., r.}
The last step is due to Proposition 1 as well as the fact that ri is subsumed by r'.
Therefore, the deductive behavior of S' is the same as that of S. 0
5.3 Redundancy Detection and Removal Procedure and Its Completeness
Proposition 1 deals with one kind of rule base redundancy that requires the re
moval of a rule from a set of rules; Proposition 2 deals with another kind of redun
dancy that requires the removal of part of a rule in a set of rules. A redundancy
detection and removal procedure needs to be able to identify and remove these two
basic types of redundancies.
The procedure for redundancy detection and removal is as follows:
1. Perform deductions based on the levelsaturation resolution on a given set of
rules S.
2. If a clause ri in S is subsumed by another clause r1 in S, delete the subsumed
clause ri.
3. If a clause ri in S is subsumed by a clause deduced from a subset S' of S, and
S' includes ri, then replace ri with the deduced clause. If a clause ri in S is
subsumed by a clause deduced from a subset S' of S, and S' does not include
ri, then delete ri (i.e., delete derivable clauses).
After applying this procedure to a given set of rules, some rules in the set will be
deleted or replaced by some other deduced rules. The resulting set of rules is the one
that contains no redundancies; therefore, it is the minimal set of rules among all the
sets of rules which have the same deductive behavior.
We need to show the correctness of the above procedure in terms of its sound
ness and completeness. Based on propositions 1 and 2, we know that the deductive
behavior of a set of rules will not change after its reduction by the above procedure.
In other words, this procedure is sound. We shall use some examples to show that
this procedure can be used to handle uniformly the problems of "subsumed rules"
and "unnecessary IF conditions" and to remove the redundancies from a given set of
rules.
Examples.
Case 1: Subsumed rules.
(1) A A B + C
(2) B + C
The clausal form is
(1) A VBVC C
(2) B V C
Because (2) subsumes (1), the subsumed rule (1) is deleted from the set. The result
is
(2) B V C
i.e. B  C
Case 2: Unnecessary IF conditions.
(1) AAB +C
(2) AA B + C
The clausal form is
(1) ,A V B V C
(2) ,AVBVC
The resolvent of (1) and (2) is
(3) ,A V C
Because (3) subsumes both (1) and (2) and it is deduced from (1) and (2), so (3)
replaces (1) and (2). Thus, the resulting set contains only (3), or
AC
Case 3: Unnecessary IF conditions. (To the author's knowledge, the following kind
of problem has not been recognized in the literature of expert systems verification.)
(1) AAB +C
(2) B+ C
The clausal form is
(1) A V,BVC
(2) B V C
The resolvent of (1) and (2) is (3)
(3) A V C
Because (3) subsumes (1) and it is deduced from (1) and (2), so (3) replaces (1). The
resulting set of rules is
(2) B V C
(3) A V C
That is, the given set of rules can be reduced to
(1') A C
(2) B > C
From these examples, we can see that this single procedure is able to identify
and delete many different kinds of redundancies from a rule base. In contrast, exist
ing works in expert systems verification treat these redundancy problems separately
based on the different syntactic properties of the rules in their rule languages and
use different procedures to detect these redundancies individually. Not all the redun
dancy problems are detected and resolved. In other words, the existing methods are
not "complete" in their redundancy detection and removal.
Another issue on the correctness of the redundancy detection and removal proce
dure is its completeness. While the soundness of the procedure ensures that it deletes
only the redundancies from a set of rules but nothing else, we are not sure at this
point that the procedure will delete all the redundancies existing in a set of rules. A
redundancy detection and removal procedure is complete if it can guarantee to detect
and remove all the redundancies from a set of rules. The following theorem shows
that the discussed redundancy detection and removal procedure is complete.
Theorem 4 (Completeness of the Procedure). A set of rules S is redundant if and
only if there is a clause in S which is subsumed either by another clause in S or by
a clause deduced from S.
Proof: (=.) We first prove that a set S of rules is redundant if there is a clause in
S which is subsumed either by another clause in S or by a clause deduced from S.
Case 1: A clause in S is subsumed by another clause in S.
According to Proposition 1, if a clause in S is subsumed by another clause in S, the
deductive behavior of the remaining set of rules will not change if the subsumed rule
is removed. Thus, based on the definition of redundancy, S is redundant.
Case 2: A clause in S is subsumed by a clause deduced from S.
According to Proposition 2, if a clause in S is subsumed by a clause deduced from
S, the deductive behavior of the remaining set of rules will not change if the sub
sumed rule is replaced by its subsuming rule. Because the subsuming rule has less
predicate(s) than the subsumed rule, the replacement of the subsumed rule by its
subsuming rule is in effect equivalent to the removal of part of the subsumed rule.
Based on the definition of redundancy, S is redundant.
(<=) Next, we need to prove that, if S is redundant, then there is a clause in
S which is subsumed either by another clause in S or by a clause deduced from S.
Because a set of rules is redundant under two caseseither a rule or part of a rule
can be removed from the set without changing its deductive behaviorwe shall deal
with the two cases separately.
Case 1: A rule is removed from a set of rules without changing its deductive
behavior.
Suppose, a rule ri is removed from S and the remaining set of rules is S' which has
the same deductive behavior as S. For this case, we want to prove that the removed
clause ri is subsumed by a clause in S' or by a clause derivable from S'. Suppose,
by way of contradiction, clause ri is not subsumed by any clause derivable from S'.
(Note, in particular, a clause in S' is obviously a clause derivable from S'.) Further
assume that
ri = P1AP2A...APk Pn
= P VP2 V ... VPk V Pn
= {P1, P2... Pk, Pn}
(Note that the last two expressions are the rule's clausal form.) Then, P" can be
deduced from S when the conditions Pi A P2 A ... A Pk are satisfied. Since ri is not
subsumed by any clause derivable from S' (the hypothesis), no clause derivable from
S' has the following form:
rj = P1A P2 A... A PI*Pn
= P V P2 V ... V P V Pn
= {"Pi,P2,..., PI,Pn}
where 1 < k. Thus, if ri is removed from S, the output fact P,, will never be deduced
from the remaining set of rules S' based on the set of input facts {P1, P2,... Pk }.
That is, the deductive behavior of S is not the same as that of S'. This contradicts
with the condition that S is redundant. Therefore, ri must be subsumed by a clause
in S' or by a clause derivable from S'.
Case 2: Part of a rule is removed from a set of rules without changing its deductive
behavior.
For this case, we want to prove that a clause in S is subsumed by a clause deduced
from S. Suppose S is a given set of rules and S' is the remaining set of rules obtained
by removing part of a rule from S. That is,
S = {ri,r2,...,ri,...,rn}
S' = {ri,r2,...,ri,...,r,}
where r\ C ri (in their clausal forms). Let rt be a given set of input facts and To
be the set of output facts obtained by applying S on FI. Because S and S' have the
same deductive behavior, we have
F, U S Fo
ri U S' F o
We need to prove that (1) ri is subsumed by ri and (2) ri is derivable from S.
The first part is obvious. Since ri C ri (a given condition), r, is subsumed by r,.
We now prove the second part: r' is indeed derivable from S. Suppose
ri = PA P2 A ... A Pk Pm
= PI V P2 V... V Pk V P
r = PAP2 A ... A P Pm
= PI V 'P2 V ... V .Pj V Pm
where j < k.
By modus ponens, we have
{Pi,P2,...,} J}U{r'} {Pm}
Expressing r\ in its clausal form, we have
{Pi,P2,...,Pj} U {P1V P2 V...VP V Pm} {Pm}
Of course, Pm can also be deduced from S' which contains r\, i.e.,
{P1,P2,...,Pj}US' {Pm}
Since S and S' have the same deductive behavior (as given in the condition), we have
{P1,P2,....Pj}US {Pm}
By extracting detailed ri from S, the above expression is rewritten as following.
{P1, 2,..., Pju{'P1VP2V...VPjV...VPkVPm,ri,r2,..., r.i1, i,...,rl} H {Pm}
Performing deductions based on the resolution principle, we yield
{Ps, P2,  , Pj}U {'Pj+l V Pj+2V.. .VPkV Pm,rx, r2,..., ri1, r+i,..., rn} H {Pm}
In order to resolve away 'Pj+i, Pj+2,..., 'Pk, and to deduce Pm from
Pj+x V Pj+2 V .. ..V Pk V Pm
there must be clauses Pj+i (or P+1i V Pm) and Pj+2 (or Pj+2 V Pm) and ... and Pk
(or Pk V Pm) derivable from
{P1, P2,... P} U S
Hence, there must be clauses of the following forms derivable from S: {Sj+1 } U {Pj+1 }
(or {Sj+1} U {Pj+i,Pm}) and {Sj+2} U {Pj+2} (or {Sj+2} U {Pj+2,Pm}) and ...and
{Sk} U {Pk} (or {Sk} U {Pk,Pm}), where
Sj+j C {P P2 *,..., "Pj}, i = 1,2,..., k j
and Sj+i can be an empty set. Thus, using these clauses and the clause in S, ri =
PI V 'P2 V ... V PV... V Pk V P, we can resolve away Pj+i,..., "Pk in ri
and derive the clause P1 V P2 V ... V Pj V Pm, which is r. That is, r, is derivable
from S. E
5.4 Circular Rules Detection
The most serious problem with a rule base is the existence of a circular rule chain
because it can cause a system to perform deductions indefinitely. In this section,
we first define circular rules. Then, based on the definition, we show how deduction
techniques can be applied for detecting circular rules.
Definition 8 (Circular Rules). A set of rules is circular if the same predicate appears
in the condition (i.e., the LHS) of some rule as well as in the conclusion (i.e., the
RHS) of some rule, and there is a derivation link between these two occurrences of
the same predicate.
Example 1:
AAB + C
CAD  E
E A
(5.1)
(5.2)
(5.3)
In this example, the predicate A appears in the condition of the first rule and in
the conclusion of the third rule, and there is a derivation link between these two
occurrences, i.e.,
A(, B) Rule 5.1 C(,D)Rule 5.2 E Rule5.3 A
A circular chain of rules can be formed among these three rules in a deduction, for
instance, based on the lefttoright predicate selection strategy, as shown in Fig
ure 5.1(a).
E C, D > E
C,D A,B> C
A,B,D
A D, E, C> A
D. E, C
C A, B >C
A, B
(b)
Figure 5.1. The deductions of circular rules.
Example 2:
AAB + C
(5.4)
DAEAC  A (5.5)
In the second example, the predicate A appears in the condition of the first rule and
in the conclusion of the second rule, and there is a derivation link between these two
occurrences.
A(, B) Rule 5.4 (D, E,)C Ru 5 A
A circular chain of rules can also be formed in a deduction, as shown in Figure 5.1(b).
It is important to point out that, for the same deduction control strategy, when the
relative position of a predicate in the LHS of a rule is changed, the sequence of
deductions may be changed as well. However, the circular chain will eventually be
formed as long as the given set of rules is circular. This remains true even if different
control strategies are used in the deductions.
Having defined and illustrated the problem of circular rules, we want to show
that the same basic deduction technique we have been using for the other rule base
problems can also be used to detect the existence of a circular rule chain. The
following theorem provides us with an underlying principle for circular rule detection.
Theorem 5. A set of rules is circular if and only if a tautology that contains the
disjunction of a literal and its complement literal can be deduced from the set of
rules by resolutions.
Proof: Suppose S is a given set of rules:
S = {ri,r2,...,rn}
(=) What we need to prove is that if a tautology can be deduced from S, then
S is circular. Suppose a tautology deduced from {rl, r2,... r} is ('A V A). Since
ri, r2,..., rn are Horn clauses, the negative literal 'A must originate from the pred
icate occurrence A in the condition (i.e., LHS) of some rule, and the positive literal
A must originate from the predicate occurrence A in the conclusion (i.e., RHS) of
some rule. In addition, since (A V A) is a resolvent deduced from {ri, r2,..., r},
there must exist a derivation link between the occurrence A in the condition of some
rule and the another occurrence A in the conclusion of some rule. Therefore, based
on the definition, S is circular.
(<=) What we need to prove is that if S is circular, then a tautology can be
deduced from S. Since S is circular, we can assume that a predicate A appears in
the condition of rule ri and in the conclusion of rule rs,. So, we have
ri = C(A)
rn = C(A)
where the expression C(X) represents a clause containing X. In other words, ri is
a clause containing the literal 'A, and rn is a clause containing the literal A. Also,
because there is a derivation link in {ri, r2,..., r,} between the occurrence A in the
condition of ri and the occurrence A in the conclusion of rn, we can deduce a resolvent
C(A V A) based on {ri, r2,..., rn}. A tautology has been deduced. N
Based on this theorem, the procedure for detecting circular rules is shown below:
1. Perform deductions based on the levelsaturation resolution on a given set of
rules.
2. Detect tautologies of resolvents. If a resolvent is a tautology, then there is a
circular rule chain; otherwise, there is no circular rule chain. The set of rules
which are involved in the deduction of a tautology forms the circular chain.
The correctness of this procedure has been guaranteed by the above theorem.
5.5 Discussions on NonHorn Clauses
So far, our refinement theory and the detection procedure are based on the as
sumption that all rules can be represented as Horn clauses. We use some examples to
illustrate what will happen if the assumption is removed, i.e., rules are represented
as nonHorn clauses. In particular, we want to see whether the theory of rule refine
ment also works for general forms of rules. In the discussion, we study basically two
categories of nonHorn clauses: definite rules and indefinite rules. A definite rule is
the one with only one predicate in the RHS, and an indefinite rule has more than
one predicates in its RHS in the disjunctive form. In the following examples, the Ci's
represent predicates.
Example 1 (definite rule base with negative conclusion and negative condition):
ri: C1 A C2 C3
r2 : C1 C2
The clausal form is
ri: C V C2VC3
r2 : C1 V C2
Hence, the resolvent of r1 and r2 is 'C1 V C3, which subsumes rl. Based on the
redundancy detection and removal procedure, we obtain a new set of clauses:
r : C1 V C3
r2 : C1 V 'C2
Or
r': C1+C3
r2: C1 'C2
The new set of rules has the same deductive behavior as the original set. Therefore,
in this case, the rule refinement theory still holds.
Example 2 (definite rule base with negative conclusion):
ri: C A C2 C3
r2 : C C2
The clausal form is
ri : C, V C2 V C3
r2 : 'C1 V 'C2
We notice that rule r2 subsumes rule rl. Based on our rule refinement theory, rule
r, will be deleted from the rule base. However, if we consider the local behavior of
each rule, we see that r2 cannot replace r, because C3 cannot be deduced from r2 but
it can be deduced from rl. Based on this argument, it is clear that the redundancy
detection and removal procedure does not maintain the same local deductive behavior
of the original rule base in this case.
Now, let us look at this example from the perspective of the global deductive
behavior of a rule base. When fact C, is given, based on rule r2, we have {Ci}U {r2} F
'C2. Then, the condition of r1 is false, i.e., C1 A C2 = False. From the logic point
of view, rule r1 is always true. In this sense, rule r1 is not necessary, thus redundant,
if rule r2 is present. This result agrees with the rule refinement theory. On the other
hand, since C1 A C2 = False, C3 in r1 is an unreachable conclusion.
We also notice that, in the above set of rules, if C1 and C2 were given to deduce
C3, 'C2 would be deduced as well from r2; therefore in this case, there would be a
rule conflict between ri and r2.
The above example shows that our rule refinement theory takes into consider
ation the "global semantics" of a rule base rather than just the local semantics of
rules (i.e., the semantics of an individual rule) considered in most research in logic
programming [Lloy87]. This is important because, when only local semantics are
considered, a program's semantics are dependent upon the underlying system's se
quential rule execution model (i.e., the control strategy). For example in a system
with a sequential rule execution model such as a production rule system, if rule ri in
our example rule base is selected to be fired first, fact C3 will be deduced based on
the facts CO and C2. The system then fires rule r2 and deduces the fact 'C2, without
knowing that it has produced a contradiction with the fact used by the previously
fired rule. This kind of problem can be avoided only if the global semantics of a
rule base are taken into consideration because global semantics are independent of
the sequence of rule execution. The global semantics of a rule base revealed by the
rule refinement theory is also very useful for expert systems verification. Using the
information provided by a rule refinement procedure as such, expert system designers
can detect more rule base problems (e.g., unreachable conclusions, rule conflicts, and
so on) and further modify the rule base in order to avoid those problems.
Finally, let us examine an example which represents an indefinite rule base.
Example 3 (indefinite rule base):
ri: C1AC2AC3 C 4VCs
r2: C1A C2A C3 C4
The clausal form is
ri = nC1 V _C2 V C3 V C4 V C5
r2 = Ci V 'C2 V C3 V C4
Rule r1 is subsumed by rule r2. But, when given the input facts FT = {C1, 02, C3}
we have
ri U {ri} C4 V C5
Fr U {r2} O C4
Since C4 V C5 C04, ri and r2 do not have the same deductive behavior. Therefore,
the rule refinement theory does not cover indefinite rule bases.
In summary, our rule refinement theory is proved to be applicable to a rule base
defined by Horn clauses. While we have not formally prove its validity to definite
nonHorn clauses, we have shown that the theory is also applicable to some example
rule bases defined by definite nonHorn clauses which have not been considered in
current research on rule base validation. However, the theory is not applicable to
indefinite rule bases.
CHAPTER 6
SYSTEM IMPLEMENTATION AND PERFORMANCE EVALUATION
6.1 Introduction
Based on the techniques described in the previous chapters, we have implemented
a rule base validation and refinement system in UNH Prolog on a SUN 4 worksta
tion. Our rule validation and rule refinement techniques are based on the resolution
principle. Consequently, the major computation of the corresponding algorithms is
to perform resolutions on a given rule base. Each resolution is a logical deduction.
Thus, the efficiency of the system is mainly decided by the number of logical deduc
tions that have to be generated. In order to increase the system efficiency, we need
to reduce as much as possible the number of logical deductions performed. In our
implementation, the major concern is system efficiency.
In this chapter, we first give an overview of the system's structure and functions
Section 6.2. Then, in Section 6.3, we introduce two techniques used in the imple
mentation for achieving better system efficiency: the unified framework for both
rule validation and rule refinement, and the reversed subsumption deletion strategy.
Finally, we evaluate the system's performance in Section 6.4.
6.2 Overall System Description
The implemented system performs the following tasks: (1) translate all rules in
a rule base into the clausal form; (2) perform logical deductions on the clauses using
the resolution principle; (3) detect rule inconsistencies by informing the user whether
the rule base is inconsistent, what rules are involved in deriving a contradiction, and
87
what input facts can cause the contradiction; (4) detect rule redundancies by printing
out the set of refined rules and indicating which rules are deleted or replaced by the
new rules; (5) detect circular rules by identifying different subsets of rules, each of
which can form a circular rule chain. The system also has a debugging mode; when
turned on, it will allow the user to trace all the deductions step by step.
The functionality, structure and control flow of the system are shown in Figure 6.1.
In this figure, a rectangular box represents a function block of the system while an
oval represents an input to or an output from the function block. The arrows indicate
the control flow and the structure of the system.
Figure 6.1. Overview of the rule validation and rule refinement system.
We now describe all the function blocks in Figure 6.1 according to the sequence
of their executions. First, the Rule Translation block reads in a rule base from a file
and translates all the rules into their clausal forms. A rule in the file is written as
the conventional firstorder logic formula, such as A(x), B(x, y) + C(x, y) which is
translated to its clausal form as 'A(x) V iB(x, y) V C(x, y). Then, the Resolution
Deduction block performs logical deductions on the set of clauses based on the res
olution principle until no deductions can be inferred. After all the derivable clauses
have been generated, the three function blocks, i.e., Inconsistency Detection block,
Redundancy Detection block, and Circular Rules Detection block, can be executed
independently and concurrently. The major task of each of these three detection
blocks is basically to test certain properties among the clauses in order to determine
a specific problem of the given rule base. In the Inconsistency Detection block, a
"partial deduction set" (PDS) is constructed, and based on the final PDS, the corre
sponding "potentially contradictioncausing input set" is also identified. Hence, this
block answers the three questions: (1) Is the rule base consistent? (2) If inconsistent,
which rules can cause a contradiction to be deduced? and (3) What input facts can
cause the contradiction? The Redundancy Detection block tests subsumption rela
tionships between clauses and identifies which rule can be deleted and which rule can
be replaced by another rule. It also prints out a refined set of rules which has been
refined (i.e., with rule redundancies removed). Finally, the Circular Rules Detection
block identifies, by detecting tautologies, every individual subset of rules which can
form a circular rule chain.
We note that the debugging function of the system is not depicted in Figure 6.1.
This function is implemented in the following manner. In the Resolution Deduction
block, the system writes every logical deduction into a file. Each logical deduction is
represented by the parent clauses and the resolvent. Then, in each of the three detec
tion blocks, the testing results will also be written into the file. The testing results
specify which clauses can be resolved to a contradiction, which clause is subsumed
by which clause, and which clause is a tautology. The user can look into the file to
trace each step of the deductions and to understand how a conclusion on the rule
base inconsistency or redundancy is reached.
We realize the possible efficiency problem with the levelsaturation resolution
method used in the Resolution Deduction block, especially if a rule base is large. As
mentioned before, the efficiency of the rule validation and rule refinement system is
mainly decided by the number of logical deductions that have to be generated. We use
two techniques to increase the system efficiency. The first technique is to structure
the system in such a way that the partial deductions generated for rule validation are
reused for rule refinement; thus, there is no need to repeat the deductions for the
rule refinement purpose. This technique is workable due to the unified framework
developed for dealing with both rule validation and rule refinement problems in a
uniform manner. Another technique called "reversed subsumption deletion" strategy
is used in the Resolution Deduction block to further reduce the number of logical
deductions. These two techniques are described in the next section.
6.3 Techniques for Improving System Efficiency
In this section, we present two techniques for improving the system efficiency.
We first describe how the unified framework can be used for both rule validation
and rule refinement so that the logical deductions generated can be shared for the
inconsistency detection, redundancy detection, and circular rules detection. Then we
describe the second technique, the reversed subsumption deletion strategy, used for
improving the efficiency of the levelsaturation resolution method. Further, we prove
that this strategy does not affect the completeness of our rule validation and rule
refinement algorithms.
6.3.1 The Unified Framework
Most of the existing expertsystemverification tools use different algorithms for
identifying different rule base problems encountered in expert rules verification [Gins88,
Grag87, Nguy85, Nguy87b, Nguy87a, Shor81]. For example, one algorithm is designed
for inconsistency detection of rules, one for redundancy detection of rules, and one
for cycle detection of rules. Thus, different computations have to be performed for
the detections of different problems. However, our uniform theory on these differ
ent rule base problems enables us to establish a unified frameworkbased on logical
deductionsfor handling various problems in a uniform manner.
The uniformity of our theory on rule validation and rule refinement allows the
shared computation of the three algorithms for inconsistency detection, redundancy
detection, and circular rule detection, respectively. These algorithms (described in
Chapter 4 and Chapter 5) consist of basically two phases. The first phase, which is
shared by these algorithms, is to perform logical deductions on the given rule base
and to generate all derivable clauses. This phase of computation is the dominating
performance factor in all the three algorithms. The second phase of the algorithms
is the testing phase. Different properties of the derived clauses (including the set of
rules in the given rule base) are tested in order to identify the specific rule problems
existing in the rule base. For example, a subsumption relationship between two
clauses is tested in the inconsistency and redundancy detection algorithms, and a
tautology in a clause is tested in the circular rule detection algorithm.
Because of the shared computation in the first phase, a great amount of compu
tation time is saved. This twophased processing is reflected in the system structure
shown in Figure 6.1. From the figure, we can see that the results of the Resolu
tion Deduction block is used/shared by the three detection blocks. On the other
hand, without this kind of unified framework, a rule validation and rule refinement
system would have to be built in a structure as shown in Figure 6.2 which is the
common structure found in most expertsystemverification tools. Obviously, this
kind of structure will degrade the system efficiency.
Computation for Computation for Computation for
Inconsistency Redundancy Circular rules
Detection Detection Detection
Inconsistency Redundancy Circular Rules
Detection Detection Detection
Figure 6.2. The structure for a validation system without a unified framework.
6.3.2 The Reversed Subsumption Deletion Strategy
Even though the unified framework allows the sharing of the computation results,
the computation in the Resolution Deduction block (see Figure 6.1) is still the major
computation task of the system and requires a considerable amount of time. As
discussed in Section 4.2, the levelsaturation resolution method is used to perform
logical deductions in order to guarantee the completeness of the validation algorithm.
This method is not the most efficient resolution method, in spite of the fact that
the subsumption deletion strategy introduced by Chang [Chan73] is used to avoid
deducing irrelevant clauses. Our objective is to improve the efficiency of the resolution
method by avoiding as much as possible the generation of irrelevant clauses and, at
the same time, maintaining the completeness of the rule validation and refinement
system.
We have developed and employed a "reversed subsumption deletion (RSD)" strat
egy in addition to the Chang's subsumption deletion strategyin our resolution
method to reduce the number of logical deductions that have to be generated. The
deletion strategy is used with the levelsaturation method in the following way: First,
list clauses of (So U ... U Sn1) in order, where S' represents the set of resolvents
generated in the 1th level, and So is the given set of rules. Then, compute resolvents
by comparing every clause C1 E (So U ... U S51) with a clause C2 e Sn1 that is
listed after C1. When a resolvent is computed, it is appended to the end of the list
generated so far if it is neither a tautology nor subsumed by any clause in the list.
Otherwise, it is deleted based on Chang's subsumption deletion strategy. In addition,
if any clauses in the list are subsumed by the newly generated clause, the subsumed
clauses are deleted from the list as well (the reversed subsumption deletion strategy).
The completeness of the rule validation algorithm (described in Chapter 4) is not
affected by the use of the reversed subsumption deletion strategy. This is because
that, in the algorithm, the generated final partial deduction set (PDS) is used for
determining the inconsistencies of a rule base. The following theorem ensures that
the use of the new strategy does not change the final PDS produced by the algorithm.
Therefore, it will not change the completeness of the algorithm.
Theorem 6. When the rule validation algorithm is applied to a set of rules, the in
troduction of the reversed subsumption deletion strategy into the algorithm does not
change the final partial deduction set produced by the algorithm.
