File Information

File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/intro/90/c90-2062_intro.xml

Size: 15,010 bytes

Last Modified: 2025-10-06 14:04:53

<?xml version="1.0" standalone="yes"?>
<Paper uid="C90-2062">
  <Title>An Explanation Facility for a Grammar Writing System</Title>
  <Section position="2" start_page="0" end_page="0" type="intro">
    <SectionTitle>
~1. Introduction
</SectionTitle>
    <Paragraph position="0"> Explanation for expert systems has been studied very extensively, and has become a ~tandard feature in these systems. Its objectives are to enable users to understand how conclusions are reached, to be convinced t:hat these conclusions are reasonable, and to debug the knowledge base and possibly problem solving behavior as well. Viewed in a more general context, research into explanation is an essential component of the study into the symbiosis between man and machine, supported by the empirical fact that most knowledge-based systems are intended to assist human endeavor and are almost never intended to be autonomous agents.</Paragraph>
    <Paragraph position="1"> Grammar writing systems (GWS) used in Natural Language Processing (NLP) work have been compared to expert systems (Boitet and Gerber, 1984) by equating the knowledge base to the grammar, and the problem-solving activity to the transformation performed on the text representation structure. Existing GWSs do not provide any explanation because their usage is usually confined to expert users who can understand low-level programs or rule traces, and moreover, the inferencing process for NLP applications is normally carried out in batch mode. If users do interact with the system, it is usually for the purpose of resolving ambiguities (for example), which is obviously quite different from explanation.</Paragraph>
    <Paragraph position="2"> The presence of explanation is one of the main reason why expert systems have found a substantial degree of success with users, so perhaps NLP systems could also benefit from such a service, especially in gaining end-user acceptance.</Paragraph>
    <Paragraph position="3"> In this investigation, we are not studying the nature of explanation per se, but rather, starting from an existing system, determine what explanations can be provided and how.</Paragraph>
    <Paragraph position="4"> The system under consideration is the GWS associated with a machine translation environment known as JEMAH (Tong, 1988; 1989).</Paragraph>
    <Paragraph position="5"> Previous studies on explanation (see, for example, Swartout, 1984, and Chandrasekharan, 1989) have shown that providing effective explanation frequently requires supplementary knowledge in addition to the existing knowledge base. For example, the metamorphosis from MYCIN to NEOMYCIN (Clancey, 1983) requires the addition of meta-rules to explicitly represent the diagnostic strategy and the relationship between rules. The research described in this paper will ascertain the level and degree of explanation which can be provided without resorting to the use of supplementary knowledge, more or less along the same lines as Wick and Slagle (1989), who studied the type of explanation facility that can be provided based on current expert system methodologies where supplementary knowledge is not available.</Paragraph>
    <Paragraph position="6"> Besides the knowledge content required for such explanation, the other side issues related</Paragraph>
    <Paragraph position="8"> to explanation like presentation, user modelling based on goals and background knowledge, and dialogue structure are not included in this paper. This first prototype of an explanation facility for the JEMAH system uses simple menus and pre-defined dialogs.</Paragraph>
    <Paragraph position="9"> * 2. Explanation in Expert Systems There are 3 major types of explanation which have been studied for expert systems: (a) explaining the (dynamic) inferencing on a specific input data set, (b) explaining the (static) knowledge base itself, and (c) explaining the control strategy. The fn'st type of explanation, based on the original work in MYCIN (Scott et al., 1977), has been adopted by almost all commercial expert system shells. Such trace-based explanation will answer queries on why (is a question being asked?), how (is this conclusion reached?) and what (is the current variable/rule?).</Paragraph>
    <Paragraph position="10"> The second type of explanation is exemplified by the Xplain system (Swartout, 1983), whose implementation-level knowledge base is compiled from an explicitly-represented deep knowledge model. Xplain can explain its knowledge base by referring to this deep knowledge, as well as knowledge about the compiling process itself. For grammar writing systems, such a scheme corresponds to the static and dynamic grammars in Vauquois and Chappuy (1985) and the meta and (low-level compiled) object grammars in Bogureav et al.</Paragraph>
    <Paragraph position="11"> (1988). Most commercial expert system shells only explain its implementation level knowledge base through the use of cannedtexts associated with rules and variables. NEOMYCIN (Clancey, 1983) generalizes the diagnostic problem by explicitly representing the diagnostic tasks, whose strategy can then be explained for any one data set, and this implements the third type of explanation mentioned above. Another example is the generalized task-based approach adopted by Chandrasekaran (1989).</Paragraph>
    <Paragraph position="12"> This paper will concentrate mainly on trace-based explanation, since the other two obviously require supplementary knowledge.</Paragraph>
    <Paragraph position="13"> The execution trace of the processing of a NL text contains a wealth of information, but this crude data must first be transformed into a more well-ordered structure and then rearranged into a form suitable for explanation purpose.</Paragraph>
    <Paragraph position="14"> Hence, explanation is viewed here as an information refining process (analogizing on an  oil refinery).</Paragraph>
    <Paragraph position="15"> 3. Explanation in a Grammar Writing</Paragraph>
    <Section position="1" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
System
</SectionTitle>
      <Paragraph position="0"> Any explanation system must first address the question of who its users are, and very frequently, a user classification based on user expertise, which covers the spectrum from novice to expert, is used for this purpose.</Paragraph>
      <Paragraph position="1"> Knowledge of a user's class will influence the amount of explanation to be provide, d, as well as its form and content. In the JEMAH grammar writing system, we have identified 3 groups of users: the translator, the linguist and the grammar writer (corresponding to the enduser, the expert and the knowledge engineer in an expert system). The grammar writer may use the explanation facility to debug the grammar related to the rules and the control strategy, the linguist to study the various linguistic phenomena which are associated with the translation process, and the translator to better understand the translation output, and hence, better able to edit it.</Paragraph>
      <Paragraph position="2"> For the grammar writer and the linguist, the detailed trace of execution provided by the JEMAH system contains superfluous unstructured information. One way of controlling the level of detail and the form of information is through the use of abstraction hierarchies (Clancey, 1983), and one method of implementation is to attach numeric markers to each rule to denote its level of importance and complexity. A similar scheme has been adopted by the JEMAH explanation facility.</Paragraph>
      <Paragraph position="3"> The following examples will illustrate the types of explanations encountered in grammar writing systems.</Paragraph>
      <Paragraph position="4"> (a) &amp;quot;Why is the rule XYZ applied?&amp;quot; &amp;quot;Why is the noun phrase ... attached to the verb?&amp;quot; This is explaining the inferencing process and answers can be found directly in the execution trace.</Paragraph>
      <Paragraph position="5">  (b) &amp;quot;What other rules affect noun phrases?&amp;quot; &amp;quot;What is the function of the rule XYZ?&amp;quot; This is explaining the grammar itself and answers can be generated using canned-text and abstraction hierarchies.</Paragraph>
      <Paragraph position="6"> 360 2 (c) &amp;quot;Why is the rule PQR not applied?&amp;quot; This is explaining the control strategy.</Paragraph>
      <Paragraph position="7"> (d) &amp;quot;What if the rule ABC is applied first?&amp;quot; This is the simulation type of explanation.</Paragraph>
      <Paragraph position="8"> 4. Design and Implementation  In most commercial expert system shells, explanations are provided during the inferencing process. For grammar writing systems in machine translation, this is perfomled at the end, after storing all relevant derivational (or inferencing) history.</Paragraph>
      <Paragraph position="9"> Therefore, the most important design decision is to determine how to represent this derivational history, and what to store in it. In the JEMAH system, the derivational history consists of a sequence of snapshots of the tree structure taken after each transformation.</Paragraph>
      <Paragraph position="10"> Backtracking through this derivational history will provide all necessary information on how the translation was carried out. JEMAH also provides the what-if explanation (simulation) through its restart capability; i.e. JEMAH can backtrack to a certain point in the translation process, reset specific values, and then restart the translation process from that pointdeg Explaining the control strategy is obviously much more difficult, depending on whether the control information is explicit or implicit. In ROBRA (Boitet et al., 1978), where this strategy is explicit (user-defined), any explanation will involve explaining the flow of control within its transformational subsystem. If implicit (as in JEMAH), then explanation has to be hard-coded into inference engine, as done in SOPHIE (Brown et al., 1982).</Paragraph>
      <Paragraph position="11"> The derivational history of a translation carried out by the JEMAH system is represented as a sequence of events. Each event is a single transformation on the tree structure resulting fi'om the successful application of a grammar rule. The information content of each event consists of:  their annotations.</Paragraph>
      <Paragraph position="12"> The full derivational history of a translation from source text to target text is stored in 3 sequences of events (see Fig. 1), corresponding to the analysis (*AS-TRACE*), transfer (*TS-TRACE*) and generation phase (*GS-TRACE*), as well as the final event (*GM-TRACE*). Each sequence has a start event (Eo) and a final event (En). A start event differs from the other events in that it has null values for RULE-NAMF, PIVOT-NODE, and DELETED-NODES, and all nodes of TREE are included in NEW-NODES and in ACTIVE-NODES; this represents the initial conditions for each event in a phase.</Paragraph>
      <Paragraph position="13"> The computations involved in the 3 dictionary processes of morphological analysis, lexical analysis and morphological generation are not recorded in the derivational history. Each of these phases is considered as a single transformation; for example, lexical analysis causes the transformation from En of *AS-TRACE* to Eo of *TS-TRACE*. Since there is no dictionary process between structural transfer and structural generation, the event En of *TS-TRACE* is the same as the event Eo of</Paragraph>
      <Paragraph position="15"> dialog that controls the explanation facility of JEMAH. The 4 buttons on the top half of the dialog represent the 4 query elements: Rule, Variable, Source Text, Target Text. Selecting (clicking on) any of these 4 buttons will automatically pop-up a list of all rules, variables, source words or target words respectively. User-selected items will then be used to determine the content and form of the explanation provided when the user click on the EXPLAIN button. The user can also reduce the amount of details by selecting only the interested variables for display by using the &amp;quot;Display Variables&amp;quot; button. Once items in any of these 4 query elements have been selected by the user, the system will extract the relevant events from the derivational history and then generate an output text based on a pre-defined template structure.</Paragraph>
      <Paragraph position="16"> All explanation output texts will involve describing rules and variables. Instead of using a single word (rule name or variable name) to describe each of them, special supplementary files consisting of canned-text have been created to provide a more meaningful explanation. For example, the grammar in each translation phase is associated with a supplementary file describing all rules in that grammar, and each record has the following fields: .rule-name, .author, date (of last modification), rule-type, keywords, descriotion. The rule-type field is to identify a rule's ievel of importance and its relevance to a particular group of users, while the .~.ywords field is used for indexed retrieval as well as grammar partitioning. The descriptio, field is divided into 2 sub-fields, an abstract and a main text, to provide 2 levels of explanation details. A similar canned-text approach is used for variables, each of which is described with the following fields: variable.ham.e, kevwords, (morphological, syntactic, semantic, etc.), (2 levels), rule-name (rules that either test or assign values to that variable).</Paragraph>
      <Paragraph position="17"> A sample explanation of the translation of the word &amp;quot;activate&amp;quot; in the sentence &amp;quot;This information is the input to activate the inventory control application.&amp;quot; (translated into Malay as &amp;quot;Maklumat ini adalah input untuk menggerakkan {menghidupkan giat} penerapan kawalan inventori.&amp;quot;) is shown below.</Paragraph>
      <Paragraph position="18"> &amp;quot;menggerakkan&amp;quot; is translated from &amp;quot;activate&amp;quot;, analyzed morphologically as lexical unit ACTIVATE with information (CAT V SUBV VB VL1N TENSE PRES NUM PLU VEND 2). In structural analysis, it is processed as follows: Rule ELEVATE-VCL constructs a VCL from a verbal.</Paragraph>
      <Paragraph position="19"> with changes: (SF GOV) Ru~e TO-VCL constructs an infinitive clause from TO + VCL. with changes: (K PARTCL SVL I SLOCK IMP) Rule PCL-NP absorbs a following NP into a PARTCL. with changes: (AVL1N SEMI ABST) Rule VCL-PCLCIRC absorbs the right PARTCL as circumstantial into the clause. with changes: (SF CIRC) In lexical transfer, it is translated to target GERAK with alternative translations (MENGHIDUPKAN GIAT). In structural transfer, it is processed as follows: Rule ASP-TENSE-&gt;ASPEK maps the English TENSE, VOICE and ASPect to Malay ASPEK. with changes: (ASPEK NORMAL) In structural generation, it is processed as follows: Rule CL-ARGI=ACT positions ARG1 to the right of the governor of an active clause. with changes: (RSV CAUSE)</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>
Download Original XML