=Paper=
{{Paper
|id=Vol-18/paper-8
|storemode=property
|title=Representing Capabilities of Problem Solving Methods
|pdfUrl=https://ceur-ws.org/Vol-18/8-swartout.pdf
|volume=Vol-18
}}
==Representing Capabilities of Problem Solving Methods==
https://ceur-ws.org/Vol-18/8-swartout.pdf
Representing Capabilities of
Problem Solving Methods
Bill Swartout Yolanda Gil Andre Valente
USC USC USC
Information Sciences Institute Information Sciences Institute Information Sciences Institute
4676 Admiralty Way 4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292 Marina del Rey, CA 90292 Marina del Rey, CA 90292
swartout@isi.edu gil@isi.edu valente@isi.edu
MacDermott 1988; Breuker and Van de Velde 1994].
Abstract Rather than building a system from scratch, as is
current practice, system builders would assemble a
In order to develop and use shared libraries of knowledge based system from reusable components
problem-solving methods, it is of paramount drawn from shared ontologies and libraries of problem
importance to provide adequate descriptions of solving methods. By reusing components, this
their capabilities and competence. Methods approach should allow knowledge-based systems to be
must be indexed and organized based on their constructed more rapidly. Further, the resulting
capabilities so that they can be retrieved when systems should be more error free since they will be
their capability is adequate for the task at constructed from existing (and presumably debugged)
hand. This paper describes the approach taken resources. Finally, because the emphasis in system
in EXPECT for representing method construction will be on assembling existing
capabilities and argues that it has important components, rather than building things from scratch,
features that should be used for describing it should be possible for less experienced individuals to
methods in shared libraries. EXPECT’s build knowledge based systems successfully.
capability representation is tightly coupled
with the domain ontologies in the knowledge But how should these libraries of problem solving
base, can express task-related parameters methods be organized? How can the capabilities of
explicitly, and is based on case grammars. problem solving methods be represented? This
This representation allows the system to approach to system construction will only work if
reason about the capability descriptions people (and machines) can easily find the methods that
through class subsumption and reformulation. are capable of addressing the problem at hand. Other
The benefits of this approach include self- approaches, such as CommonKADS, use a functional
organizing method libraries, reuse, and specification of method capabilities. However, the
support for explanation. The representation has matching of these capabilities with problem goals in
already been used extensively within e.g. the CommonKADS Library [Valente et.al., 1998]
EXPECT to express a wide range of method are meant to be done by a human that analyzes a semi-
capabilities, ranging from abstract to specific, formal method description. The library is organized
small to large, and domain-dependent to “by design”, for example using typologies of methods
general-purpose methods. The paper also and explicit collections of related decompositions.
discusses some of the additional features that
we anticipate will be useful to structure shared In contrast, our approach aims to build a library of
method libraries. problem-solving methods that is self-organizing, in the
sense that we can automatically find the right place for
a new method in the library and have tools that can use
1 Introduction the library to build a problem solver for a specific
Libraries of problem solving methods could facilitate problem. We believe such a library will enhance
the construction and adaptation of knowledge based reusability. Also, we want to have capabilities that are
systems [Chandrasekaran 1986; Eriksson et al. 1995; amenable to produce explanations – both of the
methods and the systems constructed using these
methods. To achieve these goals, we need a rich and
The copyright of this paper belongs to the papers authors. expressive specification of method capabilities that
Permission to copy without fee all or part of this material is granted allows the system to reason about the capability
provided that the copies are not made or distributed for direct
commercial advantage. descriptions through class subsumption and
Proceedings of the IJCAI-99 workshop on Ontologies reformulation.
and Problem-Solving Methods (KRR5) Stockholm,
Sweden, August 2, 1999 In this paper we describe the approach we have been
(V.R. Benjamins, B. Chandrasekaran, A. Gomez-Perez, N. using to represent problem solving method capabilities
Guarino, M. Uschold, eds.) in EXPECT, our knowledge based system framework
http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-18/
Swartout, Gil, Valente 8-1
Expectation-based Tools for Knowledge Acquisition
KB expectation agenda
modifiers builder manager
Knowledge Bases
Ontology
and Domain-
Factual K specific
KBS KBS Execution
Compiler Trace
Problem
Solving
User
Knowledge Interaction
(strategies) Interdependency LISP Manager/
Model code Interpreter Explainer
(Design History)
Automatic
Method
Instantiator
Figure 1: EXPECT Architecture
that supports knowledge acquisition [Swartout and Gil the details of the implementation. Figure 1 shows the
1995; Gil 1994; Gil and Melz 1996]. We begin with a architecture of EXPECT.
brief overview of the EXPECT framework, followed by
a discussion of a set of desiderata that motivated the EXPECT uses Loom [MacGregor 1991] to represent
design of our representation for method capabilities. domain facts and the domain ontology. Loom is a
We then discuss the representation we use in detail. description logic-based representation. Like other
description logics, Loom is based on a semantic
network approach to knowledge representation.
2 The EXPECT Framework Concepts in Loom are descriptions of objects (which
A major goal of the EXPECT framework is to allow may or may not actually exist) while Loom instances
domain experts to change and add knowledge to a represent objects that do exist. Concepts can have roles
knowledge based system. EXPECT keeps track of the which may be used to specify attributes of the concept.
interdependencies in a knowledge based system, such A distinguishing feature of description logics like
as what factual knowledge must be present to support Loom is that they provide a way of precisely defining
the problem solving methods that the KBS uses, and the meaning of a concept, that is, what it denotes.
how factual knowledge is used in problem solving. For Loom provides a classifier, which is a reasoner that
instance, in a configuration system that uses propose- uses concept definitions to determine whether one
and-revise as its problem solving method, each concept subsumes another concept. Specifically, a
constraint must have one or more associated “fixes” concept A is said to subsume a concept B if all the
that are used in problem solving to resolve a violation possible entities that could be described by B are also
of the constraint when it occurs. This is an example of necessarily described by A. For example, ``a man who
a dependency that arises between the domain only drinks beer'' subsumes ``a man who only drinks
representation of constraints and the problem solving imported beer.'' The classifier can determine whether
method. EXPECT captures such dependencies in an all the instances that could possibly be described by
interdependency model which is specific to each one concept are also necessarily described by another
knowledge based system built in EXPECT. When based on the definitions of the two concepts. As a
new knowledge is added to a knowledge based system, result, it is possible to automatically organize concepts
EXPECT examines the interdependency model to into an AKO (a kind of) lattice based only on their
determine what additional knowledge must be provided definitions.
to make the new knowledge usable by the problem
solving methods currently employed in the system. In EXPECT, a goal represents a task to be done or a
Similarly, if one of the problem solving methods is problem to be solved. Problem solving methods are
modified, EXPECT rederives the interdependency used to accomplish these goals. Each problem solving
model to determine if any of the dependencies have method has a capability description which describes
changed. If so, it will request the needed additional the kinds of problems the method can solve and a
information from the user. In this way, EXPECT method body which consists of step(s) for achieving the
helps a user modify and adapt a knowledge based method’s capability. These steps may include
system while freeing him from the need to understand subgoals. Figure 2 shows an example of a problem-
Swartout, Gil, Valente 8-2
CAPABILITY
(compute (obj ?d is (spec-of LinesOfComm-distance))
(for ?coa is (inst-of coa)))
RESULT-TYPE (inst-of distance-value)
BODY
(if (equal (obj (count (obj (r-locations ?coa)))) (to 1))
then
(take (obj (spec-of maximum)) control constructs
(of (find (obj (spec-of distance))
(between (set-of (spec-of geoloc)))
(in ?coa))))
else subgoal posting
(take (obj (spec-of maximum))
(of (find (obj (spec-of distance))
(from (r-locations ?coa)) retrieval of facts
(to (r-locations ?coa))))))
Figure 2: An EXPECT Method
solving method in EXPECT. The method computes outline the desiderata that led to EXPECT’s
the distance of lines of communication in a course of representation for capability descriptions and goals.
action (COA).
• A representation tied to the domain ontology. We
As we described above, EXPECT’s interdependency wanted a representation that was tied to the
model captures part of the design of the knowledge ontologies used in EXPECT so that goals could be
based system. EXPECT creates an interdependency defined using terms from the domain. Further,
model for a knowledge based system by synthesizing integrating the representation for capability
the system from a set of abstract problem solving descriptions and goals with the domain ontology
methods and knowledge about a domain. As it assures us that the semantics of the two
synthesizes the system, EXPECT records how different representations will be consistent.
parts of the system depend on each other in the
• A broad spectrum representation. Some problem
interdependency model.
solving methods are very general, while others are
especially tuned to work in highly specialized
EXPECT uses a form of partial evaluation and
situations. We believe that problem-solving method
hierarchical decomposition to create a knowledge based
libraries need to include both kinds of methods.
system. Starting with an initial high level goal that
General methods will provide broad coverage and
specifies what the knowledge based system is supposed
allow us to build robust systems, while highly
to do, EXPECT looks for a method whose capability
specific methods will substantially enhance
description matches the goal. When a method is
efficiency in specific situations. We wanted a
found, its method body is instantiated by replacing
representation that would allow us to describe the
variables in the method with corresponding instances
capabilities of both very general and highly domain-
in the goal. The instantiation of the method body may
specific methods.
result in the posting of subgoals, in which case the
process recurs. If no method can be found for a goal, • Support for “loose coupling” between goals and
EXPECT attempts to reformulate the goal into a new method capabilities. Reuse of problem solving
goal or set of goals that are semantically equivalent to methods will be increased if the capability
the original. It then attempts to achieve these new descriptions of the methods don’t have to match
goals, as we describe below. During this entire goals exactly. We wanted a representation that
process, EXPECT records in the interdependency would allow the system to find methods that could
model how specific factual information is used in work for a particular goal, even if they did not match
expanding the problem solving methods, thus it exactly.
capturing how different parts of the system depend on • Support for reformulation. Loose coupling and
each other. reuse can be further increased if goals can be
reformulated. Reformulation involves mapping a
3 Desiderata for the Representation of goal into a new goal or set of goals that is
semantically equivalent to the original goal.
Capability Description and Goals Reformulation allows the system to find a way of
Linking up goals and problem-solving methods is a achieving a goal even if a problem-solving method
critical part of EXPECT’s approach to knowledge could not be matched against the original goal. To
acquisition, and it places a number of demands on the be able to automatically reformulate a goal, the
representation of goals and the capability descriptions semantics of the individual terms that comprise the
of problem solving methods. In this section we goal must be well specified so that they can be
Swartout, Gil, Valente 8-3
mapped into new terms to create equivalent goals. are not strictly necessary to perform the computation
• Understandable by users. Since a goal of the itself. The fact that roles can be used both to specify
EXPECT effort is to support knowledge acquisition the parameters or objects that will be involved in a task
from domain experts, we wanted a representation that and to further describe or specify the task itself is one
could be easily understood or paraphrased into of the key capabilities that our representation supports,
English. providing us with a rich language for specifying goals.
• Self-organizing. In our view, problem solving Roles can be a type of an instance, as in:
method libraries are likely to become quite large in divide OBJ (inst-of number) BY 2
the future. Further, both AI experts and non-experts
will contribute to these libraries and use methods This results in a generic goal that can be instantiated
from them. For these reasons we felt it was with any elements of that type.
important to have a representation for method
capabilities that would support self-organization, Roles can also be filled by extensional sets as in:
that is, that would allow us to organize the methods
into a hierarchy automatically based on their find OBJ (spec-of maximum)
capability descriptions. This would allow either a OF (42 2 99)
machine or person to find methods that were
or they can be filled by intensional sets, where the set
applicable to a particular problem easily.
is described by a concept:
In the next section, we describe our representation for find OBJ (set-of
goals and method capabilities that helps us achieve the (spec-of
desiderata outlined above. violated-constraint))
IN (inst-of configuration)
4 Representing Goals and Capabilities Finally, it is possible to use descriptions (which are
EXPECT uses a structured representation for goals that similar to the definitions of Loom concepts) in roles:
arise during problem solving and the capabilities of estimate OBJ support-personnel
methods that can be used to achieve those goals. Goals IN (and location
and capabilities are represented as verb clauses using a (exactly 0 seaports))
case-grammar style formalism [Fillmore 1968]. Each
goal consists of a verb, which specifies what is to be This is a goal to estimate the support personnel in a
done, and a number of roles, or slots, which specify the location with no seaports.
parameters to be used in the action. The parameters use
terms that are defined in the domain ontology. For This approach provides us with a rich language for
example, the goal of estimating the closure date of specifying behaviors. The use of a case grammar
particular transportation movement would be specified formalism makes it relatively straightforward to
roughly as: paraphrase the goals into natural language helping to
estimate OBJ closure-date OF make them more understandable [Swartout et al. 1991].
transportation-movement-1
Here, estimate is the verb, and the roles are indicated in Capability descriptions for methods are specified in a
upper case. Roles are filled by Loom concepts and similar way, except that variables may appear in the
instances taken from the ontology, which couples our capability descriptions. These are bound when the
representation with the ontology. capability descriptions are matched with goals. Figure
2 shows an example of a method and its capability.
In EXPECT, roles can be filled in several different
ways, which allows considerable flexibility in As we just showed, EXPECT’s language to describe
specifying a task to be done. A role can be filled by a goals and capabilities is very expressive. An important
specific instance: aspect of EXPECT is how it reasons about method
add OBJ 3 TO 5 capabilities with this representation, exploiting
which allows us to specify particular instances that are subsumption and reformulation as we describe next.
to be used in an action. A role can be filled by a Further details can be found in [Swartout and Gil 1995;
concept: Gil and Gonzalez 1996].
compute OBJ (spec-of factorial) of 7
4.1 Creating LOOM Descriptions of Goals and
Capabilities
In this case, the concept factorial is used to We described earlier how EXPECT relies on LOOM’s
specify the kind of task that is to be done. The data classifier to automatically organize concepts in an AKO
required to perform the computation are specified as lattice. EXPECT also relies on the LOOM classifier to
parameters (in this case the number 7), while these reason about what goals and capabilities subsume
additional task parameters allow us to express what others. This is achieved by turning goals and
needs to be done with that data in an explicit way and capabilities into LOOM descriptions. EXPECT has a
Swartout, Gil, Valente 8-4
method OBJ
hierarchy cargo
move
WITH
vehicle
method-1
Method capability:
(move OBJ
(OBJ (inst-of cargo)) cargo
move OBJ
(WITH (inst-of aircraft))) WITH cargo
method-2 aircraft move
WITH
Goal: method-3
ship
(move
(OBJ (inst-of cargo))
(WITH C-140)) OBJ
cargo
move
WITH
goal-1 C-140
Figure 3: Translating Goals and Capabilities to Loom to organize and retrieve methods
core set of Loom definitions that are used for this, and them in a lattice, where more general definitions
include action name (its subclasses are essentially subsume more specific ones. Notice that this
verbs), action role (its subclasses are OBJ and any subsumption reasoning uses the definitions of the
parameter name), goal, and capability. Action roles domain terms and ontologies that are part of
are relations whose domain is an action name, and EXPECT’s knowledge bases. As a result, the
whose range can be any existing concept in the domain capability of a method to “move cargo with a vehicle”
(ex: ship, number) qualified by its parameter type (set will subsume one to “move cargo with an aircraft”,
or element, concept or instance, extensional or because according to the domain ontologies vehicle
intensional). For example, the goal to compute the subsumes aircraft. This is illustrated in the method
factorial of a number is expressed in EXPECT as: hierarchy shown in Figure 3. As a result, EXPECT’s
methods are automatically organized according to their
(compute capabilities, and their capabilities can be compared
(obj (spec-of factorial) based on their place in the lattice.
(of (inst-of number)))
4.3 Matching Goals and Capability
The corresponding Loom definition that is created is: Descriptions
(defconcept CM20 EXPECT also exploits the representation of goals and
:is (:and compute capabilities for matching method capabilities with the
(:the obj (:and concept-desc goals that arise during problem solving. EXPECT’s
factorial)) matcher first translates the posted goal into a Loom
(:the of (:and instance-desc concept, and then invokes the Loom classifier in order
number)))) to find methods whose capability descriptions subsume
the posted goal. Figure 3 illustrates this matching
LOOM’s classifier is now able to reason with this
process for the goal of moving some cargo with a C-
definition. Every term used in the parameters have
140 (which is a particular kind of aircraft).
their own definitions, provided in the ontologies, and
LOOM will use them in reasoning about goal
Once the match has been made using the Loom
subsumption. Notice that these terms and their
representation for the goal and capabilities, the original
definitions can be domain independent (e.g., violated-
representation is used to bind parameters in the goal to
constraints, maximum) or domain dependent (e.g.,
corresponding variables in the capability description.
location, closure-date).
This is necessary since Loom does not support
variables in concepts.
4.2 Self-Organizing Method Libraries
Using the techniques just described, EXPECT creates 4.4 Reformulating Goals
Loom definitions for the capabilities of all the methods
When a goal is posted while EXPECT is synthesizing
that are defined in the knowledge base. Loom’s
a knowledge based system and no method can be found
classifier reasons about these definitions and places
with a matching capability, EXPECT attempts to
Swartout, Gil, Valente 8-5
support personnel estimate support personnel
PARTITION COVERING
REFORMULATION
unloading personnel
seaport estimate unloading personnel
support personnel
estimate seaport support personnel
airport
support personnel estimate airport support personnel
Figure 4: A covering reformulation
reformulate the goal by transforming it into a new goal possible ways to accomplish it. Goal reformulations
(or set of goals) that is equivalent to the original goal, also illustrate how method libraries can leverage from
but expressed in different terms. EXPECT then tries to domain ontologies and their structure.
find methods for achieving these new goals. This
automatic reformulation allows EXPECT to reuse
methods in a broader range of circumstances than would 5 Related Work
be possible if EXPECT required an exact match for
Several groups have proposed approaches for
goals and methods. EXPECT supports several types of
representing PSM capabilities. In CommonKADS
reformulations.
methodology and related work [Schreiber et al 1994,
• A covering reformulation is a form of divide Valente et al 1998], method capabilities are represented
and conquer. It transforms a goal into a set of goals in a functional way, i.e., by specifying inputs and
that partition the original goal. If all the goals in outputs, plus the knowledge used in the process (called
the set are achieved, the intent of the original goal is static knowledge). Part of the semantics was also
achieved. Figure 4 shows an example covering expressed by relating the method to an element of a
reformulation. A goal of estimating support typology of methods, typically at the lowest grain size
personnel has been posted, but no applicable level (the so-called canonical inferences, see [Aben,
methods have been found. Because EXPECT’s 1993]) or at the highest grain-size level (e.g. the suite
ontology (as shown on the left in Figure 4) indicates of problem types by [Breuker, 1997]). Despite the fact
that the concept support personnel is partitioned into that EXPECT also models inputs and outputs of
unloading personnel, seaport support personnel and methods, there are many differences between the two
airport support personnel, EXPECT can reformulate approaches. First, EXPECT uses the case frame
the original goal into three new goals as indicated on representation to establish a hierarchy of types of goals,
the right in Figure 4. while there is no such notion in CommonKADS.
• A set reformulation is like a covering Second, because the EXPECT framework is based on
reformulation except that it involves a goal over a the idea of deriving or finding what knowledge is used
set of objects which is reformulated into a set of by a method in the construction of a problem solver, it
goals over individual objects. is able to derive (instead of requiring the user to
• An input reformulation is somewhat similar to specify) the static knowledge used by a method. Third,
the support that some languages provide for while the terms used in specifying the input and output
polymorphic operators. This kind of reformulation roles in CommonKADS are basically arbitrary,
occurs when a goal is specified with a general EXPECT relies on an ontology to find interrelations
parameter and no single method is available at a between them and reason about them in constructing a
sufficiently general level to handle the parameter. In problem solver. In this regard, the EXPECT approach
that case, EXPECT attempts to reformulate the goal is closer to the approach used in the Role-Limiting
into cases based on the subtypes of the parameter Methods or in PROTÉGÉ, where there is a method
given in the ontology. EXPECT also creates ontology that characterizes input, output and static
dispatching code so that once the knowledge based knowledge of a method. An interesting difference,
system has been synthesized and is being run, the however, is that EXPECT does not force the user to
code will dispatch to the appropriate subcase based separate the method ontology from the domain
on the actual type of the parameter that is passed in ontology, because the system is able to find out
at runtime. automatically what knowledge is referenced by the
method capability specifications. In summary,
Goal reformulations allow us to state the description of EXPECT finds the roles that knowledge will play when
method capabilities more independently from the the knowledge-based system is derived by the method
statement the descriptions of the goals that are posted instantiator, while these roles are pre-specified by most
by other methods or by the user. The benefit is a more other approaches.
loosely coupling between methods and tasks, i.e.,
between what is to be accomplished and what are Another important line of research about representing
Swartout, Gil, Valente 8-6
method capabilities is the work on specifying method works (as opposed to informal or formal
assumptions of PSMs [Fensel et al, 1996]. EXPECT descriptions created separately from the actual code).
represents some assumptions in the way the Loom
knowledge base is put together. For instance, it can We are planning several extensions to our current
represent a completeness assumption about descriptions approach in order to make it more suitable for
of ports by defining them to have at least one berth. describing capabilities of methods in shared libraries.
This is exploited by the Loom reasoning engine: if an
instance of port does not have a berth, Loom will One set of extensions is motivated by our work on
classify it as incoherent because it contradicts the representing role-limiting methods in EXPECT [Gil
definition of the concept port. Other assumptions are and Melz 1996]. We find that the knowledge roles used
derived during the matching process. For instance, in the method should be expressed explicitly, and that
assumptions about knowledge availability can be EXPECT can derive them automatically by looking at
derived by analyzing a method and concluding that, for interdependencies that it derives. We found the need for
example, the capacity of the C-140 needs to be known an extensive range of types of knowledge roles,
so that the method can calculate whether it can move a including classes to be defined in the domain ontologies
certain cargo using a C-140. and method stubs to be mapped to domain-dependent
methods. We would like to be able to express
additional types of parameters in goals and method
6 Summary capabilities, such as relations and method classes.
Finally, we would like to be able to express how
We have described the approach that is used in methods work together to form larger macro-methods.
EXPECT to describe and reason about goals and
method capabilities. The main features of the approach Another set of extensions is motivated by our
are: participation in DARPA’s High Performance
• the method representation is tightly integrated with Knowledge Bases Program [Cohen et al. 1998], where
ontologies as a model of the objects that the one of our goals is to develop with others a shareable,
methods reason about. Ontologies may be distributed library of implemented problem-solving
domain-specific or high-level ontologies. methods that can be used in conjunction with large-
• a wide range of parameter types, including scale ontologies to rapidly create knowledge based
intensional sets and generic instances systems. In order to organize these method libraries, in
• method capabilities state explicitly information addition to their capability we would like to represent
about the type of computation that the method and reason more explicitly about the assumptions that
does, not just which data it uses. they make on ontologies, the subtasks that they pose,
• a case-frame representation is used that is the submethods that they use, and other information
understandable by users and supports explanation. about the method’s implementation.
• a broad spectrum of methods can be represented,
ranging from small domain-specific methods to
very general domain-independent methods (such as Acknowledgements
propose-and-revise) We would like to thank all the past and present
• goals can be reformulated into more specific members of the EXPECT project for their
subgoals by using domain knowledge stated in the contributions to this work. We gratefully acknowledge
domain ontologies. the support of DARPA with contract DABT63-95-C-
0059 as part of the DARPA/Rome Laboratory
There are several advantages of this approach that Planning Initiative and with grant F30602-97-1-0195
method libraries can benefit from: as part of the DARPA High Performance Knowledge
• a loose-coupling between goals and Bases Program.
method capabilities, which facilitates reuse.
• self-organizing method libraries, where key Bibliography
features of the method (in our case their
capabilities) are used to automatically determine [Aben 1993] Aben, M. “Formally specifying re-usable
how they relate to one another. knowledge model components”. Knowledge
• understandable by users, since they are Acquisition, 5:119--141, 1993.
structured as case frames that can be easily [Breuker 1997] Breuker, J. “Problems in indexing Problem
paraphrased. Solving Methods”. In R. Benjamins and D. Fensel,
editors: Proceedings of the IJCAI'97 Workshop on
An important additional feature of EXPECT is that the Problem Solving Methods, 1997.
method body, i.e., the description of the procedure and [Chandrasekaran 1986] Chandrasekaran, B. “Generic tasks
subtasks that accomplish the method’s capability, is in knowledge-based reasoning”. IEEE Expert , 1(3):23-
also expressed explicitly. This is important for reuse, 30, 1986.
since it allows adaptation of the methods by using [Eriksson et al. 1995] Eriksson, H., Shahar, Y., Tu, S. W.,
EXPECT’s knowledge acquisition tools. It is also Puerta, A. R., and Musen, M. A. “Task modeling with
important because it allows users to look at the method reusable problem-solving methods”. Artificial
body and get first-hand information about how the Intelligence 79(1995):293--326.
[Cohen et al. 1998] Cohen, P.; Schrag, R.; Jones, E.;
Swartout, Gil, Valente 8-7
Pease, A.; Lin, A.; Starr, B.; Gunning, D.; and Burke, M.
“ The Darpa High-Performance Knowledge Bases
Project”. AI Magazine, 19(4), 1998.
[Fensel et al, 1996] Fensel, D and Benjamins, R.
“Assumptions in Model Based Diagnosis”. In Gaines, B.
and Musen, M., editors: Proceedings of the 10th Banff
Knowledge Acquisition for Knowledge-Based Systems
Workshop. Banff, 1996.
[Gil and Gonzalez 1996] Gil, Y. and Gonzalez, P. “Using
Description Logics to Match Goals”, In Proceedings of
the 1996 International Workshop on Description
Logics (DL-96), November 2-4, 1996, Boston, MA.
[Gil and Melz 1996] Gil, Y., and Melz, E. “Explicit
representations of problem-solving strategies to
support knowledge acquisition”. In Proceedings of the
Thirteenth National Conference on Artificial
Intelligence (AAAI-96), 1996.
[Gil 1994] Gil, Y. Knowledge Refinement in a Reflective
Architecture. In Proceedings of the National Conference
on Artificial Intelligence (AAAI-94), 1994.
[MacGregor 1991] MacGregor, R. “The evolving
technology of classification-based knowledge
representation systems”. In Sowa, J., ed., Principles of
Semantic Networks: Explorations in the Representation
of Knowledge. San Mateo, CA: Morgan Kaufmann.
[Marcus 1988] Marcus, S. “SALT: a knowledge-acquisition
tool for propose-and-revise systems,” in Automating
Knowledge-acquisition for expert systems S.Marcus
(ed), pp. 81-121. Kluwer Academic Publishing. 1988
[McDermott 1988] McDermott, J, “Preliminary steps
toward a taxonomy of problem solving methods,” in
Automating Knowledge-acquisition for expert systems
S.Marcus (ed), Kluwer Academic Publishing. 1988
[Musen 1992] Musen, M. A. “Overcoming the limitations
of role-limiting methods,” Knowledge Acquisition,
4(2):165--170. 1992.
[Musen and Tu 1993] Musen, M. A., and Tu, S. W.
Problem-solving models for generation of task-specific
knowledge acquisition tools. In J. Cuena (Ed.),
Knowledge-Oriented Software Design, Elsevier,
Amsterdam, 1993.
[Schreiber et al,1994] Schreiber, A., Wielinga, B.,
Akkermans. J., Van de Velde, W. and de Hoog, R.
“CommonKADS: A comprehensive methodology for
KBS development”. IEEE Expert, 1994.
[Swartout and Gil 1995] Swartout, B. and Gil, Y.
“EXPECT: Explicit Representations for Flexible
Acquisition”. In Proceedings of the Ninth
KnowledgeAcquisition for Knowledge-Based Systems
Workshop (KAW’95) Banff, Canada, February 26-March
3, 1995.
[Swartout et al 1991] Swartout, W. R., Paris, C. L., and
Moore, J. D. “Design for Explainable Expert Systems”.
IEEE Expert 6(3):58-64, 1991.
[Valente et al, 1998] Valente, A., Breuker, J. and Van de
Velde, W. “The CommonKADS Library in Perspective”.
International Journal of Human-Computer Studies, 49:
391—416, 1998.
Swartout, Gil, Valente 8-8