Viktor Tadjer**
VUB AI Lab, Pleinlaan 2, 1050 Brussels
Email: viktor@arti.vub.ac.be, ari@iinf.bg
This memo reports on the experiments performed at the AI Lab for procedural encoding of problem solving methods and associated domain models into rules, described in the language of the rule-based problem solver KAN. A separate method for this encoding has been developed as an extension to the Structured Basekit, supplied with KREST.
Keywords: Knowledge level, rule-based representations, procedural encoding
The KREST workbench is a knowledge-engineering tool that supports the analysis and development of knowledge systems according to the COMMET methodology [3]. This methodology views the analysis and design of a knowledge system from three perspectives - tasks, models and methods, and focuses on their mutual relationship and reusability. All knowledge components can be accessed and modified at any stage of the design process. An important functionality of the KREST workbench is the link between the knowledge level entities and their symbol level representation. The latter could be generated automatically from the knowledge level description. In this way reusability is achieved not only for the purposes of analysis and design but also for the purpose of configuring an executable application.
The KREST workbench uses declarative encoding of knowledge in that domain models and problem solving methods are described at the knowledge level and encoded at the symbol level independently of each other and can be combined in a variety of ways. Thus knowledge acquisition and maintenance are enhanced and the knowledge level analysis of the system is performed in a more structured way. But, as is underlined in [4], the declarative encoding of knowledge is not always efficient when the real application is to be run. This is why procedural encoding, which basically is a compilation of domain models together with a problem solving method into a domain-related procedural description, is often preferred. The most popular form of procedural encoding is that of IF-THEN rules.
Therefore the need for supporting procedural encoding of declarative knowledge arises in the framework of KREST. Users of this functionality would probably perform the knowledge level analysis and design of an application together with the knowledge acquisition activities in the KREST environment, but when it comes to execute the application they would prefer to switch to a rule-based interpreter. In what follows I describe the realisation of the method to-kan for translating declarative knowledge level descriptions in KREST to rule-based descriptions of the KAN system [1]. The method is implemented as part of the Structured Basekit [2], supplied with KREST.
This method represents the main procedure for translating KREST knowledge level descriptions into code, which can be interpreted by the problem solving system KAN. It is realised as a single input method in the Structured Basekit of KREST.
The input of the method is constrained to be a task. This means that the task structure of a knowledge level task, to which the method to-kan is assigned, will be a combination of the task itself and a single subtask. Therefore to translate a whole application task structure into a KAN code the top task in this structure should be passed as an input to the translation task. For instance, let us consider the problem of infection diagnosis, described in [4]. At the knowledge level we can define the following tasks for achieving the goal of finding and presenting an appropriate therapy on the basis of the patient's observed symptoms: acquire observed symptoms, diagnose-infection, identify-therapy-type, therapy-refinement, present therapy. They should be executed sequentially in this order. Consequently we define another task, select-therapy, which is responsible for this sequential execution. If we want to generate KAN code for the whole application, which infers the right therapy, we pass the task select-therapy as a subtask to the task to-kan, to which we have assigned the method to-kan. The result is shown on figure1.
Figure 1. Task structure for generation of KAN code for a complete application
If a simple inference task, e.g. dignose-infection, is passed to to-kan then only the descriptions associated with it will be encoded into the KAN language,
The tasks passed to the method to-kan are processed according to the method that is assigned to them. The input and output models associated with the tasks are processed as well. Methods for knowledge acquisition and presentation are skipped by the translating method to-kan because KAN has its own means for dialogue management and presentation of the results from the problem solving process to the user. At this stage of development the following inference methods are supported: linear mapping, linear mapping with probability, differentiation. Each one of these methods leads to the generation of a set of rules and the associated models serve as a basis for the generation of appropriate KAN descriptors. The method sequential task execution is supported as well and leads to the generation of an hierarchy of the sets of rules, corresponding to the lower level tasks. The next sections describe in more detail the exact actions performed by the translator for each of the above cases.
The method sequential task execution belongs to the group of task execution methods. It imposes a sequential control structure over the corresponding subtasks and executes them one after the other. The KAN language gives us the possibility to invoke a rule-set from within another one by the use of the action investigate.Therefore the procedural encoding of the method sequential task execution should lead to the generation of a rule-set containing a rule, which investigates sequentially the rule-sets, generated during the processing of the subtasks. In fact the translating procedure is activated recursively on the task structure tree and for each node generates the appropriate rule-set. Here is a sample of the code corresponding to figure 1:
(define rule-set diagnose-infection-rules
(object-type doctor)
(goal infection-types))
<definitions of rules>
(define rule-set identify-therapy-type-rules
(object-type doctor)
(goal therapy-type))
<definitions of rules>
(define rule-set therapy-refinement-rules
(define (object-type doctor)
(goal infection-therapy))
<definitions of rules>
(define rule-set select-therapy-rules
(object-type doctor)
(goal infection-therapy))
(define (rule select-therapy-rules) start-up-rule
(then
(investigate diagnose-infection-rules)
(investigate identify-therapy-type-rules)
(investigate therapy-refinement-rules))
It is seen that the goal of the rule-set corresponding to a sequential task execution method is defined to be the goal of the rule-set, generated during the processing of the last subtask. Each of the nodes in the task structure is analysed recursively by the same procedure so that eventually intermediate rule-sets with "investigating" rules could be generated.
The procedural encoding of the method linear mapping together with its associated mapping model leads to the generation of rules and also of domain descriptors, specified in the language of KAN. The encoding proceeds as follows (based on [4]):
1. The mapping model is analysed and the acquisition task for this mapping model is found. We assume that its method acquires the mapping on the basis of two models: the first one containing the source elements of the mapping and the second one containing the target elements of the mapping. Such is for instance the method acquire mapping by selecting included in the run-time library of the Structured Basekit.
2. The source and target model of the mapping model are translated into KAN domain descriptors depending on their structure (see section 2.3 for more detail).
3. A rule-set corresponding to the task being processed is generated. Its goal is defined to be associated with the target model of the mapping model (in our case the name of the model).
4. The rules in the rule-set correspond to the elements of the mapping model. The IF-part of each rule contains all the source elements of the mapping element and the THEN-part of that rule contains the target elements of the mapping element.
5. A final rule is added to the rule-set to cover the case where the goal has not been achieved and therefore the value of the descriptor is set to be unknown.
Let us consider an example from the above mentioned domain of infection diagnosis. On figure 2 the KREST task-model dependency diagram of the task diagnose infection is shown. The method assigned to the task is linear mapping.
Figure 2. KREST task model dependency diagram for a linear mapping task
The mapping model of this task is symptoms of infections and it relates the symptoms of a patient with the type of infection. This domain model is created at the knowledge level and is filled at the stage of knowledge acquisition. The corresponding acquisition task is found to be acquire symptoms of infections and its task-model dependency diagram is shown on figure 3. The method this task uses is acquire mapping by selecting.
Figure 3. Task-model dependency diagram for an acquire mapping by selecting task.
The source model is found to be symptoms and the target model of the mapping model is found to be infection types. At the knowledge level the model symptoms has a content form set of property while the model infection types has a content form attribute. These content forms are introduced as an extension of the content forms available in the Structured Basekit. They are intended to serve as a kind of domain modelling forms but we use them to generate the appropriate KAN domain descriptors: attribute and property. Figures 4, 5 and 6 show knowledge level descriptions of the models symptoms, infection-types and symptoms of infections.
Figure 4. Knowledge level description and contents of the source model symptoms.
Figure 5. Knowledge level description and contents of the target model infection types.
Figure 6. Knowledge level description of the mapping model symptoms of infections and contents of one mapping element (symptoms of the infection poliomyelitis)
We can pass the task diagnose infection as an input to the task to-kan and execute the latter. This will activate the method for procedural encoding of KREST knowledge level descriptions. The purpose of the translator in this case will be to generate rules, representing the compilation of the method linear mapping together with the domain mapping model symptoms of infections. The rules will be written in the language of KAN and along with them several KAN domain descriptors will be generated according to the algorithm described above. The generated KAN code is complete, i.e. a problem solving process can be executed and dialogue with the user will be started. Here is the code generated for the example we are considering.
(define vocabulary doctor-vocabulary)
(define object-type doctor
(vocabulary doctor-vocabulary))
(define doctor the-doctor)
(define (property doctor-vocabulary) pregnant
(to-find-out ask))
(define (property doctor-vocabulary) swollen-glands
(to-find-out ask))
(define (property doctor-vocabulary) swelling-under-jaw
(to-find-out ask))
(define (property doctor-vocabulary) swelling-of-face
(to-find-out ask))
(define (property doctor-vocabulary) paralysis
(to-find-out ask))
(define (property doctor-vocabulary) pains
(to-find-out ask))
(define (property doctor-vocabulary) stiff-neck
(to-find-out ask))
(define (property doctor-vocabulary) diarrhea
(to-find-out ask))
(define (property doctor-vocabulary) scarlet-rash
(to-find-out ask))
(define (property doctor-vocabulary) vomiting
(to-find-out ask))
(define (property doctor-vocabulary) headache
(to-find-out ask))
(define (property doctor-vocabulary) neuritis
(to-find-out ask))
(define (property doctor-vocabulary) paralysis-of-palate
(to-find-out ask))
(define (property doctor-vocabulary) inflammation-of-heart-muscle
(to-find-out ask))
(define (property doctor-vocabulary) rash
(to-find-out ask))
(define (property doctor-vocabulary) membrane-in-throat
(to-find-out ask))
(define (property doctor-vocabulary) soar-throat
(to-find-out ask))
(define (property doctor-vocabulary) pink-spots
(to-find-out ask))
(define (property doctor-vocabulary) coughing
(to-find-out ask))
(define (property doctor-vocabulary) running-nose
(to-find-out ask))
(define (property doctor-vocabulary) ear-inflammation
(to-find-out ask))
(define (property doctor-vocabulary) enlarged-glands-in-neck
(to-find-out ask))
(define (property doctor-vocabulary) fever
(to-find-out ask))
(define (attribute doctor-vocabulary) infection-types
(possible-values
unknown
poliomyelitis
scarlet-fever
diphtheria
german-measles
mumps
)
(to-find-out lookup))
(define rule-set diagnose-infection-rules
(object-type doctor)
(goal infection-types))
(define (rule diagnose-infection-rules) poliomyelitis-rule
(if
fever
soar-throat
headache
vomiting
diarrhea
stiff-neck
pains
paralysis
)
(then
(conclude (infection-types poliomyelitis))))
(define (rule diagnose-infection-rules) scarlet-fever-rule
(if
fever
soar-throat
headache
vomiting
scarlet-rash
)
(then
(conclude (infection-types scarlet-fever))))
(define (rule diagnose-infection-rules) diphteria-rule
(if
fever
soar-throat
membrane-in-throat
inflammation-of-heart-muscle
paralysis-of-palate
neuritis
)
(then
(conclude (infection-types diphteria))))
(define (rule diagnose-infection-rules) mumps-rule
(if
fever
swelling-of-face
swelling-under-jaw
swollen-glands
)
(then
(conclude (infection-types mumps))))
(define (rule diagnose-infection-rules) german-measles-rule
(if
fever
enlarged-glands-in-back-of-neck
ear-inflammation
running-nose
coughing
pink-spots
)
(then
(conclude (infection-types german-measles))))
(define (rule diagnose-infection-rules) unknown-infection-types-rule
(then
(conclude (infection-types unknown))))
(define problem-solver main-problem-solver
(rule-set diagnose-infection-rules)
(object the-doctor))
Similar code will be obtained if we encode the method and models associated with the tasks identify therapy type or therapy refinement. Here is part of the code for therapy refinement:
(define (attribute doctor-vocabulary) infection-therapy
(possible-values
unknown
laser-therapy
gammagobulin-injection
ioga-therapy
folk-therapy
antibiotics
)
(to-find-out lookup))
(define rule-set therapy-refinement-rules
(object-type doctor)
(goal infection-therapy))
(define (rule therapy-refinement-rules) antibiotics-rule
(if (therapy-type poliomyelitis-therapy))
(then
(conclude (infection-therapy antibiotics))))
(define (rule therapy-refinement-rules) gammagobulin-injection-rule
(if (therapy-type german-measles-therapy))
(then
(conclude (infection-therapy gammagobulin-injection))))
The procedural encoding as is described in this work results into a compilation of a problem solving method together with its domain models into rules. The latter however are intended to be interpreted by a specific rule-based problem solver, namely KAN. In order to generate syntactically correct KAN rules we have to take care of generating the descriptors, which comprise the conditions and actions in the rules. The KAN system provides vocabularies, containing properties, attributes, relations and roles. These descriptors are in fact a kind of domain modelling entities. KAN descriptors are generated at step 2 of the algorithm from the previous section. Consequently we now describe the interpretation of the source and target models of the domain mapping model which is compiled together with the problem solving method.
The knowledge level of KREST provides for creation and maintenance of various models. The Structured Basekit supplies several content forms of models: sets, lists, records, symbols, numbers, etc. In order to generate sensible KAN descriptors from the KREST knowledge level models we could apply several alternative strategies. One of them is to start from the content form of the model under consideration and make some assumptions (e.g. we can postulate that if the form is symbol then it should be transformed into a KAN property; if the content form is set of symbols then it should be transformed into several KAN properties, and so on). But in this case we shall encounter great difficulties as we cannot set up a full mapping between the KAN descriptors and the content forms of KREST models. To mention only one we cannot decide whether a model having the content form set of symbols should be translated into a KAN attribute or to several KAN properties. Another approach is to define new content forms corresponding directly to the KAN descriptors. This is already a step towards a new application kit intended to incorporate procedural encoding into KAN rules. There are also difficulties with this approach because the semantics of the KAN descriptors relation and role cannot be realised in KREST directly. But in all cases this strategy is better and it also leads to introducing domain modelling tools in KREST. It could be argued that if content forms, corresponding to KAN descriptors, are introduced in the Structured Basekit we would obtain a nice graphical interface to KAN, replacing, say, a simple text editor. But we must underline two things. First, the idea of descriptors such as KAN's is to model a domain and thus their application is much wider than only to be used in KAN. And second, our procedural encoding is designed to generate rules which for the same domain model will be different depending on the problem solving method. Research experiments in this direction could be done perfectly with KAN. If we would like to generate rule descriptions in a language of another rule-based problem solver, then only that part of the translator should be changed which is responsible for the derivation of the "surrounding" descriptors.
In the work reported here I have chosen to introduce new content forms in the current Structured Basekit. I have also introduced some modifications of existing run time library methods which could work with the new forms. The modifications are mainly in relaxing the constraints on the content form of the input and output models. At this stage the following content forms are interpreted by the translation method:
- property. Models with this content form are translated into KAN property. The form is equivalent to symbol.
- attribute. The form is equivalent to set of symbols. Models with this content form are translated into KAN attribute whose possible values correspond to the symbols in the model contents.
- set of property. Models with this content form are translated into several KAN properties corresponding to the elements of the set.
- set of symbols. This content form is interpreted in the following way: the symbols are considered to be names of existing knowledge level models, which in turn are translated.
An important feature of KAN descriptors is the way their value is obtained (the filler of the slot to-find-out). The translating method to-kan manages this in the following manner. If the corresponding model is a source one and does not appear as an output model of a task, to which an inference problem solving method is assigned (i.e. this model is not supposed to be inferred), the filler of the slot to-find-out is set to ask. If the model is a target one, the value of the slot is set to lookup (because the case model developed by the problem solving method is a "part" of this target model).
We have to mention here that the names of the rule-sets are taken from the names of the corresponding tasks, the names of the rules come from the name of the target element in the components of the mapping model. Besides this all descriptors are installed in a single vocabulary, object and object-type which are named on the basis of the project name,
While we describe examples of rule generation we shall see that the above mentioned content forms lead to generation of KAN descriptors. We have already seen the use of set of property and attribute as well as the manipulation of the slot to-find-out in the infection diagnosis problem.
The encoding of the differentiation method is done following the same algorithm as in the case of linear mapping. The difference is in step 4 where the strategy described in [4] is implemented for the generation of rules with a highly reduced set of conditions. Let us consider an example from the area of finch classification (taken from [4]). Figures 7-11 show knowledge level components defined in KREST for this problem. Each part of the finch is defined as a model with content form attribute : lores, breast, tail, throat, rump, back-and-wings, belly, legs, beak, eyebrow, ear-patch, crown, flanks. The possible values of all body-parts are some kind of colour: blue, green, red with black line, etc. The possible finch specimen are also defined as a model with content form attribute. The domain mapping model features-to-finch determines for each finch class the colours of the body-parts. The task classify finches infers the class from the observed features using the method differentiation.
Figure 7. Task model dependency diagram of the task classify finch.
Figure 8. Acquisition task for the domain mapping model.
Figure 9. Content form and contents of the model finches.
Figure 10. Content form and contents of the model of finch features.
Figure 11. Content form and contents of a model of a body-part.
The procedural encoding of the task classify finch leads to the generation of the following rules and KAN descriptors:
(define vocabulary finch-vocabulary)
(define object-type finch
(vocabulary finch-vocabulary))
(define finch the-finch)
(define (attribute finch-vocabulary) flanks
(possible-values
unknown
insignificant
white
black
barred
spotted
red
yellow
brown
blue
green
grey
red-with-black-line
)
(to-find-out ask))
<other definitions for the rest of the body-parts>
(define (attribute finch-vocabulary) finches
(possible-values
unknown
red-eared-firetail
beautiful-firetail
diamond-firetail
painted-finch
crimson-finch
star-finch
red-browed-finch
gouldian-finch
masked-finch
white-eared-mask
long-tailed-finch
red-bill-long-tailed-finch
black-throated-finch
black-rumped-finch
banded-finch
zebra-finch
plum-headed-finch
chestnut-breasted-finch
yellow-rumped-finch
pictorella-finch
blue-faced-parrot-finch
)
(to-find-out lookup))
(define rule-set classify-finch-rules
(object-type finch)
(goal finches))
(define (rule classify-finch-rules) gouldian-finch-rule
(if
(breast blue)
)
(then (conclude (finches gouldian-finch))))
(define (rule classify-finch-rules) crimson-finch-rule
(if
(breast red)
)
(then (conclude (finches crimson-finch))))
(define (rule classify-finch-rules) beautiful-firetail-rule
(if
(breast barred)
)
(then (conclude (finches beautiful-firetail))))
(define (rule classify-finch-rules) painted-finch-rule
(if
(belly spotted)
(breast black)
)
(then (conclude (finches painted-finch))))
(define (rule classify-finch-rules) diamond-firetail-rule
(if
(belly barred)
(breast black)
)
(then (conclude (finches diamond-firetail))))
(define (rule classify-finch-rules) long-tailed-finch-rule
(if
(legs red)
(breast spotted)
)
(then (conclude (finches long-tailed-finch))))
(define (rule classify-finch-rules) star-finch-rule
(if
(legs yellow)
(breast spotted)
)
(then (conclude (finches star-finch))))
(define (rule classify-finch-rules) red-eared-firetail-rule
(if
(legs brown)
(breast spotted)
)
(then (conclude (finches red-eared-firetail))))
(define (rule classify-finch-rules) white-eared-mask-rule
(if
(ear-patch white)
(breast insignificant)
)
(then (conclude (finches white-eared-mask))))
(define (rule classify-finch-rules) masked-finch-rule
(if
(ear-patch brown)
(breast insignificant)
)
(then (conclude (finches masked-finch))))
(define (rule classify-finch-rules) red-browed-finch-rule
(if
(ear-patch grey)
(breast insignificant)
)
(then (conclude (finches red-browed-finch))))
(define (rule classify-finch-rules) unknown-finches-rule
(then
(conclude (finches unknown))))
(define problem-solver main-problem-solver
(rule-set classify-finch-rules)
(object the-finch))
Here is a print-out of the problem solving session:
Starting up problem solver main-problem-solver
Entering rule-set classify-finch-rules
Triggering rule gouldian-finch-rule
What is the value of breast for the-finch ?
[ 0] unknown
[ 1] unknown
[ 2] insignificant
[ 3] white
[ 4] black
[ 5] barred
[ 6] spotted
[ 7] red
[ 8] yellow
[ 9] brown
[10] blue
[11] green
[12] grey
[13] red-with-black-line
make a selection (0 - 13) [0]
>> 5
Triggering rule crimson-finch-rule
Triggering rule beautiful-firetail-rule
Firing rule beautiful-firetail-rule
Adding fact (finches beautiful-firetail) to the-finch
The goal finches has been reached
problem-solver main-problem-solver ended with success, goal found.
It is very interesting to compare this code and the resulting session with the case where we assign the method linear mapping to the task classify finch. Then we obtain entirely different rules for the same domain model features-to-finch. This comparison illustrates very well the idea of the procedural encoding. It is also important to note that the change of the method is done only at the knowledge level after which we execute the translating task to-kan. Here is the new rule for the beautiful firetail:
(define (rule classify-finch-rules) beautiful-firetail-rule
(if
(belly barred)
(legs brown)
(flanks black)
(breast barred)
(throat insignificant)
(tail brown)
(rump red)
(back-and-wings insignificant)
(crown insignificant)
(ear-patch black)
(eyebrow insignificant)
(lores black)
(beak red))
(then
(conclude (finches beautiful-firetail))))
The rest of the rules are similar. Now the problem solving session will be quite longer as we have to define the value of each KAN attribute representing the separate parts of the finch body.
We can also do the same experiment with the infection diagnosis problem. If we assign the method differentiation to the task diagnose infection then we obtain rules with only one condition:
(define (rule diagnose-infection-rules) poliomyelitis-rule
(if
diarrhea
)
(then (conclude (infection-types poliomyelitis))))
(define (rule diagnose-infection-rules) scarlet-fever-rule
(if
headache
)
(then (conclude (infection-types scarlet-fever))))
(define (rule diagnose-infection-rules) diphteria-rule
(if
soar-throat
)
(then (conclude (infection-types diphteria))))
(define (rule diagnose-infection-rules) mumps-rule
(if
swelling-of-face
)
(then (conclude (infection-types mumps))))
(define (rule diagnose-infection-rules) german-measles-rule
(then (conclude (infection-types german-measles))))
(define (rule diagnose-infection-rules) unknown-infection-types-rule
(then
(conclude (infection-types unknown))))
This method optimises the rule-set according to some prior probabilities assigned to the target elements of the domain mapping model. These probabilities are described at the knowledge level in KREST by an additional model which is an input to the inference task. For instance if we want to identify the infection type using linear mapping with probability the task model dependency diagram of the task diagnose infection has the form, shown on figure 12.
Figure 12. Task model dependency diagram for a linear mapping with probability task.
The model infection type probabilities is an association between the probabilities and the names of the corresponding infections. This is shown on figure 13.
Figure 13. Probabilities of infections at the knowledge level
The procedural encoding of this problem solving method proceeds according to the algorithm in section 2.2. However there is an additional step before that, on which the elements of the mapping model are arranged by their probability. In fact the same rules are generated but in different order and the rule corresponding to the element with the greatest probability is encoded first. For the probabilities in figure 13 we get the following rules:
(define (rule diagnose-infection-rules) german-measles-rule
(if
fever
enlarged-glands-in-back-of-neck
ear-inflammation
running-nose
coughing
pink-spots
)
(then
(conclude (infection-types german-measles))))
(define (rule diagnose-infection-rules) scarlet-fever-rule
(if
fever
soar-throat
headache
vomiting
scarlet-rash
)
(then
(conclude (infection-types scarlet-fever))))
(define (rule diagnose-infection-rules) mumps-rule
(if
fever
swelling-of-face
swelling-under-jaw
swollen-glands
)
(then
(conclude (infection-types mumps))))
(define (rule diagnose-infection-rules) diphteria-rule
(if
fever
soar-throat
membrane-in-throat
inflammation-of-heart-muscle
paralysis-of-palate
neuritis
)
(then
(conclude (infection-types diphteria))))
(define (rule diagnose-infection-rules) poliomyelitis-rule
(if
fever
soar-throat
headache
vomiting
diarrhea
stiff-neck
pains
paralysis
)
(then
(conclude (infection-types poliomyelitis))))
As we see the rule for poliomyelitis has been moved from first to last place because it s mapping element is first in the domain model but has the lowest probability.
The run time library of the Structured Basekit contains all problem solving methods that are supported by the translation method to-kan [2]. However they are not designed to work with the newly introduced content forms. That is why we have defined new methods with the same Lisp code but with a little different feature-structure. The changes are in the direction of relaxing the constraints on the content form of the input and output models. The same applies also to the acquisition methods for mapping models. The method which should acquire a mapping between a set of models and a single model (as is in the finches example) still has to be introduced properly in the Basekit. All mentioned methods are kept under the top-structure kan interface methods.
The main result of this work is the claim that problem solving methods can be represented both in a declarative and procedural form and that direct transformation from the former to the latter is possible and easy to implement. The procedural encoding functionality of KREST gives knowledge engineers the flexibility and freedom to use declarative representations at the knowledge level during the analysis and design and rule-based representations for running problem solving applications.
It has also been shown that the symbol level representation of inference methods in KREST could be other than Lisp procedures. Therefore this is one more evidence supporting and justifying the separation of knowledge level descriptions from symbol and code level descriptions.
And finally, the work described here has shown that the environment of KREST is quite suitable for performing experiments in the field of knowledge systems. The knowledge engineer has free access to all structures and procedures and is able himself to extend them with his own constructs. This white-box approach [3] is especially suitable for users who want to go deeper into the system they build.
2. Goessens L., De Vroede K., Slodzan A., The Structured Basekit Manual, VUB AI
Memo, September 1993.
3. Steels L. Reusability and configuration of applications by non-programmers.VUB- AI Memo 92-4
4. Steels L. Knowledge systems. VUB-AI Lab draft edition, 1991.
** On leave from the Institute of Informatics, Bulgarian Academy of Sciences, Sofia 1113 Ac.Bonchev, bl.2, Bulgaria
