Performance Level D-RULE578 IF: 1) The infection which requires therapy is meningitis, and 2) Organisms were not seen on the stain of the culture, and 3) The type of the infection is bacterial, and 4) The patient has been seriously burned THEN: There is suggestiv evidence (.5) that pseudomonas-aeruginosa is one of the organisms (other than those seen on cultures or smears) which might be causing the infection UPDATES: COVERFOR USES: (TREATINF ORGSEEN TYPE BURNED) Support Level MECHANISM-FRAME: BODY-INFRACTION.WOUNDS JUSTIFICATION: "For a very brief period of time after a severe burn the surface of the wound is sterile. Shortly thereafter, the area becomes colonized by a mixed flora in which gram-positive organisms predominate. By the 3rd post-burn day this bacterial population becomes dominated by gram-negative organisms. By the 5th day these organisms have invaded tissue well beneath the surface of the burn. The organisms most commonly isolated from burn patients are Pseudomonas, Klebsiella-Enterobacter, Staph., etc. Infection with Pseudomonas is frequently fatal." LITERATURE: MacMillan BG: Ecology of Bacteria Colonizing the Burned Patient Given Topical and System Gentamicin Therapy: a five-year study, J Infect Dis 124:278-286, 1971.

We have so far described MYCIN largely in terms of its knowledge base and inference mechanism, and specifically in terms of rules and a rule interpreter that allow high-performance problem solving. In Chapters 27 through 29 we describe additional knowledge structures that increase the flexibility and transparency of' MYCIN's knowledge base. We refer to many of these as meta-level knowledge. When we speak of meta-level knowledge we mean nothing more than knowledge about knowledge. In a computer program it needs to be represented and interpreted in order to be useful, but the main idea is that it can be an explicit, and flexible, element of expertise. For example, metalevel knowledge can help in modifying an existing rule and in integrating the modification into the whole rule set because it provides additional information about the existing rules to the editor. The ideas for using meta-level knowledge in MYCIN grew out of several projects that Randy Davis was working on in the mid-1970s.

CENTAUR was designed in response to problems that occurred while using a purely rule-based system. The CENTAUR system offers an appropriate environment in which to experiment with knowledge representation issues such as determining what knowledge is most easily represented in rules and what is most easily represented in frames. In summary, much research remains to be done on this and associated knowledge representation issues. This present research is one attempt to make explicit the art of choosing the knowledge representation in AI by drawing comparisons between various approaches and by identifying the reasons for selecting one fundamental approach over another.

FIGURE 22-2 Summary of conclusions drawn by VM based on four hours of patient data. Current and optimal patient therapy stages are represented by their first letter: V -- VOLUME, A ASSIST, C controlled mandatory ventilation,/ changing. A double bar () is printed for each ten-minute interval in which the conclusion on the left is made.

We have found that the feature is therefbre seldom used. It would, of course, be preferable if the system "knew" on its own when such a summary is appropriate.

Representing knowledge in an AI program means choosing a set of conventions tor describing objects, relations, and processes in the world. One first chooses a conceptual framework for thinking about the world--symbolically or numerically, statically or dynamically, centered around objects or around processes, and so forth. Then one needs to choose conventions within a given computer language tor implementing the concepts. The former is difficult and important; the latter is both less difficult and less important because good programmers can find ways of working with almost any concept within almost any programming language. In one respect finding a representation for knowledge is like choosing a set of data structures for a program to work with.

A computer program that models an expert in a given domain is more likely to be accepted by experts in that domain, and by nonexperts seeking its advice, if the system can explain its actions. This chapter discusses the general characteristics of explanation capabilities for rule-based systems: what types of explanations they should be able to give, what types of knowledge they will need in order to give these explanations, and how this knowledge might be organized (Figure 18-1). The explanation facility in MYCIN is discussed to illustrate how the various problems can be approached. A consultative rule-based system need not be a psychological model, imitating a human's reasoning process. The important point is that the system and a human expert use the same (or similar) knowledge about the domain to arrive at the same (or similar) answers to a given problem. The system's knowledge base contains the domain-specific knowledge of' an expert as well as facts about a particular problem under consideration. When a rule is used, its actions make changes to the internal data base, which contains the system's decisions or deductions. The process of trying rules and taking actions can be compared to reasoning, and explanations require displays of how the rules use the information provided by the user to make various intermediate deductions and finally to arrive at the answer. If the information contained in these rules adequately shows why an action was taken (without getting into programming details), an explanation can simply entail printing each rule or its free-text translation. This chapter is a revised version of a paper originally appearing in American Journal of Computational Linguistics, Microfiche 62, 1977. The three components of a rule-based system (a rule interpreter, a set of production rules, and a data base) are augmented by an explanation capability. The data base is made up of general facts about the system's domain of expertise, facts that the user enters about a specific problem, and deductions made about the problem by the system's rules. These deductions form the basis of the system's consultative advice. The explanation capability makes use of the system's knowledge base to give the user explanations. This knowledge base is made up of static domain-specific knowledge (both factual and judgmental) and dynamic knowledge specific to a particular problem. Pertbrmance Characteristics of an Explanation Capability The purpose of an explanation capability (EC) is to give the user access as much of the system's knowledge as possible. Ideally, it should be easy for a user to get a complete, understandable answer to any sort of question about the system's knowledge and operation--both in general terms and 340 Methods for Generating Explanations with reference to a particular consultation.

The development of expert systems is plagued with a well-known and crucial bottleneck: in order for these systems to perform at all the domainspecific knowledge must be engineered into a form that can be embedded in the program. To this end the purpose and structure of two quite dissimilar rule-based systems are reviewed. Both systems were constructed using the EMYCIN system after interviewing an expert. The first, SACON (Bennett et al., 1978), meant to assist an engineer in selecting a method to perform a structural analysis; the second, CLOT (Bennett and Goldman, 1980), is meant assist a physician in determining the presence of a blood clotting disorder. The presentation of the details of these two systems is meant to accomplish two functions. The first is to provide an indication of the scope and content of these rule-based systems. The reader need not have any knowledge of the specific application domain; the chapter will present the major steps and types of inferences drawn by these consultants. This conceptual framework, what we term the inference structure, forms the basis for the expert's organization of the domain expertise and, hence, the basis for successful acquisition of the knowledge base and its continued maintenance. The second purpose of this chapter is to indicate the general form and function of these inference structures.

FIGURE 15-1 The major roles of EMYCIN: acquiring a knowledge base from the system designer, and interpreting that knowledge base to provide advice to a client.

One of the reasons for undertaking the original MYCIN experiment was to test the hypothesis that domain-specific knowledge could successfully be kept separate from the inference procedures. We felt we had done just that in the original implementation; specifically, we believed that knowledge of a new domain, when encoded in rules, could be substituted for MYCIN's knowledge of infectious diseases and that no changes to the inference procedures were required to produce MYCIN-like consultations. In the fall of 1974 Bill van Melle began to investigate our claim seriously. He wrote (van Melle, 1974): The MYCIN program for infectious disease diagnosis claims to be general. One ought to be able to take out the clinical knowledge and plug in knowledge about some other domain.