next up previous
Next: Related Work Up: Knowledge Acquisition for Propose-and-Revise Previous: Changing the Propose-and-Revise Strategy

Discussion

To summarize, we revisit SALT's limitations listed in Section 2.2 and point out which of the errors just discussed illustrate how EXPECT handles knowledge acquisition in those cases:

Notice that these errors are detecting conceptually different knowledge gaps, yet they may correspond to the same error type. Such is the case with E2 and E6 that correspond to error type e1, and E1 and E8 that correspond to error type e5.

Notice that SALT's schema for acquiring constraints (shown in Section 2.2) asks the user for more information than EXPECT does. For example, SALT requests information about the precondition, i.e., the situations under which the constraint should be used. SALT uses this information to determine efficiently the subset of the constraints that should be checked in each configuration. Our current version of propose-and-revise does not use knowledge about preconditions, so this information is not requested by EXPECT. If we changed the problem-solving methods so that they check the applicability of constraints according to the precondition, EXPECT would request this information from the user. Notice for example that another field in the schema for constraint acquisition is CONSTRAINED VALUE, which EXPECT did not ask about (see E7) until the methods were changed to use this information.

Throughout the examples, we have referred to a generic user wanting to make changes to the knowledge base. This is not necessarily one user, and not necessarily the end user or domain expert. For example, the end user may only enter knowledge about clients and new trucks to rent. A more technical user would be able to modify propose-and-revise. A domain expert who does not want to change the problem-solving methods can still use EXPECT to fill up knowledge roles and populate the domain-dependent factual knowledge base. Supporting a range of users would require adding a mechanism that associates with each type of user the kinds of changes that they can make to the knowledge base and limiting the users to make only those changes. The important point is that all the changes, no matter who ends up making them, are supported by the same core knowledge acquisition tool.


next up previous
Next: Related Work Up: Knowledge Acquisition for Propose-and-Revise Previous: Changing the Propose-and-Revise Strategy

Yolanda Gil
Tue Oct 1 12:56:15 PDT 1996