The previous section compared EXPECT with SALT as a prototypical representative of role-limiting approaches to KA using the propose-and-revise strategy. This section compares EXPECT with more recent work in knowledge acquisition.
Some recent approaches to KA support knowledge-based system construction by offering libraries of smaller-grained role-limiting strategies that can be composed to create the overall problem-solving strategy. Such is the approach taken in PROTEGE-II [Puerta et al., 1992], DIDS [Runkel and Birmingham, 1993], and SBF [Klinker et al. , 1991]. Modifying a problem-solving strategy involves changing one component for another one in the library. These frameworks allow a wider range of modifications to a system than tools that use a monolithic, unchangeable problem-solving structure. However, the kinds of modifications are still limited to what the compositions of different components allow. EXPECT allows even finer-grained modifications to the problem-solving methods, by adding new substeps and defining new methods to achieve them as we showed in Section 5. The composable role-limiting approaches provide very limited support if at all to a knowledge engineer who is trying to write a new problem solving component for the library. EXPECT represents the methods in a language that the KA tool understands, so it can support the user in making these changes. In addition, EXPECT's approach requires building only one single KA tool. In fact, in working out the examples shown in this paper we did not need to change the KA tool or to add new errors to those that were already defined in EXPECT.
The PROTEGE-II and DIDS research groups participated in Sisyphus and have implemented the propose-and-revise strategy [Schreiber and Birmingham, 1994]. This allows making a more detailed comparison here.
The DIDS framework supports several interesting features that we do not currently support in EXPECT. DIDS uses the flow of control specified by the problem-solving strategy to determine in which order to acquire each type of knowledge. This order helps in coordinating the KA dialogue for each of the individual methods. We could extend EXPECT to impose an order on the requests to the user based on the subgoal expansion sequence for a method. Another interesting feature of DIDS is that it allows incorporating special-purpose KA tools, such as CAD-based acquisition tools that allow users to specify knowledge through drawings. EXPECT does not have a mechanism to integrate such tools.
PROTEGE-II includes a suite of tools for editing ontologies. Using the ontological definitions, these tools can automatically generate customized editors that are accessible to domain experts. EXPECT currently has very limited capabilities to edit factual knowledge, and could benefit from tools that organized requests to the user using appropriate structures. The library of PROTEGE-II includes not only the problem-solving strategies but also method ontologies that describe the kinds of domain-independent knowledge used in the strategies. These method ontologies are then linked by hand to the domain-specific ontology of the application through a specific language that is used to compile the ontology links. In EXPECT, the method ontology would correspond to the upper part of Figure 1 and the domain-specific ontology to the lower part of the figure. EXPECT uses the same language to represent both, and both ontologies are linked when the domain-dependent terms are made correspond to the domain-independent ones. The KA tool can detect missing links because it can reason about the way factual knowledge interacts with problem-solving knowledge and detect when the appropriate subgoals are not invoked.
A strong emphasis in both of these approaches is knowledge reuse, i.e., using the same component of the library for different problem-solving strategies and in different applications. Reusing a component in the library would be equivalent in EXPECT to invoking a top-level goal that corresponds to a whole problem-solving strategy (for propose-and-revise that goal would be (solve (obj (inst-of cs-problem)) (using (spec-of propose-and-revise)))). EXPECT could benefit from representing the methods that are currently part of these system's libraries so that they could be used to bootstrap the creation of new knowledge-based systems.
TAQL is a knowledge acquisition tool for weak search methods, i.e., problem-solving strategies that are more generic than something like propose-and-revise [Yost, 1993]. TAQL is not targeted for domain experts, but for users that have programming skills. TAQL provides a language that allows users to define different kinds of problem-solving strategies. The knowledge roles that need to be filled out for these strategies are generic roles that are not dependent on the specific strategy defined but on the search framework underlying TAQL. Like EXPECT, in TAQL the KA tool is strategy-independent and can provide guidance that is based on principles that have broader application than role-limiting approaches do. Some of the errors that TAQL detects correspond to errors detected by EXPECT. For example ``forgetting to design a problem space'' in TAQL corresponds to an error in EXPECT that a method cannot be found to achieve a goal. Unlike TAQL, we believe that the guidance provided by EXPECT is accessible to an end-user that is trying to fill out knowledge roles.
Other work in KA that has studied problem-solving strategies (including propose-and-revise) concentrates on knowledge modeling issues [Wielinga et al., 1992, Domingue et al., 1993]. EXPECT's KA tool is an implemented system to support users in knowledge base refinement and maintenance.