date: 28.4.98
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
1.14
1.15
1.16
1.17
1.18
1.19
1.20
1.21
1.22
1.23
1.24
1.25
1.26
1.27
1.28
1.29
1.30
1.31
1.32
1.33
1.34
1.35
1.36
1.37
1.38
1.39
1.40
1.41
1.42
1.43
1.44
Structured Development of Problem Solving Methods
Dieter Fensel1 and Enrico Motta2
1
Institute AIFB, University of Karlsruhe, Germany,
dieter.fensel@aifb.uni-karlsruhe.de, http://www.aifb.uni-karlsruhe.de/~dfe
2 Knowledge
Media Institute, The Open University, UK,
E.Motta@open.ac.uk, http://kmi.open.ac.uk/~enrico
Abstract. Problem solving methods are reasoning components, which specify
patterns of behavior which can be reused across applications. While the
availability of extensive problem solving method libraries and the emerging
consensus on problem solving method specification languages indicate the
maturity of the field, a number of important research issues are still open. In
particular, very little progress has been achieved on foundational and
methodological issues. Existing libraries of problem solving methods lack a
clear theoretical basis and only provide weak support for the method
development process, usually in the form of informal guidelines. In this paper
we will address these issues by providing a structured way for developing and
reusing problem-solving methods. We present a three dimensional problem
space that expresses the development process of problem-solving methods as
adaptations of their algorithmic scheme, their assumptions on domain
knowledge and their commitment to a task. The moves within this problem
space is achieved by adapters that externalize these adaptations. We can provide
a typology of these adapters by relating them to the dimensions in which they
adapt. Based on these means, reuse at different levels of refinement becomes
possible enabling manageable libraries of problem solving methods with large
horizontal and vertical cover. The paper provides several illustrations for our
approach taken from parametric design problem solving.
1 Introduction
Problem solving methods describe domain-independent reasoning components, which
specify patterns of behavior which can be reused across applications. For instance, propose
& revise ([Marcus et al., 1988]; [Schreiber & Birmingham, 1996]) provides a generic
reasoning pattern, characterized by iterative sequences of model “extension” and
-1-
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
2.25
2.26
2.27
2.28
2.29
2.30
2.31
2.32
2.33
2.34
2.35
2.36
2.37
2.38
2.39
2.40
2.41
2.42
2.43
2.44
“revision”, which can be reused quite easily to solve scheduling [Stout et al., 1988] and
design [Marcus et al., 1988] problems. Problem solving methods provide an important
technology for supporting structured development approaches in knowledge engineering:
they can be used i) to provide strong, model-based frameworks in which to carry out
knowledge acquisition ([Marcus, 1988]; [van Heijst et al., 1992]) and ii) to support the
rapid development of robust and maintainable applications through component reuse
([Runkel et al., 1996]; [Motta, 1997]; [Motta & Zdrahal, 1998]). A state of the art report on
problem-solving methods including some of their applications can be found in [Benjamins
& Fensel, 1998]. More in general, the study of problem solving methods can be seen as a
way to move beyond the notion of knowledge engineering as an “art” [Feigenbaum, 1977],
to formulate a task-oriented systematization of the field, which will make it possible to
produce rigorous handbooks similar to those available for other engineering fields.
So far, most of the research effort has focused on identifying and specifying problem
solving methods. As a result, several problem solving method libraries are now available
([Breuker et al., 1987]; [Marcus, 1988]; [Chandrasekaran et al., 1992]; [Puppe, 1993];
[Benjamins, 1995]; [Breuker & Van de Velde, 1994]; [O'Hara, 1995]; [Motta, 1997]) and a
number of problem-solving method specification languages have been proposed, ranging
from informal notations (e.g. CML [Schreiber et al., 1994]) to formal modeling languages
(see [Fensel & van Harmelen, 1994], [Fensel, 1995b] for surveys).
Currently two projects, one in Europe, IBROW3 [Benjamins et al., 1998], and one in the
US, High Performance Knowledge Bases [HPKB, 1997], have been set up with the aim
(among other ones) of enabling semiautomatic reuse of problem-solving methods. While
the availability of extensive problem solving method libraries and the emerging consensus
on problem solving method specification languages indicate the maturity and the “healthy
state” of the field, a number of important research issues are still open concerning the
development and reuse of problem-solving methods and their libraries: (1) There is
surprisingly minor work done that describes how to develop problem-solving methods and
how to adapt problem-solving methods for given domain and task-specific circumstances.
(2) In general, the relationship between problem-solving methods at the one side and
domain knowledge and task at the other hand is still a matter of debate. (3) How to achieve
manageable libraries of problem-solving methods with sufficient horizontal and vertical
cover is still an unsolved problem.
In our view these difficulties stem from three aspects of published libraries of problem
solving methods: they lack a clear theoretical basis, the components are only informally
specified and the method refinement operators are not explicitly represented. As a result, i)
it is difficult to characterize the coverage of a particular library (i.e. what is the space of
problem solving behaviors covered by a library); ii) it is difficult to compare and contrast
problem-solving methods associated with different tasks; iii) it is difficult to understand
how a problem-solving method was developed (and what alternative specifications are
feasible); iv) it is difficult to support automatic method selection and configuration, as
-2-
date: 28.4.98
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
3.20
3.21
3.22
3.23
3.24
3.25
3.26
3.27
3.28
3.29
3.30
3.31
3.32
3.33
3.34
3.35
3.36
3.37
3.38
3.39
3.40
3.41
3.42
3.43
3.44
envisaged in the IBROW3 project; and v) it is difficult to verify the properties of a library
formally.
In this paper we will address these issues by illustrating a framework which characterizes
problem-solving methods in terms of problem problem-solving paradigms, task
commitments, and domain knowledge assumptions. This framework provides i) a
theoretical foundation for situating problem-solving method research and individual
problem-solving methods, as well as ii) an organization which allows us to characterize
method development and selection as a process of navigating through a three-dimensional
space (defined by the three components of our framework). Individual moves through this
space are formally specified by means of adapters ([Fensel & Groenboom, 1996]; [Fensel,
1997]). In the rest of the paper we will illustrate these ideas in detail, with examples taken
from parametric design problem solving ([Schreiber & Birmingham, 1996]; [Motta &
Zdrahal, 1996]). The content of the paper is organized as follows. We characterize the
problems our approach is supposed to overcome in section 2. In section 3, we characterize
the three-dimensional problem space that structures the development process of problemsolving methods. We discuss a typology of adapters that are to achieve transitions in this
space in section 4. A case study on parametric design in reported in section 5. Finally we
briefly discuss related work and conclusions.
2 The Problem we Solve
In the following, we identify three significant problems that hamper the reuse of problemsolving methods:
(i)
There is surprisingly minor work done that describes how to develop problemsolving methods and how to adapt problem-solving methods for given domain and
task-specific circumstances.
(ii)
The relationship between problem-solving methods at the one side and domain
knowledge and task at the other hand is still a matter of debate. On the one hand
problem-solving methods should abstract from both to facilitate reuse. On the
other hand, a problem-solving method should provide stronger support in deriving
an application than highly generic general purpose search procedures.
(iii)
How to achieve manageable libraries of problem-solving methods with sufficient
horizontal and vertical cover is still an unsolved problem. With horizontal cover
we refer to the fact that a library should provide support for a broad class of
problems and reasoning strategies. With vertical cover we refer to the fact that
-3-
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
4.24
4.25
4.26
4.27
4.28
4.29
4.30
4.31
4.32
4.33
4.34
4.35
4.36
4.37
4.38
4.39
4.40
4.41
4.42
4.43
4.44
ideally a library should support the entire development process from abstract
conceptual models to implemented code that describe the problem-solving process
in much more detail.
We will discuss each of these problems and will sketch our proposal how to overcome
them. A more detailed discussion of our solutions are provided in the following sections.
2.1
Developing and Adapting Problem-solving Methods
Given the amount of literature that describes problem-solving methods and their use for
describing the reasoning behavior of knowledge-based systems it is rather surprising to see
how less work was done on how to develop (and adapt) problem-solving methods. In most
knowledge engineering frameworks (cf. PROTÈGÈ-II [Puerta et al., 1992]; Role-limiting
methods [Marcus, 1988], [Puppe, 1993]; COMPONENTS OF EXPERTISE [Steels, 1990];
GDM [Terpstra et al., 1993]; CommonKADS [Breuker & Van de Velde, 1994], [Schreiber
et al., 1994]; [Benjamins, 1995]; MIKE [Angele et al., 1998]) these methods are assumed to
be already provided. The only adaptation method discussed in the literature is a kind of
hierarchical refinement where a problem-solving method P decomposes a task T into
subtasks T1,...,Tn that are recursively solved by new problem-solving methods P1,...,Pn (see
Figure 1). However, this does neither answer the question of how to develop these method
that are used as refinements nor how to adapt them for specific aspects of the domain
knowledge, that is available as resource for the reasoning process, and the specific
commitments that a task may require.
An exception are the papers of [Akkermans et al., 1993] and [Wielinga et al., 1995] that
view the construction process of problem-solving methods for knowledge-based systems as
an assumption-driven activity. A formal specification of a task is derived from informal
requirements by introducing assumptions about the problem and the problem space. This
task specification is refined into a functional specification of the problem-solving method
by making assumptions about the problem-solving paradigm and the available domain
theory. Our approach will follow this general proposal. However, we will provide a much
more precise definition of (1) the different dimensions of this process, (2) the elementary
transitions, (3) how they can be taken, and (4) how the entire process can be uniformly
expressed as a number of transition in a three-dimensional problem space. Actually, in our
point of view developing problem-solving methods is an adaptation (or refinement)
process of a problem-solving methods in the direction of three dimensions: (1) the
algorithmic scheme or search paradigm a problem-solving method subscribes; (2) the
assumptions on domain knowledge that influence the definition of its elementary inferences
and competence; and (3) the (data-) structure a problem-solving method uses to describe its
input, intermediate states and output. The latter reflects the task-specific commitments a
method makes. The algorithmic scheme introduces explicit decomposition of tasks and
-4-
date: 28.4.98
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
5.17
5.18
5.19
5.20
5.21
5.22
5.23
5.24
5.25
5.26
5.27
5.28
5.29
5.30
5.31
5.32
5.33
5.34
5.35
5.36
5.37
5.38
5.39
5.40
5.41
5.42
5.43
5.44
Problem type
Decomposition-Method-1
Task-1-1
.........................
Task-1-m
`
....
Primitive-Method-1-1-1 Decomposition-Method-n-1-1
Task-n-1-1-1
........
Primitive-Method-n-1-1-1-1
Fig. 1
Decomposition-Method-n
Task-n-1
Primitive-Method-n-1-1
`
Task-n-1-1-k
Primitive-Method-n-1-1-k-1
Generic structure of task-method hierarchies
introduce a defined control on top of them. Both aspects are treated rather vague in the
above mentioned approaches and it remains unclear how tasks can be decomposed without
such means.
2.2
Bypassing the interaction problem and the usability-reusability
trade-off
Problem-solving methods should describe reusable reasoning patterns. This reusability is
achieved via abstraction from different sources of “noise”: implementation aspects, domain
aspects, and task aspects. [Clancey, 1985] reported on the analysis of a set of first
generation expert systems developed to solve different tasks. Though they were realized
using different representation formalisms (e.g. production rules, frames, LISP) and applied
in different domains, he discovered a common problem solving behavior. Clancey was able
to abstract this common behavior to a generic inference pattern called heuristic
classification, which describes the problem-solving behavior of these systems on an
abstract level. When considering the problem-solving method heuristic classification in
some more detail (see Figure 2) we can identify the three basic inference actions abstract,
heuristic match, and refine. Furthermore, four knowledge roles are defined: observables,
abstract observables, solution abstractions, and solutions. It is important to see that such a
description of a problem-solving method is given in a generic way. Thus the reuse of such a
problem-solving method in different domains (and possible tasks) is made possible.
-5-
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6.14
6.15
6.16
6.17
6.18
6.19
6.20
6.21
6.22
6.23
6.24
6.25
6.26
6.27
6.28
6.29
6.30
6.31
6.32
6.33
6.34
6.35
6.36
6.37
6.38
6.39
6.40
6.41
6.42
6.43
6.44
abstract
observables
heuristic
match
abstract
refine
observables
solutions
inference action
Fig. 2
solution
abstractions
role
The problem-solving method heuristic classification.
However, in the following we discuss a couple of problems that arise in the course of this
approach to reuse.
Problem-solving methods abstract from the domain. The interaction problem [Bylander
& Chandrasekaran, 1988] states that domain knowledge cannot be represented
independently of how it will be used in reasoning. Vice versa, a problem-solving method
and its specific variants cannot be constructed independently of assumptions about the
available domain knowledge. Developing reusable problem-solving methods as well as
reusable domain theories requires the explicit representation of the assumptions about the
domain knowledge of the method and the explicit representation of properties of the
domain knowledge that can be related to these assumptions. [Stefik, 1995] analyzes a
number of classification methods and shows how they differ in the type and properties of
domain knowledge they require. [Motta & Zdrahal, 1996] analyze the knowledge
requirements of different methods for parametric design. We will illustrate this aspect with
a simple example taken from [Fensel, 1995b] who provides a detailed analysis of propose
& revise. In the propose step, a model of an artifact is extended. This extension is
performed by using domain knowledge. If a method can assume that there is always one
possible further extension operator it can directly apply this operator. Otherwise, it needs
first a select step that, based on some additional assumed preference knowledge, determines
the next selected extension operator. Further assumptions on the completeness, correctness
and utility of the extension knowledge influences competence and control flow of the
method (see [Fensel, 1995b] for more details).
In consequence, abstracting from the application domain is necessary for enabling reuse of
reasoning patters. However, it must be accompanied with support in efficiently refining
these reasoning patterns reflecting the available knowledge sources and their specific
-6-
date: 28.4.98
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
7.12
7.13
7.14
7.15
7.16
7.17
7.18
7.19
7.20
7.21
7.22
7.23
7.24
7.25
7.26
7.27
7.28
7.29
7.30
7.31
7.32
7.33
7.34
7.35
7.36
7.37
7.38
7.39
7.40
7.41
7.42
7.43
7.44
properties.
Problem-solving methods abstract from the task. A task defines the goal that must be
achieved by a problem-solving method. In terms of software engineering, a task describes
the required functionality of a system. In that sense, problem definition would be a better
term (see [Breuker, 1997]). However we will follow the established naming convention of
the knowledge engineering community. Often, a task also defines subtasks and define some
control regime. However, we will discuss this as provided by a problem-solving method
and do not view it as a part of the task. That is, we use the term task in the sense of
[Chandrasekaran et al., 1992]. Problem-solving methods were introduced in the literature as
specialized task-specific reasoning mechanisms (cf. [Chandrasekaran, 1986]). The were
called strong methods by [Marcus, 1988] because the make stronger assumption that may
restrict their applicability but improve their support in cases where their assumptions are
fulfilled. So-called weak methods (generic search algorithms like depth first search, breathsearch etc., see [Bundy, 1990]) are in principle applicable to any type of task however
require significant effort in adapting them and do not provide much support in acquiring the
required knowledge (cf. [Eriksson et al., 1995]). However, the literature on problemsolving methods is full of worries about the relationship between tasks and problem-solving
methods at the one side and problem-solving methods and search algorithms at the other.
For example, [Linster, 1994] reports a simple assignment task that was used as common
case study in knowledge engineering where this task were solved by different research
groups. It turned out that a variety of different problem-solving methods could be applied to
this task (for example, [Gaines, 1994] applied a classification method and [Allemang &
Rothenfluh, 1992] reports that even within one library of problem-solving methods
different ones could be applied). Vice versa, propose & revise that was introduced in
[Marcus, 1988] as method for parametric design can in principle also be applied to design
problem-solving in general or other types of tasks. Its generic algorithmic scheme assumes
two different problem-solving modes: extending an artifact (it may be a diagnosis) and
correcting an artifact (it may again be a diagnosis). Both steps are not committed to a
specific type of task. A problem with the use of task-specific conceptualizations is that, in
some cases, these can make it difficult to understand what a problem-solving method
actually does. For instance, [Motta & Zdrahal, 1996] discuss the competence of a number
of propose & revise problem solvers and show that differences in their competence can be
accounted for by formulating them as search algorithms and comparing their state-selection
strategies. Interestingly, this problem seems to be specular to the one reported by [Clancey,
1985], which complained about the "blinding effect" of the implementation terminology
used in rule-based systems, which made understanding the problem solving competence of
these systems much more difficult.
In consequence there seems to be an n:m relationship between problem solving methods
and tasks (different methods can be applied to a task and a task can be solved by different
methods). However, often this reuse across task boundaries is hampered by task-specific
commitments of a method that limits their reusability and that produces mismatches with
-7-
8.1
8.2
8.3
8.4
8.5
8.6
8.7
8.8
8.9
8.10
8.11
8.12
8.13
8.14
8.15
8.16
8.17
8.18
8.19
8.20
8.21
8.22
8.23
8.24
8.25
8.26
8.27
8.28
8.29
8.30
8.31
8.32
8.33
8.34
8.35
8.36
8.37
8.38
8.39
8.40
8.41
8.42
8.43
8.44
other tasks even in cases where its general problem-solving strategy would fit well. [Beys
et al., 1996] renewed the idea of presenting problem-solving methods task-neutral to
overcome this mismatch problem. Following [Clancey, 1992], problem solving methods
should be described in terms of set and graph operators manipulating abstract models.
However, this loses all the support in directly applying a problem-solving method to a
problem in cases it fits well.
[Klinker et al., 1991] generalized this circumstance to what they called the usabilityreusability trade-off of problem-solving methods. As more task-specific a method is as
more support for developing an application it can provide, however, it limits its reusability.
Vice versa, as less task-specific a method is as less support for developing an application it
can provide, however, it extends its reusability. In our article, we show that this dilemma
can easily be solved by providing three elements: First, abstract algorithmic schemes that
describe the problem-solving paradigm of problem-solving method. These schemes
correspond to generic search methods and are free of task-specific commitments. Second,
support is provided to refine this schemes according to task specific circumstances. For
example, [Eriksson et al., 1995], [Fensel et al., 1996a] analyze the task-specific refinement
of problem-solving methods. The generic search method chronological backtracking is
refined to a task-specific method for one-player board games by introducing additional
ontological commitments that are used to describe the input. intermediate states, and output
of the method. This ontological commitments can further be used to refine the definition of
the state transitions of the method because the vocabulary for describing the states has been
enriched. Third, externalizing this adaptation is the key that enables reuse at different levels
of refinement. The method can still be used without the refinement for different tasks, the
method plus refinement and its stronger support can be used in case it fits, and last but not
least, the externalized refinement can be reused to specialize different methods. The
refinement reported in [Eriksson et al., 1995] can also be used to refine breadth-first search,
for example, if it is kept separate. We will use adapters [Fensel & Groenboom, 1997] for
the external specifications of refinements.
Problem-solving methods abstract from the implementation. Problem-solving methods
range from implemented building blocks [Puerta et al., 1992] to textual descriptions
[Breuker & Van de Velde, 1994]. Again, we encounter a usability-reusability trade-off. A
implemented building block make strong commitments on the environment it can be used.
However, it provides actual reasoning support whereas the problem-solving methods of the
CommonKADS library [Breuker & Van de Velde, 1994] provide tutorial material that
helps the knowledge engineering in implementing the reasoner. That is, no implemented
reasoning service is provided and the missing level of detail of natural language
descriptions strongly limits is usability. There are as many meanings for a specification as
there are readers, and it is a question of text interpretation as to whether a specification is as
intended for a system. The ambiguity of such conceptual models in a Knowledge
Engineering context was aptly illustrated by Aben's analysis of the use of a single inference
step from the KADS framework in a number of papers in [Bauer & Karbach, 1992]. Aben
-8-
date: 28.4.98
9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.8
9.9
9.10
9.11
9.12
9.13
9.14
9.15
9.16
9.17
9.18
9.19
9.20
9.21
9.22
9.23
9.24
9.25
9.26
9.27
9.28
9.29
9.30
9.31
9.32
9.33
9.34
9.35
9.36
9.37
9.38
9.39
9.40
9.41
9.42
9.43
9.44
[Aben, 1995] states that out of nine papers that use the abstract inference step, only one
author uses it in correspondence with Abens understanding of the original definition in
[Breuker et al., 1987], p.37. Most of the other papers use different versions of the inference
step, even including versions with different numbers of input arguments.
Using platform-independent languages and protocols (for example, Java and CORBA, cf.
[Gennari et al., 1996]) helps to extend the scope where actual implementations of problemsolving methods can be reused. However, implementations of problem-solving methods
necessarily hardwire task- and domain-specific circumstances at a high level of detail. In
consequence, we require an implementation architecture that is based on adaptable
components when we want to provide highly usable and reusable building blocks.
2.3
Manageable libraries of problem-solving methods with broad
horizontal and vertical cover
At the moment nobody knows how to develop libraries of problem-solving methods that
are manageable and that provide a large vertical and horizontal cover. With vertical cover
we refer to the fact that ideally a library should cover the entire development process of
problem-solving methods providing description at a conceptual level, a formalization that
adds preciseness and an implementation that adds executability. With horizontal cover we
refer to the problems that can successfully be tackled by methods of the library. The
original KADS library had one problem-solving method per problem type (all in all there
were less than twenty problem-solving methods mentioned in [Breuker et al., 1987]). After
a number of years in collecting experience with problem-solving method the
CommonKADS library of [Breuker & Van de Velde, 1994] provides an order of magnitude
more problem-solving methods. Already this textbook style description of problem-solving
methods provides hundreds of methods. None of this methods is implemented and
providing these implementations would again increase the number of methods an order of
magnitude because of the additional level of details and therefore distinctions.
The mentioned problem of numerical explosion when trying to enumerate all problemsolving methods is deeply routed in what is expected by them. The must enable efficient
reasoning service by making strong assumptions on the available domain knowledge (cf.
[Fensel & Straatman, 1998]) and they must make strong commitments to the task to
efficiently develop the knowledge-based system (cf. [Eriksson et al., 1995]). Introducing a
large number of assumptions and commitments immediately leads to numerical explosion
when trying to enumerate all variants. Take the already mentioned propose & revise and its
application to the configuration of a vertical transportation system (VT-domain, cf.
[Marcus et al., 1988], [Schreiber & Birmingham, 1996]) as example. Solutions to this
problem where we participated are reported in [Motta & Zdrahal, 1996] and [Poeck et al.,
1996]. In [Fensel, 1995a], we analysed the solution of [Poeck et al., 1996] in more depth
-9-
10.1
10.2
10.3
10.4
10.5
10.6
10.7
10.8
10.9
10.10
10.11
10.12
10.13
10.14
10.15
10.16
10.17
10.18
10.19
10.20
10.21
10.22
10.23
10.24
10.25
10.26
10.27
10.28
10.29
10.30
10.31
10.32
10.33
10.34
10.35
10.36
10.37
10.38
10.39
10.40
10.41
10.42
10.43
10.44
having the goal of deriving a precise and reusable specification of propose & revise.
However, we encountered a number of difficulties. First, propose & revise makes a great
number of very strong assumptions for solving the given configuration problem. Different
variants of propose & revise can be identified according to the precise definition of these
assumptions. These assumptions influence the definition of elementary inferences as well
as the control and competence of the method (see [Zdrahal & Motta, 1995]). We identified
numerous variations of propose & revise. None of them could be determined to be the gold
standard of this method. Therefore, hardwiring all assumptions of one variant in a specific
operational description with a fixed competence may lead to non-reusable problem-solving
methods. Actually, this was the experiences of many shell developers who derived shells
from some applications and encountered serious problems when trying to apply it to new
and slightly different tasks and domains. Putting all possible variants of propose & revise
into the library also does not look very promising given the large number of different
variants. Propose & revise is only one method. Applying this strategy to all problemsolving methods would result in a nearly infinitely large library.
In consequence, there seems to be only one reasonable strategy: (1) Identifying generic
patterns from which the numerous variants can be derived by adaptation and (2) providing
support that simplifies the necessary adaptation process. This will provide a way for
designing manageable libraries with broad horizontal and vertical cover. Externalizing
adaptation is the key factor in component-based development of problem-solving methods.
A simple illustration should clarify the point. Assuming n search strategies and m problem
types. Without adapters n*m components would be necessary to cover all these
combinations. By using adapters only n+m components are necessary. The effect of
adapters becomes even more obvious when taking a closer look at search methods on the
one hand, and task- and domain-refinements on the other hand.
• A local search algorithm has four main parameters that determine its search character
[Graham & Bailor, 1996]: the selection of start nodes, the generation of successors
nodes, the selection of better nodes, and the definition of the preference relation.
Different values for these parameters distinguish between, e.g., best-first search, hillclimbing and beam search. Keeping the more precise definitions of these parameters
externally of the core definition of the method, enables to provide a large variety of
search methods with a small number of components.
• The definition of a task may be less or more specific. A parametric design task can be
defined by a design task that is refined to configurational design (where the elements of
the artifact are given) and further on to parametric design (where in addition the
structure of the artifact, i.e. the selection of the components is given).
Implementing a component for each variation of a search method or each task- and domainspecific refinement is intractable. A tractable and structured approach for reusing (usable)
components can only be achieved by performing refinements via adapters and
- 10 -
date: 28.4.98
11.1
11.2
11.3
11.4
11.5
11.6
11.7
11.8
11.9
11.10
11.11
11.12
11.13
11.14
11.15
11.16
11.17
11.18
11.19
11.20
11.21
11.22
11.23
11.24
11.25
11.26
11.27
11.28
11.29
11.30
11.31
11.32
11.33
11.34
11.35
11.36
11.37
11.38
11.39
11.40
11.41
11.42
11.43
11.44
implementing different aspects or degrees of refinement by different adapters. Thus, a
refined method is achieved by connecting to it a pile of adapters.
3 The Problem Space
A problem-solving method is a task-specific refinement of a search method that makes
strong assumptions on domain knowledge. In consequence we get a three-dimensional
problem space (see Figure 3) in which we will move with adapters. During the following
we will first characterize these dimensions and then illustrate several moves in this space.
• Problem-solving paradigm. This is a high-level description which specifies a type of
problem solving rather than an actual algorithm. A problem-solving paradigm fixes
some basic data structures, provides an initial task-subtask decomposition and a generic
control regime. This generic control regime is meant to be common to all problemsolving methods which subscribe to the same problem solving paradigm. Such schemes
are necessarily vague in the sense that they define only a basic control regime and some
very basic data structures required by this regime. Examples of problem solving
paradigms are: generate & test, local search and problem reduction ([Smith & Lowry,
1990]). An important hypothesis in AI is that all intelligent problem solving can be
characterized as a search process [Newell & Simon, 1976]. If this hypothesis is adhered
to, then problem-solving methods can be characterized as specializations of the search
paradigm.
• Domain knowledge assumptions. These are assumptions on the domain knowledge
that is required to instantiate a problem-solving method in a particular application.
Problem
-solving
paradigm
global or local search?
Problem (i.e., task) commitments
Design or Diagnosis?
Fix knowledge and with what power?
Domain knowledge assumptions
Fig. 3
The three-dimensional problem space.
- 11 -
12.1
12.2
12.3
12.4
12.5
12.6
12.7
12.8
12.9
12.10
12.11
12.12
12.13
12.14
12.15
12.16
12.17
12.18
12.19
12.20
12.21
12.22
12.23
12.24
12.25
12.26
12.27
12.28
12.29
12.30
12.31
12.32
12.33
12.34
12.35
12.36
12.37
12.38
12.39
12.40
12.41
12.42
12.43
12.44
These assumptions specify the types and the properties of the knowledge structures
which need to be provided by a domain model, in addition to those required to
instantiate a task ontology. For instance, when solving a design problem by means of
propose & revise, a domain needs to provide the knowledge required to express
procedures and fixes, in addition to the knowledge needed to formulate the specific
design problem—e.g. parts and constraints. Domain assumptions are necessary to
enable efficient problem solving for complex and intractable problems ([Fensel &
Straatman, 1998], [Fensel & Benjamins, 1998]). The reliance on such domain-specific
knowledge is the defining feature of knowledge-intensive approaches to problem
solving.
• Problem (i.e., task) commitments. These specify ontological commitments to the type
of problem that is solved by the problem-solving method. These commitments are
expressed by subscribing to a particular task ontology. A task ontology specifies a task
in terms of initial and goal states in the universe of discourse and introduces the
terminology necessary to express task-specific commitments. The ontological
commitments introduced by a task (in particular, by a problem type) can be used to
refine the competence of a problem-solving method, the structure of its computational
state and the nature of the state transitions it can execute (cf. [Eriksson et al., 1995],
[Fensel et al., 1996a], [Fensel et al., 1997]). For instance, a generic search method can
thus be transformed into a more specific method for model-based diagnosis or
parametric design. A task-specific refinement of a method is still reusable because it is
formulated independently of any domain. That is, the method may be applicable to
technical or medical diagnostic problems. However, it is limited to a specific class of
tasks. The advantage of refining problem-solving methods in a task-specific way is that
the resulting model provides much stronger support for knowledge acquisition and
application development than a task-independent one.
Figure 3 presents each of the three dimensions by an arrow which would imply a total order
of the elements of the design space for each dimension. Given two elements e1 and e2
always e1 must be derivable from e2 via several refinement steps or vice versa. However,
different tasks like diagnosis or design and different problem solving schemes like like
local search or search by pruning (e.g. branch and bound) may not be derivable from each
other. Still, they can both be derived from more abstract definitions. In consequence, each
dimension is defined by an acyclic graph. The graph is defined by the refinment
relationship between the elements of the design space and reflects the partial order defined
by refinements. Because we focus in the examples used in the paper on one type of task and
one type of problem-solving scheme these graphs collapses into total ordered ones.
Clearly identifying and separating the problem-solving Paradigm, domain Assumptions,
and problem Commitments enables a principled way to developing a problem-solving
method and structuring libraries of problem-solving methods. Current approaches to
problem- solving methods usually merge these different aspects, thus limiting the
- 12 -
date: 28.4.98
13.1
13.2
13.3
13.4
13.5
13.6
13.7
13.8
13.9
13.10
13.11
13.12
13.13
13.14
13.15
13.16
13.17
13.18
13.19
13.20
13.21
13.22
13.23
13.24
13.25
13.26
13.27
13.28
13.29
13.30
13.31
13.32
13.33
13.34
13.35
13.36
13.37
13.38
13.39
13.40
13.41
13.42
13.43
13.44
possibilities for reuse, obscuring the nature of the methods, and making it difficult to
reconstruct the process which led to a particular problem-solving method specification. In
the PAC-framework, the development and adaptation of problem-solving methods is
characterized as a navigation process in this three- dimensional space. The nature of the
navigation process itself differs with respect to the dimensions of the development process.
Moves through the three-dimensional space are represented by means of adapters. They are
needed to refine the different terminologies associated with task, method and domain
specifications. A typology of adapters will be provided in the next section. Now, we will
provide a couple of examples of moves in the problem space we defined. We will show (see
Figure 4):
(1)
We start with a generic search scheme as algorithmic scheme.
(2)
We refine the generic search scheme to local search (i.e., we refine problem
solving).
(3)
We start with a generic optimization problem.
(4)
We refine the optimization problem solving to the design problem (i.e., we add
problem commitments).
(5)
We refine the task design to parametric design (i.e., we add problem
commitments).
(6)
We instantiate the local search problem scheme for optimization. We do this in two
steps. We refine local search so that it guarantees to find local optima (6.1) and we
introduce an assumption on domain knowledge to ensure global optimal results
(6.2 (a)). We discuss why a transition without assumptions on domain knowledge
(i.e., (6.2 (b))) may miss the gist of problem-solving methods.
(7)
We instantiate the local search problem scheme for design problems.
(8)
We instantiate the local search problem scheme for parametric design problems.
(9)
We refine the algorithmic scheme to propose & revise by assuming two different
types of successor relationships.
We will discuss these different transitions during the following.
- 13 -
14.1
14.2
14.3
14.4
14.5
14.6
14.7
14.8
14.9
14.10
14.11
14.12
14.13
14.14
14.15
14.16
14.17
14.18
14.19
14.20
14.21
14.22
14.23
14.24
14.25
14.26
14.27
14.28
14.29
14.30
14.31
14.32
14.33
14.34
14.35
14.36
14.37
14.38
14.39
14.40
14.41
14.42
14.43
14.44
9
8
7
6.2 (b)
6.2 (a)
Problem
-solving
Scheme
Assumption on domain
knowledge
6.1
2
5
1
4
Problem Commitments
3
Fig. 4
3.1
Some moves in the problem space we illustrate.
A Generic Search Scheme
Figure 5 provides a definition of a generic search scheme. It consists of four elementary state
transitions, i.e. inferences. Initialize starts the search process and the sequence of Select
Node, Derive Successor Nodes, and Update Nodes recursively searches until a solution has
been found. The signature of the methods consists of objects and sets of objects which is
- 14 -
date: 28.4.98
15.1
15.2
15.3
15.4
15.5
15.6
15.7
15.8
15.9
15.10
15.11
15.12
15.13
15.14
15.15
15.16
15.17
15.18
15.19
15.20
15.21
15.22
15.23
15.24
15.25
15.26
15.27
15.28
15.29
15.30
15.31
15.32
15.33
15.34
15.35
15.36
15.37
15.38
15.39
15.40
15.41
15.42
15.43
15.44
scheme generic search
control flow
Search()
/* Initializes and starts the search. */
Nodes:= Initialize();
Output := RecursiveSearch(Nodes)
RecursiveSearch(Nodes)
Node := Select Node(Nodes);
Successor Nodes := Derive Successor Nodes(Node);
Nodes := Update Nodes(Nodes, Successor Nodes);
IF Stop criterion(Node, Nodes)
THEN RETURN Node
ELSE RecursiveSearch(Nodes)
ENDIF
terminology
sorts
functions
Object,
Node : Object;
Objects : set of Object;
Nodes, Output,
predicates
Successor Nodes : Objects;
Stop criterion : Object x Objects,
elementary inferences
Derive Successor Nodes;
Initialize
Initialize() ≠ ∅;
Select Node
Select Node(x) ∈ x;
Update Nodes
∅ ≠ Update Nodes(x,y) ⊆ x ∪ y
endscheme
Fig. 5
The generic search scheme.
used by three constants Node, Nodes, and Successor Nodes and a predicate Stop criterion to
characterize the states of the reasoning process. The formal details of our formalizations that
integrate the notion of state and dynamics into a logic framework are beyond the focus of
our paper (see [Fensel & Groenboom, 1996], [Fensel & Groenboom, 1997], [Fensel et al., to
appear] for more details). Each inference step defines a parameter of the search scheme.
Defining a precise regime that determines the initial object set, how to derive successor
objects, how to select an object, and how to update sets of objects refine the scheme. In
- 15 -
16.1
16.2
16.3
16.4
16.5
16.6
16.7
16.8
16.9
16.10
16.11
16.12
16.13
16.14
16.15
16.16
16.17
16.18
16.19
16.20
16.21
16.22
16.23
16.24
16.25
16.26
16.27
16.28
16.29
16.30
16.31
16.32
16.33
16.34
16.35
16.36
16.37
16.38
16.39
16.40
16.41
16.42
16.43
16.44
adapter local search
import generic search
export local search
axioms
Successor Nodes = Update Nodes(Nodes, Successor Nodes)
endadapter
Fig. 6
The refinement to local search.
addition, the predicate Stop criterion asks for criteria that determines a solution of the
problem. Finally, the sixth parameter of the method is the set of objects it requires. All
further refinements will be achieved by refining one or several of these parameters. In the
next step, we will refine the inference Update Nodes because it is critical for deciding about
the type of search we perform.
3.2
Refine Search to Local Search
Update Nodes significantly influences the type of search that is performed. If the output is
obtained by merging the Successor Nodes with the original input Nodes, a variant of bestfirst search is performed, where all expanded nodes are available for selecting the next
node. This may be the basis to define an (A*) search strategy. If only Successor Nodes are
returned, then the search is restricted to the environment of the selected node. In this case a
variant of hill-climbing is performed. The definition of Update Nodes in Figure 6 defines
local search.
3.3
Defining an Optimization Problem
Figure 7 provides the generic definition of a global optimization problem. Its goal asks for
an element for which no better one exists and the requirements on the preference
relationship (<) ensure that the task is solvable in a given domain (i.e., they prevent a < b
and b < a). In the following, we will stepwise refine this problem to richer ones.
3.4
Refine to Design
Design can be characterized in generic terms as the process of constructing artifacts.
Usually, a constructed artifact should fulfill certain requirements, should not violate certain
constraints, and should follow the principle of economy, i.e. should have minimal cost, (cf.
[Mittal & Frayman, 1989], [Chandrasekaran, 1990], [Motta & Zdrahal, 1996]). Figure 8
- 16 -
date: 28.4.98
17.1
17.2
17.3
17.4
17.5
17.6
17.7
17.8
17.9
17.10
17.11
17.12
17.13
17.14
17.15
17.16
17.17
17.18
17.19
17.20
17.21
17.22
17.23
17.24
17.25
17.26
17.27
17.28
17.29
17.30
17.31
17.32
17.33
17.34
17.35
17.36
17.37
17.38
17.39
17.40
17.41
17.42
17.43
17.44
shows a possible characterization of the class of design problems. We do not distinguish
requirements and constraints because they can be expressed through each other.
The definitions refine two aspects of the task global optimum. First, the definition of a
Solution is refined with the enriched terminology. It must be optimal and valid. Second, an
Object is now called a Design Model, i.e. we got a new name. This name will be refined
when we switch to parametric design.
task global optimum
sorts Object;
predicates
Solution : Object,
optimal : Object,
< : Object x Object;
goal
Solution(x) ↔ optimal(x)
optimal(x) ↔ ¬ ∃ y (x < y)
requirements
¬(x < x)
x < y ∧ y < z →x < z
endtask
Fig. 7
The task global optimum.
adapter Design
import global optimum
export design
sorts
Design Model, Constraint, Cost, Constraints : set of Constraint;
functions
violated : Design Model → Constraints;
cost : Design Model → Cost;
predicates
valid, solution, goal : Design Model;
rename
Object : Design Model;
axioms
SolutionExport(x) :↔ SolutionImport(x) ∧ valid(x)
valid(x) :↔ violated(x) = ∅
x < y :↔ (cost(y) < cost(x) ∧ valid(y))
endadapter
Fig. 8
The task design.
- 17 -
18.1
18.2
18.3
18.4
18.5
18.6
18.7
18.8
18.9
18.10
18.11
18.12
18.13
18.14
18.15
18.16
18.17
18.18
18.19
18.20
18.21
18.22
18.23
18.24
18.25
18.26
18.27
18.28
18.29
18.30
18.31
18.32
18.33
18.34
18.35
18.36
18.37
18.38
18.39
18.40
18.41
18.42
18.43
18.44
3.5
Refine to Parametric Design
This definition of design can be specialized for parametric design problems by introducing
parameters and value ranges, as shown in Figure 9. Parametric design problems reduce the
complexity of the design task by assuming the existence of a parametrized solution
template for the target artifact. Hence, as shown in Figure 9, a design model can now be
defined as a partial function from parameters to value ranges and a solution can be defined
as a valid and complete design model. This is a model in which all parameters are bound,
all requirements are satisfied and no constraint is violated. The VT elevator design problem
(cf. [Marcus et al., 1988], [Schreiber & Birmingham, 1996]) provides a well-known
example of a parametric design task. Here the problem is to configure an elevator in
accordance with the given requirements specification and the applicable constraints. The
parametrized solution template consists of 199 design parameters which specify the various
structural and functional aspects of an elevator— e.g. number of doors, speed, load, etc.
The two main refinements are the additional requirement for completeness of solutions and
a much richer notion to describe the objects of the problem-solving process that are now
partial design models.
adapter Parametric Design
import design
export parametric design
sorts
Parameter = {p1,...,pn}, Parameters : set of Parameter,
ValueRange1, ..., ValueRangen;
functions
Parametric Design Model : Parameter → ValueRange1 ∪ ... ∪ ValueRangen
where Parametric Design Model(pi) ∈ ValueRangei for all i=1,..,n;
assigned : Parametric Design Model → Parameters;
predicates
complete : Parametric Design Model;
rename Design Model : Parametric Design Model;
axioms
SolutionExport(x) ↔ SolutionImport(x) ∧ complete(x);
complete(x) ↔ ∀ y (y ∈ assigned(x));
x <Export y :↔ (x <Import y ∧ complete(y))
endadapter
Fig. 9
The task parametric design.
- 18 -
date: 28.4.98
19.1
19.2
19.3
19.4
19.5
19.6
19.7
19.8
19.9
19.10
19.11
19.12
19.13
19.14
19.15
19.16
19.17
19.18
19.19
19.20
19.21
19.22
19.23
19.24
19.25
19.26
19.27
19.28
19.29
19.30
19.31
19.32
19.33
19.34
19.35
19.36
19.37
19.38
19.39
19.40
19.41
19.42
19.43
19.44
3.6
Connecting Problem-Solving and Problem
We developed a local search method in section 3.1 and 3.2 and will now show how it can be
adapted for optimization problems as defined in section 3.3. We do this in two steps. We
first ensure that our method finds local optima. That is, we establish some competence for
our method. Up to now, we had only characterized its operational behavior, states and
elementary inferences. Second we discuss how the gap between a local optimum that is
found by the method and a global optimum that is required by the task can be filled. We
discuss two alternative strategies for this purpose.
3.6.1
Establish the Competence to find Local Optima
The local search method we defined in Figure 5 and Figure 6 cannot guarantee to find a
global optimum. Actually we cannot even guarantee to find a local one. Figure 10 adds the
necessary requirements for such a proof. We have to ensure that Select Nodes and Update
Nodes deliver an optimum of all Nodes and of the union of all Nodes and Successor Nodes.
Now we can prove that our search procedure behaves like hill-climbing that guarantees to
find local optima. Notice that Select Nodes and Update Nodes have to solve a global
optimum problem. They must provide the best node and the best successor. Therefore, the
problem of finding a global optimum reappears as subproblem, however, reduced for a
subset of all nodes. This divide & conquer strategy is common for most local search
strategies. Again, its success depends on further assumptions on the successor relationship.
For example, if every node was directly be connected with every node then Update Nodes
would already have to solve the entire problem.
We import global optimum in Figure 10 to provide the axioms characterizing an order (<).
adapter local search finding local optima
import local search, global optimum
export local search finding local optima
competence
¬ ∃x (x ∈ Nodes ∪ Successor Nodes) ∧ Output < x)
axioms
Stop criterion(x, Y) :↔ ¬ ∃y (y ∈ Y ∧ x < y )
¬ ∃x,y (
x ∈ Update Nodes(Nodes,Successor Nodes) ∧
y ∈ Nodes ∪ Successor Nodes ∧ x < y)
¬ ∃x,y (x ∈ y ∧ Select(y) < x )
endadapter
Fig. 10
The requirements for finding local optima.
- 19 -
20.1
20.2
20.3
20.4
20.5
20.6
20.7
20.8
20.9
20.10
20.11
20.12
20.13
20.14
20.15
20.16
20.17
20.18
20.19
20.20
20.21
20.22
20.23
20.24
20.25
20.26
20.27
20.28
20.29
20.30
20.31
20.32
20.33
20.34
20.35
20.36
20.37
20.38
20.39
20.40
20.41
20.42
20.43
20.44
3.6.2
Establish the Competence to find Global Optima
There is still a significant gap between finding a local optimum and a global one. In
principle there are two different strategies. First, we could strengthen the problem-solving
scheme to perform complete search ensuring that it always finds a global optimum. We
could retract the restriction in Figure 6 that introduced local search or we could incorporate
a backtracking mechanism that helps to escape local optima. Such strategies are described
in [Zdrahal & Motta, 1995] and [Motta & Zdrahal, 1996] and depictured as arrow 6.2 (b) in
Figure 4.
However, providing complete search to ensure the global optimality of an output of a
problem-solving method may miss the point of problem-solving methods. Problem-solving
methods should provide efficient problem solving (cf. [Fensel & Straatman, 1998]) and this
is impossible if the problem is intractable. Therefore, an alternative strategy is to introduce
assumptions on domain knowledge that close the gap between competence of a method and
the defined task (depictured as arrow 6.2 (a) in Figure 4). Notice that we describe problemsolving methods for knowledge-based systems. That is, parts of the problem-solving
process can be delegated from the method to the domain knowledge. The problem-solving
method defines a reasoning strategy on top of the domain knowledge to ensure that it is
used in a proper and efficient way to provide problem solving. This assumption either
strengthen the competence of the combined problem solver method plus domain knowledge
or they can be used to weaken the task that can be performed by it. In the latter case it
describes the restrictions under which proper problem solving can be guaranteed (cf.
[Fensel & Benjamins, 1998])
For our example, we have to establish a necessary property of the domain knowledge used
by Successor Nodes. The successor relationship must always provide a better successor in
the case that a node is not already a global optimum (see Figure 11). Such an assumption
prevents our local search procedure to get staked in local optima.
How such properties can be verified is described in [Fensel & Schönegge, 1997] and
[Fensel & Schönegge, 1998] provides a method called inverse verification that can be used
adapter local search for global optima
import local search finding local optima, global optimum
export local search for global optima
axioms
Solution(Output)
better-successor assumption:
∃y (successor(x,y) ∧ x < y) ∨ ¬ ∃z (x < z)
endadapter
Fig. 11
The assumption for finding global optima.
- 20 -
date: 28.4.98
21.1
21.2
21.3
21.4
21.5
21.6
21.7
21.8
21.9
21.10
21.11
21.12
21.13
21.14
21.15
21.16
21.17
21.18
21.19
21.20
21.21
21.22
21.23
21.24
21.25
21.26
21.27
21.28
21.29
21.30
21.31
21.32
21.33
21.34
21.35
21.36
21.37
21.38
21.39
21.40
21.41
21.42
21.43
21.44
to derive such assumptions like the better-successor assumption in Figure 11.
3.7
Local but Optimal Search for Design
We straightforward define an adapter that glues the discussed pieces together (see Figure
12).
3.8
Local but Optimal Search for Parametric Design
We straightforward define an adapter that glues the discussed pieces together (see Figure
12).
3.9
Refine Local but Optimal Search for Parametric Design to
Propose & Revise
Finally, we will sketch how our method can be refined to propose & revise for parametric
design. Actually propose & revise distinguish two different modes of Derive Successor
Nodes. The successor relationship is defined in terms of successors that either extend the
definition of the design model or that bypass its constraints violations:
• Propose an extension: Assign a new parameter.
• Revise an object: Repair constraint violations.
Refining the vocabulary that defines the successor relationship leads to a refined notion of
the assumption that ensures the global optimality of the result of the method. The generic
adapter Local Search for Design
import local search for global optima, design
export local search for design
endadapter
adapter Local Search for Parametric Design
import local search for design, parametric design
export local search for parametric design
endadapter
Fig. 12
Local but optimal search for parametric design.
- 21 -
22.1
22.2
22.3
22.4
22.5
22.6
22.7
22.8
22.9
22.10
22.11
22.12
22.13
22.14
22.15
22.16
22.17
22.18
22.19
22.20
22.21
22.22
22.23
22.24
22.25
22.26
22.27
22.28
22.29
22.30
22.31
22.32
22.33
22.34
22.35
22.36
22.37
22.38
22.39
22.40
22.41
22.42
22.43
22.44
adapter propose & revise for Parametric Design
import local search for parametric design, ...
export propose & revise for parametric design
axioms
/* The propose knowledge never fails and monotonically extends the state. */
¬ Complete(s) → Partial completeness(s) < Partial completeness(propose(s))
/* The application of a propose leads to an optimal state. */
¬ Complete(s) →
¬∃ s´ (Correct(s´) ∧ propose(s) < s´ ∧
Partial completeness(s´) = Partial completeness(propose(s))
/* The revise knowledge never fails. */
¬ Correct(s) → Correct(revise(s))
/* The application of revise does not change the completeness of a state. */
Partial completeness(revise(s)) = Partial completeness(s)
/* The application of revise leads to an optimal state. */
¬ Correct(s) →
¬ ∃ s´ (Correct(s´) ∧ revise(s) < s´ ∧
Partial completeness(revise(s)) = Partial completeness(s´))
endadapter
Fig. 13
The knowledge requirements of optimal propose & revise.
definition of the assumption in Figure 11 is refined by assumptions on propose and on
revise knowledge in Figure 13.
Different variants of propose & revise can be defined by defining some control on how to
apply propose and revise steps. One may want to non-deterministically apply a propose or a
revise step, one may want to apply all possible propose and revise step in parallel, one may
first apply propose steps until a model is complete and then revise, or one may want to have
stepwise propose steps which are interrupted in case a constraint violation occurs (cf.
[Fensel, 1995a], [Zdrahal & Motta, 1995]). Figure 14 shows two alternative definitions and
¬ Complete(s) → propose(s) = successor(s)
Complete(s) ∧ ¬Correct(s) → revise(s) = successor(s)
while not complete do propose od; if not correct then revise fi
¬ Correct(s) → revise(s) = successor(s)
¬ Complete(s) ∧ Correct(s) → propose(s) = successor(s)
while not (complete and correct) do
if not complete then propose fi;
if not correct then reviese fi
od
Fig. 14
Alternative control modes of propose & revise.
- 22 -
date: 28.4.98
23.1
23.2
23.3
23.4
23.5
23.6
23.7
23.8
23.9
23.10
23.11
23.12
23.13
23.14
23.15
23.16
23.17
23.18
23.19
23.20
23.21
23.22
23.23
23.24
23.25
23.26
23.27
23.28
23.29
23.30
23.31
23.32
23.33
23.34
23.35
23.36
23.37
23.38
23.39
23.40
23.41
23.42
23.43
23.44
for each a procedural and a declarative definition. That is, a refinement of Derive Successor
Nodes can be defined by a submethod that enforces some control on the new substeps or it
can be done declaratively with an adapter.
3.10
Summary
The explicit characterization of moves through the problem-solving method space is
important both to formalize the method development process and also to ensure that not
only problem solving components but also the process of creating them becomes part of a
library. The importance of recording the knowledge engineering experience in a library has
been recognized for a number of years ([Stutt & Motta, 1995]; [Van de Velde, 1994]).
However, approaches to capturing design expertise in knowledge engineering have mostly
centered on recording informal guidelines. In contrast with these approaches, adapters
provide a formal way of capturing the method development process, thus providing the
basis for automatic method configuration. An adapter is an explicit and external notion of
the adaptation of a component and a trace of adapters is an explicit notion of the refinement
process and its intermediate steps. For example, this extends the approach of [Landes &
Studer, 1995] who link model fragment and its adaptation via a hyperlink that explains in
natural language their relation, however, does not provide a separate and explicit
representation of the adaptation itself.
4 The Transitions in the Problem Space: Adapter
Integration of existing systems becomes a serious problem in most branches of computer
science. This reflects the fact that system are no longer built from scratch. Instead the are
configured from existing building blocks. In the consequence, the necessity of glue arose
that interconnects different components and adapts them for a specific application. The
adapter patter is one out of several pattern in the text book of [Gamma et al., 1995] on
design patters that deals with object connection. It enables cooperation of object with
different interfaces and the specification of reusable objects. Adapters are also present in
most approaches to software architectures ([Shaw & Garlan, 1996], [Yellin & Strom,
1997]). Often called connectors their main purpose is to bypass problems in the interaction
styles of components. Glue or adapter protocols enable communication between component
that could otherwise not interact. Mediators ([Wiederhold, 1992], [Wiederhold &
Genesereth, 1997]) were introduced to enable sharing and reuse of heterogeneous and
distributed information and knowledge sources. All these different mechanisms in different
subfields of computer science are all about the same: Adapting a component to a new
context enabling the reuse of components and externalizing the adaptation as the key that
- 23 -
24.1
24.2
24.3
24.4
24.5
24.6
24.7
24.8
24.9
24.10
24.11
24.12
24.13
24.14
24.15
24.16
24.17
24.18
24.19
24.20
24.21
24.22
24.23
24.24
24.25
24.26
24.27
24.28
24.29
24.30
24.31
24.32
24.33
24.34
24.35
24.36
24.37
24.38
24.39
24.40
24.41
24.42
24.43
24.44
enables reuse.
[Fensel et al., 1996b], [Fensel & Groenboom, 1997] introduced adapters into the
CommonKADS model of expertise as a generalization of the mappings between domain
and inference layers. Adapters enable the independent and therefore reusable specifications
of tasks, problem-solving methods and domain knowledge (cf. Figure 15). [Fensel, 1997]
generalized the use of adapters to stepwise adaptation of problem-solving methods, tasks,
and assumptions via a pile of adapters. Here adapter become itself the object of reuse
because an adapter expresses an adaptation to a generic and reusable context (i.e., a
problem type or task). This is rather specific for adapters used in knowledge engineering
reflecting the fact that only this community searches for generic description of problem
types ([Breuker & Van de Velde, 1994], [Breuker, 1997]).
Still, our current adapter concept may be too general and a typology of adapters may
significantly facilitate its usability. So far we have identified one basic aspect for
organizing adapters: in terms of their purpose (teleological aspect). This aspect indicates
whether an adapter is used to refine a problem type, a domain dependency via assumptions,
or a problem-solving paradigm. In the following we will work this out in more detail to
transforms the development process of problem-solving methods into a more structured
engineering activity.
In section 3 we introduced a three-dimensional problem space (see Figure 3) in which we
will move with adapters. The dimensions are the problem-solving paradigm, the domain
knowledge assumptions, and the problem (i.e., task) commitments. Moves in this space can
be distinguished by the dimension in which they move.
• A movement may lay in one of the three dimensions only: refining the problem-solving
paradigm, refining assumptions on domain knowledge, and refining the problem
commitments.
• A movement may lay in two of the three dimensions only: enriching a problem-solving
paradigm with knowledge assumptions, connecting a problem-solving paradigm with a
problem type, and enriching a problem type with knowledge assumptions.
• A movement may use all three dimensions. This move contains maximal complexity
(because maximally degree of freedom) and we will show a simple strategies to reduce
this complexity.
In the following, we will briefly sketch the different adapter types.
- 24 -
date: 28.4.98
25.1
25.2
25.3
25.4
25.5
25.6
25.7
25.8
25.9
25.10
25.11
25.12
25.13
25.14
25.15
25.16
25.17
25.18
25.19
25.20
25.21
25.22
25.23
25.24
25.25
25.26
25.27
25.28
25.29
25.30
25.31
25.32
25.33
25.34
25.35
25.36
25.37
25.38
25.39
25.40
25.41
25.42
25.43
25.44
Problem-solving method (PSM)
Task definition
Competence (PSMC)
Goals (TG)
Operational
Specification (PSMO)
Requirements (TR)
Requirements (PSMR)
Adapter
Signature mappings (AM)
Assumptions (AA)
Requirements (AR)
Domain model
Meta knowledge (DM)
Domain knowledge (DK)
Assumptions (DA)
Fig. 15
The four component architecture for knowledge-based systems.
- 25 -
26.1
26.2
26.3
26.4
26.5
26.6
26.7
26.8
26.9
26.10
26.11
26.12
26.13
26.14
26.15
26.16
26.17
26.18
26.19
26.20
26.21
26.22
26.23
26.24
26.25
26.26
26.27
26.28
26.29
26.30
26.31
26.32
26.33
26.34
26.35
26.36
26.37
26.38
26.39
26.40
26.41
26.42
26.43
26.44
4.1
One-dimensional Moves
In the following we investigate adapters that exclusively provide moves in a onedimensional subspace: refining elementary inferences of problem-solving paradigms,
refining domain knowledge, and refining goals of problem definitions (see Figure 16).
4.1.1
Refining a Problem-solving Paradigm
A problem-solving paradigm is specialized by refining one of its elementary state
transitions, i.e. inferences. Each inference can be seen as a parameter that is further refined
by a plug-in adapter. Problem-solving methods are components with an active interface (cf.
[Heineman, 1997]). Each inference defines a parameter that can be further refined
externally. Usually a number of axioms is added that strengthen the inference. Examples
are provided in sections 3.11, 3.2 and 5.3.2. This process moves in one dimension, i.e. it
follows the problem-solving scheme line. Notice that this holds only true if the refinement
of inferences is not accompanied by introducing new requirements and assumptions on
domain knowledge. Then we move into a two-dimensional subspace (cf. section 4.2.1).
Problem
-solving
Scheme
Refining inferences
of problem-solving
schemes
3.1,
3.2,
5.3.2
Assumption on domain
knowledge
Refining domain knowledge
(ontology mappings)
Problem Commitments
Refining goals of tasks
Fig. 16
1.
One-dimensional moves in the problem space.
Section 3.1 refines the empty problem-solving scheme.
- 26 -
date: 28.4.98
27.1
27.2
27.3
27.4
27.5
27.6
27.7
27.8
27.9
27.10
27.11
27.12
27.13
27.14
27.15
27.16
27.17
27.18
27.19
27.20
27.21
27.22
27.23
27.24
27.25
27.26
27.27
27.28
27.29
27.30
27.31
27.32
27.33
27.34
27.35
27.36
27.37
27.38
27.39
27.40
27.41
27.42
27.43
27.44
4.1.2
Refining Domain Knowledge
Refining domain knowledge independently of its use for problem-solving schemes and task
definitions is not present in our framework that is about developing problem-solving
methods. This move would describe mapping between different domain ontologies and is
covered by mediator-type approaches like [Wiederhold, 1992] and [Wiederhold &
Genesereth, 1997] to sharing and reuse of domain or common sense knowledge.
4.1.3
Refining the Goal of a Task
All examples for task refinement we showed in the paper also introduced new requirements
on domain knowledge. An optimization task requires a preference function, a design task
requires constraints, a cost function etc. Therefore these refinements immediately leave the
one-dimensional space and interact with the domain knowledge dimension. Only
refinements that are exclusively to the goal are covered by a one-dimensional task
refinement. For example, when we strengthen a goal from finding one global optimum to
finding all ones this could be done independent from additional assumptions on domain
knowledge.
4.2
Two-dimensional Moves
In the following we investigate adapters that provide moves in a two-dimensional subspace:
refining assumptions of problem-solving paradigms, refining state transitions and
inferences of problem-solving paradigms, and refining tasks (see Figure 17).
4.2.1
Refining inferences of problem-solving paradigms accompanied with new
Assumptions
Section 3.9 shows the refinement of local search for parametric design to propose & revise
for parametric design. The inference Derive Successor Nodes is refined by distinguishing
two types of successors: derived by propose that extend completeness and derived by revise
that ensure correctness. This refinement moves not into the direction of the problem
commitments. That is, the method solves precisely the type of problem as before. However,
it also moves into the direction of domain assumptions because new types of knowledge are
required (propose and fix rules and a relative completeness measurement).
4.2.2
Refining States (including Input and Output), Transitions, and Inferences
- 27 -
28.1
28.2
28.3
28.4
28.5
28.6
28.7
28.8
28.9
28.10
28.11
28.12
28.13
28.14
28.15
28.16
28.17
28.18
28.19
28.20
28.21
28.22
28.23
28.24
28.25
28.26
28.27
28.28
28.29
28.30
28.31
28.32
28.33
28.34
28.35
28.36
28.37
28.38
28.39
28.40
28.41
28.42
28.43
28.44
of Problem-solving Paradigms
Sections 3.6.1, 3.7 and 3.8 describe simple adaptation of problem-solving schemes to
problem type that are not interleaved with new assumptions on domain knowledge.
4.2.3
Refining a Task
A task is refined by strengthening its goal and knowledge requirements. Sections 3.32, 3.4,
and 3.5 provide examples for these refinements. In section 3.4, a optimization problem is
refined to design which is further refined to parametric design in section 3.5. In both steps,
we refined the definition of the goal and introduced new requirements on domain
knowledge. A solution for optimization must be optimal. A solution must in addition be
valid (i.e., consistent and suitable) when refining to design. A solution must in addition be
complete when refining to parametric design. Because new requirements on domain
knowledge are introduced it is a move in a two-dimensional subspace.
Refining state descriptions
and inferences of problem-solving
schemes 3.6.1, 3.7, 3.8
Problem
-solving
Scheme
Refining inferences of a
problem-solving scheme
that introduces new
assumptions 3.9
Assumption on domain
knowledge
Problem Commitments
Refining a task 3.3, 3.4, 3.5
Fig. 17 Two-dimensional moves in the problem space.
2.
Section 3.3 refines the empty problem definition.
- 28 -
date: 28.4.98
29.1
29.2
29.3
29.4
29.5
29.6
29.7
29.8
29.9
29.10
29.11
29.12
29.13
29.14
29.15
29.16
29.17
29.18
29.19
29.20
29.21
29.22
29.23
29.24
29.25
29.26
29.27
29.28
29.29
29.30
29.31
29.32
29.33
29.34
29.35
29.36
29.37
29.38
29.39
29.40
29.41
29.42
29.43
29.44
4.3
Three-dimensional Moves
Assumption on domain knowledge are introduced by problem-solving schemes to improve
the competence of the method without changing their algorithmic strategy. Section 3.6.2
provided the example where a local search method received the competence to find a global
optimum without any change to its incomplete search strategy. Completeness was achieved
by formulating assumptions on the structure of the search graph defined by the domain
knowledge. It may not contain nodes that lead to a death-end for the search process. This
process relates methods with problems and close the gap by assumptions on domain
knowledge. Therefore, it is necessarily a move through all three dimensions. We mentioned
the alternative strategy 3.6.2 (b) that tries to close the gap between provided and required
strength by improving the algorithmic scheme. Then we would again move in a twodimensional projection of the entire problem space. However in the case of knowledgebased systems it may be a necessary strategy to delegate parts of the problem solving to the
domain knowledge and to weaken the task in order to enable efficient problem solving.
Therefore, such a three-dimensional move may often not preventable. However it always
can be realized by a sequence of two-dimensional moves. That is, we can first map method
and task and establish in a second step assumptions on domain knowledge that close the
encountered gaps.
Another interesting example highlighting a second aspect of efficiency is described in
[Eriksson et al., 1995], [Fensel et al., 1996a]. They showed the derivation of a task-specific
problem-solving method from the generic search-strategy chronological backtracking by
introducing commitments to the terminological structure of the task. That is, the introduced
ontological commitments which are connected to the problem type. The generic problemsolving method chronological backtracking, which basically defines a search strategy, was
transformed into the task-specific boardgame method. Chronological backtracking defines
a specific control over elementary state transitions. It specifies neither these elementary
state transitions nor the internal structure of the states. All in all, two refinements are added
by the boardgame method. First, the state transitions of the search process are modeled in
terms of moves. Second, the states of the search process are represented by a set of triples
that defines a structure for them. As a consequence, this method could be immediately
applied to an assignment task, such as the Sisyphus-I office room assignment problem (cf.
[Linster, 1994]), or one-player board games, as the syntactical structure of describing a
state maps immediately with the terminological structure of these tasks. Chronological
backtracking requires extensive mappings so that it can be applied to these tasks. However,
it can be applied to any type of task. The reason for restricting problem-solving methods to
task-specific problem-solving methods using ontological commitments is their usability.
The efficiency of the development process that derives a appropriate problem solver for a
given application problem and the efficiency of the knowledge acquisition process which
models the relevant domain knowledge are improved. The improved efficiency of
knowledge acquisition is given by the fact that the refined notion to define states in the
boardgame method also provides a richer terminology to define state transitions. The
- 29 -
date: 28.4.98
30.1
30.2
30.3
30.4
30.5
30.6
30.7
30.8
30.9
30.10
30.11
30.12
30.13
30.14
30.15
30.16
30.17
30.18
30.19
30.20
30.21
30.22
30.23
30.24
30.25
30.26
30.27
30.28
30.29
30.30
30.31
30.32
30.33
30.34
30.35
30.36
30.37
30.38
30.39
30.40
30.41
30.42
30.43
30.44
boardgame method describes transitions in terms of moves that influence the board position
instead of providing only an abstract state transition function as it is the fact for
chronological backtracking. This is also the reason why the refinement of chronological
backtracking to the boardgame method is a move in three directions in our problem space:
It also introduce requirements on new types of domain knowledge.
Notice that this type of efficiency improvement is complementary to the process of
introducing assumptions that simplifies the computational complexity of the problem.
5 The Case Study on Parametric Design
The work by Motta and Zdrahal ([Motta & Zdrahal, 1996]; [Motta & Zdrahal, 1998];
[Motta, 1997]; [Zdrahal & Motta, 1995]; [Zdrahal & Motta, 1996]) attempts to provide a
task-independent foundation to problem-solving methods. Their approach, which is based
on the Task/Method/Domain/Application (TMDA) framework—see Figure 18—,
considers a problem-solving method as a specialization of a task-specific, but problemsolving method-independent, problem solving model, which is in turn constructed by
instantiating a generic problem solving paradigm (e.g. search) in terms of a task ontology.
Motta and Zdrahal instantiated their approach in the area of parametric design and showed
that several problem-solving methods existing in the literature—e.g. propose & backtrack
[Runkel et al., 1996], propose & exchange [Poeck & Puppe, 1992] and propose & revise—
could be characterized as specializations of a common problem solving model, obtained by
instantiated an ontology for parametric design tasks in terms of a search model of problem
solving. In particular, all problem-solving methods in the parametric design library
described in [Motta, 1997] subscribe to a common, generic control regime. As discussed in
([Motta, 1997]; [Motta & Zdrahal, 1998]), this approach i) makes it possible to plug and
play functionally equivalent components with no change to the control structure and ii)
facilitates the comparative evaluation of alternative problem-solving methods.
This work is important because it shows that i) it is possible to provide task-independent
foundations to problem-solving methods, even within a task-oriented approach, and that ii)
the reliance on a common problem solving model facilitates the construction and the
analysis of a library of problem solving methods. However the TMDA framework is
limited insofar as it only allows the analysis of problem-solving methods tackling the same
class of tasks— i.e. while the framework generalizes from a particular class of tasks, it is
still task-centred. Another limitation of the approach is that it only characterizes method
development informally, as a relatively unstructured specialization process. The framework
we propose in this paper addresses these problems by generalizing from the TMDA
approach and by proposing the notion of adapter as a construct for formalizing problem-
- 30 -
date: 28.4.98
31.1
31.2
31.3
31.4
31.5
31.6
31.7
31.8
31.9
31.10
31.11
31.12
31.13
31.14
31.15
31.16
31.17
31.18
31.19
31.20
31.21
31.22
31.23
31.24
31.25
31.26
31.27
31.28
31.29
31.30
31.31
31.32
31.33
31.34
31.35
31.36
31.37
31.38
31.39
31.40
31.41
31.42
31.43
31.44
Problem Solving Paradigm
Generic Task
Specification
Generic Problem Solving Model
Application Model
Problem Solving Method
(def-instance Peter_S Lecturer
((courses_chaired dm862)...)
Mapping
Knowledge
(def-instance Arthur_S Reader
((courses_chaired dm871)...)
Application-specific
Problem-Solving
Knowledge
Application Configuration
Multi-functional
Domain Model
Fig. 18
The TMDA modelling framework.
solving method refinement steps.
5.1
The Overall Picture
In the following we reconstruct the library on parametric design problem solving that was
developed within the TMDA approach and which has been applied in a number of technical
design problems (office allocation problem, elevator design, sliding bearing design,
problems of simple mechanics, initial vehicle (truck) design, design and selection of casting
technologies, and sheet metal forming technology for manufacturing mechanical parts
[Motta, 1997]). The overall picture of refining the problem specificity of a generic search
method is provided in Figure 19. On the left side we refine the problem definition and on
the right side we refine the problem-solving paradigm that guides the problem-solving
process. The virtual elements do not require a specification because these specifications
follow from a combination of an existing specification and an adapter. However, for
- 31 -
date: 28.4.98
32.1
32.2
32.3
32.4
32.5
32.6
32.7
32.8
32.9
32.10
32.11
32.12
32.13
32.14
32.15
32.16
32.17
32.18
32.19
32.20
32.21
32.22
32.23
32.24
32.25
32.26
32.27
32.28
32.29
32.30
32.31
32.32
32.33
32.34
32.35
32.36
32.37
32.38
32.39
32.40
32.41
32.42
32.43
32.44
convenience, a library may also directly provide these derived specifications.
5.2
Defining Problem, Problem Scheme and their Connection
Figure 8 provides the definition of design problems and Figure 9 provides its refinement for
parametric design. A slightly generalized version of the algorithmic search scheme search
that defines the common pattern of all problem-solving methods described in [Motta, 1997]
was given in Figure 5. We already mentioned the fact that different search strategies can be
modeled by defining alternative methods for the subtask Update Nodes. For instance, bestfirst search can be modeled by performing a simple union of Nodes and Successor Nodes,
while hill-climbing can be modeled by ensuring that Update Nodes returns only Successor
Nodes (cf. Figure 6). The local search model can be specialized for design tasks by means
of the adapter shown in Figure 12. Essentially, this adapter introduces the term design
model into the method and maps the notion of task solution to that of method solution.
Refining the resulting model of design problem solving for parametric design is simply a
matter of importing the problem type Parametric Design and the problem-solving method
Local Search for Design, to produce the problem-solving method Local Search for
Parametric Design.
5.3
Refining the Subtask (i.e., Inferences) of the Method
The resulting problem-solving method is still unspecified, as it does not say how to select
design models, how to derive successor designs, and how to update the set of designs. The
problem-solving method is parametrized in terms of the following four subtasks.
• Initialize: This defines the initial search space.
• Select Node: This selects the node which is going to be expanded.
• Derive Successor Nodes: This task derives the successors of the current node.
• Update Nodes: This task updates the current search space to take into account the
newly generated nodes.
Different problem-solving methods can be defined by introducing task- or domain-specific
commitments, or simply by selecting alternative control regimes for these subtasks.
- 32 -
date: 28.4.98
33.1
33.2
33.3
33.4
33.5
33.6
33.7
33.8
33.9
33.10
33.11
33.12
33.13
33.14
33.15
33.16
33.17
33.18
33.19
33.20
33.21
33.22
33.23
33.24
33.25
33.26
33.27
33.28
33.29
33.30
33.31
33.32
33.33
33.34
33.35
33.36
33.37
33.38
33.39
33.40
33.41
33.42
33.43
33.44
PSM Search (Fig. 5)
Task Global Optimum (Fig. 7)
Adapter local search (see Fig. 6)
Adapter Desgin (see Fig. 8)
PSM Local Search
Adapter local search for local
optima (see Fig. 10)
Task Design
PSM Local Search
for Local Optima
Adapter Parametric
Desgin (see Fig. 9)
Adapter local search for global
optima (Fig. 11)
Task Parametric
Design
PSM Local Search
for Global Optima
Adapter local search for design
(Fig. 12)
PSM Local Search
for Design
Virtual Element
(is derived from an adapter)
Adapter local search for pametric
design (Fig. 12)
Actual Element
PSM Local Search
for Parametric Design
PSM Refined Local
Search for Parametric Design
Fig. 19
Adapter refined local search for
pametric design (Fig. 20)
The development graph of a problem-solving method for parametric design.
- 33 -
date: 28.4.98
34.1
34.2
34.3
34.4
34.5
34.6
34.7
34.8
34.9
34.10
34.11
34.12
34.13
34.14
34.15
34.16
34.17
34.18
34.19
34.20
34.21
34.22
34.23
34.24
34.25
34.26
34.27
34.28
34.29
34.30
34.31
34.32
34.33
34.34
34.35
34.36
34.37
34.38
34.39
34.40
34.41
34.42
34.43
34.44
5.3.1
Initialize
Initializing the design space requires not just generating a number of design models, but
also evaluating them, so that task Select Node can be carried out. For instance, a design
model in the Motta library is evaluated in terms of four task-specific criteria: feasibility,
completeness, consistency and cost. These criteria are defined in a task-oriented style,
although, as discussed in [Fensel et al., 1997], it is also possible to characterize these
notions in a task- independent fashion.
5.3.2
Derive Successor Nodes
Derive Successor Nodes in [Motta, 1997] uses a rather complex three step procedure
instead of directly using a successor relationship. First, a design context is abstracted from
the node, then a design focus is derived within the context, and finally a transformation
operator is derived from the design focus. The application of the transformation operator
provides the successor relationship between nodes. The procedure that refines Derive
Successor Nodes is shown in Figure 20. The use of the three-step selection process is
motivated by the structure of the problem type:
• The quality information of a design model distinguishes four different criteria:
violation of constraints, fulfillment of requirements, completeness of value assignments
and costs. Four different contexts can be immediately identified according to these four
criteria: trying to repair constraint violations, trying to improve fulfillment, trying to
adapter refined local search for parametric design
import local search for parametric design;
export refined local search for parametric design;
sorts
Context, Focus, Transformation,
History : set of (Context x Focus x Transformation);
Program
Derive Successor Nodes(Design Model)
Context := Decide Over Context(Design Model);
Focus := Decide Over Focus(Design Model, Context);
Transformation := Decide Over Transformation(Design Model, Context, Focus);
Bookmark Context, Focus, and Transformation in History of Design Model;
Design Models := Apply Transformation(Design Model, Transformation);
RETURN Design Models
endadapter
Fig. 20
Refining Derive Successor Nodes.
- 34 -
date: 28.4.98
35.1
35.2
35.3
35.4
35.5
35.6
35.7
35.8
35.9
35.10
35.11
35.12
35.13
35.14
35.15
35.16
35.17
35.18
35.19
35.20
35.21
35.22
35.23
35.24
35.25
35.26
35.27
35.28
35.29
35.30
35.31
35.32
35.33
35.34
35.35
35.36
35.37
35.38
35.39
35.40
35.41
35.42
35.43
35.44
improve completeness and trying to reduce costs. As the reader may have realized, a
more pedantic organization would have already introduced three of these context
decisions for design problems, given that these are not specific to parametric design.
For reasons of simplicity we have skipped this intermediate step.
• Within a context, we can decide about the focus of the design activity by using the
object information, in this case the structure of the (parametric) design model. A
(parametric) design model is a set of violated constraints, non-fulfilled requirements,
and not-assigned parameters. Selecting a focus is therefore selecting one of these
elements (in accordance to the general context).
• Finally, we select a transformation operator. In general, several transformations may be
applicable for a given context and focus.
The method shown in Figure 20 provides the default way of carrying out task Derive
Successor Nodes in the Motta library. The reason for this choice is that this method
employs minimal commitments. Further on, we will briefly illustrate how this method can
be refined to specific problem-solving methods, such as propose & revise, which add
commitments to the basic control regime employed by Derive Successor Nodes.
5.3.3
Select Node
At any stage of a problem solving process, a reasoning system (be it human or artificial)
knows about a number of design states which are relevant to the problem in hand.
Typically, these are the states which have been explored during the current design process,
i.e. the states included in the portion of the design space searched so far. However, human
designers are of course capable of reusing past designs and the same applies to problem
solvers which make use of case-based reasoning techniques when solving design
applications ([Zdrahal & Motta, 1996]). Thus, the current design space includes in general
all the states known to the problem solver, either because they have been explored during
the current design process, or because the problem solver has access to other relevant
design knowledge (e.g. a case-based library of design states).
The task Select Node combines both control and problem solving aspects. It selects a node
according to a number of criteria, which include an estimation of its feasibility (i.e.,
whether the design model may lead to a solution). Incidentally, methods like simulated
annealing do not always select the best local node, in order to escape local optima in the
search space.
The default state selection method provided by the Motta library chooses a design model
which does not violate any constraint, has maximal extension and minimizes the cost. This
selection criterion is the one typically used by problem solvers which are not concerned
- 35 -
date: 28.4.98
36.1
36.2
36.3
36.4
36.5
36.6
36.7
36.8
36.9
36.10
36.11
36.12
36.13
36.14
36.15
36.16
36.17
36.18
36.19
36.20
36.21
36.22
36.23
36.24
36.25
36.26
36.27
36.28
36.29
36.30
36.31
36.32
36.33
36.34
36.35
36.36
36.37
36.38
36.39
36.40
36.41
36.42
36.43
36.44
with cost issues (as for instance most constraint satisfaction engines) and which deal with
inconsistencies by backtracking to an earlier state. These include both methods which make
use of simple control regimes, such as depth-first search with chronological backtracking
[Runkel et al., 1996], as well as more sophisticated regimes based on techniques such as
backjumping ([Gaschnig, 1978]; [Dechter, 1988]). The differences between these
methods—e.g. backjumping vs. depth-first search with chronological backtracking—are
therefore explained in terms of different notions of feasibility, rather than in terms of
different state selection policies. Clever backtracking techniques, such as backjumping, can
propagate infeasibility “backwards”, to nodes which precede an inconsistent state. Hence,
even though different methods may use the same state selection policy, they can still
exhibit different search behaviors. That is, different search strategies are described
declaratively by specifying the search guidance as a parameter of a generic search pattern
rather than by providing different procedural control structures for each search variant.
5.3.4
Update Nodes
We already mentioned that Update Nodes significantly influences the type of search that is
performed (see section 3.2). If the output is obtained by merging the Successor Nodes with
the original input Nodes, a variant of best-first search is performed, where all expanded
nodes are available for selecting the next node. If only Successor Nodes are returned, then
the search is restricted to the environment of the selected node. In this case a variant of hillclimbing is performed.
5.4
Capturing a family of problem-solving method specifications
A summary of parametric design problem solving in terms of its states and state transitions
is provided in Figure 21. This style of specification results from the approach adopted here,
which consists of choosing an algorithmic scheme and applying several adapters that refine
its state descriptions and state transitions. Such a specification is more abstract than what is
usually called a problem-solving method in the literature. For instance, propose & revise
for parametric design instantiates the framework by distinguishing two contexts when
deriving successor design models (cf. section 3.9):
• propose context: design models are completed,
• revise context: design models are repaired.
That is, this problem-solving method can be derived from our framework by simply
refining some of its parameters.
- 36 -
date: 28.4.98
37.1
37.2
37.3
37.4
37.5
37.6
37.7
37.8
37.9
37.10
37.11
37.12
37.13
37.14
37.15
37.16
37.17
37.18
37.19
37.20
37.21
37.22
37.23
37.24
37.25
37.26
37.27
37.28
37.29
37.30
37.31
37.32
37.33
37.34
37.35
37.36
37.37
37.38
37.39
37.40
37.41
37.42
37.43
37.44
Problem-solving Parametric Design
Competence
State
Quality
information:
consistent
suitable
complete
cost
State Transitions
Search Control Information:
History
information:
set of context,
focus, and
operator triples
Future
Information:
feasibility
Object information:
Set of parameter-value pairs
LocalSearch()
Initialize()
RecursiveSearch()
Select Node()
Derive Successor Nodes()
DecideOverContext()
DecideOverFocus()
DecideOverTransformation()
Bookmark()
ApplyTransformation()
Update Nodes()
Knowledge Requirements
a set of constraints
a set of requirements
a cost function
a set of parameters
a set of value ranges
Fig. 21
a set of contexts
a set of foci
a set of transformations
feasibility knowledge
A survey of parametric design problem solving.
6 Related Work, Conclusions and Future Work
“Usable by adaptation and reusable by abstraction.”
In this paper we have presented a systematic approach enabling the structured development,
adaptation, and reuse of problem-solving methods. A large number of problem-solving
methods can be described by means of i) a structured set of generic tasks, problem-solving
patterns, and generic assumptions and ii) adapters formalizing the relevant refinement
steps. These are explicitly modeled, thus allowing their reuse for new problem types and
- 37 -
date: 28.4.98
38.1
38.2
38.3
38.4
38.5
38.6
38.7
38.8
38.9
38.10
38.11
38.12
38.13
38.14
38.15
38.16
38.17
38.18
38.19
38.20
38.21
38.22
38.23
38.24
38.25
38.26
38.27
38.28
38.29
38.30
38.31
38.32
38.33
38.34
38.35
38.36
38.37
38.38
38.39
38.40
38.41
38.42
38.43
38.44
different problem-solving schemes. Adapters introduce a new modeling element into
existing modeling approaches, which makes the method development process explicit and
external to the model, i.e. separated from problem solving components. In most other
approaches, adaptation is treated as a side issue and adaptation via several levels is not
considered at all. In our view, by providing a clear foundation for both problem-solving
method specification and specialization we can construct sound and reusable libraries.
Externalization and explication of adaptation provides the key for reusability and
maintainability by providing the record of design decisions that lead to the constructed
problem solver. Distinguishing seven types of adapters according to their adaptation
dimensions provide rationale and guidance to the development and adaptation process of
problem solving methods.
The work we presented can be situated in the general context of program derivation from
specifications. However, the existing approaches rely on specific representation and
specification languages (functional programming languages [Smith & Lowry, 1990] or
logic-programming [Fuchs & Fromherz, 1991]) and focus on algorithmic refinement as
means to improve the efficiency of programs. Therefore they are rather complementary to
our approach that relies on a specific architecture for specifying knowledge-based systems
and that focuses on introducing problem commitments and domain knowledge assumption
to improve efficiency and to economize the adaptation of reusable components to new
applications. Refining the algorithmic structure of a problem-solving method can be
viewed as an activity during design time to optimize the runtime efficiency of implemented
systems.
Finally, we would like to mention the approach of [ten Teije, 1997] that uses meta-level
reasoning to automatically configure problem-solving methods for diagnostic problems.
The problem with this approach is its complexity. Configuring the optimal problem solver
may have an order of magnitude higher complexity than the problem that should be solved
by the problem solver. Therefore, further heuristic restrictions of her approach are required
to provide reasonable semiautomatic support in constructing problem-solvers as it is aimed
by the IBROW3-project [Benjamins et al., 1998]. It is clear that decision procedures for
limited-rationality problem-solver (problem-solving methods are heuristic problem solvers)
can only have limited rationality, too (cf. [Lipman, 1991]). Developing guidelines that
support the navigation process in the three-dimensional design space and partial
automatization of this process defines an interesting and promissing line for future
research.
Acknowledgement. We thank Richard Benjamins, Enric Plaza, Rudi Studer,
and Bob Wielinga for helpful discussions.
- 38 -
date: 28.4.98
39.1
39.2
39.3
39.4
39.5
39.6
39.7
39.8
39.9
39.10
39.11
39.12
39.13
39.14
39.15
39.16
39.17
39.18
39.19
39.20
39.21
39.22
39.23
39.24
39.25
39.26
39.27
39.28
39.29
39.30
39.31
39.32
39.33
39.34
39.35
39.36
39.37
39.38
39.39
39.40
39.41
39.42
39.43
39.44
References
[Aben, 1995] M. Aben: Formal Methods in Knowledge Engineering, Ph.D. dissertation, University
of Amsterdam, 1995.
[Akkermans et al., 1993] J. M. Akkermans, B. Wielinga, and A. Th. Schreiber: Steps in
Constructing Problem-Solving Methods. In N. Aussenac et al. (eds.), Knowledge-Acquisition
for Knowledge-Based Systems, Lecture Notes in Artificial Intelligence (LNAI) 723, SpringerVerlag, Berlin, 1993.
[Allemang & Rothenfluh, 1992] D. Allemang and T. E. Rothenfluh: Acquiring Knowledge of
Knowledge Acquisition: A Self-Study of Generic Tasks. In Th. Wetter et al. (eds.), Current
Trends in Knowledge Acquisition, Lecture Notes in Artificial Intelligence (LNAI) 599,
Springer-Verlag, Berlin, 1992.
[Angele et al., 1998] J. Angele, D. Fensel, and R. Studer: Developing Knowledge-Based Systems
with MIKE, to appear in Journal of Automated Software Engineering, 1998.
[Bauer & Karbach, 1992] C. Bauer and W. Karbach (eds.): Interpretation Models for KADS Proceedings of the 2nd KADS User Meeting (KUM´92), Munich, February 17-18, 1992, GMD
report no. 212, 1992.
[Benjamins, 1995] V. R. Benjamins: Problem Solving Methods for Diagnosis And Their Role in
Knowledge Acquisition, International Journal of Expert Systems: Research and Application,
8(2):93—120, 1995.
[Benjamins et al., 1998] V. R. Benjamins, E. Plaza, E. Motta, D. Fensel, R. Studer, B. Wielinga, G.
Schreiber, Z. Zdrahal: An Intelligent Brokering Service for Knowledge-Component Reuse on
the World-WideWeb. In Proceedings of the 11th Banff Knowledge Acquisition for KnowledgeBased System Workshop (KAW´98), Banff, Canada, April 18-23, 1998.
[Benjamins & Fensel, 1998] V. R. Benjamins and D. Fensel: Special issue on problem-solving
methods of the International Journal of Human-Computer Studies (IJHCS), to appear 1998.
[Beys et al., 1996] P. Beys, R. Benjamins, and G. van Heijst: Remedying the Reusability-Usability
Trade-off for Problem-solving Methods. In Proceedings of the 10th Banff Knowledge
Acquisition for Knowledge-Based System Workshop (KAW´96), Banff, Canada, November 914, 1996.
[Breuker, 1997] J. Breuker: Problems in Indexing Problem Solving Methods. In Proceedings of the
Workshop on Problem-Solving Methods for Knowledge-based Systems (W26) during the
Fifteenth International Joint Conference on Artificial Intelligence (IJCAI-97), NAGOYA,
Japan, August 23-29, 1997.
[Breuker et al., 1987] J. Breuker, B. Wielinga, M. van Someren, R. de Hoog, G. Schreiber, P. de
Greef, B. Bredeweg, J. Wielemaker, and j.-P. Billault: Model-Driven Knowledge Acquisition:
Interpretation Models, Esprit Project 1098, 1987.
[Breuker & Van de Velde, 1994] J. Breuker and W. Van de Velde (eds.): The CommonKADS
Library for Expertise Modeling, IOS Press, Amsterdam, The Netherlands, 1994.
[Bundy, 1990] A. Bundy (ed.): Catalogue of Artificial Intelligence Techniques, 3rd ed., SpringerVerlag, Berlin, 1990.
[Bylander & Chandrasekaran, 1988] T. Bylander and B. Chandrasekaran: Generic Tasks in
Knowledge-Based Reasoning. The Right Level of Abstraction for Knowledge Acquisition. In
- 39 -
date: 28.4.98
40.1
40.2
40.3
40.4
40.5
40.6
40.7
40.8
40.9
40.10
40.11
40.12
40.13
40.14
40.15
40.16
40.17
40.18
40.19
40.20
40.21
40.22
40.23
40.24
40.25
40.26
40.27
40.28
40.29
40.30
40.31
40.32
40.33
40.34
40.35
40.36
40.37
40.38
40.39
40.40
40.41
40.42
40.43
40.44
B. Gaines et al. (eds.): Knowledge Acquisition for Knowledge-Based Systems, vol I, pp. 65—
77, Academic Press, London, 1988.
[Chandrasekaran, 1986] B. Chandrasekaran: Generic Tasks in Knowledge-based Reasoning: Highlevel Building Blocks for Expert System Design. IEEE Expert, 1(3): 23—30, 1986.
[Chandrasekaran, 1990] B. Chandrasekaran: Design Problem Solving: A Task Analysis, AI
Magazine, 1990, 59—71.
[Chandrasekaran et al., 1992] B. Chandrasekaran, T.R. Johnson, and J. W. Smith: Task Structure
Analysis for Knowledge Modeling, Communications of the ACM, 35(9):124—137, 1992.
[Clancey, 1985] W.J. Clancey: Heuristic Classification, Artificial Intelligence, 27:289—350, 1985.
[Clancey, 1992] W.J. Clancey: Model Construction Operator, Artificial Intelligence, 53:1—111,
1992.
[Dechter, 1988] R. Dechter: Constraint Processing Incorporating Backjumping, Learning and
Cutset-Decomposition. In Proceedings of the 4th Conference on Artificial Intelligence
Applications - CAIA'88, pp. 312—319, 1988.
[Eriksson et al., 1995] H. Eriksson, Y. Shahar, S. W. Tu, A. R. Puerta, and M. A. Musen: Task
Modeling with Reusable Problem-Solving Methods, Artificial Intelligence, 79(2):293—326,
1995.
[Feigenbaum, 1977] E. A. Feigenbaum: The Art of Artificial Intelligence: Themes and Case Studies
of Knowledge Engineering. In Proceedings of the 5th International Joint Conference on
Artificial Intelligence (AAA)-77), Cambridge, MA, 1977.
[Fensel, 1995a] D. Fensel: Assumptions and Limitations of a Problem-Solving Method: A Case
Study. In Proceedings of the 9th Banff Knowledge Acquisition for Knowledge-Based System
Workshop (KAW´95), Banff, Canada, January 26 - February 3, 1995.
[Fensel, 1995b] D. Fensel: Formal Specification Languages in Knowledge and Software
Engineering, The Knowledge Engineering Review, 10(4):361—404, 1995.
[Fensel, 1997] D. Fensel: The Tower-of-Adapter Method for Developing and Reusing ProblemSolving Methods. In E. Plaza et al. (eds.), Knowledge Acquisition, Modeling and Management,
Lecture Notes in Artificial Intelligence (LNAI) 1319, Springer-Verlag, 1997.
[Fensel & Benjamins, 1998] D. Fensel and R. Benjamins: The Role of Assumptions in Knowledge
Engineering, International Journal of Intelligent Systems (IJIS), 13(7), 1998.
[Fensel et al., 1996a] D. Fensel, H. Eriksson, M. A. Musen, and R. Studer: Conceptual and Formal
Specification of Problem-Solving Methods, International Journal of Expert Systems, 9(4),
1996.
[Fensel et al., 1996b] D. Fensel, A. Schönegge, R. Groenboom and B. Wielinga: Specification and
Verification of Knowledge-Based Systems. Proceedings of the ECAI-96 Workshop Validation,
Verification and Refinement of Knowledge-Based Systems, at the 12th European Conference
on Artificial Intelligence (ECAI-96), Budapest, Hungaria, August 1996.
[Fensel et al., 1997] D. Fensel, E. Motta, S. Decker, and Z. Zdrahal: Using Ontologies For Defining
Tasks, Problem-Solving Methods and Their Mappings. In E. Plaza et al. (eds.), Knowledge
Acquisition, Modeling and Management, Lecture Notes in Artificial Intelligence (LNAI) 1319,
Springer-Verlag, 1997.
[Fensel et al., to appear] D. Fensel, R. Groenboom, and G. R. Renardel de Lavalette: Modal Change
Logic (MCL): Specifying the Reasoning of Knowledge-based Systems, Data and Knowledge
- 40 -
date: 28.4.98
41.1
41.2
41.3
41.4
41.5
41.6
41.7
41.8
41.9
41.10
41.11
41.12
41.13
41.14
41.15
41.16
41.17
41.18
41.19
41.20
41.21
41.22
41.23
41.24
41.25
41.26
41.27
41.28
41.29
41.30
41.31
41.32
41.33
41.34
41.35
41.36
41.37
41.38
41.39
41.40
41.41
41.42
41.43
41.44
Engineering (DKE), 25(),1998.
[Fensel & Groenboom, 1996] D. Fensel and R. Groenboom: MLPM: Defining a Semantics and
Axiomatization for Specifying the Reasoning Process of Knowledge-based Systems. In
Proceedings of the 12th European Conference on Artificial Intelligence (ECAI-96), Budapest,
August 12-16, 1996.
[Fensel & Groenboom, 1997] D. Fensel and R. Groenboom: Specifying Knowledge-Based Systems
with Reusable Components. In Proceedings of the 9th International Conference on Software
Engineering & Knowledge Engineering (SEKE-97), Madrid, Spain, June 18-20, 1997.
[Fensel & Schönegge, 1997] D. Fensel and A. Schönegge: Using KIV to Specify and Verify
Architectures of Knowledge-Based Systems. In Proceedings of the 12th IEEE International
Conference on Automated Software Engineering (ASEC-97), Incline Village, Nevada,
November 3-5, 1997.
[Fensel & Schönegge, 1998] D. Fensel and A. Schönegge: Inverse Verification of Problem-Solving
Methods, to appear in [Benjamins & Fensel, 1998].
[Fensel & Straatman, 1998] D. Fensel und R. Straatman: The Essence of Problem-Solving
Methods: Making Assumptions to Gain Efficiency, The International Journal of Human
Computer Studies (IJHCS), International Journal on Human-Computer Studies (IJHCS),
48(2):181-215, 1998..
[Fensel & van Harmelen, 1994] D. Fensel and F. van Harmelen: A Comparison of Languages which
Operationalize and Formalize KADS Models of Expertise, The Knowledge Engineering
Review, 9(2):105—146, 1994.
[Fuchs & Fromherz, 1991] N. E. Fuchs and M. P. Fromherz: Schema-Based Transformations of
Logic Programs. In Proceedings of LOPSTER 91, International Workshop on Logic Program
Synthesis and Transformation, University of Manchester, July 4-5, Springer-Verlag, Berlin,
1991.
[Gamma et al., 1995] E. Gamma, R. Helm, R. Johnson, and J. Vlissides: Design Patterns, AddisonWesley Pub., 1995.
[Gaines, 1994] B. R. Gaines: A Situated Classification Solution of a Resource Allocation Task
Represented in a Visual Language. In [Linster, 1994], pp. 243—271.
[Gaschnig, 1978] J. Gaschnig; Experimental case studies of Backtrack vs. Waltz-type vs. new
algorithms for satisfying assignment problems. In Proceedings of the 2nd Biennial Conference
of the Canadian Society for Computational Studies of Intelligence, Toronto, July 1978.
[Gennari et al., 1996] J. H. Gennari, A. R. Stein, and M. A. Musen: Reuse for Knowledge-Based
Systems and CORBA Components. In Proceedings of the 10th Banff Knowledge Acquisition
for Knowledge-Based System Workshop (KAW´96), Banff, Canada, November 9-14, 1996.
[Graham & Bailor, 1996] R. P. Graham, Jr. and P. D. Bailor: Synthesis of Local Search Algorithms
by Algebraic Means. In Proceedings of the 11th Knowledge-Based Software Engineering
Conference (KBSE-96), 1996.
[Heineman, 1997] G. T. Heineman: A Model for Designing Adaptable Software Components,
Computer Science Technical Report Series, Worcester Polytechnic Institute, WPI-CS-TR-976, September 1997.
[HPKB, 1997] High Performance Knowledge Bases (HPKB). Darpa Project. Details available from
http:// www.teknowledge.com:80/HPKB/, 1997.
- 41 -
date: 28.4.98
42.1
42.2
42.3
42.4
42.5
42.6
42.7
42.8
42.9
42.10
42.11
42.12
42.13
42.14
42.15
42.16
42.17
42.18
42.19
42.20
42.21
42.22
42.23
42.24
42.25
42.26
42.27
42.28
42.29
42.30
42.31
42.32
42.33
42.34
42.35
42.36
42.37
42.38
42.39
42.40
42.41
42.42
42.43
42.44
[Klinker et al., 1991] G. Klinker, C. Bhola, G. Dallemagne, D. Marques, and J. McDermott: Usable
and Reusable Programming Constructs, Knowledge Acquisition, 3:117—136, 1991.
[Landes & Studer, 1995] D. Landes and R. Studer: The Treatment of Non-Functional Requirements
in MIKE. Proceedings of the 5th European Software Engineering Conference (ESEC´95),
Sitges, Lecture Notes in Computer Science, LNCS 989, Springer-Verlag, Berlin, 1995.
[Linster, 1994] M. Linster (ed.): Sisyphus ´91/92: Models of Problem Solving, International
Journal of Human-Computer Studies (IJHCS), 40(3), 1994.
[Lipman, 1991] B. L. Lipman: How to Decide How to Decide Hot to ...: Modeling limited
Rationality, Econometria, 59(4);1105—1125, 1991.
[Marcus, 1988] S. Marcus (ed.): Automating Knowledge Acquisition for Experts Systems, Kluwer
Academic Publisher, Boston, 1988.
[Marcus et al., 1988] S. Marcus, J. Stout, and J. McDermott VT: An Expert Elevator Designer That
Uses Knowledge-based Backtracking, AI Magazine, 9(1):95—111, 1988.
[Mittal & Frayman, 1989] S. Mittal and F. Frayman: Towards a Generic Model of Configuration
Tasks. In Proceedings of the 11th International Joint Conference on Artificial Intelligence (IJCAI‘89), San Mateo, CA, 1989.
[Motta, 1997] E. Motta: Reusable Components for Knowledge Modeling, Ph.D. Thesis, Knowledge
Media Institute, The Open University, UK, 1997.
[Motta & Zdrahal, 1996] E. Motta and Z. Zdrahal: Parametric Design Problem Solving. In
Proceedings of the 10h Banff Knowledge Acquisition for Knowledge-Based System Workshop
(KAW´96), Banff, Canada, November 9-15, 1996.
[Motta & Zdrahal, 1998] E. Motta and Z. Zdrahal: An approach to the organization of a library of
problem solving methods which integrates the search paradigm with task and method
ontologies, to appear in [Benjamins & Fensel, 1998].
[Newell & Simon, 1976] A. Newell and H. A. Simon: Computer Science as Empirical Enquiry:
Symbols and Search, Communications of the ACM, 19(3):113—126, 1976.
[O'Hara, 1995] K. O'Hara: The GDM Grammar, v.4.6. VITAL Project Report NOTT/T252.3.3.
Available from the author at AI Group, Department of Psychology, University of Nottingham,
UK, 1995.
[Orsvärn, 1996] K. Orsvärn: Principles for Libraries of Task Decomposition Methods—
Conclusions from a Case-study.
In N. Shadbolt et al. (eds), Advances in Knowledge
Acquisition, Lecture Notes in Artificial Intelligence, 1076. Springer-Verlag, Berlin, pp. 48—
65, 1996.
[Poeck et al., 1996] K. Poeck, D. Fensel, D. Landes, and J. Angele: Combining KARL And CRLM
For Designing Vertical Transportation Systems. In [Schreiber & Birmingham, 1996].
[Poeck & Puppe, 1992] K. Poeck and F. Puppe: COKE: Efficient Solving of Complex Assignment
Problems with the Propose- and-Exchange Method. In Proceedings of the 5th International
Conference on Tools with Artificial Intelligence, Arlington, Virginia, USA, 1992.
[Puerta et al., 1992] A. R. Puerta, J. W. Egar, S. W. Tu, and M. A. Musen, A Multiple-Method
Knowledge Acquisition Shell for the Automatic Generation of Knowledge Acquisition Tools,
Knowledge Acquisition 4:171—196, 1992.
[Puppe, 1993] F. Puppe: Systematic Introduction to Expert Systems: Knowledge Representation and
Problem-Solving Methods, Springer-Verlag, Berlin, 1993.
- 42 -
date: 28.4.98
43.1
43.2
43.3
43.4
43.5
43.6
43.7
43.8
43.9
43.10
43.11
43.12
43.13
43.14
43.15
43.16
43.17
43.18
43.19
43.20
43.21
43.22
43.23
43.24
43.25
43.26
43.27
43.28
43.29
43.30
43.31
43.32
43.33
43.34
43.35
43.36
43.37
43.38
43.39
43.40
43.41
43.42
43.43
43.44
[Runkel et al., 1996] J. T. Runkel, W. B. Birmingham, and A. Balkany: Solving VT by Reuse. In
[Schreiber & Birmingham, 1996], pp. 403—433.
[Schreiber & Birmingham, 1996] A. Th. Schreiber and B. Birmingham (eds.): Special Issue on
Sisyphus, International Journal of Human-Computer Studies (IJHCS), 44(3-4), 1996.
[Schreiber et al., 1994] A. TH. Schreiber, B. Wielinga, J. M. Akkermans, W. Van De Velde, and R.
de Hoog: CommonKADS. A Comprehensive Methodology for KBS Development, IEEE
Expert, 9(6):28—37, 1994.
[Shaw & Garlan, 1996] M. Shaw and D. Garlan: Software Architectures. Perspectives on an
Emerging Discipline, Prentice-Hall, 1996.
[Smith & Lowry, 1990] D. R. Smith and M. R. Lowry: Algorithm Theories and Design Tactics,
Science of Computer Programming, 14:305—321, 1990.
[Steels, 1990] L. Steels: Components of Expertise, AI Magazine, 11(2), 1990.
[Stefik, 1995] M. Stefik: Introduction to Knowledge Systems, Morgan Kaufman Publ., San
Francisco, 1995.
[Stout et al., 1988] J. Stout, G. Caplain, S. Marcus, and J. McDermott: Toward Automating
Recognition of Differing Problem-Solving Demands, International Journal of Man-Machine
Studies (IJMCS), 29(5): 599—611, 1998.
[Stutt & Motta, 1995] A. Stutt and E. Motta: Recording the design decisions of a knowledge
engineering community to facilitate re-use of design models. In Proceedings of the 9th Banff
Knowledge Acquisition for Knowledge-Based System Workshop (KAW´95), Banff, Canada,
January 26 - February 3, 1995.
[ten Teije, 1997] A. ten Teije: Automated Configuration of Problem Solving Methods in Diagnosis,
Ph.D. thesis, University of Amsterdam, the Netherlands, 1997.
[Terpstra et al., 1993] P. Terpstra, G. van Heijst, B. Wielinga, and N. Shadbolt: Knowledge
Acquisition Support Through Generalized Directive Models. In M. David et al. (eds.): Second
Generation Expert Systems, Springer-Verlag, 1993.
[Van de Velde, 1994] W. Van de Velde: A Constructivistic View on Knowledge Engineering. In
Proceedings of the 11th European Conference on Artificial Intelligence (ECAI-94),
Amsterdam, the Netherlands, August 1994.
[van Heijst et al., 1992] G. van Heijst, P. Terpstra, B. J. Wielinga and N. Shadbolt: Using
Generalized Directive Models in Knowledge Acquisition. In T. Wetter et al. (eds.), Current
Developments in Knowledge Acquisition, Lecture Notes in Artificial Intelligence (LNAI),
Springer-Verlag, 1992.
[Wiederhold, 1992] G Wiederhold: Mediators in the Architecture of Future Information Systems,
IEEE Computer, 25(3):3849, 1992.
[Wiederhold & Genesereth, 1997] G. Wiederhold and M. Genesereth: The Conceptual Basis for
Mediation Services, IEEE Expert, September/October, pp. 3847,1997.
[Wielinga et al., 1995] B. Wielinga, J. M. Akkermans, and A. TH. Schreiber: A Formal Analysis of
Parametric Design Problem Solving. In Proceedings of the 9th Banff Knowledge Acquisition
for Knowledge-Based System Workshop (KAW´95), Banff, Canada, January 26 - February 3,
1995.
[Yellin & Strom, 1997] D. M. Yellin and R. E. Strom: Protocol Specifications and Component
Adapters, ACM Transactions on Programming Languages and Systems, 19(2):292—333,
- 43 -
date: 28.4.98
1997.
44.1
44.2 [Zdrahal & Motta, 1995] Z. Zdrahal and E. Motta: An In-Depth Analysis of Propose & Revise
44.3
Problem Solving Methods. In Proceedings of the 9th Banff Knowledge Acquisition for
Knowledge-Based System Workshop (KAW´95), Banff, Canada, January 26 - February 3,
44.4
1995.
44.5
44.6 [Zdrahal & Motta, 1996] Z. Zdrahal and E. Motta: Improving Competence by Integrating CaseBased Reasoning and Heuristic Search. In Proceedings of the 10th Banff Knowledge
44.7
Acquisition for Knowledge-Based System Workshop (KAW´96), Banff, Canada, November 944.8
14, 1996.
44.9
44.10
44.11
44.12
44.13
44.14
44.15
44.16
44.17
44.18
44.19
44.20
44.21
44.22
44.23
44.24
44.25
44.26
44.27
44.28
44.29
44.30
44.31
44.32
44.33
44.34
44.35
44.36
44.37
44.38
44.39
44.40
44.41
44.42
44.43
44.44
- 44 -