Designing Expert Systems relate expert system research to that findings are abstracted into problem categories (they call them only "intermediate hypotheses") or that hypotheses are refined into subtypes (they say that hypotheses can be organized in a taxonomy, but give no examples). Most importantly, they miss the idea that expert systems often solve a sequence of problems by classification. Common examples are: making a diagnosis and then selecting a repair, characterizing a patient stereotypically and matching this to diseases, and modeling a user's needs and satisfying them (see (Clancey, 1984) for further discussion). Beyond this, Weiss and Kulikowski perpetuate the confusion that classification is a property of problems, rather than a problem solving method. Diagnosis is not inherently a "classification problem."

The application of Artificial Intelligence techniques to real-world problems has produced promising research results, but seldom has a system becoma a useful tool in its domain of expertise.

We have developed and partially Imp;zmented an "automated consultant" called SACON (Structural Analysis CONsultant), using the EMYCIN system as Its framework. SACON advises non expert engineers in the use of a large, general-purpose structural analysis program. The structure of the knowledge b,:se, including the major concepts used and Inferences drawn by the consultant, is presented. We conclude by making some observations 11 light of this application about the EMYCIN system as a representational vehicle and the process of acquiring knowledge for rule-based systems. Key words: knowledge-based systems, knowledge acquisition, knowledge representation, automated consultant, structural analysis, inference structure. This research was supported by the Defense Advanced Research Projects Agency (ARPA Order No. 2494 Contract No. DAHC15-73-C-0435) and the Air Force Flight Dynamics Laboratory. Reprinted from the Sixth International Joint Conference on Artificial Intelligence, Tokyo, Japan, August 1979. Used by permission of the International Joint Conference on Artificial Intelligence, Inc.; copies of the Proceedings are available from Morgan Kaufmann Publishers, Inc., 95 First Street, Los Altos, CA 94022, USA.

EMYCIN is a programming system for writing knowledge-based consultation programs with a production-rule representation of knowledge. Several major components of the system, Including an explanation program and knowledge acquisition routines, are described. EMYCIN has been used to build consultation systems in several areas of medicine, as well as an engineering domain. These experiences lead to some general conclusions regarding the potential applicability of EMYCIN to new domains. Keywords: knowledge-based systems, production rules, knowledge representation, automated consultant.

Working in the EMYCIN environment, they were delighted to find that they could more easily distill their criteria for test interpretation by using the production rule formalism.

In this book we have presented experimental evidence at many levels of detail for a diverse set of hypotheses. As indicated by the chapter and section headings, the major themes of the MYCIN work have many variations. In this final chapter we will try to summarize the most important results of the work presented. This recapitulation of the lessons learned should not be taken as a substitute for details in the sections themselves. We provide here an abstraction of the details, but hope it also constitutes a useful set of lessons on which others can build. The three main sections of this chapter will reiterate the main goals that provide the context for the experimental work; discuss the experimental results from each of the major parts of the book; and summarize the key questions we have been asked, or have asked ourselves, about the lessons we have learned. If we were to try to summarize in one word why MYCIN works as well as it does, that word would be flexibility.

This chapter describes an oncology protocol management system, named ONCOCIN after its domain of expertise (cancer therapy) and its historical debt to MYCIN. The program is actually a set of interrelated subsystems, the 1 primary ones being: 1. the Reasoner, a rule-based expert consultant that is the core of the system; and 2. the Interviewer, an interface program that controls a high-speed terminal and the interaction with the physicians using the system. The Interviewer is described in some detail in Chapter 32. This chapter describes the problem domain and the representation and control techniques used by the Reasoner. This chapter is based on an article originally appearing in Proceedings of the Seventh IJCAI, 1981, pp. Used by permission of" International Joint Conferences on Artificial Intelligence, Inc.; copies of the Proceedings are available from William Kaufmann, Inc., 95 First Street, l.os Ahos, CA 94022. Another program, the Intemctor, handles interprocess communication.

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.