Our approach to automated configuration of problem solvers relies on exploiting the theory about problem solving methods from [ten Teije & van Harmelen, 1994] and [ten Teije & van Harmelen, 1996b]. In that work we have proposed a uniform representation of (the functionality of) problem solving methods. The central idea of this representation is that the functionality of a class of problem solving methods is captured in a single schematic formula. Some of the predicates and terms from that formula are regarded as parameters that must be further instantiated to capture different members of the class of problem solving methods. Thus, given a schematic formula that defines the functionality of a whole class of problem solving methods, different members of that class correspond to different definitions for the parameters occuring in the schematic formula.

It is exactly this uniform representation of an entire class of problem solving methods that will allow us in this paper to view the construction process of problem solving methods as a parametric design task. Since we will illustrate our theory about the configuration of problem solving methods with examples from diagnostic problem solving methods, we will now give our schematic definition of these diagnostic methods.

In general, a diagnostic problem arises if there is a discrepancy between the
observed behaviour of a system (e.g. an artifact) and how the system should
behave, in other words, the expected behaviour does not correspond with
reality. The diagnostic task is to find out the cause of this discrepancy. A
diagnostic method computes the solutions for a diagnostic problem by using a
model of the expected behaviour (the behaviour model, * BM*), the actually
observed behaviour * OBS*, and contextual information * CXT*. The
computed
solutions of a diagnostic problem represent an explanation for the observed
behaviour.

Our uniform representation of diagnostic problem solvers is based on the
following general account of their functionality:
An explanation distinguishes * two types of observations*: it covers some
observations, and it does * not contradict* other observations. The
explanation is restricted to a * vocabulary* of special candidates that
could be causes of a behaviour discrepancy (e.g. components). Usually we are
not interested in all possible explanations, but only the * most
reasonable* explanations. We also want to * represent* an explanation
as a
solution that a user can interpret. (For example, in medical domains, users
are usually interested in the disease, and not in all the current states of
the parts of the patient's body).

Together, these six aspects written in italics make up the particular notion of diagnosis that is realised in a given method. We can capure these general characteristics of a diagnostic method in the following formal definition:

When given as input the behaviour model * BM*, a context * CXT* and
a set of
observations * OBS*, a diagnostic method computes a set of solutions *
Sol*
such that:

Each of the six underlined terms is one of the parameters in our
representation of diagnostic methods. Varying one or more parameters amounts
to describing a different diagnostic methods. The * Obs-mapping*
determines
which observations must be explained (or: covered) , and which
need only not be contradicted (). *
E* is an explanation for the
observed behavoiur by covering some observations (), and not
contradicting others (). We write and as different symbols to emphasise that one is not
necessarily the negation of the other, and that neither is necessarily the
same as the classical entailment . *
E* is expressed in a particular
* Vocabulary*. We are interested in the most reasonable explanations,
determined by a * Selection* criterion. The * Solution-form*
determines the
representation of the final result of the method. The dependencies between
all these components of a diagnostic method is shown in figure
1

**Figure 1:** Components of diagnostic methods and their
relations.
Ovals are components, boxes are their inputs/outputs, thick boxes are
inputs/outputs of the entire method

In [ten Teije & van Harmelen, 1994], we show that we can formulate properties of this general schematic formula, as well as properties of instances of the schema. Such properties will be exploited in the configuration of methods. In [ten Teije & van Harmelen, 1996b] we have argued that this representation can in principle be applied to other families of methods than diagnostic methods, such as methods for monitoring, design, classification etc. As a result, we will claim that also our approach to the configurtion of methods is general, and could be applied to such other families of problem solving methods.

Fri Oct 4 13:40:35 MET DST 1996