Veri cation and Correctness Issues for Nonmonotonic Knowledge Bases Grigoris Antoniou
Grith University, CIT Nathan, QLD 4111, Australia
[email protected] Abstract
Anomalies such as redundant, contradictory or de cient knowledge in a knowledge base indicate possible errors. Various methods for detecting such anomalies have been introduced, analyzed and applied in the past years, but they usually deal with rule-based systems. So far, little attention has been payed to the veri cation and validation of more complex representations, such as nonmonotonic knowledge bases, although there are good reasons to expect that these technologies will be increasingly used in practical applications. This paper does a step towards the veri cation of knowledge bases which include defaults by providing a theoretical foundation of correctness concepts and a classi cation of possible anomalies. It also points out how existing veri cation methods may be applied to detect some anomalies in nonmonotonic knowledge bases, and dicsusses methods of avoiding potential inconsistencies (in the context of default reasoning inconsistency means nonexistence of extensions).
1 Introduction The importance of assuring the reliability of knowledge systems is now widely recognized. One of the main ways of ensuring reliability of such systems is knowledge base veri cation, a topic that has attracted increasing interest in recent years and has led to the development of successfully applied systems (for an overview of the subject see [9, 14]). These veri cation methods are usually dealing with rule-based knowledge. Little, if any, attention has been payed to the veri cation of more complex representations such as nonmonotonic knowledge bases [15]. It is ex1
pected that nonmonotonic representations will play an increasingly important role in future applications; if predicate logic is the logic of mathematical reasoning, nonmonotonic logic has the impact to become the logic of commonsense reasoning. Another advantage of nonmonotonic representations is that they tend to be more compact and do not require as many modi cations in view of new information. The reason that veri cation work has not been done in the area is probably that there are not yet signi cant, large applications using these techniques. But with the emerging of powerful implementations for nonmonotonic reasoning [2], large applications on areas like diagnosis or legal reasoning are not too far away. Then we will need to verify such knowledge bases for the same reasons as for rule-based systems. Veri cation and validation will be even more useful and necessary because of the following factors: Knowledge bases in a, say, default reasoning framework, are more complex in the sense that they include two di erent kinds of knowledge items (usual rules and default rules). The development of nonmonotonic knowledge bases requires more caution to avoid unexpected e ects; even more in the beginning of the application of this new technology, since the knowledge engineers will not yet have the full understanding they have, for example, of rule-based systems. This paper makes a contribution to the veri cation of nonmonotonic knowledge bases by laying down a formal foundation for veri cation. Our work is strongly motivated by [9] which gives a clear foundation of veri cation for rule-based systems. The knowledge bases we will consider are rule-based systems enhanced by defaults, thus leading to a variant of default logic [11]. Apart from providing formal correctness concepts, we discuss how classical methods may be adapted too deal with some classes of anomalies, illustrate what new problems arise and should be addressed, and take a closer look at consistency in the context of nonmonotonic knowledge. Throughout the paper we assume that the reader is familar with notation and basic concepts of predicate logic.
2 Veri cation principles In this paper we shall follow the approach taken by the usual veri cation work for classical systems. In particular, we accept the commonly accepted 2
assumptions of the eld, as they have been described in [9]: 1. Both syntax and semantics of anomalies are de ned in terms of syntax and semantics of the knowledge representation language in which the knowledge base studied is expressed. 2. Anomalies are de ned declaratively and not procedurally. 3. Anomalies are detected by examining the syntax of the knowledge base. 4. Veri cation methods apply to the knowledge base only; some properties of the inference engine are assumed to be true. 5. Anomalies indicate probable errors, but are not errors themselves. Usually, anomalies are de ned in a language of propositional or predicate logic. In our case we shall often refer to extensions of a default theory. Extensions are predicate logic theories that are based on the default theory (knowledge base) under consideration; see section 4 for more details. The second principle says that we are dealing with static instead of dynamic aspects of the knowledge base, and that veri cation work may be carried out on the conceptual level. Together with the fourth principle, it states that veri cation of knowledge bases and inference engines may, and should be, carried out separately, which is a natural implication of the separation of knowledge base and inference engine in knowledge systems. The third principle is an important one. Its implication is that, for example, whereas nonexistence of extensions is a semantical property (see discussion in subsequent sections), veri cation methods must be able to detect this anomaly by studying the form of the knowledge base. It would be counterintuitive, of course, if a veri cation method woud try dynamically to actually determine one extension by running the knowledge base.
3 Correctness issues for nonmonotonic knowledge bases: an informal discussion This section aims to make the reader a little bit more familiar with the notation and concepts of knowledge bases in default logic, and to outline some forms of anomaly that are speci c for such knowledge and have no counterparts in rule-based systems. 3
In general, defaults have the form ': 1 ;:::; n where '; 1; : : :; n; are predicate logic formulae without free variables. The intuitive meaning of such a default is as follows: If ' is known, and if nothing contradicting any one of 1 ; : : :; n is known, then you may assume . Thus, the default bird:flies is read as \If it is consistent to assume that a bird ies, then conflies clude that it ies", or simpler \Birds usually y". ' is the prerequisite, 1; : : :; n the justi cations, and the consequent of the default. The defaults in the knowledge bases we will be studying in this paper have the more restricted form A1 ::: AnC:B1 ::: Bm where A1 ; : : :; An ; B1; : : :; Bm ; C are ground literals. A knowledge base in default logic distinguishes between defaults and predicate (or propositional) logic formulae which may be rules as they are used in rule-based knowledge bases. Therefore, the knowledge bases we consider in this paper are generalizations of those usually studied in the eld of veri cation and validation. The semantics of a knolwedge base in default logic is given in form of extensions; these are predicate logic theories that are based on the knowledge base. They are obtained by applying as many defaults as possible, without destroying the previous application of a default. To see what is meant by this, consider the defaults trueB :A and B : AA . The rst default may be applied since we may assume A; so, B becomes part of the knowledge base. Then, the second default may be applied (now we know B , and we may consistently assume :A which does not contradict the current knowledge base). But now :A becomes part of the knowledge base. Though there is no inconsistency, note that :A shows a posteriori that we should not have assumed A as done when we applied the rst default. In such a case, application of these two defaults (in this order) will not yield an extension. To illustrate a rst cause of problems without a counterpart in rule-based systems, consider the default trueA:A . It is strange as it says \If it is consistent to assume A, then conclude not A". From what we said above, it should be clear that this default destroys its application a posteriori. The problem is that it actually destroys every extension which does not already possess :A (i.e. all etxensions that allow us to assume A). In fact, defaults like this one are a new kind of anomaly (see section 5). Defaults may contradict each other in the sense that they describe alternative plausible conjectures. One of the strengths of default logic is that it allows representation of potentially inconsistent information without the problems known from classical (predicate) logic. In the usual case, contradicting defaults lead to di erent extensions. For example, there is no ^
^
^
:
:
:
4
^
: pacifist problem in having the defaults republican (republicans are usually pacifist quaker :pacifist nonpaci sts) and pacifist (quakers are usually paci sts) in the knowledge base. Even if someone is known to be both republican and quaker (like Nixon was), there will be one extension where he will be paci st and one where he will be not. So, these defaults do not form an anomaly1. :politician On the other hand, suppose we had the defaults republican and pacifist quaker:politician . Now, there is a potential inconsistency, if the facts quaker pacifist and republican are both included in the knowledge base. The reason is that, then, both defaults would be applicable together leading to a contradiction (i.e. destroying some, maybe all extensions). The situation is now di erent than it was before, because the justi cations are the same in both defaults. These cases should be treated just as potential inconsistencies among rules. Finally, let us describe a case of redundancy, where a rule and a default are involved. In case a rule C A1 ^ : : : ^ An is included in the knowledge base, the default A1 ::: AnC:B1 ;:::;Bm is redundant: if it is applicable (by knowing that A1 ^ : : : ^ An are true and B1 ; : : :; Bm may be assumed), then the rule is also applicable, so there is no new information obtained by the default. This anomaly is an indication of an error like missing conditions or having forgotten to remove the rule when the default was added. :
:
:
^
^
4 Knowledge base de nitions
4.1 Knowledge base
A knowledge base KB consists of a rule base R, a default base D, and a declaration set DEC . A rule base R is a nite set of expressions called rules. A rule has the form A B1 ^ : : : ^ Bn , where A; B1; : : :; Bn are rst-order literals. For such a rule R, we de ne cons(R) = A (the consequent of R), and ante(R) = fB1 ; : : :; Bng (the set of entecedents of R). A default set D consists of nitely many defaults. A default has the form A1 ::: AnC:B1 ::: Bm , where A1; : : :; An ; B1; : : :; Bm ; C are ground literals (i.e. literals without variables). For such a default , we de ne pre( ) = fA1; : : :; Ang (the set of prerequisites of ), just() = fB1; : : :; Bmg (the set of justi cations of ), and cons( ) = C (the consequent of ). As already ^
^
^
^
In fact it is one of the advantages of nonmonotonic representations that con icting pieces of knowledge can be maintained within the knowledge base without \trivializing e ects" as in classical logic. 1
5
said in section 3, the intuitive meaning of such a default is: If we know all of the Ai and if it is consistent to assume that all of Bj are true, then we may imply C. It should be noted that, in actual examples, defaults may have free variables. In that case they are treated as schemas, meaning we consider all ground instances of a default with variables. Thus the restriction to defaults with closed formulae only is not a real restriction for practical purposes; it is used for theoretical reasons [11]. A declaration set DEC consists of a set G of goal literals, a set I of input literals, and a set C of constraints. The declaration of goal literals speci es that set of literals that may be output by the knowledge base. Their declaration is, of course, dependent on the domain or problem under consideration; typically, goal literals describe conclusions or proposed actions. Input literals are the literals that are obtained from the knowledge system's environment in form of observations or commands. Constraints are sets of literals fC1; : : :; Ck g. In the case of classical rule-based knowledge bases constraints describe cases of inconsistency (a constraint fC1; : : :; Ck g means that not all of C1; : : :; Ck should be derived or given). As we explained in the previous section, the semantics of nonmonotonic knowledge bases is given in terms of extensions, and there may be more than one. One implication of this fact is that we have a greater variety of possible constraints. A look at computer science may be helpful here: when considering concurrent or nondeterministic programs, there is a greater variety of correctness concepts (safety conditions, eventuality conditions etc. [6]) compared to sequential deterministic programs. The reason is that we may de ne conditions that are matched by all possible computations, by at least one etc. Therefore, for nononotonic knowledge bases, we distinguish between safety constraints SC and eventuality constraints EC . Safety constraints specify conditions that must be true of all extensions of the knowledge base (one such would be fA; :Ag for all any literal A; this condition is implicitly assumed). Eventuality constraints specify conditions that should be full lled by at least one extension. As an example, imagine a knowledge base which, based on actual weather conditions, distances etc. proposes transportation ways of going to work. One eventuality condition would be not to use ecologically problematic transportations. By using this as an eventuality constraint we want to ensure that at least one extension will propose an 6
ecologically acceptable way of going to work. So, if a user desires to do so, they may ask for extensions until an appropriate one is provided. On the other hand, the user is not forced to do so (which would have been the case if we had declarared the constraint as a safety constraint). Finally, we de ne an environment as a subset of input literals that does not imply a constraint (safety or eventuality). The set ENV of all environments describes the possible inputs to the knowledge base.
4.2 Knowledge base extensions
In default logic [11], the semantics of a default theory is given in terms of extensions. Accordingly, the semantics of knowledge bases as described in 4.1 will be given in form of extensions. One thing that needs modi cation is the underlying monotonic inference relation ` in order to capture the fact that rules may be used in one way only. For example, given the information :A and the rule A B, it should not be possible to infer :B via contraposition. To do so, we use the following hyper-resolution inference rule (used, for example, in [8]):
B1; : : :; Bn; A
A
B1 ^ : : : ^ Bn
which is, of course, incomplete in the sense of rst order logic but mirrors the forward chaining philosophy of rule-based systems. We denote by ` the inference relation imposed by this inference rule, and by Cn(M ) the deductive closure of a set of formulae M w.r.t. `. M is called inconsistent i there exists a formula ' such that M ` ' and M ` :'. A default A1 ::: AnC:B1 ::: Bm is applicable to a set of formulae E i , for all 1 i n and 1 j m, E ` Ai and E 6` :Bj . In the following we give an operational de nition of extensions avoiding the usual one which is based on xed-point equations. We believe that our de nition is more understandable and easier usable (see [1] for more details). Let KB be a knowledge base and Env an environment as de ned in subsection 4.1. Let = (0 ; 1 ; 2 ; : : :) be a sequence of defaults from D without multiple occurrences (modelling an application order of defaults from D). We denote by [k] the initial segment of of length k, provided the length of is at least k. ^
^
^
^
In() is Cn(M ), where M is the set R [ Env united with all consequents of defaults occurring in . 7
Out() = f:BjB 2 just() for some in g. is called a process of KB [ Env i k is applicable to In([k]), for every k such that k occurs in . is called successful i In() \ Out() = ;, otherwise it is called
failed. is closed i every 2 D which is applicable to In() already occurs in . In() collects all formulae in which we believe after application of the defaults in , while Out() consists of all those formulas which we should avoid to believe for the sake of consistency. Let be a closed and successful process. Then, In() is called an extension of KB [ Env . Ext(KB [ Env ) denotes the set of all extensions of KB [ Env . Once again, let us note that whereas the semantics of nonmonotonic knowledge bases is given in the spirit of Reiter's default logic, the concept of extension introduced here is di erent because the underlying consequence relation for classical logic is di erent. This is done in order to use a rule A ! B only to infer B from A, but not :A from :B, as would be the case in default logic. Also, this is the reason why we have avoided the term \default theory" in this paper and have used the term \nonmonotonic knowledge base" instead.
4.3 Knowledge base dynamics
The set H of hypotheses in the nonmonotonic knowledge base KB is the set of consequents of defaults plus the set of all instances of consequents of rules. Formally: H 2 H i (9R 2 R : cons(R) = H ) or (9 2 D : cons( ) = H ). A literal H is an inferrable hypothesis of a knowledge base KB if there is an environment Env such that H is contained in some extension of KB[Env . A rule R is reable in an environment Env i there is an extension E of KB [ Env such that ante(R) E . A default is reable in an environment Env i there is an extension E of KB [ Env such that pre() E and just() [ E is consistent.
5 A formal presentation of anomalies In this section we present a variety of possible anomalies following the classi cation used in [9]. For some of the anomalies we additionally give formal 8
de nitions to demonstrate that in this paper we present a complete theoretical foundation of veri cation of nonmonotonic knowledge bases.
5.1 Redundancy: unsatis able condition
A rule R in R (or a default in D) contains an unsatis able condition if a literal in its antecedent uni es with neither an input literal nor with the consequent of another rule or default. Formally (here and in the following subsections, denotes a substitution):
9L 2 ante(R) : :((9I 2 I 9 : L = I) _ (9 2 D 9 : L = cons())_ (9 9R 2 R ? fRg : L = cons(R ) )) 0
0
9L 2 pre() : :((9I 2 I 9 : L = I) _ (99R 2 R : L = cons(R))_ (9 2 D ? f g : L = cons( ))) 0
0
5.2 Redundancy: unusable consequent
A rule R in R (or a default in D) contains an unusable consequent if its consequent uni es neither with a goal literal nor with a literal in the antecedent of another rule nor with a literal in the prerequisite of a default (other than ). Formally (for the case of R only):
:((9G 2 G 9 : cons(R) = G)_ (9 9R 2 R ? fRg 9L 2 ante(R ) : cons(R) = L )_ (9 2 D 9L 2 pre( ) : L = cons(R) )) 0
0
5.3 Redundancy: subsumed rule
A rule R in R is redundant if there is another rule R such that for some substitution we have R ! R . 0
0
5.4 Redundancy: subsumed default
A default = A1 ::: AnC:B1 ::: Bm in D is redundant if there is another default = A1 ::: An C:B1 ::: Bm in D such that C = C , fA1 ; : : :; An g fA1; : : :; Ang and fB1; : : :; Bm g fB1; : : :; Bmg. Informally, is redundant because when it is applicable, is also applicable and yields the same result. ^
0
0
^
^
^
0
^
0
0
^
^
^
0
0
0
0
0
0
0
0
9
0
0
0
5.5 Redundancy: redundant default
A default = A1 ::: AnC:B1 ::: Bm in D is redundant if there is a rule R in R and a substitution such that ante(R ) fA1; : : :; An g and cons(R ) = C . This means that R is capable of achieving the same as without consistency checks (and possibly with less antecedents). ^
^
^
^
5.6 Redundancy: redundant rule or default
This is the most general form of redundancy. A rule R or a default is redundant if the same set of extensions is achieved without the presence of R or . This form of redundancy includes all forms described above (but is far more dicult to detect; see next section). Formally:
8Env 2 ENV : E 2 Ext(KB [ Env) () E 2 Ext((KB ? fRg) [ Env) 8Env 2 ENV : E 2 Ext(KB [ Env) () E 2 Ext((KB ? fg) [ Env)
5.7 Ambivalence: ambivalent rule pair
A pair of rules R and R is ambivalent if the antecedents of R subsume those of R and their consequents infer a constraint C . Formally: 0
0
9 : ((ante(R) ! ante(R )) ^ fcons(R); cons(R )g 2 C ). 0
0
5.8 Ambivalence: ambivalent default pair
A pair of defaults and is ambivalent if the prerequisites of include those of , both defaults have the same justi cations, and their consequents infer a safety constraint. Formally: pre( ) pre( ), just( ) = just( ), and fcons(); cons( )g 2 SC . Note that here we only use safety constraints, whereas in 5.7 we additionally used eventuality constraints. The reason is that whereas rules are used in all extensions, defaults are possibly used only in some extensions. 0
0
0
0
0
5.9 Ambivalence
A knowledge base KB is ambivalent if there is an environment Env such that some extension E of KB[ Env violates a safety condition. The latter means that there is a substitution such that E contains all members of a safety constraint. Another form of ambivalence is that all extensions of KB [ Env 10
violate an eventuality condition. Formally, we say that an extension E violates a constraint C i C E for some substitution .
5.10 Inconsistency
A knowledge base KB is called inconsistent if it has no extension. KB is called potentially inconsistent if there is an environment Env such that KB [ Env has no extension.
5.11 Circularity: circular dependency
A knowledge base contains a circular dependency if there is a hypothesis H which uni es with the consequent of a rule R (or a default ), and R (resp. ) is rable only in environments that include H . This means that H depends on itself.
5.12 De ciency: unused input
This anomaly arises if, for some input literal I , I is neither a goal literal nor is it used in the prerequisite of a default nor does it unify with a literal in the antecedent of a rule.
5.13 De ciency: missing rule or default
This de ciency arises if there is no extension that includes some goal literal. In this case there may be extensions but they contain no useful information (by convention, useful information must be given in form of goal literals).
5.14 De ciency: contradictory default
A default is contradictory if :cons( ) 2 just( ). We discussed this case in section 3.
6 Use of veri cation methods for rule-based systems According to [9], existing anomaly detection procedures may be classi ed according to their computational complexity. First, there are simple integrity checks (e.g. [10]) which, roughly speaking, test the connectivity of the knowledge base, viewed as a directed graph. These methods have linear 11
complexity and may be extended to nonmonotonic knowledge bases, as illustrated in subsection 6.1. They detect anomalies like unsatis able conditions, unusable consequents and unused input. The next group are so-called rule checks that analyse pairs of rules (in classical systems); their complexity is quadratic. Some examples of such systems are [3, 7, 10]. This group of procedures may also be extended to treat defaults as well, as illustrated in subsection 6.2. Typical anomalies detected by such methods are ambivalent or redundant rules or defaults. The third group, rule extension checks, detect the more general anomalies and have to run the knowledge base at least to some extent. This means that they are intractable in the worst case. Nevertheless, experiments have shown that they are usable in restricted cases, or they show a good behavior based on heuristics. Some representative methods that t in this group are [5, 12, 13]. It is in this group that most work is necessary to treat nonmonotonic knowledge bases. New methods have to be developed and tested to detect anomalies like general inconsistency or ambivalence. Existence of extensions, safety and eventuality constraints are new issues that must be addressed. In particular, it is necessary to develop an understanding of which parts of the knowledge base may lead to, say, an ambivalent situation.
6.1 Integrity checking
Integrity checking comprises the computationally simplest checks for anomalies. Roughly speaking, it consists of a \walk through" the given knowledge tracing inference chains, looking for anomalies like unexpected dead ends. Anomalies that can be detected this way include unsatis able conditions, unusable consequents or unused input. The time complexity is linear to the number of rule instances and defaults. Several methods have been developed to detect such anomalies in rule{ based knowledge bases, COVER being one example. In such practical systems there are many restrictions concerning the expressive power of the rules. Usual restrictions are the existence of nitely many rule instances, and the use of attribute{discrete value pairs only. In the following we abstract from such details and give a generic framework for integrity checking in nonmonotonic knowledge bases; the changes are minimal and could be added to existing systems in a straightforward way. In the following a \walkthrough" starting from the output literals is realized. [A1; : : :; An ] denotes a list with n elements A1; : : :; An . 12
G
FOR all goal literals DO CALL CheckData([G],output) END; FOR all rule instances R DO IF R is unmarked THEN write(`Anomaly: unusable consequent in', R) END END; FOR all default instances DO IF is unmarked THEN write(`Anomaly: unusable consequent in', ) END END; FOR all input literals DO IF is unmarked THEN write(`Anomaly: unused input', ) END END
I
I
I
PROCEDURE CheckData(L: LIST of literal; S: source); BEGIN FOR all in DO IF is an input literal THEN mark ELSE BEGIN 0 determine the set of rule instances such that unifies with ( ); 0 determine the set of default instances such that unifies with ( );
A
A
L
A
R
A
R
cons R D
cons
13
A
R =;
;
D
0 AND = THEN IF S=output THEN write(`Anomaly: unobtainable output', ) ELSE write(`Anomaly: unsatisfiable condition', , `in', ) END END; 0 FOR all in DO BEGIN mark ; CALL CheckData (ante(R),R) END; 0 FOR all in DO BEGIN mark ; CALL CheckData(pre( ) ) END END
IF
0
A
A
S
R
R
R
D
;
END END;
7 Rule checking This class of methods checks pairs of rule or default instances, and detects anomalies like subsumed rules or defaults, or ambivalent rule or default pairs. Obviously the complexity is quadratic to the number of rule and default instances. Several systems have been developed for classical, rule{ based systems, for example [3, 7, 10]. Below we give a generic description of this kind of checking for nonmonotonic knowledge bases. Once again let us note that concrete systems have far simpler tests; for example, a rule pair may only be ambivalent if the two rules assign di erent values to the same attribute.
R
FOR all rule instances DO FOR all rule instances 0 DO
R
14
IF
R
R
subsumes THEN write(`Anomaly: subsumed rule', ) END; 0 IF ( ) is an ambivalent rule pair (see 4.6) THEN write(`Anomaly: ambivalent rule pair', , 0 ) END END; FOR all default instances DO IF ( ) ( ) AND ( )= ( ) THEN write(`Anomaly: redundant default', ) END END END; FOR all default instances DO FOR all default instances 0 DO IF ( )= ( 0 ) AND ( 0) ( ) AND ( 0) ( ) THEN write(`Anomaly: subsumed default', ) END; 0 IF the pair ( ) is ambivalent (see 4.7) THEN write(`Anomaly: ambivalent default pair', , 0 ) END END END 0
R
R; R
R R
ante R pre cons cons R
cons cons pre pre just just
;
8 Inconsistency in nonmonotonic knowledge bases As we have already pointed out, logical inconsistency of default knowledge bases means that there exists no extension. This situation is highly unde15
sirable since it means that the knowledge base can provide no information. There are though cases, where existence of extensions is guaranteed. One such case is when all defaults in the knowledge base are normal. A default is called normal if it has the form ' : (to be read: if ', then usually ). It is well known in the theory of default logic that normal default knowledge bases always have an extension. So, here we have a method that does not detect anomalies but even guarantees existence of extensions. Normal defaults are often too weak from the representational expressiveness point of view. In such cases, so-called semi-normal defaults have to be used; they have the form ': . Unfortunately, existence of extensions is not guaranteed in this case, but [4] has described a syntactic condition which does guarantee this. In the following we give an adapted version of Etherington's theorem (remember that we have restrictions on the set of facts, and we must take the forward chaining interpretation of rules in R into account). Given a literal L, we denote by L the literal :L, if L is a positive literal, and L , if L = :L and L is a positive literal. The (partial) relations and on literals occurring in KB are de ned as follows: 1. Bi A for each rule A B1 ^ : : : ^ Bn in R. 2. For each A1 ::: An :BB1 ::: Bm B in D (a) Ai B if Ai is not the formula true. (b) Bj B . 3. and are the least relations satisfying (a) conditions (1) and (2). (b) A B and B C implies A C (c) A B and B C implies A C (d) A B and B C implies A C (e) A B and B C implies A C KB is called ordered if there is no literal L such that L L. Note that orderedness is a syntactic condition in accordance to the veri cation principle 3 in section 2. Theorem. If KB is ordered then, for every environment Env, KB [ Env possesses at least one extension. ^
0
0
0
^
^
^
^
^
16
9 Conclusion We argued that veri cation and validation of nonmonotonic knowledge bases is an important topic that should be addressed. In this paper we restricted attention to default knowledge bases which are de ned as epxansions of rule-based knowledge bases. We presented a formal foundation for de ning and evaluating veri cation methods. In particular, we described some new classes of anomalies that are not found in classical systems, and discussed one such issue, namely the absence of extensions, in more detail. On the other hand, we scetched how existing methods may be used to deal with many of the anomalies de ned. Of course, there is much to be done to address veri cation of nonmonotonic knowledge bases. Existing methods have to be extended and evaluated, and new methods will have to be developed for some anomalies. We hope, though, that this paper establishes a background for such work to be carried out in the near future.
References [1] G. Antoniou. Nonmonotonic Reasoning. MIT Press 1997 (in press) [2] P. Cholewinski, W. Marek and M. Truszczynski. Default Reasoning System DeReS. In Proc. 5th International Conference on Principles of Knowledge Representation and Reasoning (KR'96), Morgan Kaufmann 1996 (in press) [3] B.J. Cragun and H.J. Steudel. A decision-table-based processor for checking completeness and consistency in rule-based expert systems. International Journal Man-Machine Studies 26(1987): 633{648 [4] D.W. Etherington. Formalizing Nonmonotonic Reasoning Systems. Arti cial Intelligence 31(1987) [5] A. Ginsberg. Knowledge-base reduction: A new approach to checking knowledge bases for inconsistency and redundancy. In Proc. 7th National Conference on Arti cial Intelligence (AAAI-88) [6] Z. Manna and A. Pnueli. The Temporal Logic of Reactive and Concurrent Systems. Springer 1992 17
[7] T.A. Nguyen, W.A. Perkins, T.J. La ey and D. Pecora. Checking an expert systems knowledge base for consistency and completeness. Proc. 9th International Joint Conference on Arti cial Intelligence, 1985 [8] H. Nonfjall and H.L. Larsen. Detection of Potential Inconsistencies in Knowledge Bases. International Journal of Intelligent Systems 7(1992): 81{96 [9] A.D. Preece and R. Shinghal. Foundation and Application of Knowledge Base Veri cation. International Journal of Intelligent Systems 9(1994): 683{701 [10] A.D. Preece, R. Shinghal and A. Bakarekh. Verifying expert systems: A logical framework and a practical tool. Expert Systems with Applications 5(1992): 421{436 [11] R. Reiter. A Logic for Default Reasoning. Arti cial Intelligence 13(1980): 81{132 [12] M.-C. Rousset. On the consistency of knowledge bases: The COVADIS system. Computational Intelligence 4(1988): 166{170 [13] R.A. Stachowitz, J.B. Combs and C.L. Chang. Validation of knowledgebased systems. In Proc. 2nd AIAA/NASA/USAF Symposium on Automation, Robotics and Advanced Computing for the National Space Program, Arlington 1987 [14] N. Zlatareva and A.D. Preece. State of the Art in Automated Validation of Knowledge-Based Systems. Expert Systems with Applications 7,2(1994): 151{167 [15] N. Zlatareva. Veri cation of non-monotonic knowledge bases. In Proc. IJCAI'95 Workshop on the Veri cation and Validation of KnowledgeBased Systems, 29{34
18