Generation of Knowledge Bases from Target Tools

The generic knowledge-base generator is an important component of the target knowledge-acquisition tools. We shall provide an example that illustrates how target knowledge bases are generated from the contents of knowledge modules. This example is loosely based on the Sisyphus VT task. Suppose that we want to generate rules from the information entered in the fix form (Figure 4). We assume that the developer has already defined the knowledge editor and the appropriate knowledge module for representing the information acquired. The task of the knowledge-base generator is to produce appropriate rules from such knowledge modules. For the form shown in Figure 4, we wish to generate an instance of the fix class for the knowledge base, in this example:

(definstance increase_pit_depth1 of fix
  (desirability 9)
  (variable pit_depth)
  (action increase)
  (amount 1)
  (description "Try increasing..."))

In DOTS, transformation rules map the knowledge modules to the target knowledge base. Figure 5 shows a sample transformation rule (generate-1) that produces target instances from the knowledge modules. The clause ($km:whichis fix-km) states that the transformation rule is applicable to all knowledge modules of type fix-km, and that the variable $km is bound to a knowledge-module instance during the generation process (i.e., where fix-km). The precondition of the transformation rule tests whether the user has filled in the variable field in the fix form (Figure 4). If the precondition is satisfied, the conclusion of the transformation rule builds an instance of the class fix in the target knowledge base. If the expert has entered several fix-km into the knowledge-acquisition tool, several instances of the generate-1 transformation rule may generate multiple target instances. The purpose of the build-instance clause is to provide a convenient syntax for instance generation, and to allow the knowledge-acquisition tool to maintain the target knowledge base as the knowledge modules change, by adding and deleting rules from the knowledge base.

An alternative to using instances of the fix class to represent fixes in the knowledge base, is to use production rules to represent the fixes. In this case, the production rules would implement fix operations (e.g., increase a state variable). By using a build-rule clause, we can define readily a transformation rule that generates production rules from the contents of the fix-km knowledge module. In this approach, the user interface of the knowledge-acquisition tool and the fix form (Figure 4) would remain the same after we modified the transformation rule. By using this technique, we can defer design decisions about the knowledge representation in the knowledge base until we have acquired a significant body of knowledge.

(define-transformation-rule generate-1
  ($km :whichis fix-km)
  IF (not-empty (get-value $km variable))
  THEN
   (build-instance
     :name (target-id $km)
     :class 'fix
     :initargs
     `((desirability ,(get-value $km desirability))
       (variable ,(get-value $km variable))
       (action ,(get-value $km action))
       (amount ,(get-value $km amount))
       (description ,(get-value $km description)))))