Changing the Propose-and-Revise Strategy

We pointed out in Section 2.2 that SALT does not allow users to change the problem-solving strategy or to define new knowledge roles. This section shows how this can be done with EXPECT.

Suppose that the user wants to change the revision process of propose-and-revise to introduce priorities on what constraint violations should be resolved first. The priorities will be based on which variable is associated with each constraint.

The user would need to identify which of the problem-solving methods that express propose-and-revise in EXPECT needs to be modified. The change involves adding a new step in the method to revise CS states shown in Figure 2. The new step is a subgoal to select a constraint from the set of violated constraints. The modified method is as follows (the new step is indicated with stars on the right-hand side):

(defmethod REVISE-CS-STATE
  :goal         (revise (obj (?state is (inst-of cs-state))))
  :result       (inst-of cs-state)
  :method-body  (apply 
                  (obj (find (obj (set-of (spec-of fix)))
                             (for 
                               (select                          ; ******
                                 (obj (spec-of constraint))     ; ******
                                 (from                          ; ******
                                  (find 
                                    (obj (set-of (spec-of violated-constraint)))                                              
                                    (in ?state)))))))
                  (to ?state)))

EXPECT would signal the following request:

E6--I do not know how to achieve the goal (select (obj (spec-of constraint)) (from (set-of (inst-of violated-constraint)))).

This is an error of type e5, and it indicates that the user has not completed the modification. The user needs to create a new method to achieve this goal as follows:

(defmethod SELECT-CONSTRAINT
  :goal         (select (obj (spec-of constraint))
                        (from (?vc is (set-of (inst-of violated-constraint)))))
  :result       (inst-of constraint)
  :method-body  (take (obj ?vc)
                      (with (spec-of maximum))
                      (of (r-preference 
                              (r-constrained-variable ?vc)))))

where r-preference is defined as a role of variables and has a numeric range, and r-constrained- variable is defined as a role of constraint and has variable as its range. The user may also need to define a new method for the take subgoal if there is no such method available.

With these modifications to the knowledge base, the propose-and-revise strategy that EXPECT will follow has changed. Because the representation of the new strategy is explicit, EXPECT can reason about it and detect new knowledge gaps in its knowledge base. As a result of the modification just made, there is additional factual information needed including new information about an existing knowledge role and a new kind of knowledge role. EXPECT would then signal the following requests (both of type e5):

E7--I need to know the constrained variable of TrailersForNewCarsOnly.

E8--I need to know the preference of equipment-variable.

E7 is one of the fields in SALT's constraint schema shown in Section 2.2, which was called CONSTRAINED VALUE. E8 is a new knowledge role centered around the notion of variables. In SALT, making the change just described to the revise strategy would have required reprogramming the tool to change the problem-solving method and to add a new schema for the new knowledge role VARIABLE that would acquire preferences for each variable or parameter.

E7 and E8 illustrate that EXPECT has noticed that the change in the problem-solving strategy requires the user to provide new kinds of information about the factual knowledge used by the strategy. This shows that in EXPECT the acquisition of problem-solving knowledge affects the acquisition of factual knowledge. Recall that E2 illustrated the converse.