W. Swartout, C. Paris, and J. Moore. Design for explainable expert systems. IEEE Expert, 6(3):58--647, 1991.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....match[4] As the complexity of the monitored information and the number of valid triggering conditions grows, it is necessary to be able to explain either why or why not active mediation rules match. Though there have been attempts to endow intelligent systems with explanatory capabilities[12] 10][11], little has been done to guarantee that explanations are complete and correct. This paper defines a mechanism for providing complete and correct explanation of positive, negative, and conditional instance membership in class nodes of an Inference Hierarchy, and then applies this mechanism toward ....

....why it has the status it does. Alternatively there would be a way to let users request explanations for why an airport did not have a particular status. 7 Comparison to Previous Work As stated previously, there have been attempts to endow intelligent system with explanatory capabilities[12] 10][11]. Although such systems demonstrated the usefulness of explanation, there was little in the way of formal justification of the 18 That is which classes in the action inference hierarchy it is a member of. 10 WEATHER RPT(1, 10 km hour, 76 F, 0 rain) MAINTENANCE RPT(1, 0 planes) WEATHER RPT(3, ....

W. Swartout, C. Paris, and J. Moore. Design for explainable expert systems. IEEE Expert, 6(3):58--64, 1991.

....logic. Each goal is translated into a description, and matching relies on the reasoning performed by a classifier to determine which rules unify with the posted goal. Our work stems from the EXPECT project [ Swartout and Gil, 1995; Gil, 1994; Gil and Melz, 1996 ] and its predecessor system EES [ Swartout , 1991 ] an architecture for developing knowledge based systems that is tightly coupled with LOOM [ MacGregor, 1988; 1991 ] a description logic system. EXPECT represents domain objects and classes in LOOM, as well as the goals of the methods to manipulate those objects. We have also extended the ....

W. R. Swartout, C. L. Paris, and J. D. Moore. Design for explainable expert systems. 6(3):58--64, 1991.

....types of explanations, and in this paper we presented an outline for explanation generation by means of FBRL models. As FBRL can represent various concepts of function and behavior, it enables model based expert systems to generate explanations with appropriate functional terms. W. Swartout et al. [14] and T.R.Gruber et al. 5] show some techniques to explain the system s action and the knowledge which the system possesses. It goes without saying that a domain model plays an important role in each of the frameworks, however, discussion about what information should be included in the model and ....

W. Swartout, C. Paris, and J. Moore. Design for explainable expert systems. IEEE Expert, pp. 58--64, June 1991.

....problems and shortcomings, and also later systems through to state of the art. It concludes with a presentation of outstanding research issues. Explainable Expert Systems: This is a framework for building expert systems capable of explaining their reasoning as well as their domain knowledge [SPM92] Intelligent User Interfaces: One of the rst discussions on general features of intelligent interfaces was that provided by Rissland [Ris84] A workshop was held at Monterey, California in 1988 on Architectures for Intelligent Interfaces: Elements and Prototypes and a subset of the papers ....

W R Swartout, C L Paris, and J D Moore. Design for explainable expert systems. IEEE Expert, 6(3):58-64, 1992.

....explanations (Moore, 1994, p.31) Specifically, simply paraphrasing the chain of reasoning of the expert system does not let a human user easily understand that reasoning. Two separate approaches have been proposed to address this problem: ffl In the Explainable Expert System (EES) approach (Swartout et al. 1991; Swartout and Moore, 1993) the knowledge representation used by the expert system is enriched to include explicit strategic knowledge, i.e. knowledge about how to reason, and domain specific knowledge. From this knowledge, the rules used by the expert system are compiled, and this knowledge ....

....not for reasoning. RDK and CDK of course overlap, but they are not identical. This is in fact the lesson from much previous work in expert system explanation, for example the work of Paris et al. 1988) contrasting the line of reasoning and the line of explanation , and the claim of Swartout et al. 1991) that the domain representation must be augmented with additional knowledge about the domain and about reasoning in the domain. CDK is different from DCK in that CDK is knowledge about the domain as it is needed for communication, but DCK is knowledge about how to communicate in that domain, and ....

Swartout, W., Paris, C., and Moore, J. (1991). Design for explainable expert systems. IEEE Expert, 6(3):59--64.

....derivation and rationale information. The conceptual model underlying the design of the knowledge system is not present in the rules and frames. It is now well accepted that working directly at the symbol level makes it hard to verify, reuse, maintain, and explain the knowledge in the system [6 10] . Progress in knowledge acquisition depends on the development of high level representations and problemsolving methods that provide the appropriate building blocks for modeling. To shed some light on the general problem of modeling in knowledge systems, we will describe the problem of model ....

Swartout, W., C. Paris and J. Moore. Design for explainable expert systems. IEEE Expert . 6, 58 - 64, 1991.

....are designed primarily for describing behavior for engineering analysis. Textual annotations used for explanation are optional and have no behavioral semantics. Integrating model formulation and explanation in DME is analogous to the approach used in the Explainable Expert System project [22]. In EES, the developer gives high level specifications of a knowledge system, and the low level code is synthesized. Then, the answers produced by the compiled knowledge system can be explained in terms of the original specifications. In DME, the model builder gives high level descriptions of a ....

W. Swartout, C. Paris, & J. Moore. Design for explainable expert systems. IEEE Expert, 6(3):58 - 64, June 1991.

....a goal to estimate the support personnel in a location with no seaports. This approach provides us with a rich language for specifying behaviors. The case grammar formalism makes it relatively straightforward to paraphrase the goals into natural language, helping to make them more understandable (Swartout, Paris, Moore 1991). An important aspect of the systems we have implemented that use this expressive representation is how they reason with it, exploiting subsumption and reformulation as we describe next. Further details can be found in (Swartout Gil 1995; Gil Melz 1996) Capabilities are translated into Loom ....

Swartout, W. R.; Paris, C. L.; and Moore, J. D. 1991. Design for explainable expert systems. IEEE Expert 6(3):58--64.

....the components of the explanation effect the user s belief in the conclusion, and it is only able to explain relatively simple causal chains. Other important work on explanation focuses on issues other than eliminating insignificant information. Both NEOMYCIN [Clancey and Letsinger, 1981] and EES [Swartout et al. 1991] deal with the issue of explaining particular domain knowledge by showing how it is derived from general domainindependent principles. It could be interesting to combine these approaches with the one presented here, which focuses on selecting the specific domain knowledge to present rather than ....

William Swartout, Cecile Paris, and Johanna Moore. Design for explainable expert systems. IEEE Expert, 6(3):58--64, June 1991.

....make this information available to the explanation mediator and the explanation mediator maintains a model of query processing, consisting of concepts and classification rules, by which it interprets such information. This approach is similar to the Explanation Explainable Expert System (EES) [25] framework, though its model of query processing is built specifically to interpret CoBase operations, and work is focused on providing explanations any time during system execution. changed In addition, the representation, classification and generation formalism covers the complete explanation ....

W. Swartout, C. Paris, and J. Moore. Design for explainable expert systems. IEEE Expert, 6(3):58--64, June 1991.

....will result on a closed loop integration of plan generation and plan quality evaluation that will let the user guide a planner in finding the desired kind of solutions. 4 Current Status We are exploring this approach using O Plan [1, 6] as the plan generation system and the expect system [5, 2] as the knowledge based framework. The O Plan project has sought to identify modular components within an ai command, planning and control system and to provide clearly defined interfaces to these components and modules. The background to this work is provided in [ The various components plug ....

Swartout, W. R., Paris, C. L., and Moore, J. D. Design for explainable expert systems. IEEE Expert 6(3):58--64. 1991.

....to all that has occurred and may summarize actions and results. However in the absence of interpretation, these traces may not contain enough information to produce meaningful explanations. Execution traces only record what has occurred, not why. The Explainable Expert Systems (EES) framework[14] bases explanation on knowledge structures that capture the rationale behind system actions. This is achieved by integrating explanation at the expert system specification and design phase, insuring that rationale knowledge is compiled into the expert system. Additional advances in explanation ....

Swartout, William R., Paris, Cecile L., and Moore, Johanna D. Design For Explainable Expert Systems. IEEE Expert, Volume 6, Number 3, pages 58-64.

....the traces themselves are impoverished. Execution traces only record what has occurred, not why. A common problem with direct trace based attempts is that they lack a framework in which to interpret the contents of the trace prior to communication. The explainable expert systems (EES) framework[12] bases explanation on knowledge structures that capture the rationale behind system actions. This is achieved by integrating explanation at the expert system specification and design phase, insuring that rationale knowledge is compiled into the expert system. In EES terms, at design time a domain ....

....has been interest in integrating the strategic and tactical sides of natural language generation[6] Many of the tasks that a content planner and a surface realizer do are analogous. 1. 2 Comparisons To Previous Work The approach here is similar to the Explainable Expert System (EES) Framework[12], however its model of query processing is built specifically to interpret CoBase operations. In addition we have developed a representation, classification and generation formalism that describes the complete explanation generation task. This formalism provides a structured approach to ....

Swartout, William R., Paris, Cecile L., and Moore, Johanna D. Design For Explainable Expert Systems. IEEE Expert, Volume 6, Number 3, pages 58-64.

....goal of the expect project of the Information Sciences Institute of the University of Southern California is to provide an environment for the development of knowledge based systems that aids in the acquisition, maintenance, and documentation of the knowledge about a task. The expect architecture [9, 10, 11] is being applied to producing staff estimates for tentative courses of action to produce briefings for a commander. To date, we have a prototype system that takes an assessment of the situation and evaluates relevant factors for the alternative courses of action from the logistics perspective. ....

Swartout, W. R., Paris, C. L., and Moore, J. D. Design for explainable expert systems. IEEE Expert 6(3):58--64. 1991.

....are several reasons for this choice: ffl LOOM is a well established knowledge representation tool that has been widely used in the Artificial Intelligence community. It has, for example, been used in the Penman Text Generation Project (Mann, 1985) the FAST project (Neches, 1988) the EES project (Swartout et al. 1991), the EXPECT project (Paris and Gil, 1993) and the ALFRESCO system (Carenini et al. 1993) ffl It is actively supported not only by its developers, but also by the researchers who use it. Communication between these researchers is facilitated by LOOM Forum, a mailing list to which questions, ....

Swartout, W. R., Paris, C. L., and Moore, J. D. (1991). Design for Explainable Expert Systems. IEEE Expert, 6(3):58--64.

....plan feasibility estimators. A version of this domain is available upon request in a fictitious but realistic scenario called PRECiS, and is described in detail in [4, 3] 4 Current Status We are exploring this approach using O Plan [1, 6] as the plan generation system and the expect system [5, 2] as the knowledge based framework. The O Plan Project is exploring a practical computer based environment to provide for specification, generation, interaction with, and execution of activity plans. O Plan is intended to be a domain independent general planning and control framework with the ....

Swartout, W. R., Paris, C. L., and Moore, J. D. Design for explainable expert systems. IEEE Expert 6(3):58--64. 1991.

....application state graphically in accordance with familiar, intuitive metaphors. Yet in many instances we wish to grant systems broader, more complex responsibilities. Simple communication techniques are insufficient in these cases. If required, such systems must be able to explain themselves [7][11][10] 6] One area in which explanation technology is required is in Cooperative Information Systems[5] Traditionally database systems accept precise query specification (SQL, Datalog, etc. and return exact answer sets. In Cooperative Information Systems people pose imprecise queries and receive ....

Swartout, William R., Paris, Cecile L., and Moore, Johanna D. Design For Explainable Expert Systems. IEEE Expert, Volume 6, Number 3, pages 58-64.

....easier to describe. Additionally, we have to define (c) the semantics of the inference steps. 4 Both types of semantics must be terminologically described to serve as a basis for an explanation. It is difficult to describe terminologically how an inference step proceeds. In EES [Swartout, 1983, Swartout et al. 1991] inferences are broken down into primitives using domain principles in the specification process. Consequently, at the lowest level it must be verbalised and thus appropriately represented. Sprenger [1991] explains knowledge sources by naming them and verbalising the entries of the according ....

....and the programmers. 3 See the discussion on plurals and the referent field in the CG mailing list in spring 1994. 4 What is missing at this point is the integration of a development history, that can serve as a source of knowledge relevant for explanation, as in the EES approach [Swartout, 1983, Swartout et al. 1991] Librarians, like the KADS consortium partners, assume having a library of well defined inference layer models 5 , for different kinds of problems. It is the advantage of this view that a knowledge engineer only has to do two things: to choose an inference layer and to model the domain layer. ....

Swartout, W.R., Paris, C.L. and Moore, J.D. (1991) Design for Explainable Expert Systems.

....based systems so that they will be structured in a way that provides better support for knowledge acquisition and explanation. It is then possible to build tools that exploit this additional information to provide enhanced capabilities. In prior work on the EES framework [Neches et al., 1985; Swartout et al. 1991] we explored the architectural modifications that are needed to support explanation. EXPECT extends the EES framework to support knowledge acquisition. In this paper, we discuss the architectural features that support knowledge acquisition. There are several knowledge acquisition capabilities ....

....their failure to provide good explanations, these architectural flaws create problems for acquisition as well. A number of second generation expert system frameworks have emerged in recent years (see [Chandrasekaran, 1986; Clancey, 1983a; Hasling et al. 1984; Neches et al., 1985; Swartout, 1983; Swartout et al. 1991; Wielinga and Breuker, 1986] A common theme among these frameworks is that they encourage a more abstract representation of domain knowledge and problem solving knowledge that makes distinctions between different kinds of knowledge explicit. By moving toward architectures that allow a system ....

William R. Swartout, Cecile L. Paris, and Johanna D. Moore. Design for explainable expert systems. IEEE Expert, 6(3):58-64, June 1991

....Several improvements are then possible. On the one hand, a deep domain model would bring supported rationales for both the relation between motivations and driving styles and the reasoning performed by the system. On the other hand, making design knowledge explicit [Tanner Keuneke, 91; Swartout et al. 91] would shed light on the nature of the relations between planning (domain) knowledge, and recognition knowledge. Both improvements would have a direct impact on the articulateness and quality of explanations. In addition to improving explanations, several interesting problems can be the object ....

Swartout W.R., Paris C., and Moore J., "Design for Explainable Expert Systems", IEEE Expert, June 1991, pp. 58-63.

....to estimate the support personnel in a location with no seaports. This approach provides us with a rich language for specifying behaviors. The use of a case grammar formalism makes it relatively straightforward to paraphrase the goals into natural language helping to make them more understandable [Swartout et al. 1991]. Capability descriptions for methods are specified in a similar way, except that variables may appear in the capability descriptions. These are bound when the capability descriptions are matched with goals. Figure 2 shows an example of a method and its capability. As we just showed, EXPECT s ....

Swartout, W. R., Paris, C. L., and Moore, J. D. "Design for Explainable Expert Systems". IEEE Expert 6(3):58-64, 1991.

....based systems so that they will be structured in a way that provides better support for knowledge acquisition and explanation. It is then possible to build tools that exploit this additional information to provide enhanced capabilities. In prior work on the EES framework [Neches et al., 1985; Swartout et al. 1991] we explored the architectural modifications that are needed to support explanation. EXPECT extends the EES framework to support knowledge acquisition. In this paper, we discuss the architectural features that support knowledge acquisition. It is interesting to note that some of the features that ....

....as inverse processes, and these architectural flaws create problems for both. A number of second generation expert system frameworks that support better explanations have emerged in recent years (see [Chandrasekaran, 1986; Clancey, 1983a; Hasling et al. 1984; Neches et al., 1985; Swartout, 1983; Swartout et al. 1991; Wielinga and Breuker, 1986] A common theme among these frameworks is that they encourage a more abstract representation of domain knowledge and problem solving knowledge that makes distinctions between different kinds of knowledge explicit. By moving toward architectures that allow a system ....

[Article contains additional citation context not shown here]

William R. Swartout, Cecile L. Paris, and Johanna D. Moore. Design for explainable expert systems. IEEE Expert, 6(3):58-64, June 1991

No context found.

W. Swartout, C. Paris, and J. Moore. Design for explainable expert systems. IEEE Expert, 6(3):58--647, 1991.

No context found.

W. Swartout, C. Paris, and J. Moore. Design for explainable expert systems. IEEE Expert, 6(3):58--647, 1991.

No context found.

Swar91. Swartout, W.R.; Paris, C.; Moore, J. Design for Explainable Expert Systems. IEEE Expert, 6 (1991), 58-64.

No context found.

W.R. Swartout, C.L. Paris and J.D. Moore, Design for Explainable Expert Systems. IEEE Expert , June 91 (1991), 58-64.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC