• TABLE OF CONTENTS
HIDE
 Title Page
 Acknowledgement
 Table of Contents
 Abstract
 Introduction
 Survey of related works
 A pattern-based object calculu...
 Rule validation
 Rule refinement
 System implementation and performance...
 Conclusions and future researc...
 Reference
 Biographical sketch
 Copyright
 Copyright






Title: Rule validation in object-oriented knowledge bases
CITATION THUMBNAILS PAGE IMAGE ZOOMABLE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00082395/00001
 Material Information
Title: Rule validation in object-oriented knowledge bases
Physical Description: vii, 120 leaves : ill. ; 29 cm.
Language: English
Creator: Wu, Ping, 1964-
Publication Date: 1993
 Subjects
Subject: Object-oriented databases   ( lcsh )
Expert systems (Computer science) -- Validation   ( lcsh )
Electrical Engineering Sciences thesis Ph. D
Dissertations, Academic -- Electrical Engineering Sciences -- UF
Genre: bibliography   ( marcgt )
non-fiction   ( marcgt )
 Notes
Thesis: Thesis (Ph. D.)--University of Florida, 1993.
Bibliography: Includes bibliographical references (leaves 114-119).
Statement of Responsibility: by Ping Wu.
General Note: Typescript.
General Note: Vita.
 Record Information
Bibliographic ID: UF00082395
Volume ID: VID00001
Source Institution: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
Resource Identifier: aleph - 001934378
oclc - 30833725
notis - AKB0468

Table of Contents
    Title Page
        Page i
    Acknowledgement
        Page ii
        Page iii
    Table of Contents
        Page iv
        Page v
    Abstract
        Page vi
        Page vii
    Introduction
        Page 1
        Page 2
        Page 3
        Page 4
        Page 5
        Page 6
        Page 7
        Page 8
    Survey of related works
        Page 9
        Page 10
        Page 11
        Page 12
        Page 13
        Page 14
        Page 15
    A pattern-based object calculus
        Page 16
        Page 17
        Page 18
        Page 19
        Page 20
        Page 21
        Page 22
        Page 23
        Page 24
        Page 25
        Page 26
        Page 27
        Page 28
        Page 29
        Page 30
        Page 31
        Page 32
        Page 33
        Page 34
        Page 35
        Page 36
        Page 37
        Page 38
        Page 39
        Page 40
        Page 41
        Page 42
        Page 43
        Page 44
        Page 45
    Rule validation
        Page 46
        Page 47
        Page 48
        Page 49
        Page 50
        Page 51
        Page 52
        Page 53
        Page 54
        Page 55
        Page 56
        Page 57
        Page 58
        Page 59
        Page 60
        Page 61
        Page 62
        Page 63
        Page 64
    Rule refinement
        Page 65
        Page 66
        Page 67
        Page 68
        Page 69
        Page 70
        Page 71
        Page 72
        Page 73
        Page 74
        Page 75
        Page 76
        Page 77
        Page 78
        Page 79
        Page 80
        Page 81
        Page 82
        Page 83
        Page 84
        Page 85
        Page 86
    System implementation and performance evaluation
        Page 87
        Page 88
        Page 89
        Page 90
        Page 91
        Page 92
        Page 93
        Page 94
        Page 95
        Page 96
        Page 97
        Page 98
        Page 99
        Page 100
        Page 101
        Page 102
        Page 103
        Page 104
        Page 105
        Page 106
        Page 107
        Page 108
        Page 109
    Conclusions and future research
        Page 110
        Page 111
        Page 112
        Page 113
    Reference
        Page 114
        Page 115
        Page 116
        Page 117
        Page 118
        Page 119
    Biographical sketch
        Page 120
        Page 121
    Copyright
        Copyright
    Copyright
        Copyright
Full Text














RULE VALIDATION
IN
OBJECT-ORIENTED 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: Suey-Chyun Fang,

Yaw-Huei Chen, and Hsin-Hsing 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 #CCR-9200756.



















TABLE OF CONTENTS





ACKNOWLEDGEMENTS ..............................

ABSTRACT .. .. . .. .. .. .... ..... .. . .. .. ... .. ...

CHAPTERS

1 INTRODUCTION ...............................


2 SURVEY OF RELATED WORKS ...........

2.1 Knowledge Representation ............
2.2 Validation of Rule-Based Expert Systems .....
2.2.1 Overview ..................
2.2.2 Verification and Validation Tools ....

3 A PATTERN-BASED OBJECT CALCULUS .....


page

ii

vi


3.1 Introduction .. ... .. ...... ... .. ... .. -
3.2 Alternative Views of a Database: Object-Oriented 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 Non-Horn 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
OBJECT-ORIENTED KNOWLEDGE BASES

By

Ping Wu

August 1993


Chairman: Dr. Stanley Y. W. Su
Cochairman: Dr. Nabil N. Kamel
Major Department: Electrical Engineering

A knowledge-based 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 real-world 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 object-oriented approach to represent knowledge. An

object calculus, a formalism based on first-order 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: knowledge-based systems, logical deduction, object-oriented approach,

resolution principle and theorem proving, rule refinement, rule validation.

















CHAPTER 1
INTRODUCTION

A knowledge-based 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 knowledge-based system can be

regarded as a meta-interpreter which manipulates statements (information) in the

knowledge base. A knowledge-based 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

knowledge-based system is called derivation. In other words, new information can

be derived by a knowledge-based system. This abstract model of a knowledge-based

system is illustrated in Figure 1.1.

Based on this abstract knowledge-based 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 so-called knowledge-based 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













Knowledge-based 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 rule-modus 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 rules-modus

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 full-fledged knowledge-based 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 so-called 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 first-order 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

knowledge-based systems (i.e., expert systems and deductive database systems) but

also in object-oriented (00) knowledge-based systems. Our research on rule valida-

tion is mainly motivated by the existence of potential conflicts in an 00 knowledge

base. Object-oriented databases and knowledge-based 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, user-defined semantic constraints. These

properties and constraints provide the expressiveness needed for modeling data used

in advanced applications, such as CAD/CAM, office automation, and multi-media

databases. A database or knowledge base defined in terms of these three types of

semantic abstractions may have semantic conflicts. For example, user-defined 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 object-oriented 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 knowledge-based system has been designed "correctly," i.e., determining

the system's reliability. It gives the users of a knowledge-based system confidence in

the system. The answer to the second question can help the knowledge-based 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 knowledge-based 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 real-world 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 knowledge-based 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 knowledge-based 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 logic-based method [Moor85]. Most implemented expert systems

use rules (i.e., logic-based 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 object-oriented 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 user-defined 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

calculus-a logic-based formalism-for 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 scheme-a pattern-based object calculus. Chapter 4

and Chapter 5 describe a unified framework-based on mathematical logic and me-

chanical theorem proving-for 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 knowledge-based

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 knowledge-based 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, first-order logic has been shown to be both sound and complete.

Another advantage of a predicate calculus-like 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 logic-like 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 first-order 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 logic-based

formalism as our knowledge representation.

2.2 Validation of Rule-Based Expert Systems

Rule-based 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 rule-based 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 input-output 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 high-level 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 metaknowledge-based system shell that provides verification and val-

idation capabilities for knowledge-based systems in use at the Lockheed Artificial












Intelligence Center in Austin, Texas. It is written in QUANTAS PROLOG and cov-

ers ART and LISP knowledge-based systems. ESC is a decision-table-based processor

for checking the completeness and consistency of a rule-based 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 PATTERN-BASED OBJECT CALCULUS

3.1 Introduction

Many object-oriented (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 multi-media 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 object-oriented database management systems (DBMSs) are

primarily founded on ideas adopted from object-oriented programming languages.

Implementations of object-oriented 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], object-oriented 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 "hard-coded" 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 well-defined mathematical formalism. Efficiency in object-oriented

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 F-logic [Kife89a]. F-logic 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 F-logic, the database schema is incorporated as part of the language. Its

computation model is a resolution-based proof procedure. Unlike the approach taken

in F-logic, 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 pattern-based object calculus for formally describing

and manipulating objects and object association patterns in 00 databases. This

object calculus is based on first-order 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 calculus-based 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 union-compatible (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 high-level 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: Object-Oriented vs. Relational

In this section, we shall point out the main differences between the relational

and object-oriented 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. Foreign-to-primary-key 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 attribute-based.












Unlike the relational view, our object-oriented view of a database is based on

the essential characteristics of the object-oriented 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 system-defined 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 association-types 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 bi-directionally 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 round-about 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 object-objected 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 Object-oriented Semantic Association Model

(OSAM*) [Su89b]. The OSAM* data model provides five types of system-defined

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 object-oriented 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 user-issued 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 tuple-oriented 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 "asso-name" 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.





















range-definition
::= RANGE OF variable IS range-item
range-item
::= class I ( expression )
expression
::= target-item-commalist [ WHERE wff ]
target-item-commalist
::= target-item I target-item target-item-commalist
target-item
::= variable attribute I variable
wff
::= association-pattern
comparison
( wff )
NOT wff
wff AND wff
wff OR wff
EXISTS variable ( wff )
FORALL variable ( wff )
IF wff THEN wff
association-pattern
::= class
I class *[asso_name] association-pattern
I class ![asso_name] association-pattern
comparison
::= target-item op target-item
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 "association-pattern" 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 "*[asso-name]" or "![assoname]", and classic is an

object variable for the class. In general, we use the "asso-name" 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 "asso-name" 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 "well-formed formula." Wffs are discussed in
detail in the following subsections.

5. For simplicity of descriptions, the following abbreviations are used-NOT (-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:

target-list [ 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 target-list 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 object-oriented 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 object-oriented 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 object-oriented 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 system-defined or user-defined 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

outer-join 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 union-compatible 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

system-defined and/or user-defined database operations (e.g., DELETE, UPDATE,

ASSIGN-PROJECT, 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 user-defined semantics. In

the operation part we can specify system-defined or user-defined operations which

are performed on the specified subdatabase. Consider two examples which employ

respectively a system-defined operation and a user-defined 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 system-defined 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 user-defined operation

ASSIGNPROJECT is performed on these objects in the subdatabase. Here, we

assume that the user-defined operation ASSIGN-PROJECT 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 application-oriented

constraints which can be represented in an object-oriented 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/non-existence

of some association patterns may depend on the existence/non-existence of other

association patterns. In the following subsections, we shall describe various types of

constraints that may exist in object-oriented databases and formally specify these

constraints by rules using object calculus expressions. The usage of object variables

is self-explanatory 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 first-order

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 Dept-1 IS Department

RANGE OF Dept-2 IS Department

IF TA Depti1 A Dept-l.name = "EE"

THEN

-'(TA Teacher Section Course Dept-2 A Dept2.name # "EE")












In this example, we use the alias variables Dept-1 and Dept-2 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 Dept-1, is a short

hand for TA Grad Student Dept-1.

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 high-level 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 system-defined and user-defined 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.

Trigger-condition (After update(Grad), After update(TA), After update(RA))

(IF Grad TA THEN VRA(Grad! RA))A

(IF Grad RA THEN VTA(Grad! TA))

Corrective-action (Message: ("A graduate student cannot be both a TA

and an RA"))

3.6 Summary

In this chapter, we have introduced a pattern-based object calculus which incor-

porates the concept of association pattern specification into the first-order 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 set-oriented 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 union-compatible (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 high-level 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 defined-based on rule

syntax, not semantics-to 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 knowledge-based

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 left-hand side (LHS) of the clause and the disjunction of the Rj's

as the right-hand 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 knowledge-based 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 rule-based

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 knowledge-based 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 knowledge-based system. Therefore, we need a different definition of consis-

tency/inconsistency in the context of rule validation, which takes the input facts of

a knowledge-based 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 first-order 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 SLD-resolution, the reader is referred to [Lloy87]. In

this section, we first briefly introduce the level-saturation 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 Sn-1) and C2 E Sn-1 },

n = 1, 2, 3,...

This procedure is called the level-saturation (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 level-saturation 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 rule-based 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 clauses-for example, one considered as the rule base and the other as the

fact base-are 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 left-hand 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 knowledge-based 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 level-saturation 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 level-saturation 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 multi-literal 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 contradiction-causing input set."











From this procedure, we can obtain a PDS and a potentially contradiction-causing

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 level-saturation 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 multi-literal clause can be put into PDS; therefore, PDS = {-A, -B}

6. Potentially contradiction-causing input set = {A, B}



From the potentially contradiction-causing 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)

S-B 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 level-saturation 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 level-saturation resolution method.

We know that in mechanical theorem proving, there are more efficient resolution











methods than the level-saturation resolution method, such as linear resolution, input

resolution, unit resolution, SLD-resolution, and so on. However, the level-saturation

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 SLD-resolution 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 contradiction-causing input set. The major shortcomings

of the linear-resolution-based 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 resolvents-some 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 SLD-resolution (which is commonly used

in Prolog language) has the same problems as the ones mentioned above because

SLD-resolution 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

query-answering system in which the query is always selected as the top clause.








64


In summary, the rule validation algorithm based on level-saturation 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 syntax-based defini-

tions of rules to detect a small amount of redundancies in a knowledge base is not

enough; a more general technique which uses semantics-based 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 non-Horn 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 Horn-clauses. In the

final section, we shall discuss how the developed theory can be applied to a set of

rules represented as non-Horn 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 Horn-clauses, 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 right-hand-side 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,..., ri-1, ri, rzi+,, r* }

= The deductive behavior of {ri, r2,..., ri-1, ri, ri+i,.. ., rn, r'}

= The deductive behavior of {ri, r2,..., i-1 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 level-saturation 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 V-BVC 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

A--C

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 cases-either a rule or part of a rule

can be removed from the set without changing its deductive behavior-we 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 V-P2 V ... V-Pk 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...V-P 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{-'P1V-P2V...V-PjV...V-PkVPm,ri,r2,..., r.i-1, i,...,rl} H {Pm}


Performing deductions based on the resolution principle, we yield


{Ps, P2, - -, Pj}U {'Pj+l V -Pj+2V.. .V-PkV Pm,rx, r2,..., ri-1, 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 left-to-right 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 level-saturation 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 Non-Horn 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 non-Horn 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 non-Horn 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

non-Horn clauses, we have shown that the theory is also applicable to some example

rule bases defined by definite non-Horn 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 first-order 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 contradiction-causing 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 level-saturation 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

re-used 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 level-saturation 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 expert-system-verification 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 framework-based on logical

deductions-for 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 two-phased 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 expert-system-verification 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 level-saturation 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 strategy-in our resolution

method to reduce the number of logical deductions that have to be generated. The

deletion strategy is used with the level-saturation method in the following way: First,

list clauses of (So U ... U Sn-1) 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 S5-1) with a clause C2 e Sn-1 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.




University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs