
           






         


                                      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!) 



