SALT [Marcus and McDermott, 1989] is a knowledge acquisition tool for propose-and-revise using a role-limiting approach. In this problem-solving strategy, there are three types of knowledge roles: 1) procedures to assign a value to a parameter, which would result in a design extension, 2) constraints that could be violated in a design extension, and 3) fixes for a constraint violation. Consequently, the user can enter one of the three types of knowledge: PROCEDURE, CONSTRAINT, and FIX. For each type of knowledge, a fixed menu (or schema) is presented to the user (in SALT's case a domain expert) to be filled out. An example of the information provided by a user for a constraint is as follows (from [Marcus and McDermott, 1989]):
1 Constrained value: CAR-JAMB-RETURN 2 Constraint type: MAXIMUM 3 Constraint name: MAXIMUM-CAR-JAMB-RETURN 4 Precondition: DOOR-OPENING = SIDE 5 Procedure: CALCULATION 6 Formula: PANEL-WIDTH * STRINGER-QUANTITY 7 Justification: THIS PROCEDURE IS TAKEN FROM INSTALLATION MANUAL I, P. 12b.
The fields to be filled in by the user include the value constrained (1), the nature of the limit that the constraint imposes on the value (2), and a procedure for specifying a value for the constraint (6). SALT includes special-purpose modules to support the user in filling up these schemas. For example, it checks that the formula is correct and that it references variables that have been defined by the user.
One great advantage of role-limiting strategies is reuse. A tool like SALT can be used to acquire knowledge in other applications that use the propose-and-revise strategy. The problem-solving strategy would be the same, thus saving a lot of effort in building a new system. Only the domain-dependent knowledge roles would need to be acquired. Parts of the KA tool would have to be adapted in the way the knowledge roles are filled (such was the experience reported when using SALT for a flow-shop scheduler [Marcus and McDermott, 1989]).
But because role-limiting approaches to KA constrain so strongly the kind of knowledge that they can acquire, they are limited in that they can only do that form of knowledge acquisition. As a knowledge acquisition tool, SALT was specifically built for a type of problem solving strategy (i.e., propose-and-revise) that used certain types of knowledge (procedure, constraint, and fix). Its interaction with the user can never change unless, of course, SALT itself is reprogrammed. As a result, SALT is not very adaptable as a knowledge acquisition tool. For example, SALT could not be used in an application domain that required using domain knowledge to select a preferred fix, because such a knowledge role does not exist in SALT's propose-and-revise strategy. The schemas cannot be changed either. For example, suppose that the user wanted to add numerical priorities to specify which constraints should be preferred over others when resolving violations. The schema for acquisition of constraints would have to be modified. Furthermore, this would require changing the implementation of propose-and-revise so that it would use this preference information in the revision phase.
Special-purpose modules are needed to acquire some specific kinds of knowledge. For example, there is a consistency checker for the formulas in the constraint schemas. The values of the input parameters are also acquired through an interface that was specifically designed for the elevator application.
SALT does not provide support in updating or maintaining the knowledge about elevator components. This would be a very useful capability, since product knowledge changes at a high rate (40-50 percent per year is the rate reported for configuration systems such as R1 and PROSE [McDermott, 1982, Wright et al., 1983].)
The essence of the argument made here about SALT applies to other role-limiting KA tools such as MOLE, [Eshelman, 1988], MORE [Kahn et al., 1985], and PROTEGE [Musen, 1989]. To summarize, the main limitations of role-limiting approaches to knowledge acquisition in terms of their lack of flexibility are:
Section 5 shows how EXPECT supports the acquisition of these kinds of knowledge. We do not claim that EXPECT can support any kind of user in making these changes to the knowledge-based system. For example, domain experts will not normally have the background knowledge to change a problem-solving strategy, which will normally require knowledge engineering skills. The focus of our work is to show that it can be done using a single KA tool that is independent of the problem-solving strategy used.