Role-limiting approaches have been the main focus of research in knowledge acquisition (KA) tools for knowledge-based systems construction for over a decade [Birmingham and Klinker, 1993]. Several researchers have identified commonly occurring, domain-independent problem-solving strategies or inference structures that are useful for describing the reasoning behind knowledge-based systems [McDermott, 1988, Clancey, 1985, Chandrasekaran, 1986]. These problem-solving strategies determine the roles that domain-dependent knowledge plays. The task of a KA tool, then, is to guide users in filling out those roles. Several such tools have been built to support KA for a specific problem-solving strategy: SALT for propose-and-revise [Marcus and McDermott, 1989], MOLE for cover-and-differentiate [Eshelman, 1988], PROTEGE for skeletal plan refinement [Musen, 1989], etc. Each tool was designed for a specific strategy and could be used in principle to acquire knowledge for any application whose problem-solving behavior could be cast in terms of that strategy. In role-limiting approaches to KA, knowledge roles strongly determine what kinds of knowledge need to be acquired, and the dialogue with the user is centered on the acquisition of domain-dependent knowledge to fill these roles.
Although having a role-limiting strategy provides very strong guidance for knowledge acquisition, these tools lack the flexibility that knowledge-based system construction needs [Musen, 1992]. The problem-solving structure of an application cannot always be defined in domain-independent terms, as Musen explains was the case with R1 [McDermott, 1982]. Furthermore, one single problem-solving strategy may not address all of the particulars of an application, simply because it was designed with generality in mind.
More recent approaches to KA overcome these limitations by offering the system builder a library of finer-grained problem-solving strategies whose components can be used to put together a knowledge-based system [Puerta et al., 1992, Runkel and Birmingham, 1993, Klinker et al. , 1991]. Each problem-solving strategy is then associated with a KA tool specific to that strategy. The components of the library can be designed to be as small-grained as necessary to be useful in system construction. These frameworks provide more flexibility because the overall problem-solving strategy can be customized to the needs of the application. However, their support to the user is still limited to filling knowledge roles that have been identified beforehand by the designers of these components. The kinds of modifications to the problem-solving strategy are limited to exchanging one component for another in the library. Also, a KA tool needs to be built for every problem-solving strategy.
EXPECT [Swartout and Gil, 1995, Gil, 1994, Gil and Paris, 1994]
takes a different approach to knowledge acquisition.
The problem-solving strategy is represented explicitly,
and the knowledge acquisition tool reasons about it and
dynamically derives
the knowledge roles that must be filled out, as well as
any other
information needed for problem solving.
Because the problem-solving strategy is explicitly represented,
it can be modified, and as a result, the
KA tool changes its interaction with the user to
acquire knowledge for the new strategy.
Only one KA tool needs to be built,
because it can identify knowledge gaps for any problem-solving strategy
that can be explicitly represented in EXPECT.
EXPECT provides greater flexibility in adapting problem-solving
strategies because their representations can be changed
as much as needed.
Because the systems that have been built to date with
EXPECT do not use a
domain-independent problem-solving
strategy
,
it is hard to compare role-limiting approaches
with EXPECT's approach of having explicit representations
to guide knowledge acquisition.
This paper illustrates how EXPECT's knowledge
acquisition tool works when the system is using a
specific problem-solving strategy.
This allows a more detailed comparison with
role-limiting approaches and shows that
EXPECT not only supports users in filling out knowledge roles,
but extends the support to
acquire additional knowledge needed for
problem-solving--a process
that role-limiting approaches to KA do not support.
To show how EXPECT works with a role-limiting strategy we chose propose-and-revise, one that has been the focus of much recent work within the KA community. [Schreiber and Birmingham, 1994]. Propose-and-revise was first identified as the problem-solving strategy used in VT, a system for elevator configuration [Marcus et al., 1988]. Perhaps the main reason for the interest in propose-and-revise is that the VT domain has been used as a common domain for the Sisyphus effort within the KA community, where research groups are invited to show their solutions to a common problem to allow comparisons among the different frameworks [Schreiber and Birmingham, 1994]. The main sections of this paper compare EXPECT with SALT [Marcus and McDermott, 1989], the prototypical KA tool that uses a role-limiting approach for that problem-solving strategy. Contrasting EXPECT with SALT is useful to illustrate the main points of this work, but at the end of the paper we compare EXPECT with more recent approaches to building knowledge acquisition tools. Because the VT domain takes a significant amount of time to implement, we used instead a smaller domain for U-Haul ©rentals--one that also uses propose-and-revise, designed by the PROTEGE group at Stanford University, and used in their own work [Gennari et al., 1993]. This domain was sufficient to allow us to implement propose-and-revise in EXPECT and to enable a more direct comparison of its KA tool with other approaches.
The paper begins by describing propose-and-revise and its use in a role-limiting tool for knowledge acquisition. Then we describe how propose-and-revise and the U-Haul domain were implemented in EXPECT. Section 4 describes EXPECT's knowledge acquisition tool. Section 5 shows several examples of how EXPECT can acquire knowledge for propose-and-revise and also support users in acquiring additional types of knowledge. We then compare EXPECT's approach with recent KA tools and approaches that have been used for propose-and-revise.