.. \.' -·
`
`October 1981
`
`Also numbered:
`HPP·B/·16
`
`Report. No. ST AN·CS~l-885
`
`The Emycin Manual
`
`by
`
`W. Van Melle
`A. C. Scott
`J.S.Bcnnctt
`M. Peairs
`
`Department of Computer Science
`
`Stanford University
`Stanford, CA 94305
`
`----------------·--
`
`eBay Inc. et al. Exhibit 1007 Page 1
`
`

`

`' t
`
`.. I
`
`The EMYCIN Manual
`
`William van Melle, A. Carlisle Scott
`
`James S. Bennett, and Mark A. S. Peairs
`
`9 November 1981
`
`Abstract
`
`This manual describes a domain-independent system, called EMYCIN, for constructing one class of
`expert computer programs: rule-based consultants. The resulting programs use knowledge specific
`to a problem domain to provide consultative advice to a client. The system-building tool, EMYCIN, is
`based on the domain-independent core of the MYCIN program. Domain knowledge is represented in
`EMYCIN systems primarily as production rules, which are applied by a goal-directed backward·
`chaining control structure. Rules and consultation data may have associated measures of certainty,
`and incomplete data entry is allowed. The system includes an explanation facility that can display the
`line of reasoning followed by the consultation program, and answer questions from the client about
`the contents of its knowledge base.
`
`To aid the system designer in producing a knowledge base for a domain quickly and accurately,
`EMYCIN provides the following features: (1) a terse, stylized, but easily understood language for
`writing rules; (2) extensive checks to catch common user errors, such as misspellings; and (3)
`methods for handling all necessary bookkeeping chores. Other human-engineering features allow
`the system architect to produce, with a minimum of effort, a consultation program that is pleasing in
`appearance to the client.
`
`Several consultation programs have been developed using EMYCIN, including r;onsultants for
`medical problems and a consultant for structural analysis.
`
`Copyright (c) 1981 The Board of Trustees of Leland Stanford Junior
`
`University. All Rights Reserved.
`
`.
`
`Research supported in part by NSF grant MCS-7903753
`
`eBay Inc. et al. Exhibit 1007 Page 2
`
`

`

`#
`
`t
`
`,
`
`I
`
`Table of Contents
`
`1. Introduction
`2. Contexts
`
`2.1. The Context Tree
`2.2. Uses of the Context Tree
`2.3. Defining Contexts
`2.4. Parameter Groups and Rule Groups
`2.5. Properties of Context Types
`3. Parameters
`
`3.1. Defining Parameters
`3.2. Properties of Parameters
`3.3. Examples of Parameters
`4. Rules
`
`4.1. The Structure and Definition of Rules
`4.2. The Rule Interpreter
`4.3. Rule Groups
`4.4. The Uses of Rules
`4.5. Abbreviated Rule Language (ARL)
`5. Building an EMYCIN Consultant
`
`5.1. Organizing your Knowledge Base
`5.2. Example: Acquiring a Business Consultant
`6. Creating and Maintaining the Knowledge Base
`
`6.1 . Putting the Knowledge Base On-line
`6.2. The EMYCIN Executive
`6.3. The Knowledge Base Editors
`6.4. Saving the Knowledge Base
`6.5. Listing the Knowledge Base
`7. Debugging the Knowledge Base
`7.1. Consultation Tracing
`7.2. WHY and HOW Questions
`7.3. The EXPLAIN, TEST, and REVIEW Options
`7.4. The OA Module
`7.5. Debugging with Batch
`8. Consultation Options
`
`8.1. Consultation Special Options
`8.2. Maintaining Consultant Cases
`8.3. Controlling the Interaction of the Consultant
`· 9. Implementation Details
`
`9.1. Miscellaneous System Variables
`9.2. Pointers to and from Rules
`
`3
`15·
`15
`18
`21
`22
`22
`27
`
`30
`' 31
`36
`39
`39
`41
`44
`46
`51
`55
`
`55
`57
`63
`
`63
`64
`65
`66
`71
`75
`
`75
`'75
`77
`81
`84
`89
`89
`92
`93
`101
`
`101
`101
`
`eBay Inc. et al. Exhibit 1007 Page 3
`
`

`

`II
`
`9.3. Internal Data Structures during a Consultation
`9.4. Modifying OA for your domain
`9.5. The Dictionary
`9.6. Defining New Predicate and Action Functions
`Appendix I. Functions
`1.1. Non-Numeric Predicate Functions
`1.2. Numeric Predicate Functions
`1.3. Conclusion Functions
`1.4. Auxiliary functions
`1.5. Functions for TEXT-valued Parameters
`I.e. Mapping functions
`Appendix 11. An Introduction to the lnterllsp editor
`Index
`
`102
`104
`105
`107
`""111
`111
`114
`"116
`118
`119
`121
`127
`135
`
`eBay Inc. et al. Exhibit 1007 Page 4
`
`

`

`••
`
`List of Figures
`
`Figure 1·.1 : The major roles of EMYCIN
`Figure 1·2: A sample rule from the domain of structural analysis
`Figure 1·3: Example of ARL format for rule input/output.
`Figure 2·1: SACON's static tree of context types
`Figure 2·2: An instance tree from SACON
`Figure 2·3: MYCIN's static tree
`Figure 2·4: A tree of instances during a particular MYCIN consultation
`. Figure 2·5: LITHO's static tree and an instance tree
`· Figure 2·6: CLOT's static tree and an instance tree
`Figure 2· 7: GRAVIDA's static tree and instance tree
`Figure 2·8: An example of a dynamic relationship between context instances
`Figure 2·9: Prompt properties required by a context
`Figure 3·1: Parameter Editor commands
`Figure 4·1: A sample rule from the CLOT system.
`Figure 4·2: CFCOMBINE
`Figure 4·3: MYCIN's static tree
`Figure 4·4: ARL Operators
`Figure 4-5: ARL Forms
`Figure 5·1: SACON Inference Structure
`Figure 5·2: A Goal Rule forSACON
`Figure 6-1: EMYCIN Executive commands
`Figure 6· 2: Property Editor commands
`Figure 6·3: Migration of Changes
`Flgu re 6·4: Knowledge base files for a consultant
`Figure 7·1: QA Options
`Figure 7 • 2: Legal question forms for QA
`Figure 8·1: Special Options Available Before a Consultation
`Figure 8·2: Instructions for Running Consultations
`Figure 8·3: Possible Answers During a Consultation
`Figure 8-4: Special Options during TAB
`Figure 9·1: Non-Numeric Predicate Functions
`Figure 9·2: lnterlisp Editor Commands
`
`iii
`
`4
`6
`10
`16
`16
`18
`19
`19
`20
`20
`21
`24
`30
`39
`44
`45
`53
`53
`56
`57
`64
`66
`68
`70
`82
`83
`89
`90.
`91
`95
`112
`131
`
`eBay Inc. et al. Exhibit 1007 Page 5
`
`

`

`..
`
`1
`
`Preface
`
`This document describes the basic knowledge structures and operation of the EMYCIN system. It
`has been oriented toward the prospective system builder and contains substantial details about the
`available knowledge acquisition aids.
`
`The first chapter contains a brief introduction to the EMYClN system and includes descriptions of
`some recently incorporated features such as rule checking and the Abbreviated Rule Language. We
`recommend that you read this first chapter before exploring the rest of the manual, even if you are
`familiar with the EMYCIN system. In addition to refreshing your memory, it serves as a map t!) the rest
`of the manual's contents.
`
`The basic building blocks of a knowledge base (contexts, parameters, and rules) are described
`chapters 2, 3, and 4 respectively. You should be familiar with each of these components before trying
`to create a knowledge base. The predicate and action functions of rules are described in appendix I.
`
`Much of the material discussed in these chapters is highly interconnected, and certain amount of
`forward referencing cannot be avoided. Thus, some sections will be difficult to appreciate until later
`ones have been read. A second reading of these sections will be to one's advantage.
`
`We assume that the reader has a modest familiarity with the Lisp language and, in particular, with •
`the lnterlisp dialect [Teitelman 78]. Most data structures in the system are entered in a Lisp format,
`although they are not necessarily maintained in that exact form internally. Some ability to use. the
`is very useful, as that is the principal means for editing Lisp structures. We have
`lnterlisp editor
`provided a brief introduction to the structure editor (see appendix II). Further knowledge of lnterlisp
`is useful, especially the break package and the file package, but not strictly essential. For an
`introduction to the Lisp language see [Charniak 80] or [Horn 81].
`
`Text followed a "+-" is to be typed to the lnterlisp executive (whose prompt character is +-). This
`character prints as a "-" on some terminals. The prompt for the lnterlisp structure editor is "• ".
`Words in lower case and surrounded by brackets are symbols that are meant to be replaced by an
`appropriate value. "<cr>" denotes a carriage return; "tx" denotes control-x for any letter x, e.g. tG
`rings the bell at the terminal.
`
`Example output from a terminal session is printed in this font. Text within these exan'fples
`displayed in bold. face represents input typed by the expert or the client. Comments on the examples
`are displayed in italics.
`
`eBay Inc. et al. Exhibit 1007 Page 6
`
`

`

`2
`
`Acknowledgments
`
`Many people have contributed to the construction and development of the EMYCIN system,
`through code and ideas. They include Edward H. Shortliffe, Bruce G. Buchanan, Lawrence M. Fagan,
`Janice S. Aikins, William J. Clancey, Randall Davis, Miriam B. Bischoff, Alain Bonnet, Sharon Wraith·
`· Bennett, and the entire SUMEX staff.
`SeveraJ people read and made comments on earlier drafts of this manual: Alain Bonnet, Bruce
`G. Buchanan, Val catanzarite, David Goldman, Jacques Harry, Clifford A. Ho!lander, and Steven
`
`Snyder.
`
`The authors would like to especially thank Thomas Dietterich for giving a final draft of this manual a
`particularly thorough reading and for suggesting (and drafting) countless important Improvements.
`
`,., .. _.,,~ ............... ~ ......... ----··--·~-~,---·-, ------------·----·-----·----
`
`eBay Inc. et al. Exhibit 1007 Page 7
`
`

`

`• >
`
`1
`
`Introduction
`
`3
`
`1. Introduction
`
`Much of the current research in artificial intelligence focuses on computer programs that aid
`scientists with complex reasoning tasks. Recent work has indicated that one key to the creation of
`intelligent systems is the incorporation of large amounts of task-specific knowledge. Building such
`"knowledge-based" or "expert" systems from scratch can be very time-consuming, however, Thus
`research has also concentrated on the design of general tools to aid the construction of knowledge·
`based systems.
`
`This manual describes a domain-independent framework for constructing one ciBS$ of expert
`programs: rule-based consultants. The system, called EMYCIN, 1
`is based on
`the domain·
`independent core of the MYCIN program [Shortliffe 76].
`
`The Task
`
`EMYCIN is used to construct and run a consultation program, a program that offers advice on
`problems within its domain of expertise. The consultation program elicits information about a
`particular problem (a "case") by asking questions of a user.
`It then applies Its knowledge to the
`specific facts of the case and informs the user of its conclusions. The user is.free to ask the program
`questions about its reasoning in order to better understand or validate the advice given.
`
`For example, the MYCIN system was constructed to advise a physician on the selection of an
`appropriate anti-microbial therapy for a patient with an infection.
`In order to suggest any drugs
`MYCIN reasons about the type of the patient's infection and about the organisms that might be
`causing it. MYCIN bases its reasoning on data the physician supplies regarding laboratory tests, prior
`medical history, and any current or prior therapy the patient has received.
`
`In a non-medical application, the SACON consultant was constructed to advise a structural
`engineer on the use of a very complex computer program, MARC, which uses a finite-element method
`to simulate a mechanical structure's response to various load conditions. SACON recommends
`different packages and options available in the MARC system based on an estimation of the kinds of
`stress and deflection behaviors that are likely to arise for a structure. This estimation is based on_, in
`turn, a description of the structure itself, its geometry and construction, and a descriptio~ of the
`various loads (such as braking, bending, etc.) that it will sustain.
`
`There are really two "users" of EMYCIN, as depicted in Figure 1·1. The system designer or expert
`interacts with EMYCINto produce a knowledge base for the domain. The knowledge base is made up
`of two basic components: factual knowledge about the case under consideration and rule-based
`knowledge about how to carry out the consultation. EMYCIN interprets this knowledge base to
`provide advice to the client or consultation user. Thus the combination of EMYCIN and a specific
`
`1
`
`•Essential MYCIN", I.e., MYCIN stripped of its domain knowledge. EMYCIN is written in lnterlisp , a pr()gramming
`environment for a particular dialect of Lisp language, and runs on a oec POP·10 or ·20· under the TENEX or TOPS20 operating
`systems. The current implementation of EMYCIN uses about 45K words of resident mel'llory and an additional 80K of swapped
`code.space. The vei'Sion of INTERLISP in which it is embedded occupies about 130K of resident memory, leaving approximately
`80K free for the domain knowledge base and the dynamic data structures built up during a consultation.
`
`eBay Inc. et al. Exhibit 1007 Page 8
`
`

`

`4
`
`Introduction
`
`1
`
`knowledge base of domain expertise is a new consultation program.
`
`SYSTEM DESIGNER
`
`expertise
`
`·~
`
`debugging feedblck
`
`EMYCIN
`
`,,
`
`Knowledge Base
`Construction Aids
`
`Consultation
`Driver
`
`~
`
`case data
`
`advice
`
`•lr
`
`CLIENT
`
`,
`
`J
`
`...
`
`,
`
`Domain
`
`Knowtedge
`
`Base
`
`Flgu re 1·1: The major roles of EMYCIN
`
`Knowledge Organization
`
`Facts
`
`The factual knowledge about a case is stored much as information is stated in traditional dat-..
`bases, as context-parameter-value triples. A context Is an actual or conceptual entity in the domain of
`the consultant, e.g., a patient, an aircraft, or an oil-well. Associated with each context Is a set of
`parameters such as the age, sex, and race of the patient or the location, depth, and estimated lifetime
`the RACE parameter of the
`of the oil-well. Each parameter of each context can take on values;
`patient context could take on values such as caucasian, black, asian, etc~
`
`In terms of traditional programming languages, a context is like a record structure and the
`parameters are the variables that make up that record structure. The main goal o'f a consultation,
`·then, is to fill'in the values for a few key parameters, such as the organisms causing the patient's
`
`eBay Inc. et al. Exhibit 1007 Page 9
`
`

`

`..
`
`1
`
`Introduction
`
`5
`
`infection or stress behaviors to be observed in the structure. To accomplish this, however, it is often
`necessary to fill in values for other parameters and so on.
`
`The expert uses the EMYCIN knowledge acquisition aids to define these record structures·
`(contexts, parameters, and values) and then specifies in the production rules how to create it1Stances
`of these record structures during a consultation and how to fill in the values of the record structures
`variables.
`
`An important difference between traditional record structures and EMYCIN's factual knowledge
`structure is that parameters can take on multiple values. The uncertainty of data or competing
`hypotheses is represented by a number called certainity factor (CF) attached to each fact triple. The
`CF is a number between -1 and 1 indicating the strength of the belief in, or the importance of, that
`fact. A CF of 1 represents total certainty, while a CF of -1 represents certainty in the negation of the
`fact. Although certainty factors are not conditional probabilities, they are informally based on
`probability theory.2
`
`Some sample triples from the SACON system might be
`
`parameter
`
`context
`
`value
`
`(CF)
`
`of SUB-STRUCTURE-2 ~ CONCRETE (1.0)
`(a) COMPOSITION
`of SUB-STRUCTURE-3 ~ PLANAR
`(-1.0)
`(b) GEOMETRY
`(c) TIME-DEPENDENT of STRUCTURE-24
`(1.0)
`~YES
`
`in other words, (a) the composition of the second sub-structure is concrete, (b) the geometry of the
`third sub-structure is not planar, and (c) there are time-dependent terms in the equilibrium equations
`of Structure-24. Multiple values for a single context and parameter are permitted if the CF's are less
`than unity; e.g., alternative hypotheses for the identity of an organism in MYCIN might be
`
`(d) IDENTITY
`(e) IDENTITY
`
`of ORGANISM-I
`of ORGANISM-I
`
`~PSEUDOMONAS (.8)
`~ E.COLI
`(.15),
`
`is probably Pseudomonas, or, alternatively, that
`indicating (d) the identity of ORGANISM-1
`Pseudomonas is important enough that i.t must be considered further, but (e) there is some evidence
`to believe it is E.coli.
`
`A useful way of thinking about CF's is to consider them as single numbers combining subjective
`probabilities and utilities. As such they represent the importance of the fact. Either it is highly
`In either case, the fact is important
`probable or its consequences carry high costs or benefits.
`enough to warrant further consideration.
`
`2 At first glance, the concept of a certainty measure associated with a belief or an i~ferential statement appears to be
`inherently probabilistic and, accordingly, amenable to analytical techniques such as Bayes' Theorem. The serious limitations
`of a mod~l based on conditional probabilities, however, have been discussed in detail il"! the paper that describes the CF model
`of inexact reasoning [Shortliffe 75).
`
`·-------·--------·
`
`eBay Inc. et al. Exhibit 1007 Page 10
`
`

`

`6
`
`Rules
`
`Introduction
`
`1
`
`The system reasons about a domain using knowledge encoded as production rules:
`if premise. then action (CF).
`Each rule has a premise, which Is a conjunction of predicates over the fact triples In the knowledge
`base. Rules also have a CF, reflecting the degree to which the preml~ facts Imply the action facts. If
`the premise is true, the conclusion In the action part of the rule is drawn, updating one or more fact
`triples in the knowledge base. The strength of the conclusion is modified .using the CF's of the fact
`·
`triples in the premise and the CF of the rule.
`
`Figure 1·2 shows a typical rule from the domain of structural analysis (SACON). The English
`version of the rule is shown first; this is the form in which the user of the consultation program sees
`the rule. The second version is the internal Usp form manipulated by the pro~ram; the English
`version can be generated from the Usp form on demand. The predicates, e.g., LESSP•,
`GREATERP•, SAME, are simple Usp functions operating on fact triples and returning CF's as results.·
`Conjunction of the facts in the premise clauses is accomplished by the Usp function $AND, the
`multivalued analogue of the Boolean AND function. It performs a minimization operation on CF's, and
`passes the resulting certainty measure to the action portion of the rule.
`
`RULE068
`
`If: 1) The material composing the sub-structure is one of
`the metals,
`2) The analysis error (in percent) that is tolerable is
`less than 5,
`3) The non-dimensional stress of the sub-structure is
`greater than .5, and
`4) The number of cycles the loading is to be applied is
`greater than 10000
`Then: Fatigue is one of the st.ress behavior phenomena in the
`sub-structure.
`
`PREMISE:
`
`ACTION:
`
`(SAND (SAME CNTXT COMPOSITION (LISTOF METALS))
`(LESSP• (VALl CNTXT ERROR)
`5)
`(GREATERP• (VALl CNTXT NO-STRESS)
`.5)
`(GREATERP• (VALl CNTXT CYCLES)
`10000))
`(CONCLUDE CNTXT 55-STRESS FATIGUE TALLY 1000)
`
`Figure 1·2: A sample rule from the domain of structural analysis
`
`At any given time during a consultation, EMYCIN is working toward the goal of establishing the
`value of some parameter of a context; this operation is termed tracing the parameter. To this ~nd, the
`system retrieves the (precomputed) list of rules whose conclusions bear on the goal. SACON's
`RULE068 (Figure 1·2), for example, would be one of the rules retrieved in the attempt .to determine the
`stress of a substructure. Then for each rule in the list, EMYCIN evaluates the premise; if true, it makes
`
`eBay Inc. et al. Exhibit 1007 Page 11
`
`

`

`. '
`
`1
`
`Introduction
`
`7
`
`the conclusion indicated in the action.
`
`In the course of evaluating the premise of one of these rules, some clause might not yet be known,
`In this case,
`i.e., the context/parameter pair tested In the clause may not yet have been traced.
`EMYCIN suspends interpretation of the rule while it sutisfies the subgoal of finding out the unknown
`parameter; this may in turn cause other rules to be invoked. Thus, the rules are said to "chain
`backward" from the top-level goal to the low·level data; it is the attempt to achieve each goal that
`drives the consultation. The whole process ·begins by tracing the top·level "goal" parameter,
`generally the desired "result" of a consultation (e.g., a di!!gnosis or recommendation).
`
`The order of the rules in the list is assumed to be arbitrary, and all the rules are applied unless one
`of them succeeds and concludes the value of the parameter with certainty (in which cas~ the
`remaining rules are superfluous). The order of application of r~;~les is .determined by (a} the logical
`structure of the chains of rules and (b) the tree of objects described in the context tree. See the
`section 4.2 for the exceptions to this description of rule interpretation.
`
`Questions are asked during the consultation when the rules fail to deduce the necessary
`If the client cannot. supply the requested
`information (or there are no rules at all to conclude it).
`information, it remains unknown, and rules that require it will fail.
`
`This control structure tends to ask only "relevant" questions. Questions are asked only if the
`information (the value of the parameter) is needed by some rule under consideration, and the rules
`are tried only because they are relevant to some goal the system is trying to achieve. Thus, the
`questions asked, and the order in which they are asked, may vary from case to case; this contrasts
`with other kinds of consultation programs that have a pre-specified set of questions that are ~lways
`asked for all cases.
`
`This control structure permits the graceful handling of incomplete information. If the user is unable
`to supply some piece of data, the rules that need the data will fail and make no conclusion. The
`system will thus make conclusions, if possible, based on less information. Similarly, if the system has
`inadequate rules (or none at all) for concluding some parameter, it may ask the user for the value.
`When too many items of information are missing, of course, the system will be unable to offer sound
`advice.
`
`There are many advantages to having rules as the primary representation of knowledge. Since
`each rule is intended to be a single "chunk" of information, the knowledge base is inherently
`Individual rules can be added, deleted or modifi~d
`modular, making it relatively easy to update.
`without drastically affecting the overall performance of the system. The rules are also a convenient
`unit for explanation purposes, as a single step in the reasoning process can be 'meaningfully
`explained by citing the English translation of the rule used.
`
`Applications
`
`Several consultation systems have been written using EMYCIN. The original MYCIN program and
`the SACON system have already been described. MYCIN is now implemented in EMYCIN, but its
`knowledge base was largely constructed before EMYCIN was developed as a separate system.
`
`eBay Inc. et al. Exhibit 1007 Page 12
`
`

`

`8
`
`Introduction
`
`1
`
`ResultS of formal evaluations ·of MYCIN's competence in the domains of bacteremia (bacterial
`infections in the blood) [Yu 79] and meningitis [Yu2 79] indicate that MYCIN's performance in these
`areas has begun to approach that of medical specialists.
`
`The PUFF program [Kunz 78] performs Interpretation of measurements from a pulmonary fun~tion
`laboratory. PUFF's knowledge base was constructed using an early version of EMYCIN; the system
`designers were Stanford computer scientists who had previous experience with MYCIN, collaborating
`with a pulmonary physiologist and biomedi.cal engineers. The data from over 100 cases were used to
`create some 60 rules diagnosing the·presence of pulmonary disease. The rules are used to create a
`complete report including the input measurements, other patient data, and the measurement
`interpretation.
`
`The PUFF rule set was expanded and converted into a Basic program to run on a PDP·11 at Pacific
`Medical Center in San Francisco •. ln this form, PUFF Is the only EMYCIN system being used routinely
`for other than experimental purposes.
`Its reports are reviewed by a staff physician before being
`entered into a patient's record; most reports (95%) are accepted without change.
`
`The HEADMEO program [Heiser 78] is an application of EMYCIN to clinical psychoph~rmacology.
`The system diagnoses a range of psychiatric disorders and recommends drug treatment when
`indicated.
`
`CLOT [Bennett 80] is an experimental system dealing with the diagnosis of disorders of the bloc~
`coagulation system. Such diagnoses, once the system was completed, could be used by a physician
`to estimate. the severity and cause of a particular episode of bleeding, to evaluate the effects of
`various anti·coagulation therapi~s on a patient, and to estimate the pre-operative risk of a patient
`having serious bleeding problems during surgery.
`
`Several additional consultants have been constructed using EMYCIN, notably GRAVIDA, a
`consultant to assist a physician during a patient's pregnancy, LITHO, a ~onsultant that interprets the
`that gives advice on computer
`geology surrounding an oil well, and DART, a system
`telecommunication system failures [Bennett 81 ].
`
`Range of Applicability
`
`EMYCIN is designed to provide consultative advice. The system takes as Input a body of
`measurements or other information pertinent to a case, and produces as output some form of
`recommendation or analysis of the case. The framework seems well suited for some deductive
`problems, notably .some classes of fault diagnosis, where a large body of input measurements
`(symptoms, laboratory tests) is available and the solution space of possible diagnoses can be
`It is less well suited for "formation" problems, where the task is to piece together
`enumerated.
`existing structures according to specified constraints to generate a solution.
`
`It is thus wholly
`EMYCIN was not designed to be a general-purpose representation language.
`unsuited for some problems. The limitations derive largely from the fact that EMYCIN has chosen one
`basic, readily understood representation for the knowledge in a domain: production rules applied by
`a backward-chaining control structure, with facts about the case represented as associative triples.
`
`eBay Inc. et al. Exhibit 1007 Page 13
`
`

`

`, ' J
`
`1
`
`Introduction
`
`9
`
`While the rule representation is quite general, this choice of control structure is unsuitable for
`problems of constraint satisfaction, or those requiring iterative techniques.3 Among other classes of
`problems that EMYCIN does not attempt to handle are simulation tasks, and tasks involving planning
`with stepwise refinement.
`
`Facilities and Features of EMYCIN
`
`The remainder of this chapter describes several of the important features that the EMYCIN system
`provides. EMYCIN is best viewed as a collection of- several systems, each of which deals with
`different aspects of the construction, maintenance, and use of a knowledge base. There are editors
`for each type of knowledge base component, numerous debugging aids, ar:'d facilities for creating
`and using case libraries for a domain. All of these features are available through a convenient
`executive (see section 6.2).
`
`Explanation Capabilities
`
`EMYCIN's explanation program allows the user of a consultation program to interrogate the
`system's knowledge, either to find out about inferences made (or not made) during a particular
`consultation or to examine the static knowledge base in general, independent of any specific
`consultation.
`
`During the consultation, EMYCIN can offer explanations of the current, past, and likely future lines
`of reasoning. If the motivation for any of EMYCIN's questions is unclear, the client may temporarily
`put off answering and instead inquire why the information is needed. Since each question is asked in
`an attempt to evaluate some rule, a first approximation at an answer is simply to display the rule
`currently under consideration. The program can also explain what reasoning led to the current point,
`and what use might later be made of the information being requested. This is made possible by
`examining records left by the rule interpreter, and by inspecting the rules in the knowledge base to
`determine which are relevant. This form of explanation requires no sophisticated language
`understanding by the program; it is invoked by simple commands from the client ("WHY" and "HOW"
`as described in [Davis 76] and section 7.2).
`
`Another form of explanation is available through the Question Answering (QA) Module, which is
`automatically invoked after the consultation has ended, and which can also be entered dur.in~rthe
`consultation to answer questions other than those handled by the specialized WHY /HOW commands
`described above. The QA Module aqcepts simple English-language questions dealing with ar'ly
`conclusion drawn during the consultation and about the domain in general. Explanations are again
`based on the rules; they should be comprehensible to anyone familiar with the domain, even if not
`familiar with the intricacies of the EMYCIN system. The questions are parsed by pattern matching and
`keyword lookup, using a dictionary that defines the vocabulary of the domain. EMYCIN automatically
`constructs the dictionary from the English phrases used in defining the contexts and parameters of
`the domain; the system designer may refine this preliminary dictionary to add synonyms or better tune
`
`I
`
`3w.th a different control mechanism, production rules are quite capable of iterative use. The VM program [Fagari 79], for
`example, deals with the management of patients receiving assisted ventilation after cardiac surgery.
`·
`
`eBay Inc. et al. Exhibit 1007 Page 14
`
`

`

`10
`
`Introduction
`
`1
`
`QA's parsing~ The QA module is described in much more detail.in [Scott 77] and section 7.4. ·
`
`Knowledge Acquisition
`
`The system designer's principal task is entering and deb&,~gging the production ruleS and the fact
`triples in the knowledge base. EMYCIN provides a terse stylized, but easily understood, language for
`writing rules and several high-level knowledge base editors for each of the additional knowledge
`structures in the system. These editors perform extensive checks to catch common input errors, such
`as misspellings, and handle all necessary bookkeeping chores. These facilities allow the system
`builder to quickly try out new ideas and therebY. assess the feasibility of any particular formulation of
`the domain knowledge into rules.
`
`The Abbreviated Rule Language (ARL; see section 4.5) constitutes an intermediate form between
`English and pure Lisp. ARL is a simplified Algol-like language that uses the names .of the parameters
`and their values as operands; the operators correspond to EMYCIN predicate and action functions.
`For example, SACON's Rule 68 (Figure 1·2) could have been entflred or printed as:
`
`If Composition • (LISTOF METALS) and
`Error < 5 and
`Nd-stress > .5 and
`Cycles > 10000
`Then Ss-stress • fatigue
`
`Figure 1·3: Example of ARL format for rule lnpuVoutput.
`
`ARL is a shorthand form derived from ad hoc notations that we have seen several of our domain(cid:173)
`experts use to sketch out sets of rules. The parameter names are simply the labels that the expert
`uses in defining the parameters of the domain. Because of its conciseness, entering rules in ARL is
`much easier than entering them in either English or Lisp, an important consideration when entering a
`large number of rules.
`
`As each rule is entered or edited, it is checked ·for syntactic validity to catch common input errors.
`By "syntactic" we mean issues of rule form-that terms are spelled correctly, values are legal for the
`parameters with which they are associated, etc.-rather than the actual Information (semantic)
`· . content (i.e., whether the rule "makes sense"). Performing the syntactic checks at acquisition time
`reduces the likelihood that the consultation program will fail due to "obvious" errors. This permits the
`expert to concentrate on debugging logical errors and omifiSions.
`
`The purely syntactic checks are made by comparing each rule clause with an internal "function
`tei'TlfJiate" corresponding to the predicate or action function used in the clause. Using this template,
`EMYCIN determines whether the arguments to these functions are correqtly filled. For example, each
`argument requiring a parameter must be filled by a valid parameter of some context, and any
`argumen~ requiring a value must be a legal value for that parameter.
`If an unknown parameter is
`found, the checker tries to correct it w