Programmer 7500

home *** CD-ROM | disk | FTP | other *** search

/ Programmer 7500 / MAX_PROGRAMMERS.iso / CLIPPER / MISC / ESIE.ZIP / TUTOR < prev

Wrap

Text File | 1986-07-06 | 59.3 KB | 1,436 lines

ESIE The Expert System Inference Engine Tutor Lightwave July 1986 P.O. Box 16858 Tampa, FL 33617 Copyright 1986 All Rights Reserved. This manual may only be distributed as one file on the ESIE distribution diskette. Such duplication and distribution is authorized without compensation as long as the diskette is a duplicate of the ESIE distribution diskette. This manual may also be distributed in printed form as long as a copy of the distribution diskette is attached. All other distribution is strictly prohibited. Page 1 Table of Contents Introduction . . . . . . . . . . . . . . . . . . . . . . 2 Some Example Knowledge Bases . . . . . . . . . . . . . . 3 Animal . . . . . . . . . . . . . . . . . . . . . . . 5 Doctor . . . . . . . . . . . . . . . . . . . . . . . 9 Building Your Own Knowledge Base . . . . . . . . . . . . 11 An Example: Building PC . . . . . . . . . . . . . . . . . 16 Hints For Building Really Super Knowledge Bases . . . . . 24 Page 2 Introduction This manual is designed for the person who has limited experience in the field of Artificial Intelligence (AI), or who needs a little refresher. This manual is intended to give you: a working knowledge of AI, help you learn about ESIE, give you enough information to build your own knowledge bases (KB), and provide some tips for building better knowledge bases in the future. You should print and keep the file MANUAL, which gives all the details concerning ESIE, with you while reading this manual and working the examples. An important point to keep in mind is that ESIE, by itself, can do absolutely nothing for you. ESIE is like a newborn child: it has absolutely no information about what is going on in the outside world. ESIE is the "brain" in that empty head. That brain must be fed knowledge, in the form of knowledge bases, for ESIE to be useful. On the other hand, an infinite number of knowledge bases can be used by ESIE. Therefore, ESIE can be a knowledgable mechanic at one minute then turn around and be a knowledgable doctor the next. A bit more versatile than a human, but not capable of storing as much information (yet!) Page 3 Some Example Knowledge Bases In order to get you used to the ESIE rule structure, seven sample KBs have been included on the distribution diskette. The seven knowledge bases are: ANIMAL, DOCTOR, GLASS, ABOARD, HEIGHT, HAIR, and GETAWAY. The last three of these are not knowledge bases and are meant simply to show rule structure and capabilities. ANIMAL is a KB that plays "twenty questions" with you in order to find out what type of animal you are thinking about. Before typing in 'GO' to ESIE, after loading the ANIMAL KB, think of an animal you want ESIE to try and find. Answer the questions put to you about the animal and ESIE will find out what animal it is in far less than twenty questions. ANIMAL is a decision tree KB that is fully structured. A fully structured KB indicates that there is a terminating leaf on every path of the decision tree. In a fully structured KB it is impossible for the rules in the KB to be out of order as there is one and only one path to every single goal in the KB. These types of KBs usually take the most effort to build, but are the most satisfying in their completion. You generally "map out" how the information should look before you begin coding. For example: type.transportation /\ / \ / \ / \ /2.wheels\ 4.wheels /\ /\ / \ / \ / bike car \ /motor \ /\ \ / \ truck / \ / \ moped bicycle Note that the there is a terminating leaf for every path in the tree. In these types of KBs, the user response is usually limited to YES and NO. ANIMAL is much like this. This is what a session with ANIMAL looks like. The splats indicate output from ESIE: Page 4 go Does your animal have a backbone? * yes Is the animal warm blooded? * yes Normally, does the female of your animal nurse * its young with milk? * yes Does your animal eat red meat? * yes Does your animal have finger wings? * no Does your animal have an opposing thumb? * yes Does your animal have a prehensile tail? * no Is your animal nearly hairless? * yes * I think your animal is a MAN * * I have completed this analysis. * * ==> * DOCTOR is a KB that is used to diagnose illness in children. Do not take DOCTOR too literally, please. We are not physicians, and the information in the KB came out of a single book. The KB was built in about 8 hours. The DOCTOR KB is there just to show off ESIE and is not meant to replace your physician. DOCTOR is a decision tree KB and is not fully structured. We coded DOCTOR and ANIMAL in two distinct styles in order to demonstrate ESIE's capabilities. GLASS is rather special for us. First, we didn't write it. We asked a friend of a friend to be one of the beta testers for ESIE and she came up with GLASS. She has no experience in AI whatsoever. GLASS demonstrates ESIE's ease of use. GLASS is used to give an evaluation of antique or depression era glass, which has gathered quite a following from what we understand. ABOARD is a knowledge base written by one of our users. This knowledge base is used in trying to learn a reason for a U.S. government officer to board a ship. It shows yet another style of KB coding. The ABOARD.DOC file is documentation for ABOARD. Page 5 Some Example Knowledge Bases Animal ANIMAL is a fully structured decision tree knowledge base. In order to build ANIMAL we gathered information concerning the classification of the animal kingdom. Gathering information on any subject that you wish to put into an ES will probably be the toughest part of your job as a Knowledge Engineer. A good approach is to begin by listing all the possible terminations of the decision tree. In ANIMAL all the terminations are the different animals, such as BEAR, FOX, etc. Then, using additional information, group the terminations into categories at the highest possible level and in as few categories as possible, hopefully two. In ANIMAL, the highest categorization offered by our information was, "does the animal have a backbone?" We know what you are thinking: that is not a good classification if one considers all the possible animals in the world. But we were not working with all the possible animals in the world; we decided at the outset to limit the number of animals to those that a person has a pretty good chance of thinking about. This included all the mammals, etc. Other animals are grouped into large single terminators, such as 'insect.' Now that you have all your terminators broken down into two categories, the next step is to take one of the two categories and break it into two smaller categories. Continue in this fashion until ALL your categories have been dismantled down to the single level, or leaves. You should have something that looks like the decision tree in the previous section. Now let us diverge for a moment to discuss decision points, depth, and KB cleanliness. At every "fork" in the knowledge base you have what is called a decision point. Here is where the work of a KB is carried out. Depth is how far down in the KB you currently are. For example, in the previous decision tree chart: 2.wheels and 4.wheels are on the same level, and motor, bike, car, and truck are also on the same level, but a different level than 2.wheels and 4.wheels. Motor, bike, car, and truck are said to be a level "deeper" than 2.wheels and 4.wheels. As you break up your knowledge base you often separate terminators based on qualities you as KE have determined. For example, we used backbone as a determining factor in ANIMAL, but there really are several very high order Page 6 qualifications for animals. The phylum Chordata is the only one having backbones, and makes up about half our terminators. Therefore, we chose backbone as the highest level qualifier. Now that you have your decision tree made there are two ways to write the KB: first, you can write each terminator with all of its qualifiers in each rule, or you can write rules for each decision point. If you remember your mathematics for expontial versus geometric expansion, you will see that it is better, and often easier to debug, if you choose the rule per decision point method. If you choose the former method not only would you be typing forever, but the KB may be too big to be operated on. Ok. So you decide to start coding ANIMAL, and although it does not matter where in the tree you start or go to, we always start at the top and kind of work left to right. We have decided the initial question is going to be: "Does your animal have a backbone?", and you are going to set something based on the answer to that question. However, you can not determine the type of animal from the existence of a backbone, so you must create "level designators." These designators determine which path you take at any given level or decision point. Many times they are artificial. For example, we used the level designators in ANIMAL of SUPERPHYLUM, PHYLUM, CLASS, ORDER, FAMILY, GENUS, SPECIES, SUBSPECIES, and SUBSUBSPECIES. While these are, indeed, the qualifiers used in animal classification (except subspecies and subsubspecies), we do not use them as a biologist would. It is perfectly alright to use artificial designators, as the user will never see them. It is a good idea to use something mneumonic. We once tried to debug a knowledge base where all the level designators were variables from A1 to A258! Level designators are used to determine which path to take in the tree. It is a good idea to make sure that assignments to that designator are unique throughout the tree. A note about style and KB cleanliness here. Some practiced KEs will tell you that you can use the same level designator everywhere in the tree. This is true. However, if you use the same level designator everywhere in the tree debugging your KB may become impossible, because you have no idea where you currently are in a consultation. The trace function on many packages becomes nearly useless because you are always looking for the same thing. Point of interest: some texts may call the level designator the decision designator. Also, some KEs pick a unique designator for every decision point. You may do this too if you like, and it may be useful Page 7 on especially difficult KBs, but is not often required. One level designator per tree level is usually fine. Then begin coding your KB. The first rules will be the ones concerning backbone. if has.backbone is yes then superphylum is backbone if has.backbone is no then superphylum is jellyback Since you need this information from the user, you include the QUESTION rule: question has.backbone is "Does the animal have a backbone?" For the next rule in the KB you decide to go down the right hand side of the tree where the warm blooded qualifier splits up your terminators. Therefore you have to ask about the warm-bloodedness of your animal. Caution, here however, because the warm blooded attribute has nothing to do with the left side of the tree. Therefore, you have to make sure you are only dealing with the right side of the tree. To do this you incude an AND qualifier in the rules: if superphylum is backbone and warm.blooded is yes then phylum is warm if superphylum is backbone and warm.blooded is no then phylum is cold Several things to note here. First, we are going down a level in the tree, so phylum becomes our next level designator instead of superphylum. The superphylum part of the rule goes first, otherwise you would be asking your user questions that may not pertain to his animal, in this case about the animal's warm-bloodedness. In the above two rules you are again splitting the decision path in the decision tree. You will generally have one rule per link in the tree. You continue in this fashion until you have reached the terminators, upon where a rule will look like this: if species is notail and nearly.hairless is yes then type.animal is man ESIE works by tying in terminator rules with rules they reference, and rules those rules reference, etc., all the way to the top of the tree. In ANIMAL, the species part refers Page 8 to a genus part, which refers to an order part, etc., all the way up to the backbone rules. Continue writing rules in this fashion until you have written an appropriate rule for every link, and an appropriate question for every decision point. If you print out and read ANIMAL you will see what we are talking about. You can reconstruct the decision tree we used by looking at the ANIMAL KB. The next thing you need to do is to tell ESIE which one of the qualifiers in the KB we are really looking for. This is the goal, or the reason for the consultation: goal is type.animal ESIE will stop the consultation when he finds out what type.animal is. By being fully structured, ANIMAL has a terminator for every path through the decision tree. No matter what the user responds, ESIE will come up with an animal for him. While looking at the ANIMAL KB, you will also note that all the levels of the tree are kept together in the KB. There is a very good reason for this: user ergonomics. Let us say that we coded ANIMAL such that all the parts for the right side of the tree are first. Then if a users first question indicates an animal in the left side of the tree, then the user will have to wait until ESIE chugs through all those rules on the right side until he hits rules he can fire on for the left side. While ESIE is a very fast ESS, the wait can be several seconds. On the other hand, if the rules for various levels in the decision tree are kept together, then the user will never have to wait for a question. Page 9 Some Example Knowledge Bases Doctor DOCTOR is a non fully structured decision tree knowledge base. Non fully structured means different things to different AI researchers: for one it means that there are decision points in the tree that are not connected to the rest of the tree, for another it means that the ESS may not come up with a conclusion for every possible set of end user inputs. (There is not a leaf for every decision path in the tree.) A few say it means both. In any case, DOCTOR is both. We gained the information in DOCTOR from a single book that has a few chapters on childhood illnesses. As in building ANY knowledge base the first thing to do is obtain the knowledge. We began DOCTOR as we began ANIMAL: listing all the possible illnesses that a child could have (finding all the terminators in the tree), and we gathered information about each one that would make it unique from the others. However, here is were the similarity ceases. We realized that our knowledge would be far from complete. That is, it would be nearly impossible for us to group the different illnesses into categories based on the knowledge source we had. So, we simply started entering illnesses into the KB, making sure that every illness entered had rules that made it unique from the illnesses entered previously. That is the key to making a non fully structured KB work. Although, with the KB given it, ESIE may ask some questions that have absolutely no pertinence as to the child's illness (i.e. he may or may not have the symptom and answering it will not help the determination), and the user may be asked to answer more questions than with a fully structured KB, the KB will still be GREAT. When building a non fully structured KB you must look out for positioning in the rule base. It is the only time you must do so. Let us explain. When you have a KB that is not fully structured, rule positioning can be important. You need only worry about rule positioning if the <variables> in the IF parts are identical. This becomes obvious in the following two rule example: if has.fever is yes then type.disease is roseola if has.fever is yes and has.inflammed.ears is yes then type.disease is serious.ear.infection Page 10 As ESIE is searching for 'type.disease' he comes across the first rule and invokes a QUESTION for has.fever. The end user specifies yes so ESIE concludes that type.disease is roseola and terminates this consultation. However, the child really had a serious ear infection, but ESIE never got that far. A better way to arange the rules would be: if has.fever is yes and has.inflammed.ears is yes then type.disease is serious.ear.infection if has.fever is yes then type.disease is roseola Now, when ESIE encounters the first rule he invokes a question to find has.fever. Since the answer is yes he invokes the QUESTION to determine if the child has inflammed ears. Since the answer is yes, ESIE reaches the correct conclusion that the type.disease is a serious ear infection. Of course, if your information about 'roseola' was more complete you could simply add another rule to make it unique from serious ear infection. If your information is not complete, then you can add a rule like the one above to be your "catch all." If none of the other has.fever rules fire, then the disease must be roseola. Take a minute to look at the DOCTOR KB and compare it to the KB for ANIMAL. Any tree you try to put together for DOCTOR will look much different than the fully structured one for ANIMAL. Do not be fooled into thinking that the only type of KB you plan on doing is the fully structured kind. Nearly every usable KB is of the non fully structured variety, and, believe us, they are more than successful. Building structured KBs can often be nearly impossible. A system such as ANIMAL is often used as a learning tool in expert system education because biologists have spent lifetimes building schema to classify the animals, and it is possible to build fully structured knowledge bases with this very scientific, well documented, information. Page 11 Building Your Own Knowledge Base The first thing you must do when you decide to build a KB is to decide in what area the knowledge base is going to present expertise in. This may be a tough decision. It should be something were there is clear, formulated information, with enough presented decision steps to get you started. You will have to translate this information into production rules. The area you are thinking about building an ES for is called the "target" in AI parlance. Some areas are very prone to decision making, for example, the ANIMAL example KB. The information about the animal kingdom is plentiful, well categorized, and there are clear decision steps in separating the available leaves of the tree. Sources of information can be nearly limitless. As you are an expert in several areas of human endeavor, you already possess plenty of clear, well formulated information that can be put into knowledge bases. The problem comes in analyzing our own thinking process; describing in words what we automatically do in our heads can be a very strenuous exercise. However, it is usually pretty easy to ask yourself questions. For example, you may be able to code the "rules" that go into the maintenance of a '57 Chevy (love that car: Chevy should come out with a limited production run of them), as the rules would be obvious and explainable by a mechanic. However, the decisions a fighter pilot uses when confronted with an enemy may be impossible to code into rules because he uses intuition to guide his decisions. Welcome to the wonderful world of knowledge engineering (KE)! Experienced KEs are very adept at prying into a person's thought patterns without making it seem like an invasion of privacy. One of the worst obstacles to overcome when interviewing an expert is: "I don't know how I know that, I just know that!" It turns out that much of what we do as humans is very intuitive in nature. That does not mean we should all change our name to Samantha, it just means that we have not thought about our thinking. This obstacle can be overcome with patient, helpful interviewing and good analysis. Another obstacle is that the expert's decision making may be too cumbersome to code easily into production rules. It may be difficult, or even impossible, to code the decision-making process from the expert's frame of reference to the machine's. Page 12 For these reasons, it is a good idea to spend a fair amount of time researching where you want to apply AI. ESs are generally required where human action or knowledge is not easily available to solve the problem or to make a decision. This may be occurring due to a shortage of qualified personnel or due to the cost of hiring and training such personnel. Once the application has been decided on, then you must begin gathering knowledge in the form of production rules. These rules resemble an "IF-THEN" relationship. IF one thing is true THEN do another. For example, IF the car won't start THEN check the battery. Defining these IF-THEN rules, by interviewing and consulting experts in the target field, is how you build a KB. It is important to check the qualifications of the expert as well as the dedication of the expert to develop the system. A common language to be used between you and the expert(s) should be developed right away. Communication is essential! This common speaking ground should be mnemonic and very easy to use. A review of the KB and KB structure with as many of the experts who helped you develop the knowledge base is almost always a good idea. They will tell you where they said one thing yet meant another, or possibly were you made a mistake in creating a production rule. However, you may find it worthwhile to train the experts in the building of the knowledge base themselves. An even greater possibility for success comes if you are an expert in a field and choose that field to be built into a KB. Often, experts prefer developing systems in this manner instead of being interviewed by a programmer who might not have excellent communications skills. Some might even get carried away and develop a system par none. ESIE is very easy to use, and the expert might even have some fun coding his knowledge into a KB. Most people like to show off their expertise when given a chance! The gathering of information is often the toughest and the most discouraging step in building a KB. We urge you not to give up if it seems impossible or is very frustrating. It will probably fall very easily into place when you start coding the KB. Do not worry if you do not have complete knowledge, or that your knowledge is only rudimentary when you start building the ES: you can, and should, go back to the expert to ask new questions as the KB takes form. Most people have many things that they are very good at. Several of these might be built into KBs. We assume there is Page 13 something you are an expert in and can put your information into some production rules. This is often one of the most productive environments for building KBs. Try it: you may even find that someone wants to buy it from you. If you are your own expert in building a KB, try to do two things: 1) be objective. If you have an area that you are a little fuzzy about, or where there is significant difference of opinion among your technical peers, then get a second or third opinion. 2) be understanding. Allow a person not versed in your field to use the system as it begins taking shape. He/she will often tell you where something doesn't make sense. While it makes sense to you and is perfectly obvious, remember that you are building this system to help the kind of person sitting in that chair. After you have gathered a good chunk of information, or at least enough to get started, you should start entering the knowledge as rules in the KB. In ESIE there are seven kinds of rules. Now would be a good time to read The ESIE Rule Structure in the manual. What you read in that section will be the types of rules entered into the KB. When you get started with building your KB you will find that building these types of rules often comes naturally. No real work should be expended in translating knowledge into rules. If it is a chore for you, then relax: you are trying too hard, probably to keep the KB structured and coherent. Do not attempt this at first. You can always go back and make the KB "pretty" after the knowledge is in there. Simply think about the information you have and how that would look translated LITERALLY into an IF-THEN construct. Then cram that into the knowledge base right away. Entering rules in the KB is easy. You use your own word processor (see the section on ESIE Requirements in the manual to make sure your editor is compatible) and type in the rules as you would type in a letter to an old friend. The rules in ESIE can be entered into the KB in free format. That is, the KB can look pretty strange when you are through with it. For example, the following two KBs are identical: goal is type.animal if has.backbone is yes and has.finger.wings is yes then type.animal is bat question has.backbone is "Does it have a backbone?" question has.finger.wings is "Does it have finger wings?" answer is "Your animal is a " animal.type Page 14 and: goal is type.animal if has.backbone is yes and has.finger.wings is yes then type.animal is bat question has.backbone is "Does it have a backbone?" question has.finger.wings is "Does it have finger wings?" answer is "Your animal is a " animal.type We recommend something like the former structure. We might suggest, dear reader, that you make a couple of "play" KBs just to get used to ESIE, before you really dig in with the real world ones. Follow the guidelines for ESIE outlined in The ESIE Rule Structure, and we are sure you will have no problem. Although we would love to help everyone out there who is trying to debug a KB, we will offer telephone support only to the individuals who have paid the $145 price for ESIE. When you have enough rules in a KB to make a simple run, we recommend that you test what you have. See the manual on starting ESIE. When you get to the top level we suggest you turn trace on until you have the KB fully debugged. When trace is on ESIE will keep you informed of what it is doing. It will tell you what it is currently looking for and what it has learned. ESIE learns things when a QUESTION is answered and when a rule is "satisfied." Run through your KB, testing every path to your terminators using the GO command. Good luck! (We know, you are not superstitious, but it can't hurt, can it?) One of the best hints we can give you is to use mnemonic names for your <variables> and <values>. We can remember cringing when we was asked to help debug a KB with all the <variables> assigned a letter designator of A1 to A287. For the LEGALANSWERS type rule we suggest you try to restrict the end user responses to as few responses as possible. And, if you want to offer multiple responses, make a valid response for one question be an impossible answer for another, unrelated question. For example, if the question is about what time of day it is, and you want him to answer morning or afternoon, do not have numbers as legal reponses or specifically ask him if it is morning or afternoon. An unexpected response may make the consultation useless. On the QUESTION rule type try always to "beg the question" or "bait the response" as it is sometimes called. Remember what you will accept as valid answers and try to get the user to give you one of those answers through the question you are asking. Always try to be friendly, or at least not hostile, in your questioning. A good trick is to shorten the length of your questioning as you get deeper into the KB. As you Page 15 get deeper into the KB, the user will already have answered several questions and may not care to continue with all the verbage. You might substitute: "Does it have wings?" for "Does the animal you are thinking about have wings?" if you have already asked several questions. In the ANSWER type rule remember to leave a space at the end of your <text> if you want one. Try to phrase the <text> so that it accounts for every possible <value> of the <variable>. Be descriptive and friendly, but remember that the user has just been through a consultation, so superfluous verbage is not needed. Most of all, have fun with what you are doing! Page 16 An Example: Building PC This section of TUTOR is going to take you through the process of building an example knowledge base. Please enter the various pieces of the knowledge base into a file as they are built in this text. As with any KB we want to build, we must first determine the target. For one that everyone seems to know something about, Lightwave has chosen personal computers. The target is potential buyers of personal computers, and our KB will provide the expertise needed to aid in what type machine to buy. Good idea! Now, we begin our research into the different types of personal computers available. Wow! Talk about a headache! Persistently, we drive on. Soon, we note that there are just too many types of personal computers available, so we redefine the domain of our KB to aid people in making the decision of what to put in/with their personal computer. Super. We now have a domain we can work with and a heavily researched target area. We have trained ourselves to be the expert in this area. The next step, since we plan on building a fully-structured knowledge base, is to list all of the leaves on the decision tree. We believe we can build a fully-structured knowledge base because the information on configurations is well-documented and has clearly defined decision steps. The leaves are easily grouped because features of some leaves are identical. For purposes of this example only, we list four different leaves on our tree (possible configurations): minimum: 128KB RAM, monochrome monitor, 1 DSDD disk drive, portable. home: 256KB RAM, color monitor, 2 DSDD disk drives, dot matrix printer. business: 512KB RAM, monochrome monitor, 1 DSDD disk drive, 10 MB hard drive, letter quality printer. fully_loaded: 640 KB RAM, color monitor, high resolution monochrome monitor, 2 DSDD disk drives, 30 MB hard disk, dot matrix color printer. Page 17 We realize this to be overly simple, and you can simply ask the user what he wants here, but what if he does not know? The next step is to organize the leaves of the tree into categories. Oh-oh, trouble time. You are already an expert on the different types of categories out there, but you may be a little foggy on which type to recommend to a buyer. Time for more research. So you head on down to the store where you bought your personal computer and ask for some help. You happen to be a very lucky person and the person who sold you your machine is willing to give you an hour of his time so you can interview him. Besides, he knows that you paid list price for everything you own and he can afford to relax a little because of his commission. Also, he wants you to put his name in the knowledge base to help round up some more customers. OK. You two go where you won't be disturbed. (He suggests lunch at Bennigan's because you're buying.) Once alone, you show him your list of possible different personal computer configurations and ask him, "Why would a person want to buy a minimum system instead of a home system?" His answer is, "Because a person is going to be on the road a lot and cannot afford much weight." You whip out your little note pad and start writing, or better, have a concealed tape recorder so you do not miss anything and do not make him nervous. Next you ask him why a person would select a home computer instead of a business computer. He tells you that a home computer can play games and costs less, while the business computer has the memory needed to run big spread sheets. Fantastic. You are cruising now. By asking several more questions you find that: a fully_loaded system would be picked over the other three if someone wanted to run scientific or engineering applications, that you can separate home from the other three based on where the computer will be used, that minimum can be separated from the other three based on permanent location, that business can be separated from the other three by need for high-quality letters, and that fully_loaded can be separated based on the need for color prints. You are now totally confused and take a long pull on your margarita. So you ask him, "I want to break these choices into two groups. How would I do it?" Response: "I don't know." Great. And this is costing you lunch! So you look at your data again, and being on the ball you ask, "Are any two of these choices similiar?" He says, "Hmmm, yes - the business and fully_loaded are similar because they will purchased by businesses and need a fixed location." Page 18 Bingo. A pattern emerges, you tell him you have to go and pay the bill before it gets too far out of hand. A key to good interviewing is the ability to ask the question in far more than one way. You know what information you want to get, but you have to get that information out of your interviewee in the only manner he knows it - his own internal data arrangement. Re-asking the question in a different form might get you the information you need. So now you rush home and build your decision tree: (moveable) <= yes no => / \ / \ / \ minimum (games) / \ / \ / \ home (high-quality letters) / \ / \ / \ business fully_loaded A point of good KB style here: never, ever use your first pass at a decision tree. Take a good look at your first pass and you will nearly always see something that can be improved. Improve it and take it back to the experts, (usually doesn't cost you lunch the second time around), for their ideas. For purposes of this example, we will use the decision tree shown above. Once you have a high quality decision tree the next step is to load the knowledge base. Please note that we have not even turned on the computer yet. Lots of work to do before-hand. You note that your tree is three levels deep, so you will have to come up with two level designators. The number of level designators will be the depth of the tree minus one. (Simple, huh?) Let's choose the level designators of: MOVEABLE, and GAMES. Level designators are used to hold intermediate answers. By using level designators, a person does not have to include all the rules that make up a leaf decision. Goal will be TYPE.MACHINE. You will also need to choose question variables for every decision point in the tree where you need user input. For Page 19 fully structured decision trees, this will be at every decision point. Our question variables will be NEED.MOVE, PLAY.GAMES, and HIGH.QUALITY. Time to begin. Calling up your favorite text editor you enter this into a file: goal is type.machine if need.move is yes then type.machine is minimum if need.move is no then moveable is stay.still if moveable is stay.still and play.games is yes then type.machine is home if moveable is stay.still and play.games is no then games is no.games if games is no.games and high.quality is yes then type.machine is business if games is no.games and high.quality is no then type.machine is fully_loaded An important rule of thumb in building fully structured knowledge bases is this: if ask-a-question rule and level-designator rule then level-designator or goal rule The root question is the only one that is an IF rule without an AND rule. A second point to mention in fully structured KBs is that every possible answer to a question has a place to go to. For this reason, many fully structured KBs limit legal answers to YES and NO. In a fully structured knowledge base the rules can exist in any order in the rule file. Our sample KB is fully structured. After we complete it, try running it through ESIE after changing the order of the rules. The results and order of questioning will be exactly the same. If you had not used level designators, the KB would have looked like this: goal is type.machine Page 20 if need.move is yes then type.machine is minimum if need.move is no and play.games is yes then type.machine is home if need.move is no and play.games is no and high.quality is yes then type.machine is business if need.move is no and play.games is no and high.quality is no then type.machine is fully_loaded Which doesn't seem too bad, but remember that our tree is only three levels deep. For each level deeper in the KB we go we would have to add another AND clause to every rule. For a KB even 8 layers deep, (up to 256 leaves), that would mean 1,792 AND clauses. ANIMAL is ten levels deep and has significantly fewer AND clauses. To make matters even more confusing, some KEs suggest that the level designator and the question should be the same variable. Fair enough. This is what the PC KB would look like using the same variables: goal is type.machine if need.move is yes then type.machine is minimum if need.move is no and play.games is yes then type.machine is home if play.games is no and high.quality is yes then type.machine is business if play.games is no and high.quality is no then type.machine is fully_loaded The problem with doing this is that now the KB is not completely fully structured: you cannot move the rules about willy-nilly and get the same questions asked in the order you want them asked. That might not seem a disadvantage to you, but it might well be later when you move rules around looking for better user response. Page 21 With all that good stuff out of the way, we need to make up some questions, select an answer and list the legal answers: question need.move is " Do you need to take your computer with you on the road?" question play.games is " Do you intend on playing games with your computer?" question high.quality is " Do you need letter quality printing?" answer is " Your personal computer should be " type.machine legalanswers are yes no * Now to select some suitable introductory and terminating text: introtext is " Welcome! This very simple Artificial Intelligence knowledge base will try to help you decide what personal computer you should buy based on your needs. Please answer all the questions either yes or no. Acknowledgement goes to John Smith who still owes me a margarita. " termtext is " Thank you very much. The various configurations are: minimum: 128KB RAM, monochrome monitor, 1 DSDD disk drive, portable. home: 256KB RAM, color monitor, 2 DSDD disk drives, dot matrix printer. business: 512KB RAM, monochrome monitor, 1 DSDD disk drive, 10 MB hard drive, letter quality printer. fully_loaded: 640 KB RAM, color monitor, high resolution monochrome monitor, 2 DSDD disk drives, 30 MB hard disk, dot matrix color printer. " Putting all that together gives us this: goal is type.machine Page 22 if need.move is yes then type.machine is minimum if need.move is no then moveable is stay.still if moveable is stay.still and play.games is yes then type.machine is home if moveable is stay.still and play.games is no then games is no.games if games is no.games and high.quality is yes then type.machine is business if games is no.games and high.quality is no then type.machine is fully_loaded question need.move is " Do you need to take your computer with you on the road?" question play.games is " Do you intend on playing games with your computer?" question high.quality is " Do you need letter quality printing?" answer is " Your personal computer should be " legalanswers are yes no * introtext is " Welcome! This very simple Artificial Intelligence knowledge base will try to help you decide what personal computer you should buy based on your needs. Please answer all the questions either yes or no. Acknowledgement goes to John Smith who still owes me a margarita. " termtext is " Thank you very much. The various configurations are: Page 23 minimum: 128KB RAM, monochrome monitor, 1 DSDD disk drive, portable. home: 256KB RAM, color monitor, 2 DSDD disk drives, dot matrix printer. business: 512KB RAM, monochrome monitor, 1 DSDD disk drive, 10 MB hard drive, letter quality printer. fully_loaded: 640 KB RAM, color monitor, high resolution monochrome monitor, 2 DSDD disk drives, 30 MB hard disk, dot matrix color printer. " By having all the above in a KB file your are ready to run ESIE! Please read the manual on how to get her fired up. As you can see, the actual implementation is pretty straight forward. It is the gathering of data that takes the most work. Piece of cake. There are literally millions of good, important knowledge bases that can be built. It is simply up to you to build them! For those of you who like instant reward for your work, Lightwave will accept your version of the PC KB until midnight December 31, 1986. The best two of those received by that time will earn their designers a free upgrade to version 3.0 of ESIE. All people who enter a PC KB will be kept advised of the current contest status. Judging will be done by the staff at Lightwave, and all decisions are final. Using the numerical operators of ESIE earn extra credit. Entries must be received on a DOS-formatted double sided double density 5 1/4 inch diskette. The knowledge base should reside in a file called PC, while your name and address should reside in a file called READ.ME. Your phone number, comments and other files/information is optional. Page 24 Hints For Building Really Super Knowledge Bases This section is a catch-all of KB building ideas that have not been covered elsewhere in these manuals. You might never need to use any of these, and these may not be enough, but they are here in case you need them. The sample KB GETAWAY shows how to display already learned information to the user in subsequent questions. The trick to making this work well is to have segments of the decision tree without branches. While this is easy to do in the example by forcing the user to type in YES, this is not the recommended solution. A quickie, usable solution would be to ask the user if he/she needs to do something that nearly everyone would answer yes to. In GETAWAY, asking if a person needs to drive if his age is over 20, 17, or 15, will almost always get a yes answer. Another solution is to ask the question, but not to care what the answer is. You can do this by duplicating the rule but substituting 'no' for 'yes.' When the user is running knowledge bases through ESIE it is important that he not have to wait too long for the next question to appear. In ESIE you will not have to worry about rule positioning until your KBs start to get pretty large. In large KBs, you can assure quick questioning by positioning rules that appear at the same level in the tree together. If you have a very, very large KB, then you can also position the rules within these level boundaries so that the most likely rule is hit first. If your knowledge base is fully structured, then you can have your rules anywhere and the results will be the same. If your KB is not fully structured, then you must watch for correctness first, then worry about getting questions out to the user quickly. In a non fully structured KB, you seldom have to worry about speed. Use your introductory and terminating text freely. Use the introtext to explain: what this KB is all about, what kind of things are going to happen, why this KB exists in the first place, where and when this KB is to be used, and, of course, to give yourself some pats on the back and put your name up in lights! One of the best uses for termtext is to describe what the decision means. Also tell a user where to go if he would need more information about a conclusion. (Nope, you CAN'T tell him to go there!)