|
|
|
|
The purpose of this workshop is to · Introduce you to the basic look and feel of Kappa PC: its 'main' window, 'edit tools' window, 'Object browser' window, and 'Session' window; and its various object editors. · Introduce you to the most essential objects that go to make up a Kappa-PC program: classes, instances, slots, methods, monitors, rules, and functions. · Help you implement your own simple rule-based system. You might just want to jump to the end of this workshop and try to implement your own system.
When you load Kappa-PC, you will see three windows on screen:
The main Kappa window, at the top of the screen, allows you to display any or all of nine other windows - via the nine icons shown. The first and third of these - the object browser and edit tools windows - are already on screen. The second, the 'session window' is also particularly important. The main Kappa window also has some menus, of which only the 'File' menu is important - it contains 'New', 'Open', 'Save', 'Save as…', and 'Exit' options, and allows you to access the Help facility via the 'On-line Manual …' option. The object browser displays the class and instance objects that currently form the system's knowledgebase (apart from any that are concealed), together with an indication of how they are organised into a hierarchy. When you have written your own knowledgebase, some of these objects will represent concepts in the domain, and others will represent parts of the user interface. At the moment, however, most of them represent parts of the user interface. You can use the object browser to get a general overview of the way the knowledgebase is organised (at least as far as the classes and instances are concerned). You can also use it as a quick way to find and access the internal structure of one of these classes or instances, or to add classes or instances to the hierarchy. The edit tools window allows you to easily access editors for five different sorts of objects, so that you can examine, make, change or delete these objects. It's particularly useful for functions, rules and goals, which you can't access via the object browser.
What the objects are for - a quick overview 1. Classes and instances. You need to be aware of the central role that these objects play in the construction of a Kappa knowledgebase. They contain slots, and these are the places where information about things or concepts that are important in the knowledge domain is stored. And, in addition, each of the images that go to make up the user interface is represented by class and instance objects. As an example, if you were writing a medical diagnosis expert system, you would of course be interested in patients and what was wrong with them, so you might very well invent a class object called 'patient'. You might very well give it a slot called 'diagnosis'. The system would do some reasoning, to examine the evidence and decide what was wrong with the patient, and might conclude that they had pneumonia. 'Pneumonia' would be stored in the slot called 'diagnosis' as its value. The system might have a window labelled 'Diagnosis: what the patient is suffering from', and it might be arranged so that it appeared on screen when the reasoning was finished. This window would be an object (an instance of a class of windows) in its own right. It would display the word 'Pneumonia' - that would be the value that it contained - but it would get this value from the slot called 'diagnosis'. As well as slots, a class/instance can possess 'methods'. These are little programs that actively do something with the information that the class/instance possesses (such as displaying it on screen). A method can be used as a 'monitor' - this is a little program attached to a slot, that is automatically put into effect whenever something happens to the slot (such as its value changing). In the interests of efficient storage of knowledge, classes are organised into an inheritance hierarchy. This means that classes can have sub-classes, and sub-sub-classes, and so on. The objects at the bottom of this hierarchy are often instances rather than classes. 'Inheritance' means that a particular class will normally possess all the slots and methods of all the classes above it in the hierarchy. For example, if you were to invent a class called 'patient', and three classes to act as its subclasses - 'orthopaedic_patient', 'circulatory_patient', 'gynaecological_patient', and an instance of an orthopaedic_patient called 'john_smith', and if you were to give 'patient' a slot called 'body_temperature', then all the other three classes and the instance would automatically have this slot too. 2. Rules. Rules provide the main mechanisms for reasoning, for solving problems, in a system like this. A rule has an 'if-part' (elsewhere in this reader I have called it 'the conditions of the rule.), and a 'then-part' (elsewhere in this reader I have called it 'the conclusions of the rule'). The task of the if-part is generally to spot a pattern in the available evidence - this evidence will generally be stored in slots attached to classes/instances. The task of the then-part is generally to draw a conclusion or a set of conclusions, (or occasionally to perform a calculation), and to store these conclusions in slots attached to classes/instances. 3. Goals. Goals are mainly used when rules are being used for 'backward-chaining' reasoning. You can't start a backward-chaining process unless you know what the final conclusion of the chain of reasoning is (at least roughly) supposed to be: a goal specifies what that final conclusion is. 4. Functions. Functions provide a series of instructions, rather like a piece of conventional programming. If the job of a particular expert system is to find out what's wrong with a patient by backward chaining, and then prescribe some medicine by forward chaining, it is likely to contain a function that instructs it to do this piece of backward chaining and this piece of forward chaining, in that order. 5. User interface objects. As mentioned above, these are all instances of classes. The task of one of these objects may be to get some information from the user, in which case it will probably put the information into the slots of class/instance objects. Or it may be to put some information on screen in front of the user, in which case it will probably get this information from the slots of class/instance objects. Or it may be to allow the user to make the program do something (such as run), by setting some function in motion.
Exercise 1. Log onto one of the PCs using your own account. 2. Access Kappa-PC via the 'Start' menu, the 'Middlesex Local Software' sub-menu, and the 'Common Applications' sub-sub-menu. It has an icon which is a red-and-yellow K symbol. Once it has loaded, you should see the three windows described earlier on screen. You could call this the "undeveloped" version of Kappa, since no attempt has yet been made to turn it into a working knowledgebase. 2. Choose File.Open in the main Kappa window. In the dialogue box, look in the panel on the left for the file 'QUICK.KAL'. Double click on it to load it. 3. You will see that an extra window appears on top of the three that were already there. This is labelled 'Main Screen', but is in fact the session window for this application. The session window is the main vehicle for an application's user interface. It contains as many input, output and control images as you want to put into it. It can have subsidiary session windows, and this one has. 'QUICK.KAL' has some claims to be an intelligent database. It contains a little data about five employees in an engineering firm, together with tools for displaying the data and for easily changing some of the stored features of the various employees (their performance, job title, etc.) Try out the various features, including those on the sub-window that appears when you click on 'Change employee status'. 4. Now click on the 'object browser' window to bring it to the front. Observe how the object hierarchy now has a whole cluster of objects that weren't in the 'undeveloped' version of Kappa: Bill Engineer Jean JobLevel Tom Manager Mary Dick The five items in the last column are instances, the others are classes (the arrangement of instances that you have may not be exactly the same as you see here, because your experimentation with the user interface may have moved them around in a different way to the way mine did). Double-click on one of the objects: this will bring up its editor and allow you to examine its internal structure. Double-click on the slots and methods in order to examine their internal structure. Use the 'cancel' and 'X' buttons to get the editors off screen after you've finished using them. 5. Use the 'Rule' button on the 'Edit tools' window to get up the editor for the rule 'Recommend' and examine its structure. Notice the way it looks for a pattern involving a particular engineer's performance and salary, and draws a conclusion (that they should be moved to the post of 'manager'). Use the 'X' button to get the editor off screen after you've finished using it. 6. Use the 'Function' button on the 'Edit tools' window to get up the editor for the function 'Promote' and examine its structure. Notice the way it contains a series of instructions, to be executed one after the other, although some of them are only executed if a certain condition is true. Use the 'X' button to get the editor off screen after you've finished using it. 7. When you've finished exploring the knowledgebase, leave Kappa via the File.Exit option on the main Kappa window. No need to save any changes you've made.
**********************************************************************
Now that you've familiarised yourself with Kappa PC, you should create your own expert system.
First, create a new expert. Make sure to save this file as your own .kal file. Save it to your floppy or your network drive.
Second, think of a rule you'd like to implement.
Third, create an object and give it two slots.
Fourth, create a rule which will test one slot, and change the other slot.
Fifth, create a user interface. This should enable you to set the first slot (via for instance a radio button), and invoke the rules (via a button). An example of how this can be done can be found in workshop 2, but first try to work it out by yourself.
Sixth, run the system and see if the second slot has changed.
Seventh, expand the system.
