This section briefly summarizes how EXPECT uses the explicit representations of factual and problem-solving knowledge to detect knowledge gaps and to guide knowledge acquisition. More details about EXPECT's knowledge acquisition tool can be found in [Gil, 1994, Gil and Paris, 1994]. Section 5 will illustrate how EXPECT's KA tool acquires knowledge for the propose-and-revise and the U-Haul knowledge bases.
EXPECT guides KA by requesting users to resolve errors or knowledge gaps that it detects in the knowledge bases. EXPECT's problem-solver is designed to detect these errors and to report them to the KA tool together with detailed information about how they were detected. The KA tool uses this information to support the user in fixing them. Other modules that can detect and report errors are the parser (which detects syntax errors and undefined terms), the method analyzer (which detects errors within a problem-solving method), and the instance analyzer (which detects missing information about instances).
EXPECT's problem-solver can analyze how the different pieces of knowledge in the knowledge-based system interact. For this analysis, it takes a generic top-level goal representing the kinds of goals that the system will be given for execution. In the U-Haul example, the top-level generic goal would be (solve (obj (inst-of uhaul-problem))), and a specific goal for execution would be (solve (obj jones-uhaul-problem)). EXPECT analyzes how to achieve this goal with the available knowledge. EXPECT expands the given top-level goal by matching it with a method and then expanding the subgoals in the method body. This process is iterated for each of the subgoals and is recorded as a search tree. Throughout this process, EXPECT propagates the types of the arguments of the top-level goal, performing an elaborate form of partial evaluation supported by LOOM's reasoning capabilities. During this process, EXPECT derives the interdependencies between the different components of its knowledge bases. This analysis is done every time the knowledge base changes, so that EXPECT can rederive these interdependencies.
The design of each module of EXPECT takes into account the possibility that the knowledge base may contain errors or knowledge gaps. For example, EXPECT's problem solver is designed to detect goals that do not match any methods, and to detect relations that try to retrieve information about a type of instance that is not defined in the knowledge base (e.g., retrieving the upgrade of a fix when only components have upgrades). In addition to detecting an error, each module is able to recover from the error if possible, and to report the error's type and the context in which it occurred. For example, after detecting that a posted goal cannot match any available method, EXPECT's problem solver would mark the goal as unachievable and continue problem solving by expanding other goals. It would also report this error to the knowledge acquisition module, together with some context information (in this case, the unmatched goal with its parameters) and a pointer to the part of the problem-solving trace where the subgoal was left unsolved.
Table 1: Some of the potential problems in the knowledge bases detected by EXPECT.
Each component of EXPECT is able to detect an error,
recover from the error if possible,
and report the error's type and context in which it occurred.
EXPECT's knowledge acquisition tool uses
this information to support users in resolving errors.
Underlined error codes are used in the examples.
Once the errors are detected, EXPECT can help users to fix them as follows. EXPECT has an explicit representation of types of errors, together with the kinds of corrections to the knowledge base that users can make in order to solve them. This representation is based on typical error situations that we identified by hand. Table 1 shows some of the errors that can currently be detected by two of the modules: the problem solver and the instance analyzer. The error codes shown underlined will be used in the examples in the next section. When EXPECT detects an error, it presents the suggested corrections as possible choices to the user. Consider the case of error e1, where a goal G in the body of method M cannot be achieved by any method. EXPECT suggests that the user either 1) modify the body of method M to change or delete the expression of the goal G, 2) modify the goal of some other method N so that it matches G, 3) create a new method L whose goal will match G, or 4) modify an instance, a concept, or a relation that is used in G. We will see in the next section that the user's choice of one suggestion over the others depends on the context.
