Assumptions of Problem-Solving Methods Richard Benjamins and Christine Pierret-Golbreich University of Paris-Sud, LRI, Bat. 490 91405 Orsay Cedex, France Tel: +33-1-69416495, Fax: +33-1-69416586 E-mail:frichard,
[email protected] Abstract Assumptions of problem-solving methods refer to necessary applicability conditions of problem-solving methods, indicating that a problem-solving method is only applicable to realize a task, if the assumptions are met. In principle, such assumptions may refer to any kind of condition involved in a problem-solving method's applicability, including its required domain knowledge. In this paper, we propose a conceptual organization for assumptions of problem-solving methods and suggest a formal language to describe them. For illustration we take examples from the Propose & Revise problem-solving method and from diagnosis.
1 Introduction and motivation In the context of task-method frameworks [Puerta et al., 1992, Wielinga et al., 1992, Chandrasekaran et al., 1992, Steels, 1990, Pierret-Golbreich, 1994], tasks can be realized by applying problem-solving methods (Psms, methods). A task de nes what needs to be achieved (a declarative functional speci cation), and a Psm how it has to be achieved (an operational speci cation). This view introduces the problem of deciding when Psms can be applied to tasks: the applicability problem. A common view is that a Psm can be applied to a task in a particular domain if some conditions are satis ed. Such conditions can be exploited during knowledge engineering, where we are concerned with knowledgebased system (KBS) construction, and we have to decide which Psms to include in the KBS (static use). Applicability conditions are also useful during reasoning (dynamic use), where they can be exploited by a meta-level reasoner that dynamically selects Psms for tasks. In this paper, we are interested in conditions of Psms without committing ourselves to how they will be used. Several ways have been put forward to express applicability conditions. In Knowledge Engineering, examples include \task features" [Aamodt et al., 1992], assumptions [Akkermans et al., 1994, Fensel, 1995a], \suitability criteria" [Benjamins, 1995], \resources" and \process characteristics" [Pierret-Golbreich, 1994] and \method ontologies" [Gennari et al., 1994]. In dynamic reasoning, examples include \applicability conditions" [Vanwelkenhuysen & Rademakers, 1990, van Marcke, 1990], \additional knowledge of problem solving actions" [Reinders & Bredeweg, 1992], \resources" and \process characteristics"(again) [Pierret-Golbreich, 1994], \suitability criteria" (again) [Benjamins, 1993], and \sponsors" [Punch & Chandrasekaran, 1990]. 1
Whatever the terms used, in most approaches mentioned above, applicability conditions are not more than sets of labels that refer to some notion assumed to be known by its interpreter (knowledge engineer or KBS). Two things seem to lack: (1) a principled organization of the applicability conditions, and (2) a well-de ned language to express them in an unambiguous manner. In the rest of the paper, we will use the term assumption for applicability condition; a Psm is applicable only when its assumptions hold. Making assumptions of Psms explicit, helps us to decide whether a Psm can be (re)used in a particular situation. If we, in addition, formalize the conditions, then it becomes possible to nd out whether the assumptions of a Psm are provable from the knowledge of a particular application. In [Fensel, 1995b], it is proposed to formulate this proof obligation as:
domain knowledge ` PSMassumptions (1) where it is called the applicability proof of a Psm. Such proofs require a thorough insight in assumptions of Psms, a suitable formal speci cation language, and a proof calculus. The rst two form the aim of this paper. In the sequel, we will suggest a di erent formulation of proof obligation (1) based on an analysis of assumptions. There are other proof obligations in the context of the task-method framework (see Section 4.2), and formalizations of assumptions can be used in these proofs. In Section 2, we present a conceptual organization of assumptions which analyzes their horizontal (Section 2.1) and vertical inter-relationships (Section 2.2). Section 3 presents how sorted First-Order Predicate Logic (FOPL) can be used as a language to formalize assumptions. Some example formalizations are given from the \select-propose-check-revise" method (SPCR) as discussed in [Fensel, 1995a, Fensel, 1995b] (Section 3.1) and from diagnosis [Benjamins, 1993, Benjamins, 1995] (Section 3.2). Section 3.3 illustrates some proofs, and in Section 4 we describe related work. Finally, Section 5 concludes the paper.
2 A conceptual organization for assumptions As stated in the introduction, most work dealing with Psm assumptions considers them as an unorganized set of labels. In this section, we propose a conceptual organization to understand assumptions in a principled way. As will turn out, the organization provides several valuable insights. The organization consists of two parts: the rst concerns a horizontal organization of assumptions (Section 2.1) and the second a vertical organization (Section 2.2).
2.1 Horizontal organization of assumptions assumptions of Psms can be organized in a specialization hierarchy as shown in Figure 1. Epistemological assumptions refer to the domain knowledge required by the Psm for lling static input roles and dynamic input roles [Wielinga et al., 1992]. We divide epistemological assumptions further into two types. Availability assumptions refer to the availability of domain knowledge, for instance, a causal model. A causal model could be referred to by a static role of a Psm and can be described as a set of states ST related by causal relations: rcausal (st1; st2 ), where st1 ; st2 2 ST . To verify availability assumptions 2
assumption
epistemological
availability
pragmatic
teleological
property
FIGURE 1: A specialization organization of assumptions.
we have to prove that such concepts and relations exists in a particular application domain. For example, 9st1; st2 2 ST rcausal (st1 ; st2). An example of an assumption corresponding to a dynamic role, could be the availability of domain concepts that play the role of hypotheses in diagnosis. Property assumptions refer to properties of the domain knowledge, for instance, that a causal model is non-cyclic. Non-cyclicness is not a characteristic that can be veri ed by simply checking (at the object-level) the existence of some domain concepts and relations, but requires reasoning about the object concepts and relations. Pragmatic assumptions refer to Psm requirements related to the physical context or external environment in which the system operates. For instance, a method for testing hypotheses by measuring, requires that the device is accessible for measurements. Pragmatic assumptions often show up when a KBS interacts with its environment. Teleological assumptions relate to the goal to be achieved, that is, a functional speci cation. If such assumptions are not ful lled, then, although the Psm can be applied, the correctness of the solution with respect to the goal is not guaranteed or no solution can be found at all. For example, if the no-fault-masking assumption of the corroboration method in diagnosis does not hold, we possibly discard valid solutions (hypotheses) from consideration. Another example concerns the singlefault assumption of the intersection method. If this assumption is not ful lled, then the Psm might not be able to nd a solution at all. Other proposals to organize assumptions along with their relation to our work will be discussed in Section 4.1. Our organization is bene cial for several reasons. First of all, the organization gives a better understanding of what assumptions are. It goes without saying that we need to understand assumptions before we can formalize them. Second, the distinction between epistemological, pragmatic and teleological assumptions has implications for the applicability problem, and in particular for proof obligation (1), which we reformulate in light of the di erent assumption types to:
application knowledge ` PSMassumepist ^ PSMassumpragm ^ PSMassumteleol
(2)
We divide application knowledge into domain knowledge (relevant concepts and relations), task knowledge (the goal of a particular application, e.g., car diagnosis) and in external knowledge (characteristics of the speci c environment in which the system has 3
to operate, such as \device is accessible for measurements" in diagnosis). Given this division of application knowledge, we identify three proof obligations for a particular Psm. (2a) domain knowledge ` epistemological assumptions, (2b) external environment ` pragmatic assumptions and (2c) task knowledge ` teleological assumptions. Proof obligation (2a) can be mechanized in a particular domain, because epistemological assumptions refer to the availability and properties of the represented domain knowledge. Proof obligation (2b), on the other hand, cannot be automated. Whether a particular application satis es the pragmatic assumptions of a Psm, has to be externally guaranteed (e.g., by an expert). With respect to proof obligation (2c), we have to be more careful. We are currently investigating whether this proof can be established, based on a description of task knowledge in a speci c application. We have noted that teleological assumptions can sometimes be proved afterwards, but never in advance. For example, with regard to the single-fault assumption, once we have a solution, we can show (prove) that it is indeed a single fault. Table 1 and Table 2 give some assumption examples for respectively the SPCR-method and methods for diagnosis. Availability
network of propose rules
Epistemological Property
set of constraints over parameter values set of xes
Teleological
not more than one propose rule per parameter either propose rule or user input for each parameter not propose rule and user input for same parameter constraints de ne solvable problem xes are independent
Pragmatic
number of parameters is constant user gives complete parameter-value information property of solution is expressible as user is passive input provider constraints over parameters selection sequence of parameters does not in uence problem-solving process TABLE 1: Assumption examples for the Select, Propose, Check & Revise method.
Availability
simulation rule set fault-simulation rule set contributor set
Epistemological Property
fault behavior not constrained hypothesis-set related
Teleological
Pragmatic
no fault masking components replaceable single-fault assumption device accessible complete fault-simulation rule set independence of causes TABLE 2: Assumption examples of methods in diagnosis.
4
2.2 Vertical organization of assumptions Apart from the horizontal organization in the previous section, assumptions can also be organized along a vertical dimension. These relations are important for reasons of consistency, completeness and no redundancy when associating assumptions to Psms. If we want to (re)use a Psm in a particular domain, we have to know the assumptions that belong to it. We could represent them extensively, that is, enumerate all assumptions for each Psm. However, this easily leads to forgetting an assumption (incompleteness), to combining contradictory assumptions (inconsistency), and to representing the same assumption at several places (redundancy) where it could have been deduced. To overcome these problems, we propose to exploit vertical inter-relations between assumptions to automatically generate them. Tasks, Psms and inferences are organized in a task-method structure (see Figure 2). In such a structure, there are main and speci c Psms. Assumptions of high-level Psms are partly based on assumptions of lower-level Psms, tasks and inferences. For example in Figure 2, method3 is part of method1. Suppose that method3 makes assumption1, then method1 also makes assumption1. In general, assumptions of lower level Psms are propagated upwards to higher levels. Following this line of reasoning, we can distinguish between own assumptions of a Psm, propagated ones and abstracted ones. Propagated and abstracted assumptions can be generated automatically (Section 2.2.2 and 2.2.3), as opposed to \own" assumptions. task1 method1
task2
task3
method3 primitive inference1
method2
task4
task5
primitive inference1
method4
task6
primitive inference2
realized by method consists of subtasks or primitive inference
FIGURE 2: A task-method structure.
2.2.1 \Own" assumptions of Psms Most of the assumptions of a Psm are based on assumptions of its constituents (see Section 2.2.2). However, Psms also can have assumptions of their own which do not stem from one of their constituents. Such assumptions refer to speci c requirements introduced by the Psm and are related to its declarative functional speci cation (the Psmdec ). Suppose for example that we have a Psm for nding single-fault hypotheses based on multiple symptoms in a diagnosis application, and that this Psm consists of the inference \intersect". A teleological assumption of this method would be that the singlefault assumption holds. This assumption does not come from the intersect inference, because an intersection may contain any number of elements, and is therefore an \own" assumption of the method. 5
2.2.2 \Upward propagated" assumptions of Psms
A task-method structure (Figure 2) enables upward propagation of assumptions from lower levels to higher levels. Inferences are primitives and therefore have only own assumptions. Assumptions of inferences and Psms are propagated upwards to tasks and higher-level Psms. Respecting the character of the task-method structure (Figure 2), where a task may be realized by alternative methods (OR), and a method consists of subtasks/inferences (AND), the assumptions of any task or Psm can be expressed as a logical combination (AND/OR) of the assumptions of its constituents. A Psm adds the logical AND of the assumptions of its constituents to its own assumptions. A task has as assumptions the OR of the assumptions of its realizing Psms. Figure 3 shows an example of an AND/OR combination that speci es the assumptions of the model-based hypothesis generation method (MBHG-method) [Benjamins, 1993, Benjamins, 1995]. Note that in this case there are no pragmatic assumptions, because the Psm concerns only hypothesis generation, which requires no interaction with the environment. The gure is the output of Expass,1 a Prolog program which has been realized to experiment with assumptions. The combination represents the own and the propagated assumptions of the MBHG-method. The \non intermittency assumption" is an own assumption of the method. The method has three subtasks, of which the rst has one assumption (device model). For the second subtask there are three alternative Psms, which is re ected in the OR of three ANDs. The third subtask has three assumptions (the last AND). Control knowledge of a Psm may re ne the upward propagation process of low-level assumptions for assumptions concerning the availability of dynamic roles. For example, if control knowledge of a Psm assigns a particular inference as the starting inference, the assumptions of that inference are propagated to the Psm. However, if some inference I1 of a Psm is executed before inference I2, and the output of I1 is the input of I2 and the assumption A corresponds to the dynamic input of I2, then A is not propagated to the Psm because it will be made true by I1 during execution of the Psm. Of course, this is not valid for assumptions corresponding to static roles, because their content is unchangeable during problem solving. This consideration of control knowledge is not yet implemented in Expass, but it is similar to the propagation of process characteristics described in [Pierret-Golbreich & Talon, 1995] which has now been implemented in the Task prototype.
2.2.3 Abstracted assumptions of Psms
If the task-method structure is large, there is a risk that high-level Psms and tasks accumulate large collections of assumptions, which might obscure a clear overview of the assumptions. Instead, it might be possible to rephrase collections of low-level assumptions into (more abstract) high-level ones. The following formula, whose right-hand side has to be understood as a rewrite rule, captures this intuition.
consists ? of (z; [x1; : : : ; xn]) , ((x1 ^ : : : ^ xn) ! z ); where z is a high-level assumption and x1;:::;n represent the low-level ones. An example of such a composition rule in diagnosis is: consists-of(behavioral-fault-model, [simulation1 Experiments with Psm Assumptions. 6
AND( teleological : non_intermittency_assumption epist_avail : device_model OR( AND( teleological : independence_of_causes epist_avail : contributor_set ) AND( epist_prop : fault_behavior_not_constrained teleological : independence_of_causes epist_avail : contributor_set ) AND( teleological : single_fault_assumption epist_avail : contributor_set ) ) AND( epist_avail : fault_simulation_rules_of_components epist_avail: simulation_rules_of_components teleological : complete(fault_simulation_rules_of_components) ) )
FIGURE 3: The logical combination representing the assumptions of the MBHGmethod. \Teleological" refers to teleological assumptions, \epist-avail" denote availability assumptions of the epistemological type, and \epist-prop" denote property assumptions.
rules-of-components, fault-simulation-rules-of-components]), which allows us to deduce that behavioral-fault-model is an assumption of a Psm, if simulation-rules-of-components and fault-simulation-rules-of-components are assumptions of it. Figure 4 shows an example for the MBHG-method in diagnosis produced by Expass. The output presents (1) the \own" assumptions of the MBHG-method, (2) the abstracted assumptions generated by a composition rule (the example rule given above), (3) the collection of assumptions which are generated by the upward propagation process (after having processed the composition). Note that this overview of assumptions does not re ect the logical (AND/OR) structure as shown in Figure 3. Currently we are working on the identi cation of composition rules in the SPCR-method. An open question is whether the \own" assumptions of a Psm can be deduced automatically from the assumptions of inferences by using the propagation process and composition rules, or whether \own" assumptions are really additional assumptions, speci c to the Psm.
2.3 Additional organization In addition to the horizontal organization presented in Section 2, every assumption type can, in principle, be classi ed into hard and soft assumptions. All of the hard assump7
Own assumptions of: model_based_hypothesis_generation : teleological : non_intermittency_assumption
(1)
Abstracted assumption: epist_avail : behavioral_fault_model from: epist_avail : simulation_rules_of_components epist_avail : fault_simulation_rules_of_components
(2)
Propagated assumptions of: model_based_hypothesis_generation epist_avail : behavioral_fault_model epist_avail : device_model epist_avail : simulation_rules_of_components teleological : fault_behavior_not_constrained teleological : independence_of_causes epist_avail : contributor_sets teleological : single_fault_assumption epist_avail : at_least_one_set epist_prop : complete(fault_simulation_rules_of_components)
(3)
FIGURE 4: The assumptions for the MBHG-method after the composition process has been applied.
tions of a Psm have to be ful lled before a Psm is applicable; they are necessary. Soft assumptions can be relaxed, that is, if they are not ful lled the method still works, but less optimal or ecient (cf. the necessary and useful suitability criteria in [Benjamins, 1993]).
3 A language for assumptions So far, we have used descriptive names to denote assumptions. These names are labels which give some indication of what assumptions mean, but do not de ne them formally. We propose sorted First-Order Predicate Logic (FOPL) as the language to formalize assumptions. FOPL, because it has well-known properties and, so far, FOPL has been suf ciently expressive for our purpose. We use sorted logic because it makes formulae easier to read and reduces their length [Schmidt-Schau, 1989]. The arguments of function- and predicate-symbols may have di erent sorts (types), and constant- and function-symbols also have some type (sort). This extension is conservative in the sense that everything that can be expressed and deduced in FOPL can also be expressed and deduced in sorted FOPL. One contribution of the conceptual organization presented in Section 2 is that it distinguishes between provable and non-provable assumption types. We suggested that epistemological assumptions are provable from the domain knowledge, that pragmatic assumptions have to be guaranteed externally, and that the provability of teleological assumptions requires more investigation. An assumption is de ned as (,) a well-formed formula. To prove that an epistemological assumption holds, means to prove that its corresponding formula is valid in the context of the domain knowledge of a particular application. In formal speci cation languages, domain knowledge is commonly represented in mod8
ules or theories consisting of a signature and a set of axioms. The axioms specify, among others, the application domain knowledge (expressed in the language de ned by the signature). Thus the applicability proof for epistemological assumptions can be reformulated as: axiomsdomain knowledge ` PSMepistemological assumptions. The axioms and the assumptions have an object|meta relation to each other. The assumptions constitute the meta-level language to talk about the axioms at the objectlevel. We therefore need a naming connection (naming relation) between axioms and assumptions, that is, the elements of assumptions need to be mapped onto (groups of) axioms. For readability and simpli cation reasons, we use trivial naming relations (i.e., identical names at both levels). In the following, we rst will give some example formalizations of assumptions from the Select, Propose, Check & Revise Psm (Section 3.1) and from Psms for diagnosis (Section 3.2). Then, in Section 3.3, we will give examples of proofs of how assumptions logically follow from the axioms of some application domain.
3.1 Formalizations of assumptions of the SPCR-method In this section, we introduce the necessary de nitions for formalizing assumptions of the SPCR-method applied to the VT-domain [Yost, 1992]. In a sorted logic, we can have di erent types (sorts) of variables, functions and relations. Let V be a countable set of variables. Di erent sorts (types) of variables are distinguished in V . Let P be the set of variables of sort parameter. Let V be the set of variables of sort value, D the set of variables of sort dependency, C the set of variables of sort constraint, F the variable set of sort x and PList the set of variables of sort list of parameters. Let F be the set of functions farg; par; valg with arg : D 7! PList, par : D 7! P , val : P 7! V , and let user be a constant user :7! PList. Let R be the set of relations fassigned; affected ? by; p ? intern; p ? user; propose ? rule; user ? ruleg with assigned P , affected ? by P P , p ? intern P , p ? user P , propose ? rule D, and user ? rule D. Below we give the semantics for the arg and par functions of a dependency d.
8p 2 P 9dp 2 D 9Lp 2 PList arg(dp) = Lp ^ par(dp) = p:
(3) This axiomatization suces because at the meta-level we do not have to reason about the speci c dependencies and parameter values of the object-level, but we only need to know that there are dependencies between certain parameters2. The axiom giving semantics to the relation \a ected-by" between two parameters p and q is as follows:
affected ? by(q; p) , 9p; q; r 2 P 9d 2 D (q = par(d) ^ (p 2 arg(d)_ (r 2 arg(d) ^ affected ? by(r; p)))) (4) The relation assigned P is true for a particular p if and only if p a has a value: assigned(p) , 9v 2 V val(p) = v. The axioms giving semantics for the relations proposerule and user-rule are respectively: propose ? rule(d) , 9Lp 2 PList arg(d) = Lp ^ Lp 6= In the case that speci c assumptions need to know the precise relation between the parameter and the list of parameters of a dependency, it is possible to de ne a predicate compute D P PList, which explicates this relation. 2
9
user and user ? rule(d) , arg(d) = user. The axioms giving semantics for the relations p-intern and p-user are respectively: p?intern(p) , 9d 2 Dp = par(d)^propose?rule(d) and p ? user(p) , 9d 2 D p = par(d) ^ user ? rule(d). Equipped with this language, we can now formalize the assumptions, which are taken from [Fensel, 1995a, Zdrahal & Motta, 1995]. At the left side of the formulae, the type of assumption is indicated.
network-of-propose-rules
Assumption
A collection of propose rules (dependencies) associated with parameters needs to be available. This assumption states that there exists at least one such parameter { propose rule pair, otherwise there is nothing to select from. The structure of the \network" (see next assumption) is exploited to determine which pair to select. Since axiom (3) already states that a parameter is associated with at least one dependency, we reduce the assumption to the statement that D is not empty. For the sake of simplicity, we omit the semantics of a network. (1) (2) (3)
epistemological availability
network-of-propose-rules ,
9d 2 D
propose-network-is-non-cyclic
Assumption
The network of dependencies or propose rules should be cycle-free, that is, parameters should not depend directly or indirectly on themselves. This allows us to stratify the set of parameters to get an order in which they can be selected to propose values for them [Fensel, 1995a]. Strati cation means that each parameters gets a value re ecting on how many other parameters and propose rules it depends. Parameters given by the user have value zero. If a parameter depends on itself, it would never be selected. (4) (5) (6) (7) (8) (9)
epistemological property
propose-network-is-non-cyclic ,
8 p; q 2 P p= 6 q ^ p ? intern(p) ^ p ? intern(q) ^ affected ? by(p; q) ! :(affected ? by(q; p))
Where \a ected-by" is de ned in axiom (4).
Assumption
either-propose-rule-or-user-input-for-each-par
For each parameter there has to be either a propose rule or the parameter value is given by the user. 10
(10) (11) (12) (13) (14) (15) (16)
either-propose-rule-or-user-input-for-each-par ,
epistemological property
8p2P 9 dp 2 D
p = par(dp) ^ propose ? rule(dp) _ user ? rule(dp)
not-propose-rule-and-user-input-for-same-par
Assumption
It is forbidden to have a user input and a propose rule for the same parameter. This contributes to avoiding contradictions between values of parameters. epistemological property
(17) (18) (19) (20) (21) (22)
not-propose-rule-and-user-input-for-same-par ,
8p2P
p = par(d) ! :propose ? rule(d) _ :user ? rule(d)
not-more-than-one-propose-rule-per-par
Assumption
It is also forbidden to have two or more propose rules for the same parameter. Together with the previous assumption, this avoids contradictions between proposed values for parameters. epistemological property
(23) (24) (25) (26) (27)
not-more-than-one-propose-rule-per-par ,
8 d; d 2 D 0
par(d) = par(d ) ! d=d 0
0
Actually, this formalization is too simple [Fensel, 1995b]. In the VT-domain [Yost, 1992], there may be several propose rules for the same parameter [Fensel, 1995b], however, they will never be applied at the same time. For example, depending on the chosen motor, di erent propose rules for calculating the \peak" parameter have to be applied.
parameters-dependent
De nition
Two parameters p; q are dependent if either p is a ected by q, or q is a ected by p.
11
(28) (29) (30) (31)
de nition
parameters-dependent(p, q) ,
affected ? by(p; q) _ affected ? by(q; p)
parameters-independent
De nition
Two parameters p; q are independent if they are not dependent. (32) (33) (34)
de nition
parameters-independent(p, q) ,
:parameters ? dependent(p; q)
Where \parameters-dependent" is de ned in lines (29{31).
Assumption
user-gives-complete-par-val-information
Some parameter values have to be provided by the user. It is assumed that the user indeed provides values for all of these parameters, otherwise the Psm does not work. (35) (36) (37) (38)
pragmatic
user-gives-complete-par-val-information ,
8p2P p ? user(p) ! assigned(p)
3.2 Formalizations of Psms for diagnosis The formalizations presented are based on informal descriptions from literature on diagnosis and on [Benjamins, 1993, Benjamins, 1995]. In the example formalizations, we are concerned with model-based diagnosis, where the cause of a fault is identi ed by reasoning about a model of the device. A device model consists of components with simulation rules that calculate values of output parameters of components. Similarly to the SPCR-method, we can formalize assumptions of methods for diagnosis3 . The di erent sorts (types) distinguished in (the countable set) V include: P is the set of variables of sort parameter, SR the set of variables of sort set of simulation rules, O the set of variables of sort observation, PList the set of variables of sort list of parameters, Comp is the set of variables of type component , h (hypothesis) is the set of variables of type set of components , H (hypothesis set) is the set of variables of type set of h , and Integer is the set of variables of sort integer. Let F be the set of functions farg; par; cardg with arg : SR 7! PList, par : SR 7! P , and card : H 7! Integer. Let R be the set of relations faffected ? by; explains; g with affected ? by P P , explains H SR O, and H H . Let sr be the constant of sort SR which refers to the speci c set of simulation rules for the application. 3
We only de ne the symbols which are needed in the example formalizations.
12
The semantics for the arg and par functions for the simulation rules are identical to axiom (3) if we rename d to sr (see assumption \simulation rules of components"). affected ? by has been de ned in axiom (4). The relation explains is not de ned formally here, but expresses that a set of components (i.e, a hypothesis) is an explanation for some observations taking into account the simulation rules.
simulation-rules-of-components
Assumption
In order to do model-based diagnosis, we need to have a device model. In our case, this is a collection of simulation rules. epistemological availability
(39) (40) (41)
simulation-rules-of-components ,
9sr 2 SR
As one can notice, this is equal to the assumption \network-of-propose-rules" as de ned in lines (2{3), if we substitute d by sr. Actually, simulation rules can be considered as the dependencies or propose rules of the SPCR-method; both calculate values of parameters based on input parameters. This is the reason why we did not rede ne arg and par for diagnosis. They are already de ned in axiom (3).
hypotheses-related
De nition
A hypothesis h2 is a ected by another hypothesis h1 if a change in h1 leads to a change in h2. We already pointed out the similarity between dependencies (propose rules) and simulation rules. Parameters of simulation rules play the role of hypotheses in diagnosis, so hypotheses can be considered as parameters. This implies that we can use the \a ected-by" relation de ned between two parameters (axiom (4)) also between two hypotheses. The only di erence is that we have to substitute d with sr and p with h1 and q with h2. However, this correspondence between parameters and hypotheses is only true, if the hypotheses are single-fault hypotheses (formalized in lines (58{60)), because only in that case a hypothesis consists of one element (component), and the a ected-by relation is de ned between two elements. de nition
(42) (43) (44) (45)
hypotheses-related(h-1, h-2) , affected ? by(h1; h2) _ affected ? by(h2; h1)
Notice that this de nition is the same as \parameters-dependent" (lines (29{31)), and we could have used that one instead.
Assumption
hypothesis-set-related
This is an assumption of a Psm which discards a set of hypotheses based on the test result of one hypothesis. In order to do this, all hypothesis pairs in the hypothesis set have to 13
be related to each other. This assumption uses the de nition given in lines (43{45). (46) (47) (48) (49)
hypothesis-set-related , 8 hi ; hj 2 H
epistemological property
hypotheses ? related(hi; hj )
independence-of-causes
Assumption
This assumption is relevant in case of multiple faults. A multiple fault is a composite hypothesis, that is, a hypothesis consisting of several components. The assumption states that \an individual cause (component) explains a set of observations regardless of what other causes (components) are being considered." In other words, it means that if a hypothesis h explains some observations O taking into account the simulation rules SR and h h , then h also explains O. Remember that a hypothesis h is de ned as a set f components. 0
(50) (51) (52) (53) (54) (55) (56)
0
independence-of-causes ,
8 h; h 2 H 8o2O h h ^ 0
teleological
0
explains(h; sr; o) ! explains(h ; sr; o) 0
h should at least explain the same observations as h, but may explain more. 0
single-fault-assumption
Assumption
Single faults are hypotheses (i.e., sets of components) that contain exactly one element, that is, their cardinality is one. This assumption is relevant when multiple hypotheses (h: set of components) are intersected to nd a single-fault hypothesis. (57) (58) (59) (60)
teleological
single-fault-assumption ,
8h2H
card(h) = 1
3.3 Example proofs To prove the applicability of a Psm, we have to show that the logical combination (see Section 2.2.2) of its assumptions is provable from the domain knowledge of a particular application. To demonstrate the feasibility of our approach, we will show how to prove two assumptions of the SPCR-method: \not more than one propose rule per parameter" 14
and \propose network is non cyclic". The latter implies that we also have to prove the \a ected-by" de nitions. Prolog is used as the theorem prover, which requires that we translate the assumptions into Horn clauses. Although Horn clauses form a subset of full FOL, we encountered no diculties during the translation. The main di erences between the formalizations and the corresponding Prolog code are due to the fact that (1) the formalizations have only a declarative meaning, whereas Prolog has in addition a procedural meaning, and (2) all functions are translated in predicates as follows: an n-ary functions maps on a n+1-ary predicate. First, we will present a small example application domain with parameters, dependencies and arguments (see Figure 5 and below). user
u_i
i
d_e
e
d_d
d p
user
u_h
d_c h d_a
user
u_g
g
d_f
a
d_b
c
parameter with propose rule dependency
b
f
FIGURE 5: Graphical representation of example domain. % The parameters % -------------p(a). p(b). p(c). p(d). p(e). p(f). p(g). p(h). p(i). % The dependencies % ---------------d(d_a). d(d_b). d(d_c). d(d_d). d(d_e). d(d_f). d(d_g). d(d_h). d(d_i). % par(d_p, p) p = par(d_p): p is the parameter calculated by d_p. % --------------------------------------------------------------------par(d_a, a). par(d_b, b). par(d_c, c). par(d_g, g). par(d_i, i). par(d_f, f). par(d_e, e). par(d_d, d). par(d_h, h). % arg(d_p, Arg) Arg = arg(d): arg gives the list of parameters % i.e., the arguments of a dependency (propose rule). In case of a user % parameter, the argument is the atom "user". % --------------------------------------------------------------------arg(d_a, [h, f]). arg(d_b, [a]). arg(d_g, user). arg(d_d, [e]). arg(d_e, [i]). arg(d_h, user). arg(d_c, [d, b]). arg(d_f, [g]). arg(d_i, user). % A parameter's value is given by the user, if the parameter belongs % to a "dependency" whose argument is the user. If the argument is not % equal to "user", then the parameter is internal. %---------------------------------------------------------------------p_user(P):d(D), par(D, P), arg(D, user). p_intern(P):-
15
d(D), par(D, P), arg(D, PList), PList \== user. % Translation of axiom (4). Q is affected by P, if P is an element of % the arguments of Q, or if there is an argument of Q, R which is % affected by P. %-------------------------------------------------------------------affected_by(Q, P):aff_by(Q, P, [Q]). aff_by(Q, P, Visited):d(D), par(D, Q), arg(D, Args), ( member(P, Args) ; member(R, Args), not(member(R, Visited)), aff_by(R, P, [R| Visited]) ).
The list \Visited" is needed to prevent Prolog from running into an endless loop in case of cycles.
Assumption
not-more-than-one-propose-rule-per-parameter
The formalization of this assumption is given in lines (23{27). The corresponding Prolog code is given below. not_more_than_one_propose_rule_per_parameter:findall(P, (p(P), not(p_user(P))), PList), forall_p_only_one_d(PList). forall_p_only_one_d([]). forall_p_only_one_d([P1| Pn]):d(D), par(D, P1), findall(Dn, (d(Dn), Dn \== D), DList), p_is_not_par_dn(P1, DList), forall_p_only_one_d(Pn). p_is_not_par_dn(_, []). p_is_not_par_dn(P, [D1| Dn]):not(par(D1, P)), p_is_not_par_dn(P, Dn).
Assumption
propose-network-is-non-cyclic
The formalization of this assumption is given in lines (4{9). It refers to \a ected-by" whose Prolog code is given above (see also axiom (4)). The corresponding Prolog code is: 16
propose_network_is_non_cyclic:findall(P, p(P), PList), collect_all_pairs(PList, PairsList), forall_pairs_one_way_dependent(PairsList). collect_all_pairs(List, PairsList):findall([P, Q], (member(P, List), member(Q, List), Q \== P, p_intern(P), p_intern(Q)), PairsList). forall_pairs_one_way_dependent([]). forall_pairs_one_way_dependent([[P, Q]| PairsRest]):( affected_by(P, Q) -> not(affected_by(Q, P)) ; true), forall_pairs_one_way_dependent(PairsRest).
If we now ask Prolog to prove the two assumptions, we get: ?- not_more_than_one_propose_rule_per_parameter. Yes ?- propose_network_is_non_cyclic. Yes
If we change the propose network in such a way that there are several propose rules per parameter or that the network contains cycles, Prolog answers with \no".
4 Related work Relevant related work concerns alternative frameworks for understanding assumptions and other approaches to formalizing assumptions.
4.1 Organizations of assumptions Most approaches to Knowledge Engineering agree on the importance of required domain knowledge for deciding whether a Psm can be applied to realize a task [Steels, 1990, Chandrasekaran, 1990, Aamodt et al., 1992, Pierret-Golbreich, 1994, Gennari et al., 1994, Benjamins, 1995]. The epistemological task features in [Aamodt et al., 1992] are similar to our epistemological assumptions, the di erence being that task features describe a feature of the world, while assumptions refer to a requirement of a method. We make however a further distinction between availability and property assumptions. Pragmatic assumptions are reminiscent of the pragmatic aspect in [Steels, 1990], pragmatic task features in [Aamodt et al., 1992], and environmental suitability criteria in [Benjamins, 1995]. We have not found the equivalence of our teleological assumptions in the literature. We do think however that such assumptions are di erent from the other two categories (cf. Table 1 and Table 2), and currently we are investigating whether teleological assumptions are provable from a formal description of the application task goal. 17
4.2 Formalizations of Psms Within the context of the task-method framework [Puerta et al., 1992, Wielinga et al., 1992, Chandrasekaran et al., 1992, Steels, 1990, Pierret-Golbreich, 1994], other proof obligations can be identi ed (see [Fensel, 1995b, Fensel et al., 1995]).
PSMassumptions ^ PSMop ` PSMdec (5) Proof obligation (5) represents the correctness proof [Fensel, 1995b] of the Psm, that is, the declarative functional speci cation of the Psm (PSMdec ) is provable from the conjunction of its assumptions (PSMassumptions) and the Psm operational speci cation (PSMop ). PSMop describes the subtasks and the control knowledge of the Psm. In light of the Psm organization we have proposed this proof obligation could be re ned. Related work is reported in [Akkermans et al., 1994], which describe the constructive process of going from PSMdec to PSMassumptions ^ PSMop . Although they do not provide proofs, they provide signi cant insight in this relation. [Aben, 1995] shows proofs for parts of (5) in diagnosis, in particular for PSMop ` PSMdec . Thus assumptions are not considered. Control knowledge also is not considered. PSMdec ` taskgoal (6) Proof obligation (6) represents the relevance proof of a Psm for a task: we need to ensure that the functional speci cation of the Psm (PSMdec ) meets the task goal (taskgoal, which is also declaratively stated). The PSMdec must at least ful ll taskgoal , but might ful ll other things in addition. Related work concerns the Task approach [PierretGolbreich, 1994] and in particular the relation between the \task-module competence" and the \situation".
5 Conclusions Assumptions of Psms are a relatively new area in the eld of Knowledge Engineering. In such areas, theory development usually starts with an inductive phase, in which case studies are analyzed and generalized. This is the approach followed in this paper. Based on the literature and on experience with Psms for diagnosis and the Propose, Select, Check & Revise method, we have proposed an organization of assumptions which distinguished between three types: assumptions which refer to the required domain knowledge of a Psm (epistemological ); assumptions that refer to the pragmatic aspects of the application domain and environment (pragmatic); and assumptions that relate to the goal to be achieved (teleological ). Epistemological assumptions can be further divided into those referring to the availability of domain knowledge, and those referring to properties of domain knowledge. Further research is needed to see whether the proposed organization holds across other domains. A relevant conclusion for the knowledge engineering practice is that proofs of epistemological assumptions can be automated, while the truth of pragmatic assumptions has to be guaranteed externally (by a domain expert). The provability of teleological assumptions is still an open question, on which we currently are working. Whereas in the literature, so far, assumptions have been described informally (in natural language), we have shown how sorted First-Order Predicate Logic can be used to formalize them. The formalization allows us to de ne assumptions in a clear and unam18
biguous manner. We have demonstrated some proofs of assumptions of the Propose & Revise method, using Prolog. While formalizing, it turned out that some assumptions from di erent domains (i.e., diagnosis and Propose & Revise) appear to be identical when formalized. This was the case with assumptions about simulation rules and propose rules (dependencies), and about hypotheses and parameters. This is an interesting result because it suggests that some assumptions can be de ned in a domain-independent manner, which might facilitate their acquisition. However, we suspect many other assumptions to be domain speci c. More research is required to verify to what extent assumptions can be formalized in a domainindependent manner. In this paper, we have shown some formalizations of assumptions. The language proposed has been sucient for the examples, but further research is required to formalize other assumptions. For example, most of the assumptions formalized in this paper relate to the structure of the domain knowledge. An important issue regards the completeness of assumptions of a Psm. It is our intuition that we can only prove completeness as far as epistemological assumptions are concerned, excluding pragmatic and teleological assumptions. Moreover, we guess that epistemological assumptions of a Psm are complete if the correctness proof (proof obligation (5), Section 4) can be established [Fensel, 1995b]. Further research is, however, required to verify these intuitions.
Acknowledgment Dieter Fensel and Xavier Talon are acknowledged for discussions on some topics in this paper. We thank Manfred Aben for his LaTEX macros used in the formalizations. Richard Benjamins works with an institutional research fellowship of the Human Capital & Mobility program, nanced by the Commission of the European Communities.
References [Aamodt et al., 1992] Aamodt, A., Benus, B., Duursma, C., Tomlinson, C., Schrooten, R., & Van de Velde, W. (1992). Task features and their use in commonkads. Technical Report KADS-II/T1.5/VUB/TR/014/1.0, Free University of Brussels & University of Amsterdam & Lloyd's Register. [Aben, 1995] Aben, M. (1995). Formal Methods in Knowledge Engineering. PhD thesis, University of Amsterdam, Amsterdam. [Akkermans et al., 1994] Akkermans, J. M., Wielinga, B. J., & Schreiber, A. T. (1994). Steps in constructing problem-solving methods. In Gaines, B. R. & Musen, M. A., editors, Proceedings of the 8th Ban Knowledge Acquisition for Knowledge-Based Systems Workshop. Volume 2: Shareable and Reusable Problem-Solving Methods, pages 29{1 { 29{21, Alberta, Canada. SRDG Publications, University of Calgary. [Benjamins, 1993] Benjamins, V. R. (1993). Problem Solving Methods for Diagnosis. PhD thesis, University of Amsterdam, Amsterdam, The Netherlands. [Benjamins, 1995] Benjamins, V. R. (1995). Problem-solving methods for diagnosis and their role in knowledge acquisition. International Journal of Expert Systems: Research and Applications, 8(2):92. [Chandrasekaran, 1990] Chandrasekaran, B. (1990). Design problem solving: A task analysis. AI Magazine, 11:59{71.
19
[Chandrasekaran et al., 1992] Chandrasekaran, B., Johnson, T. R., & Smith, J. W. (1992). Task-structure analysis for knowledge modeling. Communications of the ACM, 35(9):124{137. [Fensel, 1995a] Fensel, D. (1995a). Assumptions and limitations of a problem-solving method: A case study. In Gaines, B. R. & Musen, M. A., editors, Proceedings of the 8th Ban Knowledge Acquisition for Knowledge-Based Systems Workshop, Alberta, Canada. SRDG Publications, University of Calgary. [Fensel, 1995b] Fensel, D. (1995b). A case study: Assumptions and limitations of a problemsolving method. International Journal of Human Computer Studies, (submitted). (Formerly Journal of Man Machine Studies). [Fensel et al., 1995] Fensel, D., Straatman, R., & van Harmelen, F. (1995). ADAM: Assumption driven adaption of problem-solving methods. Technical report, SWI, University of Amsterdam, Amsterdam. [Gennari et al., 1994] Gennari, J., Tu, S., Rotenfluh, T., & Musen, M. (1994). Mapping domains to methods in support of reuse. International Journal of Human-Computer Studies, 41:399{424. [Pierret-Golbreich, 1994] Pierret-Golbreich, C. (1994). TASK model: a framework for the design of models of expertise and their operationalization. In Gaines, B. R. & Musen, M. A., editors, Proceedings of the 8th Ban Knowledge Acquisition for Knowledge-Based Systems Workshop, pages 37.1{37.22. SRDG Publications, University of Calgary. [Pierret-Golbreich & Talon, 1995] Pierret-Golbreich, C. & Talon, X. (1995). An algebraic speci cation of the dynamic behavior of knowledge-based systems. In Gaines, B. R. & Musen, M. A., editors, Proceedings of the 9th Ban Knowledge Acquisition for Knowledge-Based Systems Workshop, Alberta, Canada. SRDG Publications, University of Calgary. [Puerta et al., 1992] Puerta, A., Egar, J., Tu, S., & Musen, M. (1992). A multiple-method shell for the automatic generation of knowledge acquisition tools. Knowledge Acquisition, 4:171{ 196. [Punch & Chandrasekaran, 1990] Punch, W. F. & Chandrasekaran, B. (1990). An investigation of the roles of problem-solving methods in diagnosis. In Proc. of the Tenth International Workshop: Expert Systems and their Applications, pages 25{36, Avignon, France. EC2. [Reinders & Bredeweg, 1992] Reinders, M. & Bredeweg, B. (1992). Strategic reasoning as a re ective task. In Proceedings of IMSA-92, pages 159{163. [Schmidt-Schau, 1989] Schmidt-Schau, M. (1989). Computational Aspects of an OrderSorted Logic with Term Declarations. Berlin, Germany, Springer-Verlag. Lecture Notes in Arti cial Intelligence No. 395. [Steels, 1990] Steels, L. (1990). Components of expertise. AI Magazine, 11(2):28{49. [van Marcke, 1990] van Marcke, K. (1990). A generic tutoring environment. In Aiello, L. C., editor, Proc. of the Ninth European Conference on Arti cial Intelligence, pages 655{660, London, UK. Pitman. [Vanwelkenhuysen & Rademakers, 1990] Vanwelkenhuysen, J. & Rademakers, P. (1990). Mapping knowledge-level analysis onto a computational framework. In Aiello, L., editor, Proc. ECAI{90, pages 681{686, London. Pitman. [Wielinga et al., 1992] Wielinga, B. J., Van de Velde, W., Schreiber, A. T., & Akkermans, J. M. (1992). The CommonKADS framework for knowledge modelling. In Gaines, B. R., Musen, M. A., & Boose, J. H., editors, Proc. 7th Ban Knowledge Acquisition Workshop, volume 2, pages 31.1{31.29. SRDG Publications, University of Calgary, Alberta, Canada.
20
[Yost, 1992] Yost, G. (1992). Con guring elevator systems. Technical report, Digital Equipment Corporation, 111 Locke Drive (LMO2/K11), Marlboro MA 02172. [Zdrahal & Motta, 1995] Zdrahal, Z. & Motta, E. (1995). An in-depth analysis of propose & revise problem solving methods. In Gaines, B. R. & Musen, M. A., editors, Proceedings of the 9th Ban Knowledge Acquisition for Knowledge-Based Systems Workshop, Alberta, Canada. SRDG Publications, University of Calgary.
21
