Knowledge Based Processor for Application Programs Using Conventional Data Processing Capabilities

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.

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 becoming useful for problems that require diagnosis, recommendation, selection or classification. Such tasks in the past have been performed by human experts. It is becoming known that 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, often even 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 the 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 ideas 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. 525 University Avenue, Palo Alto, Calif. 94301) are patterned after a tool called EMYCIN described in The Emycin Manual by Van Melle at al., Stanford University Report No. STAN-CS-81-885, Stanford Calif. 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 primary 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 client about the content of the knowledge base. To aid the system designer in producing a knowledge base for a specific domain, EMYCIN provides a terse and stylized language for writing rules; extensive checks to catch common user errors, such as misspellings; and methods for handling all necessary indexing chores.

In addition to production rules, the knowledge base for an EMYCIN system includes a hierarchical structure called a "context tree". The elemental representation of an object or idea is defined as a context-parameter-value triple. The context refers generally to an instance of a particular context type, the parameter refers to an attribute of the context instance, and the value refers to the particular value of the parameter for the particular context instance. The context tree is defined by parent and offspring declarations for the context types.

A consultation is started by instantiating a root context and the branches from this root context define major steps in the consultation during which the offspring contexts of the root node are instantiated. Thus, the context definitions are used to structure the data or evidence required to advise a user about the root context. Besides consultation control, the context tree may be used to organize the distinguished components of some object, and to represent distinguished events or situations that happen to an object.

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 the context definitions which define the structure of the domain. As described in Erman et al., U.S. patent application Ser. No. 618,038 filed June 7, 1984, this control knowledge should be made explicit by encoding it in an applicative and 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 hierachies, 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. Ser. No. 618,038 has been manufactured and sold by Teknowledge, Inc., 525 University Avenue, Palo Alto, Calif. 94301, under the trademane "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 U.S. patent application Ser. No. 617,791 filed June 6, 1984. 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 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 Ser. No. 617,791 has been manufactured and sold by Teknowledge, Inc., 525 University Avenue, Palo Alto, Calif. 94301, under the trademark "M.1".

Although knowledge system tools are available for inexperienced programmers as well as experienced knowledge engineers, the inventors of the present invention have recognized that a large class of potential users of knowledge systems have been inhibited by a shortage of tools adapted to their particular abilities and resources. Specifically, there are many highly skilled computer programmers fluent in high-level conventional computer languages such as BASIC, FORTRAN, and "C", but who are not familiar with languages such as LISP or PROLOG which are commonly used by experts working in the field of knowledge systems. Most knowledge engineering tools are based on LISP or PROLOG, and an understanding of the underlying language is required for realizing the full capabilities of a knowledge engineering tool.

LISP and PROLOG are to a great extent incompatible with the above-mentioned conventional high-level computer languages. The above-mentioned conventional computer languages are general purpose languages having readily available support facilities such as utility libraries, optimizing compliers, and user interfaces which may be operated on a wide variety of computer models. By contrast, LISP and PROLOG are not widely used as general purpose languages and have limited support facilities, although they are especially suited for symbol manipulation and symbolic reasoning. Even though the same computer may have facilities for compiling and loading LISP and PROLOG programs as well as a conventional language program, it is difficult to use both languages simultaneously to perform a common task due to the incompatability of the basic data structures for each language and their procedures for program interruption and execution transfer, for example, by subroutine calls. Therefore a LISP or PROLOG program generally cannot use the support facilities available for the conventional computer programming languages, and conversely conventional computer language programs cannot use the limited support facilities available for LISP and PROLOG. As a consequence, presently available knowledge engineering tools cannot exploit the readily available support facilities for the general purpose languages.

Accordingly, the primary object of the present invention is to provide a knowledge engineering tool that is compatible with the conventional computer programming languages and their support facilities such as utility libraries, optimizing compliers and user interfaces.

Another object of the invention is to increase the performance of knowledge systems by permitting them to use the support facilities of conventional computer programming languages.

Yet another object of the invention is to permit a computer programmer to use a conventional computer programming language to specify most of the control knowlege for a knowledge system.

Still another object of the invention is to permit a computer programmer to use a conventional computer programming language to modify the basic operation of the knowledge system and to extend or enhance the capabilities of the knowledge system.

Moreover, another object of the invention is to permit a conventional computer program to easily perform symbolic reasoning tasks.

Briefly, in accordance with primary aspects of the present invention, a knowledge base processor is callable by an application program to build and maintain a knowledge base, and to govern the execution or interpretation of the knowledge base to find the values of selected objects or expressions defined in the knowledge base. The application program is written in a conventional computer language which specifies control by the ordering of program steps. The application program provides a user interface for input/output and provides top level control for calling the knowledge base processor to find values for goal expressions. Typically the application program provides initial values for objects, initiates and directs the search for goal expressions, defines questions and prompts a user for relevant information, and checks for legal values and assigns default values. During its search for the values of goal expressions, the knowledge base processor calls the application program to determine values of expressions which are not concluded by the knowledge base, and to signal important events during the execution of the knowledge base. In response to these events, the application program may interrupt or modify the execution of the knowledge base. Preferably the knowledge base processor and application program each include a library of subroutines which are linked-loaded to provide a complete knowledge system for a specific application or task. Therefore, the knowledge base processor provides the essential functions for symbolic reasoning, and establishes a framework for building the knowledge system which permits application program developers to exploit the best available conventional data processing capabilities. The application programmer is free to exercise his or her knowledge and skill regarding the use of conventional programming languages and their support facilities such as utility libraries, optimizing compilers and user interfaces.

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

FIG. 1 is a block diagram of the preferred embodiment of the invention;

FIG. 2 is a diagram showing the format for the basic data structure used in the preferred embodiment of the invention;

FIG. 3 is a table showing the meanings of the permissible value types for the basic data structure of FIG. 2;

FIG. 4 is a diagram showing the format for an expression;

FIG. 5 is a diagram showing how an expression is represented as an array of the basic data structures shown in FIG. 2;

FIG. 6 is a diagram showing how more complex expressions are represented as linked arrays of the basic data structures;

FIG. 7 shows a determination state table used for indicating whether the inference engine is seeking or has sought a value or values for an expression;

FIG. 8 shows an expression characteristic table for indicating whether an expression is multi-valued and whether its value or values should be noted in cache when they are determined;

FIG. 9 is a diagram showing the format of a variable binding stack for recording and indicating the current bindings of variables, the trail of variable binding modifications that must be undone for backtracking, and the groups of variables which are local to the same environment;

FIG. 10 is a diagram showing the permissible formats for a proposition;

FIG. 11 is a diagram showing the format for a fact;

FIG. 12 is a diagram showing the format for a rule;

FIG. 13 is a diagram showing the format of an invocation stack for indicating each rule, fact or expression being evaluated by the inference engine;

FIG. 14 is a diagram showing various meta-facts which are either internally defined or are typically defined by the application program;

FIG. 15 is a diagram showing the format for the knowledge base;

FIG. 16 is a table showing various meanings of permissible values for the knowledge base entry type;

FIG. 17 is a diagram showing the format for data stored in the cache;

FIG. 18 is a flowchart of a subroutine named "find" for finding the value or values of an expression and storing them in the cache;

FIGS. 19A and 19B comprise a flowchart of a subroutine named "evalExpr" for evaluating an expression after the expression has been converted to a parsed format by the "find" subroutine of FIG. 18;

FIG. 20 is a flowchart of a subroutine named "evalRule" for invoking a rule; and

FIG. 21 is a flowchart of a subroutine named "evalProp" for evaluating a proposition such as the premise of a rule and for asserting a conclusion or performing another action in the event that the proposition is found to be true.

The present specification includes a number of appendices, including a glossary of terms, a sample knowledge base, an application program listing for a "Stock Market Advisor" knowlege system, a consulatation listing showing the typical operation of the Stock Market Adviser knowledge system, and flow sheets and a program listing of the preferred embodiment of the knowledge base processor according to the present invention.

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 scope of the invention as defined as by the appended claims.

Turning now to the drawings, there is shown in FIG. 1 a functional block diagram of the preferred embodiment of a knowledge system according to the present invention. The knowledge system, generally designated 30, comprises a digital computer 31 having a knowledge base 32 stored in its memory. For controlling the internal operations of the digital computer 31 to govern the manner in which the knowledge base 32 is executed or interpreted, the memory of the digital computer also includes a control procedure for a knowledge base processor 33 and an application program 34. The knowledge base processor 33 includes inference engine subroutines 35 which reason over the knowledge base 32 to arrive at conclusions. To communicate with a user 36, the application program 34 includes a user interface 37 providing input and output. The system 30, therefore, is recognized as a knowledge system since it comprises a knowledge base 32, an inference engine 35, and a user interface 37, which are the primary components of any knowledge system.

So that the knowledge base 32 is transparent to the knowledge engineer and is easily modified or expanded, the knowledge base includes rules 38 and facts or propositions 39 to encode domain knowledge. Each rule is a pair, composed of an antecedent (known as the premise) and a consequent (known as the conclusion), that can support the deductive process of backward chaining performed by the inference engine 35. The rules 38 are in the form of "if [premise] then [conclusion]." The premise and conclusion are made up of "propositions", or statements that can be proved true or false. Similarly, each fact 39 is a proposition.

To aid the inference engine 35 in the interpretation and execution of the rules 38 and facts 39, the knowledge base 32 also includes meta-facts 40, which are statements about the knowledge base or a consultation to be conducted with the user 36, as opposed to facts about the subject domain. One kind of meta-fact is known as a "presupposition." A presupposition is a condition that must be true in order for some other statement even to make sense. For example, it must have been raining for the question "has it stopped raining?" to make sense. A meta-fact in the form of "presupposition(expression)=condition" can be used to prevent the inference engine 35 from seeking the value of the specified expression unless the specified condition is true.

So that the interpretation of the knowledge base 32 is easily understood by a computer programmer familiar with traditional programming languages, the inference engine 35 finds the value of a specified expression by sequentially searching the knowledge base 32 for rules 38, facts 39, or meta-facts 40 which conclude values for the specified expression. The user, however, must keep in mind that when a rule or fact is encountered having other expressions for which values have not yet been sought, searching will be restarted at the top of the knowledge base in order to determine the values of these other expressions. When a rule or fact concludes a value for an expression, the value is noted in a portion of memory called "cache" 41. The searching of the knowledge base 32 for values of a given expression does not necessarily stop at this point. If the expression has the property of being "multivalued", the entire knowledge base is searched to determine all possible values for the expression. By default, each expression is assumed to be single valued, unless the expression is explicity declared as multivalued by a meta-fact 40 in the form of "multivalued(expression)" .

Even though an expression is assumed to be single valued, searching though the knowledge base 32 will not stop unless a value for the expression has been determined with complete certainty. This process is known as the occurrence of a "single valued cut-off".

In order to accumulate evidence about the value or values for an expression, the inference engine 35 can draw conclusions from inexact or imprecise data. For this purpose, each value noted in the cache 41, each rule 38, and each fact 39 has an associated "certainty factor" or number representing the confidence placed by the inference engine 35 upon the validity of the corresponding value, rule, or fact. The certainty factor is not interpreted as a probability, but rather as a subjective index of the amount of evidence that has been accumulated confirming or disconfirming the proposition. The certainty factors range from -100 to +100, indicating that a rule, proposition, or value is definitely ruled out or is definitely certain respectively. The certainty factors, however, are combined accordingly to the laws of probability for independent events. Therefore, if a value for an expression in cache initially has a certainty factor of CF, and a rule having a certainty factor of CF1 confirms the same value for the expression, then the certainty factor in the cache is changed or updated to a certainty factor of CF2 calculated according to:

provided that CF1 and CF2 are both positive.

Negative certainty factors are combined in a similar fashion, as shown in the subroutine "cfCombine" included in the STORAGE.C section of the program listing for the knowledge base processor in Appendix VI.

In accordance with the primary aspect of the present invention, the knowledge base processor 33 is callable by the application program 34 to build and maintain the knowledge base 32 and to govern the execution or interpretation of the knowledge base to find the values of selected objects or expressions in the knowledge base. The application program is written in a conventional high-level computer language which specifies control by the ordering of program steps. In addition to the user interface 37, the application program provides top level control 43 for calling the knowledge base processor to find the values for goal expressions. A subroutine named "find" 44 is specifically provided for this purpose. The knowledge base processor 33 includes a number of other "application interface" subroutines 45 that are easily called by the application program to perform selected ones of predefined functions. Although the entire knowledge base processor 33 preferably is made of user callable functions, the application interface subroutines 45 have few if any "side effects" and do not require the application programmer to have extensive knowledge of the data structures used by the knowledge base processor 33.

The application interface subroutines 45 and inference engine subroutines 35 themselves are made more transparent by using subroutine calls to separate "data structure access" subroutines 46 included in the knowledge base processor 33 for handling the details of accessing the knowledge base 32, cache 41, files 56, and other data structures used by the application interface subroutines or inference engine subroutines.

A number of application interface subroutines 45 provide easy access to the knowledge base 32. Before accessing the knowledge base, the application programmer first calls an application subroutine named "openKB" to open the knowledge base for use. Then an application interface subroutine named "loadKB" is called to load a knowledge base file into the knowledge base data structure. After loading the knowledge base file, a selected knowledge base entry can be obtained for inspection by calling an application interface subroutine named "getKB". In order to edit this knowledge base entry, the knowledge base entry is first removed from the knowledge base data structure 32 by calling a subroutine "resetKB". Then the edited version of the knowledge base entry is added or inserted in the knowledge base by calling an application interface subroutine named "addKB". When the application programmer is finished editing the knowledge base, the edited knowledge base can be saved to a file by calling an application interface subroutine named "saveKb". Then an application interface subroutine named "closeKB" is called to close the knowledge base from use.

In a similar fashion, a number of application interface subroutines 45 are provided for manipulating the contents of the cache 41. Typically this is done to suspend a consultation between the system and the user 36 for a prolonged period of time until the user wants to continue. For diagnostic purposes and for special applications it is desirable to inspect the contents of cache before running or continuing a consultation.

At the start of a consultation, an application interface subroutine named "openCache" is called to open cache for use. The entire cache can be erased by calling an application interface subroutine named "resetCache". This subroutine can also be called to remove a specified entry from cache. To resume a consultation, previously stored contents of cache are loaded from a file by calling an application interface subroutine named "loadCache". Selected entries from cache can be fetched by calling an application interface subroutine named "getCache". An entry can be added to cache by calling an application subroutine named "addCache". The entire contents of cache can be saved in a file by calling an application interface subroutine named "saveCache". The cache is closed from use by calling an application subroutine named "closeCache".

In accordance with another aspect of the present invention, the knowledge base processor 33 permits the application programmer to change the very nature of the language by which knowledge is encoded in the knowledge base 32. This language is defined by the contents of certain memory tables 47 in the memory of the digital computer 31. The inference engine subroutines 35, for example, recognize certain meta-facts 40 in the knowledge base 32 as application defined meta-facts 48. In order to recognize these application defined meta-facts 48, the inference engine subroutines 35 match the entries of the knowledge base 32 to the entries in a table of legally recognized application defined meta-facts 49. In order to add a specified application defined meta-fact to the table 49 of legally recognized meta-facts, the application programmer calls an application interface subroutine 45 named "addMetaFact".

In a similar fashion, the memory tables 47 include a table 50 for storing legal definitions of application defined meta-propositions. During evaluation of propositions, for example during the evaluation of a premise of a rule being invoked, the inference engine subroutines 35 match the proposition or portions thereof to the entries in the table 50 of application defined meta-propositions. In order to add an application defined meta-proposition to the table 50, the application programmer calls an application interface subroutine 45 named "addMetaProp".

Application defined meta-propositions are usually in the form of functions. To permit the application programmer to even further modify the language of the knowledge base, the application programmer is permitted to define certain elementary symbols or "atoms" as operators. The inference engine subroutines 35 distinguish an operator from an elementary expression by matching the expression to the entries stored in an operator table 51, which may include the definitions of application defined operators 52. The application programmer may call an application subroutine called "addOp" to add a specified operator to the application-defined operator definitions 52 in the operator table 51.

When the inference engine subroutines 35 encounter an application defined meta-fact or an application defined meta-proposition, the application programmer must have specified how the meta-fact or meta-proposition is to be evaluated. In accordance with an important aspect of the present invention, the application programmer does this by writing an "evalMetaFact" subroutine or an "evalMetaProp" subroutine, which are examples of application supplied subroutines 53 that are from time-to-time called by the knowledge base processor 33.

The application supplied subroutines 53 include a subroutine named "determine" used for determining the value of an expression after the knowledge base 32 is searched without finding a value by applying the rules 38 or facts 39. The application supplied subroutines 53 also include a subroutine named "error" for indicating that an error has occurred during operation of the knowledge base processor.

The previous examples of application supplied subroutines 53 enable the application programmer to specify actions that should be taken when the knowledge base processor 33 requests assistance in carrying out certain operations. The application supplied subroutines 53 also include subroutines for enabling the application programmer to interrupt or modify the execution of the knowledge base. For this purpose an application supplied subroutine named "event" is called to signal the occurrence of certain important events during the operation of the knowledge base processor 33. These important events include when the inference engine subroutines 35 are beginning to seek a value for an expression, when they have finished seeking an expression, when they have found a value of an expression, when they are noting a value of an expression in the cache, when they are beginning to invoke a knowledge base entry, when they have finished invoking a knowledge base entry, and when they have succeeded in producing a conclusion from the knowledge base entry under evaluation. The knowledge base processor 33 signals the respective action by passing a respective integer value from 1 to 7. To modify the execution by the knowledge base processor 33, the application programmer may write an "event" subroutine which modifies specified values in any of the data structures, or may even modify the very basic dynamic data structures used during subroutine calling to perform an unconventional return to a selected point in the procedure conducted by the knowledge base processor.

One very simple method of altering the execution by the inference engine subroutines 35 is to abort the finding of a value for a specified expression. For this purpose the application program may call an application interface subroutine 54 named "restoreAfterAbort".

In the preferred embodiment as shown in FIG. 1, the knowledge base processor 33 is embodied in the same digital computer 31 which executes the application program 34 and is also preferably written in the same high-level programming language as the application program 34. Therefore, both the application program 34 and knowledge base processor 33 may call the system resident libraries 55 to perform elementary operations. In order to give the application programmer additional flexibility in designing the user interface 37, the preferred form of the knowledge base processor 33, however, does not use the character input and output routines in the system resident libraries 55. Instead, it uses application supplied subroutines 53 named "readch" and "writebuf" to either read a character or write a string buffer, respectively.

A special event signaled by the knowledge base processor 33 to the application program 34 is the loading of an application defined meta-fact 48 into the knowledge base 32. For this purpose the knowledge base processor 33 calls an application supplied subroutine 53 named "metaFactLoaded" each time that an application defined meta-fact 40 is loaded into the knowledge base 32. This gives the application programmer the option of inserting into the knowledge base his or her own "program code" which can be executed in subroutine fashion during the loading of the knowledge base 32 instead of during the execution of the knowledge base when finding the values for specified expressions.

Another way of using application defined subroutines 53 is in the design of a tracing facility. A trace of the important events encountered by the inference engine subroutines 35 can be provided by writing an "event" subroutine which records an ordered list of the event codes along with the expression being sought or the knowledge base entry being invoked. Even more detailed tracing of the operation of the knowledge based processor 33 may use an application supplied subroutine named "demon" which signals every call or return of certain ones of the subroutines of the knowledge base processor 33. The particular subroutine is indicated by a certain function value, as shown below in Table I:

The same integer identification codes used by the "demon" subroutine are also used by the "error" subroutine to indicate the particular subroutine in which an error was detected. The "error" subroutine also provides an error identification code. The possible error identification codes are summarized below in TABLE II:

A complete working example of the preferred embodiment of the knowledge base processor 33 is given in Appendix VI to the present specification. Included in this program listing are comments defining the parameters for the subroutines in the knowledge base processor 33 and also the application supplied subroutines 53, which are shown as "dummy" functions which do not perform any action.

The preferred embodiment of the knowledge base processor as shown in Appendix VI is written in the "C" programming language. The C programming language is preferred because it permits recursive function calls, it is available for a wide variety of computers, and it has been used to implement a wide variety of applications such as compilers, operating systems, data base systems, real-time systems and document preparation systems. For further information on the C programming language, the reader may consult Kernigham & Ritchie, The C Programming Language, Prentice-Hall (1978), which includes The C Reference Manual. Although the program listing in Appendix VI should be clear to an experienced C programmer, for less experience programmers its basic operation will become clear upon consideration of the various data structures used by the program, the basic control procedure for the inference engine subroutines, and upon inspection of the sample knowledge base, appliction program and consultation listing included in Appendices II, III, and IV, respectively.

Turning now to FIG. 2, there is shown a diagram generally designated 60 of the basic data structure which is called a "pattern". The pattern consists of a parameter designating the "value type" of the pattern, and a particular one of four different parameters, including either a parameter designating the length of the pattern, an index to a name for the pattern in a symbol table, a long integer number, or a single precision floating value. Therefore, the pattern can represent any expression or value, regardless of whether the expression or value is numeric or symbolic.

Shown in FIG. 3 is a table generally designated 65 showing the meanings of various integral values for the "value type" parameter. The description in the table 65 indicates that a pattern represents either an integer number, a floating point number, an atom symbol, a variable symbol, a pointer to another pattern, or the length of a pattern array.

One of the tasks of the knowledge base processor is to translate or parse the knowledge base language from an English-based format to an internal representation including a series of "patterns". In terms of the English-based language used for writing the knowledge base, an "expression" is a symbol capable of being set to a definite value or values during operation of the inference engine. The knowledge base processor recognizes two formats for an expression, as illustrated in the diagram 70 of FIG. 4. These two formats are an "atom" and a function including an atom functor and one or more arguments such as ARG1 and ARG2. The knowledge base processor recognizes any phrase of characters starting with other than a capital letter as an atom, unless that phrase is a reserved meta-proposition or is designated a label or comment. It should be noted that according to this definition for an "expression", there are a number of statements that may include expressions and meta-propositions which are capable of representing a value but which are not expressions. Such general statements, however, can be evaluated by calling an inference engine subroutine named "evalProp". The statement "atom1 and atom2", for example, is evaluated by finding the values for the two atomic expressions, and then applying the logical "and" meta-proposition.

The difference between expressions and general statements is significant because when the knowledge base processor is told to find the value of a specified expression, for example by calling the "find" subroutine, the inference engine will search the cache and the knowledge base for the expression. A general statement including meta-propositions cannot be evaluated by searching cache and the knowledge base, since meta-propositions are not recognized and evaluated during the process of matching the statement to the knowledge base. If the expression is in the form of a function, the knowledge base is searched for an occurrence of the atom functor, and upon finding a match, the inference engine attempts to match the arguments to respective argument parameters associated with the atom functor in the knowledge base. Since the argument parameters in the knowledge base may include variables for representing patterns, it should be apparent that the arguments ARG1, ARG2 are general statements.

Turning now to FIG. 5, there is shown a diagram generally designated 75 showing how an expression in the form of a function "accnt(tbill,rate)" is internally represented as an array of patterns. The array includes a symbol for the functor atom "accnt", and a pattern for each argument, including the arguments "tbill" and "rate". The array of patterns 76 also includes a prefix pattern 77 which is an integer number indicating the number of following patterns in the array 76.

Turning to FIG. 6 there is shown the internal representation of an expression in the form of a function "accnt(tbill,rate(10.5))" which has arguments that are themselves functions. Each argument that is a function becomes replaced with a pointer pattern 80 indicated by the symbol "*". The pointer points to another pattern array for the function which is the argument, or in the specific example the argument "rate(10.5)".

Associated with each expression defined in the knowledge base 32 is an entry in a determination state table as shown in FIG. 7 and an expression characteristic table as shown in FIG. 8. The determination state table generally designated 85 indicates whether a value or values for each expression have been sought by the inference engine, and whether the inference engine is currently seeking a value for the expression. Therefore, the determination state table stores information about the dynamic state of the knowledge system. On the other hand, the expression characteristic table generally designated 90 in FIG. 8 stores relatively static information about each expression in the knowledge base. Specifically, the expression characteristic table indicates whether each expression is multivalued instead of being single valued, and indicates whether fthe expression has the atypical "nocache" characteristic. If an expression has the "nocache" characteristic, then the knowledge base can be searched to find the expression, but any values that happen to be found will not be stored in cache. Therefore, expressions having the characteristic "nochache" are primarily used for control purposes, for example, to trigger the searching of values for a group of related expressions. Expressions having the "nocache" characteristic may also be viewed as logical flags which are cleared at the start of a consultation and become set when the expression is sought, in which case the logical value of the flag is found in the "sought" column of the determination state table for the expression.

The knowledge base language used by the knowledge base processor of Appendix VI recognizes variables capable of universal instantiation. In other words, when the inference engine subroutines execute or interpret the knowledge base, a variable can be replaced by a pattern representing a number, symbol or pattern array by the process of binding or instantation. The relationship between a variable and its binding is distinguished from the relationship between an expression and its value due to the fact that a variable may be bound and unbound to different patterns, but a value becomes permanently bound or attached to its expression until a corresponding subset of cache is reset. The knowledge base processor recognizes a phrase of characters starting with a capital letter as a variable.

Variables are used in rules so that the rules have universal applicability to more than one object. For the Stock Market Advisor, a rule in the knowledge base of Appendix II is as follows:

if S has unstable-operations

then S has obsolescence.

Due do the fact that the word "has" is an application-defined operator, as more fully described below, this rule is interpreted as if it were written as follows:

if unstable-operations (S)

then obsolesence (S)=yes.

Therefore, the variable S may represent any one of a number of stocks under consideration by the Stock Market Advisor.

Variables can also be used in rules for performing arithmetic calculations. In the knowledge base of the Stock Market Advisor, such a rule is:

if book-value-per-share of S=X and shares-outstanding of S=Y and (X*Y)=VALUE

then book-value of S=VALUE.

This rule is interpreted as if it were written as follows:

if book-value-per-share(S)=X and shares-outstanding(S)=Y and (X*Y)=VALUE

then book-value(S)=VALUE.

In this example, the variables X and Y are used to receive the numerical values of the book-value-per-share of a stock S and the shares-outstanding of the stock S in order to multiply the numerical values together to conclude the book-value of the stock. In contrast to the logical meta-propositions such as "and", "or", and "not", the operands of arithmetic meta-propositions such as "+", "-", "/", "*", "<", ">" are not evaluated by searching the cache and the knowledge base in order to find values for the operands; the operands themselves should be numbers or variables representing numbers. The meta-proposition "=" is a special case in which the value of the expression to the left of the equal sign is compared or asserted as equal to the value to the right of the equal sign. Therefore, in a premise the operand to the left of the equal sign is evaluated by searching cache and the knowledge base, but the operand to the right of the equal sign is not.

The binding or instantiation process for variables is complicated by the necessity of performing backtracking in order to try alternative instantations of variables in an attempt to apply a rule. In general, backtracking is a search procedure that makes guesses at various steps during problem solving and returns to a previous decision point to make another choice when a guess leads to an unacceptable result. During the binding or instantation process upon variables in a rule, the rule may fail for one possible set of bindings of the variables. When this occurs, and there is another possible set of bindings, backtracking is performed by unbinding the variables and binding them to the other possible set of bindings in an attempt to apply the same rule in another way.

The process of binding and unbinding a variable requires some kind of means for keeping track of the current bindings of the variable. The problem is further complicated by the fact that a variable is local to the rule in which it appears. Therefore, associated with each variable and its binding is the environment of the variable, including other variables that may share the same environment and be bound and unbound at the same time. For keeping track of this information the knowledge base processor uses a data structure called the variable binding stack, named "BindStk". The format for the variable binding stack is shown in the diagram generally designated 95 in FIG. 9. The variable binding stack includes an entry generally designated 96 indicating a binding for each variable being bound. This entry includes an environment flag which is equal to zero signifying that the variable binding has the same environment as the previous variable binding in the stack, or is a non zero number indicating a separation between different environments. The entry 96 also includes a pointer to a trail of modifications that must be undone when backtracking. Moreover, the entry 96 includes an integer number designating the variable to distinguish the variable from other variables. This integer number is used internally in lieu of the name of the variable. The entry 96 also includes a pointer to the pattern indicating the binding which the variable represents.

One kind of general statement in the knowledge base language is known as a "proposition". A proposition is defined as a statement that can be evaluated and therefore may represent a particular value. The premise of a rule, for example, must be a proposition, and the conclusion of the rule is asserted in the event that the premise evaluates to a value with a certainly factor of 20 or greater.

The knowledge base processor evaluates a proposition by matching to a number of formats as shown in the diagram 100 in FIG. 10. If the proposition is recognized as an expression, the cache and then the knowledge base are searched to find the value or values for the expression. If the proposition is recognized as a number, then the value of the proposition is the number. If the proposition is recognized as a variable, the variable is replaced with the pattern which the variable represents, and the pattern is evaluated either as an expression or a number.

If a proposition is found to include a meta-proposition or operator, the other portions of the proposition are interpreted in accordance with the definition of the meta-proposition or operator and then the corresponding operation is performed. The operands for an operator are recognized by their position with respect to the operator in consideration of whether the operator is defined as a prefix operator coming before its operand, a postfix operator coming after its operand, or an infix operator coming between its operands.

Turning now to FIG. 11, there is shown a diagram 105 of the format for a "fact" in the knowledge base. A "fact" is a statement that a particular value is known to be a value of a particular expression with a particular degree of confidence indicated by a certainty factor. If the certainty factor is omitted, it is assumed to be 100.

Turning to FIG. 12 there is shown a diagram 110 illustrating the format for a "rule" in the knowledge base. A rule asserts that if a particular proposition has a value with a certainty factor of at least 20, then a particular "fact" is to be asserted. The proposition following the "if" portion of the rule is known as the premise of the rule.

The invocation of a rule and the evaluation of its premise may be interrupted to evaluate other rules for finding the values of expressions in the premise. Therefore, at any time a number of rules, facts or expressions may be under evaluation.

In order to keep track of the chain of reasoning being attempted at any point in the reasoning process, an invocation stack is used to keep track of each rule, fact or expression currently under evaluation.

The format for the invocation stack, named "InvokeStk", is shown in a diagram 115 in FIG. 13. Each expression or knowledge base entry currently under evaluation has a separate entry generally designated 120 in the invocation stack. Each entry includes a type parameter indicating whether the entry is for an expression or for a knowledge base entry, an environment parameter indicating the binding stack environment for the invocation stack entry, a pointer to the next invocation stack entry, and a pointer to the expression or knowledge base entry.

Turning now to FIG. 14, there is shown a table generally designated 125 which illustrates that the knowledge base may include a number of kinds of meta-fact entries. The knowledge base processor recognizes a meta-fact in the form of "presupposition(EXPR)=PROP" which declares that the proposition PROP presupposes the expression EXPR so that the inference engine should stop seeking a value for the expression if the proposition is false. The knowledge base processor recognizes the meta-fact "nocache(EXPR)" declaring that the expression EXPR should have the "nocache" characteristic. At the start of a consultation, all expressions are assumed not to have the "nocache" characteristic, and when the nocache meta-fact is encountered in the knowledge base, the "nocache" entry in the expression characteristic table for the expression EXPR is changed from "no" to "yes". Similarly at the start of a consultation all expressions are assumed to be single valued, and upon encountering a meta-fact in the form of "multivalued(EXPR)", the multivalued entry in the expression characteristic table for the expression EXPR is changed from "no" to "yes".

The knowledge base processor recognizes a couple of meta-facts which permit the direction of focus of a search in the knowledge base to be diverted when certain information becomes known. A meta-fact in the form of "whenfound(EXPR)=LIST" directs the knowledge base processor to find values for each proposition in the list of propositions LIST when a value is found for the expression EXPR. Similarly, the meta-fact "whencached(EXPR)=LIST" directs the knowledge base processor to find values for each proposition in the list when a value is cached for the expression EXPR. By using meta-facts in the form of "whenfound(EXPR=VALUE)=LIST" and "whencached(EXPR=VALUE)=LIST", respectively, the values for each proposition in the list will be found only when a specific value is found or cached for the expression EXPR.

Although the application programmer is entirely free to define meta-facts, typically the application programmer defines meta-facts to perform user input/output and to declare legal values for expressions. A typical application defined meta-fact in the form of "question(EXPR)"=TEXT is used to ask the user a question specified by the phrase TEXT to obtain a value or values for an expression. An application defined meta-fact in the form of "legalvalues(EXPR)=LIST" is sometimes used to declare a list of legal values for an expression. When the user is asked for a value for an expression and a list of legal values have been defined for that expression, the user's answers are then checked against the list to determine whether the answers are responsive to the question.

Turning now to FIG. 15 there is a diagram 130 showing the format for the knowledge base 32. The knowledge base is organized as a linked list of knowledge base records generally designated 131. Each knowledge base record includes a label pointer for pointing to a label for the corresponding knowledge base entry, a pointer to a "key" which is the expression determined or concluded by the knowledge base entry, an entry pointer which points to the knowledge base entry, an entry type parameter which describes the type of the knowledge base entry, a delete flag which is set to indicate that the knowledge base record will be deleted, a pointer to the next record in the knowledge base, and a flag for indicating whether the knowledge base record is executable. The flag, for example, could be cleared for certain application meta-facts which are executed by the application program only when the knowledge base is loaded.

Turning to FIG. 16 there is shown a table generally designated 132 giving verbal descriptions for the various values of the knowledge base entry type parameter. The knowledge base entry type is positive to indicate that the knowledge base entry is an application-defined meta-fact. The knowledge base entry type has a value of -5, -6, -7, -8, -9, -11 or -15 to indicate that the knowledge base record is a "nocache" meta-fact, a multivalued meta-fact, a presupposition meta-fact, a "whenfound" meta-fact, a rule, a fact, or a "whencached" meta-fact, respectively.

Turning now to FIG. 17 there is shown a diagram generally designated 135 of the format for the cache. The cache is organized as a linked list of entries for each expression having concluded with a value. Each cache entry generally designated 136 includes a pointer to the respective expression, a pointer to the value of the respective expression, a certainty factor for the value, an entry delete flag, a pointer to a reason why the particular value was concluded for the expression including a list of the knowledge base entries confirming or contradicting the particular value, and a pointer to the next cache entry.

Now that the basic data structures for the knowledge base processor in Appendix VI have been described, the basic procedure executed by the inference engine subroutines 35 will be described.

The inference engine subroutines 35 are typically accessed through the "find" subroutine. Turning to FIG. 18, there is shown a flowchart generally designated 140 of the "find" subroutine. In the first step 141, the expression for which a value is to be found is parsed or translated to the internal format described above in connection with FIGS. 2-6. Then in step 142 an inference engine subroutine named "evalExpr" is called to find the value or values for the expression, and to place any value or values that are found in cache. Upon returning from the "find" subroutine 140, the application program obtains the value for the expression from cache.

Turning now to FIG. 19A, there is shown the first part of a flowchart generally designated 150 for the "evalExpr" subroutine. In the first step 151 the application supplied subroutine named "demon" is called to provide a trace of the program execution through the inference engine. Then in step 152 the expression is looked up in the determination state table (see FIG. 7). By inspecting the corresponding "sought" entry of the determination state table, the inference engine determines in step 153 whether the expression has already been sought. If so, then in step 154 the "demon" subroutine is again called, and execution returns. Otherwise, the inference engine must search the knowledge base to find a value for the expression. In step 155 a knowledge base pointer is initialized to start searching at the top of the knowledge base.

In step 157 the knowledge base is searched for the next entry having a key expression field matching the expression being evaluated. As discussed above, the key expression field indicates the expression which the knowledge base entry asserts or concludes. If no knowledge base entry is found in step 157, the bottom of the knowledge base is reached. Therefore, in step 158 the knowledge base pointer is compared to a predetermined value to determine whether the end of the knowledge base was reached. If not, then execution continues on FIG. 19B to execute or interpret the knowledge base entry. For this purpose the knowledge base entry type (see FIG. 16) is inspected to determine the type of the knowledge base entry.

In step 159, if the knowledge base entry is an application defined meta-fact, then execution branches to step 160 to push the invocation stack (see FIG. 13), to call the application supplied subroutine named "evalMetaFact" and to pop the invocation stack.

If the knowledge base entry is a rule as tested in step 161, then in step 162 the application supplied subroutine named "event" is called to signal that a rule is being invoked. Then, in step 163 the rule is evaluated by pushing the invocation stack, calling a subroutine named "evalRule", and popping the invocation stack. Then in step 164 the event subroutine is again called to indicate that the rule has been invoked and to indicate whether the rule succeeded in producing a conclusion and found a value for the expression currently being evaluated.

If the knowledge base entry is a fact, as tested in step 165, the event subroutine is called in step 166 to indicate that a fact is being invoked. Consequently, in step 167 the invocation stack is pushed, the conclusion of the fact is evaluated with the current variable binding, the result is noted in cache, and the invocation stack is popped. The event subroutine is again called in step 168 to indicate that the fact has been invoked and a value has been found for the expression.

If the knowledge base entry is a meta-fact as tested in step 169, then in step 170 the event subroutine is called to indicate that a meta-fact is being invoked. Consequently, in step 171 the invocation stack is pushed, the meta-fact is evaluated, and thereafter the invocation stack is popped. The event subroutine is again called in step 172 to indicate that the meta-fact has been invoked.

After the knowledge base entry has been evaluated, in step 173 the conditions for a single valued cut-off are tested. In other words, searching of the knowledge base terminates if the expression is single valued and the knowledge base entry has concluded a definite value for the expression. If not, the knowledge base pointer is advanced to the next entry in step 174 so that execution may return to step 157 in FIG. 19A to continue searching through the knowledge base. Then, at the end of searching the knowledge base, execution continues in step 175. If the knowledge base has not provided a value for the expression, then in step 176 the application supplied subroutine named "determine" is called as a last resort.

After searching the knowledge base or calling the determine subroutine, in step 177 the entry in the determination state table (see FIG. 7) for the expression is marked to indicate that the expression has been sought, and the invocation stack is popped. Since the expression has been marked as sought, the knowledge base will not again be searched for the same expression unless the determination state table is reset, for example, by calling the subroutine "resetCache". It should be noted that even if the application supplied determine subroutine fails to determine a value for the expression, the system will know that the expression has a value of "unknown" since a value for the sought expression will not be found in cache. Before returning, however, the event subroutine is called in step 178 to indicate that the expression was sought, and the demon subroutine is called in step 179 to indicate that execution is returning from the "evalExpr" subroutine.

Turning now to FIG. 20 there is shown a flowchart generally designated 190 of the subroutine named "evalRule". In order to evaluate the rule, in the first step 191 a variable binding frame is created for the premise of the rule. Similarly, in step 192 a variable binding frame is created for the conclusion of the rule. Steps 191 and 192, for example, match the arguments of an expression in the form of a function to the corresponding variables defined in the rule. Then in step 193 an action parameter is set to a value of "evalConclusion" to indicate that the conclusion of the rule should be noted in the cache if the premise is found to succeed with a certainty factor of 20 or greater. In step 194 a subroutine named "evalProp" is called, and the rule's premise P, conclusion C, binding frame and action are passed as parameters so that the premise will be evaluated and the conclusion will be asserted in the event that the premise is found to have succeeded with a certainty factor of 20 or more.

Turning now to FIG. 21, there is shown a flowchart generally designated 200 of the subroutine named "evalProp" for evaluating a specified proposition P and conditionally asserting a specified action or conclusion C in the context of specified variable bindings. In the first step 201 the application supplied demon subroutine is called. Then in step 202 the metaprop table is searched for a match to the proposition P starting at the bottom of the table so as to search the application-defined meta-propositions before the built in meta-propositions. Every time the application program adds a meta-proposition to the metaprop table by calling the "addMetaProp" subroutine, the newly added meta-proposition is inserted at the bottom of the meta-prop table.

A match between the metaprop table and the proposition is tested in step 203. A match should always occur because the metaprop table includes a template for each legal form of a proposition (see FIG. 10). If the match does not occur, then in step 204 the application supplied subroutine named "error"is called to signal a syntax error, and execution returns.

If the proposition P is matched to an entry in the metaprop table, then in step 205 execution branches if the matching entry is an application defined meta-proposition. If so, then in step 206 the application supplied subroutine named "evalMetaProp" is called to evaluate the application defined meta-proposition. Otherwise in step 207 the built-in meta-proposition is evaluated, depending upon the particular matching template. The evaluation in step 207 may require recursive calls to the evalProp subroutine to reduce compound propositions to simple propositions which contain expressions. These component expressions are evaluated by recursive calls to the subroutine evalExpr of FIGS. 19A and 19B. Once the proposition P is evaluated, the specified action is done in the event that the proposition P has a certainty factor greater or equal

20.

As a final part of step 207, backtracking is performed if a certain repeat flag has been set. The repeat flag may have been set by the creation of the variable binding frame and a recognition at that time of a number of alternative variable bindings. If the repeat flag is set, then a "doAction" subroutine. performs a continuation action by recursively calling the evalProp subroutine to evaluate the proposition for the next possible set of variable bindings, although backtracking will be halted in the case of a single valued cut-off. Otherwise once the proposition is evaluated and conclusions asserted for every possible set of variable bindings, the evaluation of the proposition is finished. Before returning, however, in step 208 the demon subroutine is called to signal the completion of the evaluation process.

This completes the description of the basic procedure followed by the inference engine to interpret the knowledge base. Further details of the procedure are evident from the attached program listing, including English language comments, found in Appendix VI. An outline of the control flow in this program listing is given in Appendix V. The outline clearly illustrates that the program is implemented as a hierarchy of subroutines.

Turning now to Appendix III, there is shown a listing of a Stock Market Advisor application program which illustrates many of the features of the knowledge base processor of Appendix VI. It should be evident that this application program is written in the C programming language. After initializing a number of parameters, the knowledge base processor of Appendix VI is initialized by calling a knowledge base processor subroutine called "initCopernicus". None of the other subroutines of the knowledge base processor should be called before calling this initial subroutine.

Next the application program adds an application defined operator called "infix" which is defined as a prefix operator (indicated by the code FX), a rather high procedure (indicated by the precedence value of 250, the lowest procedence being one and the highest precedence being 254). Then some application defined meta-facts are added to the meta-fact table. First a meta-fact in the form of "question(E)=T" is added. Next a meta-fact in the form of "infix x" is added.

A number of application defined meta-propositions are also added to the knowledge base language syntax. A meta-proposition in the form of "display(E)" is added in order to display or output the value of a specified expression E.

In order to indicate whether a value of an expression has an associated certainty factor of 100, a meta-proposition is added in the form of "E is definite". The return value for this meta-proposition is "yes" cf 100 if the certainty factor associated with a value of the expression E is 100, and otherwise the return value is "no" with a certainty factor of 100. Therefore, to determine whether the expression is definite, its concluded values must be checked to determine whether any one of them has a certainty factor of 100.

A meta-proposition is defined in the form of "E is known" to indicate whether at least one value was concluded about the expression E that has a certainty factor greater or equal to 20. If so, the return value is "yes" cf 100; otherwise, the return value is "no" cf 100.

In order to read the "sought" column of the determination state table for a specified expression (see FIG. 7), a meta-proposition is defined in the form of "E is sought" and returns a value of "yes" cf 100 if the expression has been sought, and otherwise returns a value of "no" cf 100.

In order to indicate whether an expression has one and only one value with an associated certainty factor greater than a cut-off value such as 20, a meta-proposition is defined in the form of "E is unique". The proposition returns a value of "yes" cf 100 if it has only one such value; otherwise, the return value is "no" cf 100.

An expression is said to be unknown if it does not have any value with a certainty factor greater or equal to a cut-off value such as 20. To determine this condition, a meta-proposition is defined in the form of "E is unkown" which returns a value of "yes" cf 100 if the expression E is unknown, and otherwise returns a value of "no" cf 100.

Now that the knowledge base language syntax has been defined, the knowledge base processing begins by opening the Stocks Knowledge Base file for access. The file has a name of "stocks.kb" and the contents of the file are listed in Appendix II. An error message is transmitted to the user in the event that the Stocks Knowledge Base file cannot be opened for some reason. Otherwise, once the Stocks Knowledge Base file is opened, the knowledge base data structure is also opened by calling the subroutine named "openKB". Then the contents of the file are loaded into the knowledge base data structure. Just prior to the actual loading the user is given a message "Loading knowledge base . . . . "

After the knowledge base is loaded, the cache is opened by calling the knowledge base processor subroutine named "openCache".

The user is then given the option to enter stock data either from a file or interactively. If the user desires to use a data file, the file must have the name "stocks.dat", and after the opening of this file the data are transferred directly from the file to the cache. The stock data file should include, for any number of stocks, the name of each stock, its current price, and its five year high. These data items are individually added to cache by calling the knowledge base processor subroutine named "addCache" for each data item. For each stock, the knowledge base processor is asked to find a value for a main goal "recommend" which give a recommendation of whether the stock is a good buy. After giving the recommendations for the stocks, the stock data file is closed.

If the user desires to provide interactively the information about the stocks, the knowledge base processor subroutine named "find" is called prior to the entry of stock data to find a value for the main goal "recommend". The user is prompted for the necessary stock information after certain rules are tried and the system recognizes that the necessary information must be obtained from the user. After a value is found for the main goal "recommend", the cache is closed as well as the knowledge base data structure. Finally, the knowledge base file in the computer's mass storage memory is closed. At this point execution of the main subroutine of the application program is finished.

The application program includes a number of application supplied subroutines. A subroutine named "display" performs the user-defined meta-proposition "display(TEXT)" by printing the text. If the text includes a number of separate items, the items are printed in list form. The "display" function calls another application supplied subroutine named "display item" to display a single item by converting the internal format of the text to an appropriate string of characters. After matching the internal format against certain special cases such as a pre-defined display proposition, a new line, tab, and an integer to dollar-and-cents conversion, then the symbol, variable or structure to be directly printed is unparsed to convert from internal format to a character string. Then, the character string is printed out.

The application supplied display subroutine recognizes dotted pairs representing list structures in the knowledge base language. In order to find any dotted pair in the internal format representing the test, the display subroutine calls another application program subroutine named "isDottedPair".

The Stock Market Advisor application program supplies the subroutine named "readch" in order to read a character from a file and to return the character to the knowledge base processor.

The Stock Market Advisor application program provides the subroutine named "metaFactLoaded" in order to pre-process the "infix" application defined meta-fact when the knowledge base file in the computer's mass storage memory is loaded into the knowledge base data structure. The "infix" meta-fact is processed by interpreting the parameter of the infix meta-fact as an application defined operator to be added to the knowledge base language syntax. The parameter is added to the operator table by calling the knowledge base processor subroutine named "addOp".

The stock market advisor application program supplies the subroutine named "evalMetaFact" in order to evaluate the application defined meta-fact in the form of "question(E)=T". The application program also includes the "evalMetaProp" subroutine for evaluating the application defined meta-propositions. The meta-proposition in the form of "display(E)" is performed by calling the "display" function of the application program and then performing any specified continuation action by calling the knowledge base processor "doAction" subroutine. The other user-defined meta-propositions discussed above are performed by first evaluating the expression parameter of the meta-proposition, checking whether the respective property of the expression is present, and if so doing the specified continuation action by calling the "doAction" subroutine.

The Stock Market Advisor application program includes the "determine" subroutine to determine the value of an expression by asking the user. First the knowledge base processor subroutine "getState" is called to check whether the expression is multivalued. If the expression is multivalued, the user is asked the question, "What are the values of: [name of the expression]?" Otherwise, the user is asked the question, "What is the value of: [name of the expression]?" The user's response is read in and parsed to determine the internal code for the value or values of the expression. Also noted in cache is the reason for the value which is "you said so". This reason is converted to the internal format before being noted in cache with the value or values by calling the knowledge base processor subroutine "noteCache".

The final subroutine of the application program is the application supplied subroutine named "error". The "error" subroutine generates and transmits an error message to the user which includes the function identification code and the error number supplied by the knowledge base processor. This completes the description of the Stock Market Advisor Application Program.

A typical consultation with the Stock Market Advisor is listed in Appendix IV. After the knowledge base was loaded, the application program asked the user whether stock data should be entered from a file. The user answered "no", so that the application program called the "find" subroutine of the knowledge base processor to find a value for the main goal named "recommend". Therefore, the knowledge base processor sought the expression "recommend" by searching the knowledge base of Appendix II.

The very first rule of the knowledge base was invoked causing the expression "buy-or-sell" to be sought. The first knowledge base entry for determining "buy-or-sell" was found to be the application defined meta-fact in the form of "question (buy-or-sell)". Therefore, the user was asked the question "Do you wish to buy or sell stock?" The user answered "buy" causing the second premise clause of the first rule in the knowledge base to be evaluated. Therefore, the expression "recommended-purchases" was sought. This expression was found in the fifth rule in the knowledge base. To evaluate this fifth rule, the expression "stocks" was sought. The first knowledge base entry for determining a value for "stocks" is a question and therefore the user was asked the question, "Which stock do you wish to consider?".

Returning to consideration of the second premise of the first rule for concluding recommended-purchases, the knowledge base processor sought the value of the expression "tek has crashed" which is more formally represented as "crashed(tek)". The word "has" as well as the work "of" were used as parameters for the "infix" application defined meta-fact. During loading of these application defined meta-facts, the words "has" and "of" were consequently defined as infix operators, and upon evaluation their two operands are concatenated or combined to represent a single expression.

The knowledge base processor invoked the first rule for concluding "S has crashed" by binding the atom "tek" to the variable S. To evaluate this rule, the expression "current-price of tek" was sought. The first knowledge base entry for determining a value for this expression was a question, and therefore the user was asked "What was the current price of tek?" The user responded with the value of 1. Therefore, the second clause of the first rule for concluding "S has crashed" was evaluated thereby causing the knowledge base processor to seek the expression "five-year-high of tek". The first knowledge base entry for determining "five-year-high of tek" was a question, and therefore the user was asked "What is the 5 year high of tek?" The user responded 3. This value, however, caused the first rule for concluding the expression "S has crashed" to fail so that the second rule for concluding "S has crashed" was invoked. This second rule, however, also failed with the previously determined value of the current price and 5 year high of tek. Similarly, the third rule for concluding "S has crashed" failed.

The knowledge base processor invoked the fourth rule for concluding "S has crashed" and required a value for the expression "attribute of tek" to evaluate the fourth premise clause of this rule. Upon seeking this expression, a knowledge base entry in the form of "presupposition(attribute of S)" was found, but the knowledge base processor had already found that the value of the expression "buy-or-sell" was "buy" so that the presupposition had no effect. Therefore, the next knowledge base entry caused the user to be asked the question, "Is tek a utility, bank, component-of-djia, one-product-company, highly-volatile-market: Enter one of the above." The user indicated that tek is a bank thereby causing the fourth rule for concluding "S has crashed" to fail since "attribute of tek" is not a utility. Similarly, the fifth rule "S has crashed" also failed.

Upon invoking the next and sixth rule for concluding "S has crashed", the knowledge base processor had to seek the value of the expression "company-value of tek". The knowledge system then asked the question, "What is the current company value of tek?" The user responded 1 million. This value, however, caused the sixth rule concluding "S has crashed" to fail. Consequently the next and seventh rule for concluding "S has crashed" was invoked. To evaluate the last premise clause of this rule, the knowledge base processor sought the value of "bank-size-rating of tek". Upon searching the knowledge base for entries for determining this expression, a presupposition was found for "bank-size-rating of tek" but this presupposition has no effect since the knowledge base processor already had sought "attribute of tek" and had found the value "bank".

To determine "bank-size-rating of tek" a question was found in the knowledge base asking user, "On a national scale, numerically rate tek with other banks. Good approximations will work (1=largest, 2=second):". The user responded 4, and thereby caused the seventh and last rule for concluding "S has crashed" to conclude that the value of "tek has crashed" was "yes" cf 100.

Since the knowledge base processor determined that tek has crashed, execution returned to evaluating the second premise clause of the rule for concluding "recommended-purchases". To evaluate this second clause, the knowledge base processor sought a value for "tek has assets" and invoked the first rule for concluding "S has assets". To evaluate the premise of this rule, the knowledge base processor sought the expression "book-value-per-share of tek". The first knowledge base entry for determining this expression was the question, "What is the current book value per share of tek?" The user responded 0.75 causing the first rule for concluding "S has assets" to fail. Upon invoking the second rule concluding "S has assets", the knowledge base processor had to seek the expression "hidden-assets". The first knowledge base entry for determining "tek has hidden-assets" was a question, "Does tek have hidden (off balance sheet) assets?" The user responded "yes", and the knowledge base processor returned to evaluating the second premise cause of the second rule for concluding "S has assets". This caused the knowledge base processor to seek the expression "hidden-asset-value" resulting in the user being asked the question, "What is the monetary value of these assets?" The user responded 200,000, and the knowledge base processor returned to evaluating the third clause in the premise of the second rule for concluding "S has assets". This in turn caused the knowledge base processor to seek the expression "book-value of S".

To determine the book-value, the knowledge base processor invoked the first rule for concluding "book-value of S". The knowledge base processor recognized that it had already sought "book-value-per-share of tek" and therefore went on to evaluate the second clause of the premise for this rule which required the seeking of the expression "shares-outstanding of tek". To determine the value for this expression, the user was asked "What is the current number of shares outstanding in tek?" The user responded 100,000. As a result, the first rule for concluding "book-value of S" succeeded and concluded that the book-value of tek was 75,000 cf 100.

Returning to the evaluation of the premise of the second rule for concluding "S has assets", the knowledge base processor had to seek the expression "market-value of tek". As a result, the user was asked "What is the current market value of tek?" The user responded 200,000. As a result, the second rule for concluding "S has assets" succeeded in concluding that tek has assets.

The knowledge base processor then returned to the evaluation of the premise of the rule for concluding "recommended-purchases of tek". To evaluate the fourth premise clause, the knowledge base processor had to seek the expression "tek has signs-of-life". As a result, a first rule for concluding "S has signs-of-life" was invoked which in turn caused the knowledge base processor to seek the expression "tek has dividend-in-last-quarter". To determine this expression, the user was asked "In the most recent quarter did tek maintain a dividend?" The user responded "yes", and therefore the first rule for concluding "S has signs-of-life" succeeded in concluding that tek has sign of life.

Returning to the evaluation of the premise for the rule for concluding "recommended-purchases", the knowledge base processor next had to seek the expression "tek has obsolescence". As a result the first rule for concluding this expression was invoked. To evaluate its premise, the knowledge base processor sought the expression "tek has unstable-operations", causing the user to be asked the question "Does tek have many unstable operations or operations is unpredictable foreign countries?" The user responded "no" causing the first rule for concluding "S has obsolescence" to fail. The second rule for concluding "S has obsolescence" also failed because upon interpreting the application defined metaproposition "unknownn", the knowledge base processor called the application supplied subroutine "evalMetaProp" and determined that the expression "tek has obsolescence" was unknown. Consequently, the second rule for concluding "S has obsolescence" succeeded in concluding that tek did not have obsolescence.

The knowledge base processor then returned to evaluating the premise of the rule for concluding "recommended-purchases". To evaluate the sixth clause of the premise, the expression "tek has technical-bottom" was sought. As as result, the user was asked "Has tek reached a technical-bottom in the stock market by demonstrating at least one of the following chart patterns? Double-bottom, vee with six-month high after 90% decline, vee+flag, vee+correction, vee+gap, reverse head-and-shoulders bottom, saucer or congested, climax, saucer+gap; enter `yes` or `no`:". The user responded "yes" so that the knowledge base processor found that tek has technical-bottom.

Returning to evaluation of the seventh and last clause of the premise for the rule for concluding "recommended-purchases", the expression "tek has technical-turn" was sought. As a result, the user was asked "Have weekly price movements of tek confirmed the commencement of one of the following technical turning patterns? Volume build-up with rising prices, second run, breakout patterns, momentum gaps, 2-hook trend line; enter `yes` or `no`:". The user responded "yes". Therefore, the knowledge base processor determined that tek had technical turn and the rule for concluding "recommended-purchases" succeeded and concluded that "tek" was a value for the expression "recommended-purchases".

The knowledge base processor returned to the application of the very first rule in the knowledge base, and upon evaluating the third premise clause recognized that "display" was an application defined meta-proposition. Therefore, the "evalMetaProp" subroutine was called resulting in the display of a message to the user saying, "It is recommended that you purchase a stock belonging to tek". Upon returning, the very first rule of the knowledge base succeeded in concluding a value of "yes" cf 100 for the expression "recommend". Since the application program had called the "find" subroutine of the knowledge base processor to find the value of the expression "recommend", execution returned to the application program. The following statements in the application program did not generate any user output, so that the consultation listing was at an end. This completes the description of the Stock Market Advisor programm example.

In view of the above, a knowledge engineering tool has been described that is compatible with conventional computer programming languages and their support facilities such as utility libraries, optimizing compilers and user interfaces. A knowledge base processor has been described for performing symbolic reasoning with respect to knowledge stored in a knowledge base, yet the knowledge base processor comprises an organization of user-callable subroutines written in a conventional computer language. The knowledge base processor may call upon the utility library for the conventional computer programming language. The knowledge base processor can be compiled using an optimizing compiler for the conventional computer programming language. Moreover, the knowledge base processor or its companion application program may use the preexisting user interfaces available in that conventional computer programming language, and as a result, the performance of the knowledge system is enhanced.

An application programmer may use the conventional computer programming language to write an application program that calls selected ones of the subroutines making up the knowledge base processor. The order in which these subroutines are called is determined by the application program and therefore the computer programmer is permitted to use the conventional programming language to specify most of the control knowledge for the knowledge system. Therefore, extensive training in a new programming language is not required. During the interactive portion of a consultation, the calls to the "find" subroutine are used whenever it is desirable to perform symbolic reasoning either to find the value for some object or to exercise judgement at branch points in the application program. Therefore, there may be a clearer and more transparent relationship between the control knowledge supplied by the application program and the judgemental knowledge encoded in the knowledge base.

By using application defined meta-facts, application defined meta-propositions, and application defined operators, the application programmer can extend and enhance the capabilities of the knowledge system by defining the knowledge base language syntax that is optimal for a specific application. As illustrated in the Stock Market Advisor, the application programmer can make the changes to the knowledge base language transparent by application defined meta-facts and application defined meta-propositions that are passed to the application program during the loading of the knowledge base and are thereafter put into the memory tables of the knowledge base processor before the beginning of a consultation. In the Stock Market Advisor, for example, this permitted the rules to be written in a more English-like knowledge base language. The capabilities of the knowledge system can be further enhanced for special applications by interrupting and modifying the control procedure of the inference engine in response to calls to the application supplied "event" subroutine.

I. GLOSSARY

II. STOCK MARKET ADVISOR KNOWLEDGE BASE

III. STOCK MARKET ADVISOR APPLICATION PROGRAM

IV. STOCK MARKET ADVISOR CONSULTATION LISTING

V. FLOWSHEET OF THE KNOWLEDGE BASE PROCESSOR

VI. KNOWLEDGE BASE PROCESSOR ##SPC1##