BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to artificial intelligence and knowledge engineering, and more particularly to a digital computer for executing or interpreting a knowledge base to perform symbolic reasoning. The invention specifically relates to a knowledge system which enables its own knowledge and performance in problem solving to be compared to that of a student or expert for the purpose of providing instruction or evaluation.

2. Description of the Related Art

Knowledge systems are computer systems that emulate reasoning tasks by using an "inference engine" to interpret encoded knowledge of human experts stored in a "knowledge base". Knowledge systems are useful for problems that require diagnosis, recommendation, selection or classification. Such tasks in the past have been performed by human experts. If the domain of the knowledge base, or scope of the problem, is sufficiently narrow and a sufficiently large body of knowledge is properly encoded in the knowledge base, then the knowledge system can achieve performance matching or exceeding the ability of a human expert. In such a case the knowledge system becomes an "expert system".

The first step in building a knowledge system involves encoding unstructured and often unarticulated knowledge into machine readable form. For expert systems in a given application domain, several different kinds of knowledge are involved. The different kinds of knowledge include the vocabulary and structure of the domain, the judgmental knowledge of the domain, and the procedures or techniques by which the domain knowledge is applied to solve a specific problem. The vocabulary of the domain refers to the names of the individual objects and ideas that must be encoded in the knowledge base. The structure of the domain refers to relationships between the objects and the ideals in the domain. The judgmental knowledge of the domain refers to the rules of thumb or rules of inference which are used by human experts to solve a problem involving uncertain knowledge or to restrict the scope of relevant knowledge or to direct the search for solutions among various possibilities covered by the knowledge base. Therefore, to some extent the procedures or techniques by which the domain knowledge is applied are a part of the judgmental knowledge of the domain. The procedures or techniques, however, also include a good deal of knowledge that could be considered routine rather than judgmental, such as how to carry out a consultation with a user.

A user typically accesses knowledge in the knowledge system interactively during a consultation. It is important that the consultation occurs in a manner that assures the user that the knowledge in the knowledge base is being properly considered and applied. It is particularly important, for example, that the user is not asked for redundant information and is given specific reasons why the knowledge system arrives at particular conclusions.

Presently there are highly developed commercial tools which may be used by skilled knowledge engineers to build knowledge systems. The well-known commercial tools (such as KS300 manufactured by Teknowledge, Inc., 1850 Embarcadero Road, Palo Alto, California, 94303) are patterned after a tool called EMYCIN described in The Emycin Manual by Van Melle et al., Stanford University Report No. STAN-CS-81-885, Stanford, California, 94305 (October, 1981).

EMYCIN is specifically designed as a domain-independent system for constructing rule-based consultant expert system programs. Domain knowledge is represented in EMYCIN systems primarily as condition-action production rules which are applied according to a goal-directed backward chaining control procedure. Rules and consultation data are permitted to have associated measures of certainty, and incomplete data entry is allowed. The EMYCIN system includes an explanation facility that displays the line of reasoning followed by the consultation program, and answers questions from the user about the content of the knowledge base. When the user is asked for information, the user may respond by asking why information is being sought, and how information is known or will be found out.

EMYCIN also has special options called EXPLAIN, TEST and REVIEW for providing information at the end of the consultation about the values of selected groups of parameters. The parameters are selected by defining a variable named IMPORTANTPARMS. A condition may be specified that must be true in order for the option to have effect upon each group. The EXPLAIN option provides terse explanations about how the parameters' current values were concluded. With the TEST option specified, the system compares the current value of each parameter with a stored value for the case. REVIEW provides explanations, and if these are incorrect, helps the expert to locate the problems in the knowledge base.

A recognized shortcoming of the EMYCIN-based tools is that the high-level control knowledge about how to conduct a consultation is buried in the rules or is intermingled with definitions of objects and structures of the domain. As described in Erman et al., U.S. Pat. No. 4,658,370, this control knowledge should be made explicit by encoding it in an applicative an imperative procedural language defining control actions to be executed during interruption of a built-in control procedure at specified control steps. To provide transparent representation of control knowledge as well as factual knowledge, the knowledge base is preferably organized into distinct frames including the rules; control blocks separately encoding the control knowledge; and classes which become instantiated, attributes which take on values describing the class instances, class types, legal value hierarchies, and user defined functions, which all encode factual knowledge. The knowledge engineer may provide control blocks to be executed at the start of the consultation, after the instantiation of specified classes, when a value for a specified attribute is to be determined, after a specified attribute is determined, and upon explicit invocation by another control block.

The knowledge engineering tool described in Erman et al. U.S. Pat. No. 4,658,370 has been manufactured and sold by Teknowledge, Inc., 1850 Embarcadero Road, Palo Alto, Calif., 94303, under the trademakr "S.1". This knowledge engineering tool is intended for use by experienced knowledge engineers in building complex knowledge systems.

A knowledge engineering tool suitable for use by people with limited computer experience is described in Hardy et al. U.S. Pat. No. 4,648,044, herein incorporated by reference. Hardy discloses that because of the lack of knowledge engineering tools based on a transparent expert system language, a person needs a good deal of formal education in computer science as well as specialized training in knowledge engineering to become a skilled knowledge engineer. The term "expert system language" denotes the manner or way in which factual, judgmental and control knowledge is encoded in the knowledge base. Hardy et al. discloses a useful knowledge engineering tool for building an expert system and running a consultation on a personal-type microcomputer. The knowledge base language is easily understood because English-like language statements express facts, rules and meta-facts for specifying control knowledge, and control during a consultation is goal directed in depth-first fashion as specified by rule order. The tool includes interactive knowledge base debugging, question generation, legal response checking, explanation, and certainty factors. For the more experienced knowledge engineer, the tool permits the use of recursive rules and universally quantified variables.

The knowledge engineering tool described in Hardy et al. U.S. Pat. No. 4,648,044 has been manufactured and sold by Teknowledge, Inc., 1850 Embarcadero Road, Palo Alto, Calif., 94303, under the trademark "M.1". The current version of "M.1" provides a few additional features. The most significant of these includes a proposition called "do" for executing M.1 commands when applying a rule.

The above-mentioned knowledge system tools have been especially designed and widely used for constructing consultation systems which advise a user in a way which parallels the way that a human consultant advises a client. In this consultation mode, the system applies knowledge about how to solve a specified problem, and it also applies knowledge about how the consultation should be conducted with the user.

One field of application of knowledge systems is computer aided instruction, in which interactive computer programs are used for instigating and controlling learing. But a knowledge system that is an expert in a particular domain is not necessarily an expert teacher, since a good teacher must understand what the student is doing, not just what he is supposed do. A knowledge-based tutor should present a lesson optimized for each student, and should diagnose and correct a student's misunderstandings.

As described in A. Barr & E. Feigenbaum, The Handbook of Artificial Intelligence, Vol. 2, HeurisTech Press, Stanford, Calif. (1982) pp. 223-294, the main components of an intelligent computer-aided instruction (ICAI) system are problem solving expertise, a student model, and tutoring strategies. The problem solving expertise is the knowledge that the system tries to impart to the student. The student model is used to indicate what the student does and does not know. The tutoring strategies specify how the system presents material to the student.

On page 233 of Barr and Feigenbaum, supra, it is said that the tutoring module of ICAI systems must integrate knowledge about natural language dialogs, teaching methods, and the subject area. This is the module that communicates with the student, selecting problems for him to solve, monitoring and criticizing his performance, providing assistance upon request, and selecting remedial material. The design of this module involves issues such as when it is appropriate to offer a hint or how far the student should be allowed to go down the wrong track. This additional knowledge, beyond the representation for the subject domain and of the student's state of understanding, is knowledge of how to teach.

As described in Barr and Feigenbaum, supra, ICAI systems have been built which more or less demonstrate various parts of what would constitute a fully useable system.

A system called SCHOLAR by Jaime Carbonell concentrated on handling unanticipated student questions and generating instructional materials in varying levels of detail, according to the context of the dialog. The domain knowledge was represented in a semantic net separate from the tutor. A goal was to make the tutorial reasoning strategies independent of the domain being discussed.

A system called WHY by Alan Collins and Albert Stevens focussed on Socratic-style probing of causal relations, and attempted to reveal inadequacies in a student's general model of causal relations by selecting examples which violate rules the student has articulated.

SOPHIE (I, II and III) by John Seely Brown and Richard Burton permitted broad student initiative during tutorial interaction, and used numerous heuristic strategies for answering the student's questions, criticizing his hypotheses, and suggesting alternative theories for his current hypotheses. The original Sophie was extended by providing an articulate expert debugger or explainer having the capability to solve the problem as presented to the student and to explain reasoning or interpretation as data pertaining to the problem was given to the student. SOPHIE I, II and III are also described in Brown et al., "Pedagogical, Natural Language and Knowledge Engineering Techniques in SOPHIE I, II and III," Cognitive and Instructional Sciences, Xerox Palo Alto Research Center, REPRINTED IN Sleeman et al., eds., Intelligent Tutoring Systems, Academic Press (1981).

A system called the WUSOR/WUMPUS Tutor by Ira Goldstein described student knowledge in terms of expert rules by a use/appropriate ratio, and explained the reasoning of an expert when a student behaved differently. The system included four modules: the Expert, the Psychologist, the Student Model, and the Tutor. The Expert told the Psychologist if a player's move was nonoptimal and which skills were needed for the player to discover better alternatives. The Psychologist employed this comparison to formulate hypotheses concerning wich domain specific skills are known to the student. These hypotheses are recorded in the Student Model, which represents the student's knowledge as a subset of the Expert's skills. The Tutor uses the Student Model to guide its interactions with the player. Basically, it chooses to discuss skills not yet exhibited by the player in situations where their use would result in better moves.

A system called GUIDON by William J. Clancey demonstrated that teaching knowledge could be treated analogously to the domain expertise of consultation systems. The teaching knowledge was codified in rules and built incrementally by testing it on different cases. For encoding knowledge of the problem domain, GUIDON used the EMYCIN-type production rules of a consultation expert system called MYCIN designed for diagnosing infectious diseases. The MYCIN rules were separate from the teaching rules and they were not modified for the tutoring application but they were used in new ways, for example, for forming quizzes, guiding the dialog, summarizing the evidence, and modeling the student's understanding.

Sample interactions with GUIDON are shown on pages 268-270 and 273-274 of Barr and Feigenbaum, supra. The student asks for the data and subgoals relevant to the topic being discussed. These are extracted from MYCIN's rules. The student asks how a particular datum is useful. He is given the case specific information, and then a summary of its use in the rule or rules that apply in this case. The student indicates that he has determined a particular subgoal. If the student's response were not consistent with his claim, he would be asked to state his conclusion and then possibly support it. When the topic of discussion is completed, the student is given a summary of the relevant conclusions. "Key factors" from each rule are automatically extracted and only the "interesting" (useful) conclusions are displayed. GUIDON also probes the student to determine whether the student knows why an alternative hypothesis is discredited. GUIDON asks the student to state a hypothesis for a subgoal. The program asks the student to support his hypothesis. Factors received from the student are related to the MYCIN rules, and the student is told whether the factors are correct and is told about factors missed. Other hypotheses are then discussed.

Before a session with a student begins, a case to be presented to the student is selected from a case library, and GUIDON uses MYCIN to "solve" the case. The results of this background consultation are reconfigured so that the rules are indexed both by the goals that they conclude about and the subgoals or data needed to apply them. During the tutorial session, the student inquires and receives more case data, and the same information is used to drive the MYCIN rules in a forward direction. The record of what the expert (i.e., MYCIN) "knows" at any given time during the student-run consultation forms the basis for evaluating the student's partial solutions and providing assistance.

The operation of GUIDON is further described in William J. Clancey, "Tutoring Rules for Guiding a Case Method Dialog," appearing in Sleeman & Brown, eds., Intelligent Tutoring Systems, Academic Press, Inc. (1982) pp. 201-225, and William J. Clancey, "Methodology for Building an Intelligent Tutoring System," appearing in Kintsch et al., eds., Methods and Tactics in Cognitive Science, Lawrence Erlbaum Assoc., Chapter 3 (1984).

A LISP/GEOMETRY Tutor by John Anderson is described in Anderson et al., "The Geometry Tutor," Advanced Computer Tutoring Project, Carnegie-Mellon University. The program asks a student to solve a problem, and the program matches each student input against rules for ideal and inferior student behavior. The program corrects the student when the student's behavior deviates below a minimum threshold.

SUMMARY OF THE INVENTION

The inventor has discovered that intelligent computer aided instruction systems have not been applied to a wide range of subject domains due to the relative difficulty of properly tailoring the instruction to the subject domain and the needs of the student. This has required domain-dependent tutoring knowledge that is relatively difficult to encode. Moreover, considerable dialog with the student and computer execution time and programming have been required to determine the student's needs and to provide for a variety of levels of instruction responsive to those needs.

Accordingly, the primary object of the present invention is to provide a practical domain-independent tutor shell accepting the knowledge base of a consultation system and providing instruction tailored to the subject domain and the needs of the student.

Another object of the invention is to provide a knowledge based tutor which easily accepts domain-dependent tutoring knowledge from a user.

Still another object of the invention is to provide a knowledge based tutor which transparently encodes domain-dependent tutoring knowledge without the use of rules.

Yet another object of the invention is to provide a knowledge based tutor which tailors instruction to the subject domain and the needs of the student by using a minimum of computer execution time and programming.

And still another object of the invention is to provide a knowledge based tutor that is efficient for use by an expert to evaluate the content and capabilities of a domain knowledge base.

Moreover, another object of the invention is to provide a knowledge based tutor capable of extending its own knowledge base.

Briefly, in accordance with the invention, a knowledge based tutor includes a consultation system and encodes domain-dependent tutoring knowledge as a set of conditions for interrupting the operation of the consultation system in order to evaluate a subject system. During the evaluation, the subject system is probed for its understanding of the status of the consultation system, and its understanding is compared to the actual status to obtain a measure of the subject system's knowledge and performance relative to that of the consultation system.

The subject system can be a student, in which case deficiencies in the student's knowledge and performance are corrected by providing relevant instruction guided by further probing. Alternatively, the subject system can be an expert, in which case deficiencies in the knowledge and performance of the consultation system are revealed by providing relevant information to the expert, and the deficiencies are diagnosed by further probing of the expert. In either case, the direction for the initial probing and the source of the instruction or information provided to the subject system are easily determined from the condition causing the interruption of the consultation system. Depending upon the condition, relevant domain knowledge from the consultation system is selected for probing, instruction, or diagnosis.

In order to easily accept domain-dependent tutoring knowledge from a user, there is provided an authoring system which scans and analyzes the knowledge base of the consultation system to determine a set of possible interrupt conditions. These interrupt conditions are presented to a user, such as a teacher. The user can then exercise judgment in selecting the interrupt conditions that are appropriate for the subject domain and a group of students. Further, the teacher can also run a test consultation to provide a test case suitable for the group of students, and the interrupt conditions and the test consultation can be selected so as to be most compatible. To suit the needs of a variety of students, user dialog input and interrupt conditions can be stored in a case file, and case files for a variety of groups of students or for a number of subject domains can be stored in a case library. The student then selects or is assigned an appropriate one of the cases for use as input to the knowledge based tutor.

In order to reduce the computer processing time when a test case is run, the authoring system preferably creates a file or index of tutorial knowledge which correlates the relevant domain knowledge with the interrupt conditions. Therefore, when the consultation is interrupted, the relevant domain knowledge is immediately available for probing, instruction or diagnosis. To create the file or index of tutorial knowledge, the authoring system preferably includes an analysis system that analyzes the domain knowledge base of the consultation system to determine lists of pointers pointing to relevant expressions concluded by rules, the rules concluding those expressions, the values concluded for those rules for the relevant expressions, and the factors of those rules. In this case the relevant expressions are used to indicate interrupt conditions occurring when the values of the expressions are found during the consultation, and the indexed values, rules and factors are used for probing the subject system to a depth of three levels for information pertaining to the expression causing the interrupt.

In order to reduce the amount of programming required for the knowledge based tutor, the consultation system is preferably implemented using a knowledge system shell having an extensible knowledge base language, and the tutor system is programmed as a knowledge base appended to the domain knowledge base of the consultation system. The preferred knowledge system shell is described in Hardy et al. U.S. Pat. No. 4,648,044, herein incorporated by reference.

BRIEF DESCRIPTION OF THE DRAWINGS

Other objects and advantages of the invention will become apparent upon reading the following detailed description and upon reading the following detailed description and upon reference to the drawings in which:

FIG. 1 is a block diagram of the knowledge based tutor (KBT) according to the invention;

FIG. 2 is a flow diagram showing how various kinds of knowledge are used by the KBT;

FIG. 3 is a detailed block diagram of the preferred organization of the KBT;

FIG. 4 is a flowchart of an authoring system used by the KBT to generate an evaluation procedure;

FIG. 5 is a flowchart of an analysis system used by the authoring system of FIG. 4 for indexing components of the knowledge base which relate to interrupt conditions or traps;

FIG. 6 is a flowchart of an evaluation system that implements the evaluation procedure;

FIG. 7 is a flowchart of a procedure for performing a level 2 probe concerning important values missed by a student; and

FIG. 8 is a flowchart of a procedure for a level 3 probe concerning factors missed by the student.

While the invention is susceptible to various modifications and alternative forms, a specific embodiment thereof has been shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that it is not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Turning now to the drawings, there is shown in FIG. 1 a functional block diagram of the preferred embodiment of a knowledge based tutor (KBT) generally designated 20. The KBT 20 includes a number of software modules residing in a computer 21. As will be further described below, the software modules are relatively compact so that the computer 21 can be any one of a number of small personal-type microcomputers.

In order to provide the KBT with domain knowledge, the KBT 20 includes a domain knowledge base 22 residing in the memory 23 of the computer 21. In order to reason over the domain knowledge base, the computer 21 includes a knowledge base interpreter 24. Therefore, the knowledge based turor 20 is a knowledge system capable of symbolic reasoning. The knowledge base interpreter 24 is preferably part of a knowledge system shell which has an input and output unit 26 for communicating with a subject system 27 and for reading and writing files, such as a case file 28. A preferred knowledge system shell is described in Hardy et al. U.S. Pat. No. 4,648,044, incorporated herein by reference. Such a system shell is commercially available from Teknowledge Inc., 1850 Embarcadero Road, P.O. Box 10119, Palo Alto, Calif., 94303, and is sold under the trademark "M.1".

The knowledge based tutor 20 employs a case study method of instructing the student 27 while indicating the methods of the solution to specific problems. The case study method is particularly attractive since the knowledge system shell 25 typically includes all of the required facilities for creating and maintaining a domain knowledge base 22 for providing a consultation system. An example domain knowledge base 22 is provided by the "Wine Advisor" shown in Appendix VII of Hardy et al. U.S. Pat. No. 4,648,044. For practicing the case study method, the case file 28 includes test case input 29 which, for example, is substituted for the input of the consultation user or client. The knowledge system 25 reproduces the method of solution for the test case and indicates the method of solution to the student 27. So that the student 27 does not become passive during the solution of the test case, the test consultation could alternatively be run by presenting the test case input to the student as a set of facts, and requiring the student to correctly enter the relevant facts as the facts are called for during the test consultation.

In accordance with an important aspect of the present invention, the knowledge based tutor 20 provides additional instruction to the student 27 by interrupting the test consultation when specified conditions occur. These conditions are specified in a record 30 of the case file 28.

So that the interpretation of the domain knowledge base 22 by the knowledge base interpreter 24 is interrupted whenever any one of the interrupt conditions 30 occur, the input and output unit 26 transfers the interrupt conditions 30 from the casefile 28 to cache memory 31 which is addressable by the knowledge system 25. The knowledge system 25 further includes an interrupt condition checker 32 which determines whether the interrupt conditions occur by periodically checking a state memory 33. The state memory includes a record of the status of the consultation, including, for example, indications of whether expressions have had their values determined, and the values of determined expressions.

In accordance with an important aspect of the present invention, a consultation is interrupted upon the occurence of any one of the specified conditions so that an evaluation system probes the subject system 27 about the condition having caused the interruption. Specifically, the evaluation system 34 probes the subject system 27 to obtain a response about the status of the solution of the problem by the knowledge base interpreter 24, and compares the response to the actual status of the solution of the problem. As will be further described below, relevant information about the status of the solution of the problem is obtained by accessing the state memory 33 and interpreting the domain knowledge base 22 in accordance with the condition having caused the interrupt.

Turning now to FIG. 2, there is shown a flow diagram illustrating how the knowledge based tutor 20 of FIG. 1 is supplied with domain knowledge and tutoring knowledge. A knowledge engineer 42 creates the domain knowledge base 22 by using the knowledge system shell 41. This process is known as "knowledge acquisition" and involves the extraction and formulation of knowledge derived from current sources such as experts. The knowledge engineer encodes this knowledge into a machine readable form by defining expressions which represent objects or ideas in the subject domain, and by writing rules which specify relations between these objects and ideas.

In accordance with an important aspect of the present invention, the tutorial knowledge for the knowledge based tutor is generated by an authoring system which analyzes the content of the domain knowledge base 22 to determine conditions of interest during a test consultation. As shown in FIG. 2, the teacher 44 uses the authoring system 43 in conjunction with the knowledge system shell 41 in order to create the test case input 29 by supplying case dialog input, and by selecting interrupt conditions 30. As will be further described below, the authoring system 43 scans the domain knowledge base 22 and determines a set of conditions suitable for interrupting the test consultation. These conditions of interest are shown to the teacher 44, and the teacher 44 selects a subset of these conditions by exercising his or her judgment in consideration of the test case and the needs of the student.

In accordance with another important aspect of the present invention, the authoring system 43 also analyzes the domain knowledge base 22 to create a file of tutorial knowledge. Preferably the file of tutorial knowledge 45 is organized as an index of the information in the knowledge base pertaining to each of the interrupt conditions. The file of tutorial knowledge is therefore quickly accessed to supply information pertaining to the respective condition causing the interrupt, in order to provide information about the status of the solution of the specified problem.

Now that the file of tutorial knowledge 45 in the case file 28 has been created, the student 27 may use the knowledge system shell 41 for viewing the test case. Alternatively, the student may make up his own test cases by supplying dialog input to the knowledge system shell, and this can be done interactively in the usual fashion for a consultation system. When any of the interrupt conditions 30 occur during the test consultation, the test consultation is interrupted and the evaluation system 34 is operated to prompt the student 27 for information pertaining to the condition having caused the interrupt. The relevant information is obtained by reading the file of tutorial knowledge 45 for the condition having caused the interrupt, and by reading the domain knowledge base 22 in accordance with information read from the file of tutorial knowledge. After probing the student 27 for a response, the response is compared to the knowledge in the knowledge base 22 pertaining to the interrupt condition in order to evaluate the student's knowledge and performance. As shown in FIG. 2, the result of the comparison is recorded as a record 46 of the student's knowledge and performance.

Turning now to FIG. 3, there is shown a block diagram of the preferred implementation of the various software modules in the knowledge based tutor. The knowledge system shell 25 is preferably the "M.1" (Trademark) shell sold by Teknowledge, Inc., 1850 Embarcardero Road, P.O. Box 10119, Palo Alto, Calif., 94303. To run a test consultation, the knowledge base interpreter 24 of the knowledge system shell 25 interprets a consultation system knowledge base 51 which encodes the domain knowledge 22. The domain knowledge 22 includes rules 52 which are applied by an inference engine 53 in the knowledge base interpreter 24.

In accordance with an important aspect of the present invention, the authoring system 43 and the evaluation system 34 are implemented as procedures loaded into a "combined" knowledge base 54 which is interpreted by the knowledge base interpreter 24. Therefore the authoring system 43 and the evaluation system 34 are written in the same language as the domain knowledge base 22. This has the advantage of considerably reducing the amount of programming for the authoring system 43 and the evaluation system 34. A listing of the preferred authoring system 43 is included in Appendix II, and a listing of the preferred evaluation system is included in Appendix III. These listings are written in the knowledge base language of "M.1" (Trademark), which incorporates the knowledge base language described in Hardy et al. U.S. Pat. No. 4,648,044.

The "M.1" (Trademark) language has a proposition which enables the inference engine 53 to be interrupted upon the occurrence of a specified condition. The specified condition is tested whenever the values for any expression have been sought. The interrupt condition and the procedure to be implemented upon interrupt is specified by writing a "whenfound" proposition in the knowledge base 54. "Whenfound" statement is defined at columns 53 and 54 of Hardy et al. U.S. Pat. No. 4,648,044 as follows:

whenfound (EXPRESSION=VALUE)=PROPOSITION

Whenever the inference engine 53 has finished seeking and has found all values for any expression, the knowledge base interpreter 24 searches the knowledge base for a "whenfound" proposition defined for the expression which was sought. If such a statement is found in the knowledge base 54, then the knowledge base interpreter 24 checks whether the expression has the value specified in the "whenfound" statement. If this is true, then the proposition specified in the "whenfound" statement is tested. Therefore, in order to interrupt the consultation system 51 to operate the evaluation system 34, a "whenfound" statement is written which specifies the interrupt condition as EXPRESSION=VALUE and which includes a PROPOSITION which when tested causes invocation of the evaluation system 34 for probing of the subject system.

The authoring system 43 as shown in Appendix II scans the knowledge base and determines which expressions are concluded by the domain rules 52. These expressions are stored as entries 55 in a tutorial knowledge base which is part of the combined knowledge base 54.

For scanning and parsing the rules, the authoring system uses the matching capabilities of "M.1" (Trademark), and specifically invokes the "KBENTRY" function which operates substantially as shown in Hardy et al. U.S. Pat. No. 4,648,044. Since the authoring system 43 and the evaluation system 34 are also located in the knowledge base 54 and may employ rules, a user-defined proposition in the form of "hide(EXPR)." is written for each of the expressions EXPR which are defined by the authoring system and the evaluation system and which are to be hidden from the scanning and parsing process. This scanning and parsing process is performed by a rule analyzer 57 which ignores expressions that have been defined in a "hide(EXPR)." statement.

In order to specify interrupt conditions, the user such as the teacher 44 is shown a list of the expressions 55 concluded by the domain rules 52. The teacher 44 selects a subset of these expressions to be "trapped" when the student 27 views a test consultation. These expressions to be trapped are stored as a list 58 in the tutorial knowledge base 56. Then the rule analyzer 57 scans the domain rules 52 to determine the rules concluding the trapped expressions. These rules are also stored in a list 59 in the tutorial knowledge base 56. Moreover, the rule analyzer analyzes these rules to determine factors in the premises and the values in the conclusions of the rules, and the factors and values are stored in the tutorial knowledge base 56. Therefore, the authoring system interacts with a human user such as the teacher 44 to define an evaluation policy which is encoded in the tutorial knowledge base 56.

The tutorial knowledge base is a kind of secondary knowledge base which becomes stored in the case file 28 as part of the previous case dialog input cache 61. To make up the case file 28, the teacher 44 uses the knowledge system shell 25 to interpret the consultation system 51 to run to test case. The user input during this test case is also stored in the previous case dialog input cache 61.

When the student 27 uses the knowledge system shell 25, the evaluation system 34 is first invoked. This evaluation system reads the previous case dialog input cache 61 from the case file and loads it into the pointer cache 56 in the knowledge base 54. Also, traps are set by writing into the knowledge base entries of the form:

whenfound(EXPR=ANY)=whenfoundtutor(EXPR).

The evaluation system 34 then invokes the consultation subsystem 51 so that a test consultation is run for the student 27 using previous case dialog input from the case file 28. This test consultation continues until any one of the expressions to be trapped becomes sought and values for the trapped expression are found. When this occurs, the "whenfound" statement for the trapped expression causes the evaluation system to apply teaching heuristics 62 for probing the student 27 regarding information related to the trapped expression. Specifically, the evaluation system uses the teaching heuristics 62 to generate multiple-choice questions, to supply correct answers, to probe for the connection between a correct answer and the original probe, and to probe for important factors or conclusions.

It should be noted that the authoring system and the evaluation system 34 have the ability to invoke top-level commands of the knowledge base interpreter 24. This is done, for example, to add and delete entries from the knowledge base 54, to transfer data between the case file 28 and the pointer cache 56, and to cause execution to be passed to the consultation system 51.

In order to permit the authoring system 43 and the evaluation system 34 to execute top-level commands of the knowledge base interpreter 24, there is provided a proposition in the form of "do(LIST)". When this proposition is encountered in the premise of a rule and is tested, any commands in LIST are executed by the knowledge base interpreter 24.

The authoring system 43 and the evaluation system 34 invoke a number of other "M.1" (Trademark) propositions which simplify their programming. These propositions include a "nocheck(EXPR)" metafact which inhibits checking of the specified expression at run-time to see if it contains variables. This allows the seeking and caching of expressions with variables.

The proposition "nocache(EXPR)" prevents values of a specified expression from being stored permanently in the cache. When the specified expression is evaluated, the results are temporarily cached and the proposition that depends on the result is tested. Then, before proceeding, the entry for the expression is removed from the cache. If the value of a "no cache" expression is needed later in a consultation, the inference engine again seeks its values.

A proposition in the form of "noautomaticquestion(EXPR)" prevents an automatic question from being generated for the expression even if there are no other knowledge base entries for the expression. If the expression EXPR is a variable, then it turns off the automatic question facility for all expressions.

The proposition "X==Y" tests for a strict equality without evaluating X, as it is true when X matches Y. This proposition is true when X and Y are the same atom, the same number, or the same term. X and Y may contain variables which will be bound by the match.

The proposition "stringjoin(STRINGS) =STRING" joins the strings together into one string. The proposition "termof(STRING)=TERM" converts the characters of "STRING" into a term, just as if the characters were read from the keyboard. In the process quotes are removed from the string and the syntax of the characters between the quotes is checked.

A metaproposition in the form of "member(LIST) =V" test for membership in a list and can be used to back-track or "cycle" through all the members of a list. If V is a variable, then V is bound to each of the members of LIST in turn.

A proposition in the form of "display(FILE, ITEM)" causes the named ASCII file to be opened, apends the items to the end of the file, and closes the file.

A meta-fact in the form of "command(NAME[(ARGUMENT)]) =LIST" is used to define a new command. Whenever the user types in the command name (with or without an argument), the command is executed by evaluating the propositions in the specified list.

The "kbentry" proposition can used in the form of "kbentry(LABEL: ENTRY and KEY)" in order to reason about entries in the knowledge base. The LABEL and KEY are optional. KEY is the expression under which the knowledge based entry in index.

A top-level command named "savechanges" saves all adds and edits to the knowledge base since the start of a consultation session. These changes are written in a text file which is loadable. The "savechanges" command is used, for example, to create a text file for storing the tutorial knowledge base in the case file.

The use of the above propositions and commands is further described by comments included in the program listings of the authoring system 43 in APPENDIX II and the evaluation system 34 in APPENDIX III.

Turning now now to FIG. 4 there shown a flowchart generally designated 70 for the authoring system. This flowchart will be explained in connection with the input/output listing of APPENDIX IV. As shown in the input/output listing, the authoring system is loaded into the knowledge base of the "M.1" (Trademark) knowledge system shell by typing the command "load tshell.kb". Then interpretation of the authoring system is started by typing the command "author wine" so that the authoring system generates an evaluation procedure for teaching about the knowledge base "wine".

In the first step 71 of the authoring system, the knowledge base is scanned to determine a list of expression concluded by the rules. Then, in step 72, the user is told to select traps from the list of expressions. Specifically for the "wine" knowledge base, the user is given the option of selecting one or more of eight different expressions. In step 73 the selected traps are received from the user. Next, in step 74, the knowledge base is analyzed to extract tutorial knowledge pertaining to the traps. Finally, in step 75 the tutorial knowledge and the traps are stored in the case file.

Turning now to FIG. 5, there is shown a flowchart generally designated 80 of an analysis system used by the authoring system in step 74 for extracting the tutorial knowledge pertaining to the trap expressions. In the program listing for the authoring system in APPENDIX II, this analysis system is implemented as a rule concluding the expression "initialized (X)".

In the first step 81 of the flowchart 80, for each trap, the rules in the knowledge base are found that conclude about the trap. These rules are stored in a list named "rulesfor(EXPR)". Next, in step 82, for each rule concluding about a trap, the values are found that are concluded by the rule. These values are represented by the expression "conclvals(RULE)". Next, in step 83, for each trap, the factors relating to the trap are found. The factors are the expressions in the premises of the rules concluding about the trap. Moreover, the analysis system temporarily instantiates variables in the premises of rules concluding about a trap, in order to find the factors which the variables may represent. Once the factors are found, they are represented as the values of an expression named "factorsfor(EXP)". Finally, in step 84, for each trap, the values are found that the rules conclude about the trap.

Turning now to FIG. 6, there is shown a flowchart generally designated 90 for the control procedure for the evaluation system. This flowchart should be viewed in connection with the input-output listing of APPENDIX V. As shown in the input-output listing, the evaluation system is loaded into the knowledge base of the knowledge system shell by typing the command "load kbtutor.kb".

In the first step 91 of the flowchart 90, the student is told to select a case, and in step 93 the student's selection is received. In the input-output listing of the APPENDIX V, for example, the student selects the case "wine" by typing the command "teach wine". Then, in step 93, the selected case file of tutorial knowledge and traps are loaded into the knowledge base. Next, in step 94, a consultation is run using the selected case. In the input-output listing of APPENDIX V, the selected case is run by typing the command "restart" which results in an interactive consultation between the student and the knowledge system. During this conseltation, the student indicates that the main component of the meal includes meat, the meal does not have veal in it, the meal has a sauce on it, and sauce for the meal is tomato.

A consultation interrupt occurs when the inference engine finds the values of the expression "best-color". In step 95 this expression is matched with a "whenfound" statement including the expression "best-color". Therefore, in step 96, a "level one" probe is initiated pertaining to the "best-color" expression.

In step 97, the student is asked for the value of the trap expression. The student is asked, for example, What do you recommend for the best-color?"Then, in step 98, the student's value is received. In step 99, the actual value concluded by the knowledge system is determined, along with the rules that succeeded in concluding the actual value. Next, in step 100, the evaluation system determines whether the student's value is correct. In step 101, the evaluation system indicates whether the student's value is correct and may identify the rules which succeeded.

As shown in the input-output listing of APPENDIX V, the student correctly recommend that the best-color was red, and therefore the evaluation system responded, " Good, the expert concluded that the best-color is red."

Next, in step 102, the evaluation system determines whether any high confidence factor values were missed by the student. If not, then as tested in step 103, execution returns. Otherwise, execution continues in step 104 by performing a "level 2" probe for each high confidence factor value missed by the student.

Turning now to FIG. 7, there is shown a flowchart generally designated 110 of a level 2 probe for a missing factor. In the first step 111, the student is asked for the factors which support the missing value. In the input-output listing of APPENDIX V, the level 2 probe is illustrated by a consultation interrupt occuring when the values for the expression "best-body" are found. In the level 1 probe, the evaluation system asks, "What do you recommend for the best-body?" The student responds incorrectly with the value of "light". The evaluation system replies, "No, the expert didn't conclude that the best-body is light. You should also have concluded that the best-body is medium, full."

In step 112, the evaluation system receives the student's justification for the missed value. In step 113, the student's justification is compared with the actual factors used by the rules to conclude the high confidence factor value that was missed. Then in step 114, the evaluation system indicates to the student whether his value was correct and identifies the rules mentioning any missed factors. In step 115, execution returns if any factors were missed. Otherwise, in step 116, a level 3 probe is performed for each missing factor.

Turning now to FIG. 8, there shown a flowchart generally designated 120 of a level 3 probe. This flowchart should be viewed in connection with the input/output listing in APPENDIX VI. In the first step 121, the student is asked for the value of the missed factor. In the input/output listing of APPENDIX VI, for example, the student incorrectly recommends that the best-color is white, and omits the factor main-component after being told that his recommendation was wrong and after being asked to choose which factors support the correct recommendation that best-color is red. The student is therefore told that rule 9 also mentions main-component. Since the student omits an important factor that supports the correct conclusion, a level three probe occurs. The evaluation system probes the student for the value of the missed factor main-component by asking, "What main-component is consistent with red?"

Next, in step 122, the evaluation system receives the student's value for the missed factor. In step 123, the evaluation system determines the actual value used for the factor by the knowledge system, and also determines a rule which mentions the factor with this value. Finally, in step 124, the evaluation system indicates whether the student was correct and identifies the rules mentioning the factor with the correct value.

In the input/output listing of APPENDIX VI, for example, the student gives an incorrect value of "fish" for the factor "main-component". The evaluation system therefore tells the student that he is incorrect and says that rule 9 mentions meat and poultry, which are the correct values for "main-component". This completes the description of the evaluation system. Further features and advantages of the evaluation system and the authoring system are illustrated by the input/output listings of APPENDICIES IV to VI and are described by the comments in APPENDICIES II to VI.

In view of the above, there has been described a practical domain-independent tutor shell accepting the knowledge base of a consultation system and providing instruction tailored to the subject domain and the needs of the student. For easily accepting domain-dependent tutoring knowledge from a user, the domain knowledge base is analyzed for possible interrupt conditions or traps which may occur during a test consultation. From these possible traps, the user selects a subset which transparently encodes domain-dependent tutoring knowledge without the use of rules. The instruction is therefore easily tailored to the subject domain and the needs of the student by appropriately selecting the trap expressions and the test cases. The trap expressions and the test cases are, for example, stored in a case library, and the cases could be ranked, for example, in order of increasing difficulty and student experience level. By writing the knowledge-based tutor in an extensible knowledge base language, the rule analysis, consultation interrupts, and evaluation can be provided with a minimum of programming in addition to that provided by the knowledge system shell for the consultation system. Moreover, the computer execution time during a consultation interrupt is substantially decreased by compiling and indexing portions of the domain knowledge base which relate to the interrupt conditions.

APPENDIX I

Glossary

artificial intelligence: A subfield of computer science concerned with the concepts and methods of symbolic inference and the symbolic representation for the knowledge to be used in making inferences and solving problems using a computer.

backtracking: A search procedure that makes guesses at various points during problem solving and returns to a previous point to make another choice when a guess leads to an unacceptable result.

backward-chaining: A reasoning strategy produced by the combination of rule-based representation, modus ponens inference, and goal-directed control. In this strategy, a chain of inferences is constructed starting with a rule whose conclusion would provide a solution to the problem. Then the system works backward to establish the premise of the rule. Attempts to establish the premise of any rule lead backward to the conclusions of other rules. In an exhaustive backward-chaining system, all possible rules are examined to arrive at a result.

bind, binding, bound: A variable is bound when it is assigned a value. A variable's binding is its attachment to a value. In some systems, variables may be bound, unbound, and then bound again through the process of backtracking.

cache: In a computer system, storage which is accessed quickly. Cache storage is managed so that most-often-used entries are readily available. In M.1 the cache is the repository of all conclusions made in a consultation.

certainty factor (CF): A number representing the confidence placed by a user or knowledge system in the validity of a proposition, hypothesis or rule. Ordinarily the number is not interpreted as a probability but rather as a subjective index of the truth of a proposition. Confidence, confidence factor, cf, CF, certainty, and certainty factor are all terms used interchangeably. In "M.1" (Trademark), certainty factors range from 0 to 100 (indicating no certainty to absolute certainty).

computer aided instruction (CAI): The use of interactive computer programs for instigating and controlling learning, preferably by presenting lessons that are optimized for each student.

consultation: A question-and-answer session with a knowledge system.

consultation system: A knowledge system which advises a user in a way which parallels the way a human consultant advises a client. In consultation mode, the system works to satisfy a goal. It searches the knowledge base for rules that lead to the goal conclusion and it invokes these rules. While in this mode, the system may ask questions of the user.

expert: A human who can solve problems or perform actions requiring unusual or uncommon skill. The expert's skills may evolve slowly, and usually require extensive knowledge and lengthy experience. See, also, "expertise."

expert knowledge: See "expertise."

expertise: The set of capabilities that underlies the high performance of human experts, including extensive domain knowledge, heuristic rules that simplify and improve approaches to problem-solving, metaknowledge, and compiled forms of behavior that afford great economy in skilled performance. Expert knowledge is rare, seldom explicit or measurable, and difficult to communicate or acquire. Gained through experience, long periods of training, apprenticeship and observation, it may be organized in subtle and idiosyncratic ways.

expert system: A knowledge system that performs at or near the level of human experts. The system achieves high levels for performance in task areas that, for human beings, require years of special eduction and training.

explanation: Motivating, justifying, or rationalizing an activity by information about goals sought or heuristic rules applied during the course of the activity.

fact: Assertion, proposition, or belief. See "proposition."

goal: The result or achievement toward which effort is directed. In a knowledge system, a goal is an expression for which a value is being sought.

goal-directed control/inference/reasoning: A control strategy often used for consultation systems. Candidate solutions to a problem are considered and evidence is gathered to determine whether each is acceptable. See, also, "backward-chaining."

heuristic: A rule of thumb, strategy, trick, simplification, or any other kind of device which drastically limits search for solutions in large problem spaces. Heuristics do not guarantee optimal solutions; in fact, they do not guarantee any solution at all. But a heuristic offers solutions which are good enough most of the time.

ICAI: See "intelligent computer-aided instruction:

if-then rule: A rule that takes the form: if [premise]then [conclusion]. A certainty factor may be associated with the rule itself. See also "rule."

inference: The process of deriving new propositions from known ones. Examples of inference are modus ponens and inheritance.

inference engine: That portion of a knowledge system which reasons over the knowledge base to arrive at conclusions. The inference engine explains how and why it arrives at a conclusion or asks for information. It also manages the inheritance and the propagation of certainty factors.

inference tracer: A trace facility provided by M.1 for the knowledge engineer. The tracer displays facts and rules as they are invoked. It also displays values of logical variables.

inheritance: A type of inference mechanism common in frame-based representation schemes in which new facts are inferred from other facts within a hierarchy of elements.

intelligent computer-aided instruction: Computer-aided instruction (CAI) using a knowledge system incorporating problem solving expertise, a student model, and tutoring strategies. The problem solving expertise is the knowledge that the system tries to impart to the student. The student model is used to indicate what the student does and does not know. The tutoring strategies specify how the system presents material to the student.

invoke: The process of testing a rule. When the rule is tested, the inference engine seeks to find whether the rule is true in a particular instance. Invocation includes testing of each of the premises in the rule plus asserting any conclusions drawn by that rule.

knowledge: Propositions and heuristic rules. Those kinds of data that can improve the efficiency or effectiveness of a problem solver. Knowledge can be distinguished in many dimensions such as: symbolic vs. numeric, factual vs. heuristic, imperative vs. declarative, deep vs. shallow.

knowledge acquisition: The extraction and formulation of knowledge derived from current sources, especially from experts. The activity of transferring or transforming the knowledge and skills from a human expert or other knowledge source into a form usable by a knowledge system. Knowledge acquisition often involves chunking or parsing an expert's knowledge into a collection of if-then rules.

knowledge base: The portion of a knowledge system that contains propositions and heuristics about the domain.

knowledge base entry: A knowledge base entry is a single statement in the knowledge base. This statement may be a rule, a proposition, or other forms.

knowledge-based interpreter: That portion of a knowledge system capable for applying knowledge in the knowledge base to solve problems. The knowledge base interpreter typically includes an inference engine for reasoning over the knowledge base to arrive at conclusions, and also responds to propositions or commands in the knowledge base which modify the operation of the inference engine.

knowledge-based system: See "knowledge system."

knowledge engineer: A person who builds knowledge systems. A knowledge engineer is an expert at applying artificial intelligence methodoligies to create computer programs that solve complex problems. During this activity the knowledge engineer transfers expertise from knowledge sources into knowledge systems.

knowledge engineering: The process of formalizing symbolic knowledge with the intent of later applying it to solve hard problems automatically. The art or activity of designing and building knowledge systems.

knowledge engineering tools: Programming systems that simplify the work of building knowledge systems. The software provides (in its design) answers to the fundamental questions about what kind of inference engine, what kind of knowledge base, and what kind of control to utilize in building a knowledge system.

knowledge system: An intelligent computer system that uses knowledge and inference procedures to solve difficult poblems. The knowledge system includes a knowledge base encoding knowledge about a subject domain, and a knowledge base interpreter capable of applying the knowledge in the knowledge base to solve specified problems pertaining to the subject domain.

meta: A prefix which when attached to a term indicates that the term is used reflexively. In computer science, this prefix implies recursion. A meta-rule, for example, is a rule which guides the selection and execution of rules.

modus ponens: An inference mechanism in which a fact matching the premise of a rule is used to assert the conclusion of the rule.

PROLOG: A programming language used to create knowledge systems and knowledge engineering tools. The name comes from "programming in logic."

proposition: Fact, belief, or assertion. A proposition is a statement that can be proved either true or not true. The premises and conclusions of rules are propositions. Propositions not only appear in rules, but also stand alone as knowledge base entries.

rule: A pair, composed of an antecedent condition (known as the premise) and a consequent proposition (known as the conclusion), which can support deductive processes such as backward-chaining and forward-chaining. Most rules are of the form: "if [premise]then [conclusion]." The premises and conclusions are made up of propositions. A rule-based system is a system employing if-then rules in its representation of knowledge.

symbolic programming: Manipulating symbols that represent objects and relationships.