Section 2.2 showed that SALT needs to be given definitions of schemas to enter constraints and fixes. EXPECT does not need to be given such schemas. Instead, the information in the schemas is naturally requested by EXPECT as constraints and fixes are defined by the user.
Suppose for example that the user wants to add a new constraint that restricts the rental of trailers to clients with cars made after 1990 only. The user would add a new instance of constraint: TrailersForNewCarsOnly. EXPECT would analyze the implications of this change in its knowledge base and signal the following problem:
E2--I do not know how to achieve the goal (check (obj TrailersForNewCarsOnly) (in (inst-of uhaul-configuration))).
This is because during problem solving EXPECT calls a method that tries to find the violated constraints of a configuration by checking each of the instances of constraint of U-Haul problems. This is a case of an error of type e1. Before defining this new instance of constraint, the only subgoal posted was (check (obj capacityConstraint) (in (inst-of uhaul-configuration))) and now it also posts the subgoal (check (obj TrailersFor NewCarsOnly) (in (inst-of uhaul-configuration))). There is a method to achieve the former subgoal (shown in Figure 2), but there is no method to achieve the latter.
Notice that with this error EXPECT detects that the addition of a new constraint to the factual knowledge base requires adding a new method to the problem-solving knowledge base. This illustrates how EXPECT understands the interdependencies between factual and problem-solving knowledge and uses this to guide knowledge acquisition.
To resolve E2, the user chooses the third suggestion for errors of type e1 and defines the following method to check the constraint:
(defmethod CHECK-TRAILERSFORNEWCARSONLY-CONSTRAINT
:goal (check (obj TrailersForNewCarsOnly)
(in (?c is (inst-of uhaul-configuration))))
:result (inst-of boolean)
:method-body (is-greater-or-equal
(obj (r-year (r-car ?c)))
(than 1990)))
Once this method is defined, E2 is no longer a problem and disappears from the agenda.
Notice that with this method EXPECT is acquiring information about a knowledge role. The new method corresponds to acquiring in SALT the field formula in the schema for the constraint knowledge role (shown in Section 2.2).
EXPECT's error detection mechanism also notices possible problems in the formula used to check the constraint. In SALT, these problems are detected by special-purpose code that checked the validity of formulas. For example, if r-year had not been defined EXPECT would signal the following problem (of type e2):
E3--I do not know what is the year of a car.
When the user defines the role r-year for the concept car this error will go away. EXPECT can also detect other types of errors in the formulas to check constraints. For example, if r-year was defined to have a string as a range, then EXPECT would detect a problem. It would notice that there is no method to check if a string is greater or equal than a number, because the parameters of the method for calculating is-greater-or-equal must be numbers). EXPECT would then tell the user:
E4--I do not know how to achieve the goal (is-greater-or-equal (obj (inst-of string)) (than 1990)).
Like E2, E4 is an error of type e1. But in this case the user chooses a different way of resolving the error, namely to modify the definition of the relation r-year.
If the user defined a fix associated with the new constraint, then EXPECT would follow a similar reasoning and signal the need to define a method to apply the new fix.
We pointed out in Section 5.1 that EXPECT changes its requests for factual information according to changes in the problem-solving methods. This can be illustrated in this example of adding a new constraint. An effect of the fact that the user defined the new method to check the constraint is that new factual knowledge about the domain is needed. In particular, EXPECT detects that it is now important to know the year of the car that the client is using (and that is part of the configuration), because it is used in this new method. The following request will be generated for any client that, like in this case Mr. Jones, needs to rent U-Haul equipment:
E5--I need to know the year of the car of Jones.
This is really requiring that the information that is input to the system is complete in the sense that configuration problems can be solved. In SALT, as in many other systems, the input information (such as client preferences or the building features) is predetermined at the time the system is defined. In EXPECT, the requirements for inputs change as the knowledge base is modified. Notice that E5 is an error of type e5, and is detected by the same mechanism that was used to detect E1, even though they request conceptually different types of information: E1 requests information that is relevant to the U-Haul application and E5 requests information relevant to specific client cases.