In this paper we will be concerned with such reasoning in its most general form, that is, in inferences that are defeasible: given more information, we may retract them. The purpose of this paper is to introduce a form of non-monotonic inference based on the notion of a partial model of the world. We take partial models to reflect our partial knowledge of the true state of affairs. We then define non-monotonic inference as the process of filling in unknown parts of the model with conjectures: statements that could turn out to be false, given more complete knowledge. To take a standard example from default reasoning: since most birds can fly, if Tweety is a bird it is reasonable to assume that she can fly, at least in the absence of any information to the contrary. We thus have some justification for filling in our partial picture of the world with this conjecture. If our knowledge includes the fact that Tweety is an ostrich, then no such justification exists, and the conjecture must be retracted.

Diane Warner Hasling Heuristic Programming Project Computer Science Department Stanford University Stanford, CA 94305 stra:cgre explanation we want to generate.

ABSTReCT The research activities of the Heuristic Programming Project, for the four-year period ending July 31, 1977, are summarized in this report. Contributions to Knowledge Engineering research in the fields of knowledge acquisition (both interactive and automated), knowledge representation and knowledge utilization were reported in over thirty publications by members of the project. A summary of those publications is?resented here. The Al Handbook, an encyclopedic reference to the field of::tificial Intelligence, is described in the appendix, along with the excecteç table of contents and sample articles.

ABSTRACT A computer program that models an expert in a given domain is more likek to be accepted by experts in that domain, and by non-experts seeking its gavice. An explanation capability not only adds to the system's credibility, but also enables the non-expert user to learn from it. Furthermore, clear explanations allow an expert to check the system's "reasoning", possibly discovering the need for refinements and additions to the svstem's knowledge base. In a developing system, an explanation capability can be used as a debugging aid to verify that additions to the system are working as'hey should. The explanation facility in MYCIN is discussed as an illustration of how the various problems might be approached.

Examining the refinement structure created by the automatic programmer makes possible justifications of the code. This chapter describes XP LAIN and outlines additional advantages this approach has for explanation. The significance of Swartout's work is not just its use of a s_vstem design technique that makes explanation possible. His work reveals how principles (here, domain strategies by which specific treatment methods are apphed) are part of explanation. It is useful to supply not just an "audit trail" of what a problem solver did (on perhaps

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.

In describing MYCIN's design considerations in Chapter 3, we pointed out that an ability of the program to explain its reasoning and defend its advice was an early major performance goal. It would be misleading, however, to suggest that explanation was a primary focus in the original conception. As was true for many elements of the system, the concept of system transparency evolved gradually during the early years. In reflecting on that period, we now find it impossible to recall exactly when the idea was first articulated. The SCHOLAR program (Carbonell, 1970a) was our working model of an interactive system, and we were trying to develop ways to use that model for both training and consultation.

An answer set is a plain set of literals which has no further structure that would explain why certain literals are part of it and why others are not. We show how argumentation theory can help to explain why a literal is or is not contained in a given answer set by defining two justification methods, both of which make use of the correspondence between answer sets of a logic program and stable extensions of the Assumption-Based Argumentation (ABA) framework constructed from the same logic program. Attack Trees justify a literal in argumentation-theoretic terms, i.e. using arguments and attacks between them, whereas ABA-Based Answer Set Justifications express the same justification structure in logic programming terms, that is using literals and their relationships. Interestingly, an ABA-Based Answer Set Justification corresponds to an admissible fragment of the answer set in question, and an Attack Tree corresponds to an admissible fragment of the stable extension corresponding to this answer set.

This paper discusses how AI models of argumentation can play a role in personalized and participatory medicine. It describes our previous research on natural language generation of argumentation for genetic counseling and a pilot study on risk visualization, and our current research on argumentation mining.

We propose and investigate a simple ranking-measure-based extension semantics for abstract argumentation frameworks based on their generic instantiation by default knowledge bases and the ranking construction semantics for default reasoning. In this context, we consider the path from structured to logical to shallow semantic instantiations. The resulting well-justified JZ-extension semantics diverges from more traditional approaches.