File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/85/p85-1028_metho.xml
Size: 29,823 bytes
Last Modified: 2025-10-06 14:11:47
<?xml version="1.0" standalone="yes"?> <Paper uid="P85-1028"> <Title>Explana~..: 3tructures in XSEL</Title> <Section position="2" start_page="0" end_page="229" type="metho"> <SectionTitle> (FACT ?ATTRIBUTE TOTAL.DISK-SPACE ?STATUS INFERENCE TCLASS DISK ?UNITS MEGAB~'TE3 ?MEAN 3600 YTOKEN G'.29) </SectionTitle> <Paragraph position="0"> The fact collection process is driven by backward-chaining rules. A top-level rule deposits a few &quot;core&quot; facts for which XSEL must obtain values, such as &quot;total.disk-space&quot;, &quot;total-number.ofterminals&quot;, etc. One at a time, XSEL solicits a value for these core facts from the salesperson. If the salesperson answers &quot;unknown&quot; to a solicitation, another rule fires to deposit some additional facts that would enable XSEL to infer a value for the unknown fact. The cycle is then repeated as XSEL solicits values for each of the newly deposited facts. Any time a newly instantiated fact completes the set of facts required to infer a value for some other fact. the appropriate inference rule is automatically triggered and the value for another fact is inferred.</Paragraph> <Paragraph position="1"> This backward-chaining process continues until XSEL obtains values for all of the core facts, or until no more data can be collected and no more inferences can be made, in which case some default value rules fire to instantiate values for any remaining unknown facts.</Paragraph> <Paragraph position="2"> The most important knowledge structure used by XSEL during the component selection phase is a rank element. Like a fact, a rank element is simply a list of atthbute.value palm. In this case the attribute-value pairs represent knowledge about a candidate's score for one term in the evaluation function. A different evaluation function is associated with each class of component.</Paragraph> <Paragraph position="3"> and each evaluation function is a sum of some weighted terms.</Paragraph> <Paragraph position="4"> The terms of the evaluation function for the class disk, for example, include price, disk-pack-type, storage-capacity, average-access-time, peak-transfer-rate, and handednesa. For every candidate, XSEL computes a rank value for each term in the evaluation function. The rank value for a term is the product of the candidate's normalized SCore for the term and a weight which represents an importance factor. The essential information needed to compute a rank value for a term for a candidate is stored in a rank element, an example of which is shown in Figure</Paragraph> <Paragraph position="6"> After aJl the rank values have been computed for a candidate they are summed to obtain a total score for the candidate. The candidate with the highest total score is selected and placed on the purchase order.</Paragraph> <Paragraph position="7"> The component selection phase is driven by forward.chaining rules. These rules perform the subtasks of first, retrieving candidates from the database, next, determining a quantity and cost for each of the candidates, next, computing a total rank score for each candidate, and finally, selecting the candidate with the highest rank score.</Paragraph> <Paragraph position="8"> At present, the entire XSEL system consists of over three thousand OPS5 \[2\] rules. The explanation generator, which will be described shortly, comprises an additional five hundred rules. Anywhere from approximately five hundred to five thousand rules may fire during the fact gathering phase to create from fifty to five hundred facts, and roughly three thousand rules will fire during the component selection phase to create around one thousand rank elements. The whole process can take anywhere from ten to thirty minutes of real time, depending on how XSEL's queries are answered.</Paragraph> <Paragraph position="9"> t .2. Sample Explanations Three of the most obvious types of queries a user m~ght ask were targeted for initial explanation development. Sample explanations from each of those types are given in this section. The following sections describe the knowledge structures and processes within both XSEL and the explanation generator that produced those explanations, as well as the goals and rationale behind them.</Paragraph> <Paragraph position="10"> One type of query that is likely to be asked is why a particular component appears on a purchase order. We refer to queries of this type as &quot;why-choice&quot; queries. To answer a why-choice query the explanation generator must compare the rank elements for each candidate on each term of the evaluation function in order to determine which attributes were responsible for the higher SCore of the component that was actually selected. The following are sample explanations from the why-choice class of queries.</Paragraph> </Section> <Section position="3" start_page="229" end_page="229" type="metho"> <SectionTitle> ALTERNATIVE RXED PACK DISK, POSSIBLY BECAUSE IT HAS A SMALLER TOTAL STORAGE CAPACITY AND A SLOWER AVERAGE-ACCESS-TIME. ?why rm05 ALTHOUGH THERE ARE LESS EXPENSIVE DISK S, THE RM05 HAS A LARGER DISK PACK THAN ANY ALTERNATIVE REMOVABLE PACK DISK. </SectionTitle> <Paragraph position="0"> A second obvious type of query asks why a certain fact has whatever value it has. e.g., why total-disk.space is 3600 megabytes. We refer to queries in this class as &quot;why-lact&quot; queries. In the case of why-fact queries, the explanation generator must examine the facts that were created during the fact gathering phase, and it must determine how those facts are related through the backward-chaining process. An example of an explanation that was generated in response to a why.fact query follows: ? why q total-disk-space</Paragraph> </Section> <Section position="4" start_page="229" end_page="229" type="metho"> <SectionTitle> XSEL INFERRED A VALUE QF 3600 MEGABYTES FOR TOTAL-DISK.SPACE. 3574 MEGABYTES ARE REQUIRED FOR TOTAL.USER-DISK-SPACE. THE REMAINDER IS ACCOUNTED FOR BY OTHER FACTORS, SUCH AS SUM-OF-SYSTEM-DISK- SPACE. 3574 MEGABYTES WAS INFERRED FOR TOTAL-USER-DISK-SPACE BECAUSE 2859 MEGABYTES ARE REQUIRED FOR USER-DISK- SPACE AND THAT VALUE IS MULTIPLIED BY 125 FOR PERCENT-FOR-EXPANSION . XSEL INFERRED A VALUE OF 25 MEGABYTES FOR SUM.OF.SYSTEM.DISK-SPACE FROM 1 SYSTEM-DISK-SPACE REQUIREMENT OF 25 MEGABYTES FOR THE VMS OPERATING-SYSTEM. </SectionTitle> <Paragraph position="0"> This explanation would have ended immediately following the first paragraph had not the user previously asked for longer explanations. But because the user had earlier typed &quot;explain more&quot;, the explanation generator went on to explain the terms &quot;total-user-disk-space&quot; and &quot;sum.of.system.disk-space&quot;, which were introduced in the first paragraph. If the user were to type &quot;explain more&quot; a second time. and then ask the same question &quot;why quantity total-disk-space&quot;, the explanation generator would not stop where it did. Instead, it would go on to explain the terms user-disk.space, percent.for-expansion, and system.disk-space, which were introduced in the second and third paragraphs, There is no upper bound on the number of levels of explanation the user may request. If the number of levels to explain is high.</Paragraph> <Paragraph position="1"> XSEL will keep explaining until it reaches those facts whose values were set either by user input or by default, in which case there is nothing further to explain. The user can ~lso type &quot;explain less&quot; at any time, thus decreasing the number of levels to explain. The lower bound on the number of levels to explain is one.</Paragraph> <Paragraph position="2"> The mechanism for determining which term to explain next is a queue. As new terms are introduced they are placed in the queue. The queue was originally implemented as a stack, but as explanations got longer they began to sound less coherent using the stack mechanism. So the queue was implemented, but the stack was retained. Now one can toggle between them by typing &quot;explain queue&quot; or &quot;explain stack&quot;, thus producing alternatively structured explanations for the sake of comparison.</Paragraph> <Paragraph position="3"> The third ol~vious class of queries asks why a certain quantity is needed for any line-item. We refer to these as &quot;why-line.item&quot; queries, Why-line-item queries require the most complicated processing because the explanation generator must understand how the line-item that was selected relates back to the facts that determine the quantity needed, and there is usually a long sequence of forward-chaining rules as well as the whole evaluation function mechananism between the creation of the facts and the creation of the line-items. Figure 1-5 shows a sample explanation from the why-line-item class. In this example.</Paragraph> <Paragraph position="4"> the number of levels to explain was set at two. The first two paragrapl'~ comprise the first level, so tire explanation could have 23O stopped there; the remaining two paragraphs were generated in response to terms introduced in the first two paragraphs.</Paragraph> <Paragraph position="5"> ? why q ra60 4 RA60-AA&quot; 'S WERE SELECTED IN ORDER TO SATISFY A REMOVABLE-DISK-SPACE REQUIREMENT OF 900 MEGABYTES.</Paragraph> <Paragraph position="6"> EACH RA60-AA&quot; PROVIDES A CAPACITY OF 205 MEGABYTES. THEREFORE, 4 RA60-AA&quot; 'S ARE REQUIRED TO YIELD AT LEAST 90 PERCENT OF THE REMOVABLE-DISK-SPACE CAPACITY OF 900 MEGABYTES.</Paragraph> </Section> <Section position="5" start_page="229" end_page="229" type="metho"> <SectionTitle> 900 MEGABYTES OF THE TOTAL-DISK.SPACE REQUIREMENT OF 3600 MEGABYTES WERE ALLOCATED TO REMOVABLE.DISK-SPACE . XSEL INFERRED A VALUE OF 900 MEGABYTES FOR REMOVABLE-DISK-SPACE BECAUSE 3600 MEGABYTES ARE REQUIRED FOR TOTAL-DISK. SPACE AND 2700 RXED-DISK ARE SUBTRACTED FROM IT TO GET THE DIFFERENCE . THE VALUE OF 205 MEGABYTES FOR REMOVABLE- DISI(-UNIT.CAPABILITY WAS RETRIEVED FROM </SectionTitle> <Paragraph position="0"/> </Section> <Section position="6" start_page="229" end_page="234" type="metho"> <SectionTitle> 2. XSEL Explanation Design Goals 2.1. Related Explanation Work </SectionTitle> <Paragraph position="0"> The desi(jn of the XSEL explanation generator was motivated by three goals: first, that explanations should be accurate.</Paragraph> <Paragraph position="1"> second, that explanations should be direct, and third, that some degree of generality should be attempted.</Paragraph> <Paragraph position="2"> Most early attempts at explanation generation adopted either a canned text or an execution trace approach. The canned text approach led to accuracy problems and the execution trace approach led to directness problems. These problems are described in detail by Swartout\[12\]. In brief, canned explanations can suffer from a lack of accuracy in the event that any modifications or additions are made to the Performance program without the corresl0onding modifications or additions being made to the canned text. Execution trace.explanations tend to suffer from a lack of directness because every step during program execution gets reported, including what Swartout has referred to as &quot;computer artifacts&quot;, as in &quot;Variable X was initialized to 0&quot;.</Paragraph> <Paragraph position="3"> Another common early approach to explanation generation was the goal tree approach, which is very.similar to the execution trace approach. The original explanations produced by the MYCIN system were goal tree explanations \[1\]. This approach allowed the user to question any request for information made by the system, and the system would simply locate the goal immediately above the current one in the goal tree and report that it needed the information to resolve that higher goal. Goal tree explanations tend to suffer from the same lack of directness problems that execution trace explanations suffer from.</Paragraph> <Paragraph position="4"> Swartout's work on an explanation generator for the Digitalis Therapy Advisor attacked the accuracy and directness problems successfully. His approach was to redesign the DTA, separating descriptive facts from domain principles and from the abstract goals of the system. This allowed the performance program to be generated by an automatic programmer, which also created a goal refinement structure in the process. The goal refinement structure captures the knowledge that goes into writing the performance program, and makes it accessible to the explanation generator, where it can be used to produce explanations that are both accurate and direct. Furthermore, as Swartout points out, such explanations can be viewed as &quot;justifications&quot; for the system's behavior.</Paragraph> <Paragraph position="5"> One of the major contributions of the DTA work was to demonstrate that a singte explicit representation of knowledge can and should drive both the automatic program generation process and the explanation generation process. Further research supporting the &quot;shared explicit knowledge&quot; approach to automatic knowledge acquisition, rule generation, and explanation generation is underway for at least three other projects \[8\] \[4\] \[5\] \[6\].</Paragraph> <Section position="1" start_page="229" end_page="234" type="sub_section"> <SectionTitle> 2.2. The XSEL Explanation Approach </SectionTitle> <Paragraph position="0"> XSEL's approach to explanation generation differs from all of the approaches discussed above. The sheer size of XSEL would make implementing canned responses tedious. Similarly, the number of rule firings on any run would make reading execution trace explanations labonous even. or perhaps especially, if they were translated into natural lanaguage. The approach taken by Swartout of extracting the regularities and representing them separately as domain principles would work for the backward-chaining rules used during XSEL's fact gathering phase, but the forward-chaining rules used during the component selection phase are so irregular that attempting to extract regularities would result in the duplication of nearly the entire set of rules. Some other common denominator needed to be found in order to achieve some computational power for explanation generation.</Paragraph> <Paragraph position="1"> For about two thirds of XSEL's explanation facilities, that computational power was bought by the creation of links, which are simple knowledge structures that establish relations between elements in XSEL's working memory. The role of links will be the focus of the remainder of this paper. But first a brief general overview of all the explanation facilities is given.</Paragraph> <Paragraph position="2"> There is a simple variant of a goal tree explanation facility built into XSEL. so that the system can always state why it wants a value for any fact it reduests during the fact gathering dialog. But the explanation samples shown in the previous section were generated by an entirely different mechanism, a message-based explanation generator. A message-based explanation generator is a two-phase processor that first generates and organizes messages based on the contents of working memory, and then maps those messages into surface strings. Two different types of message generator have been implemented for XSEL. The message generator used to answer why-choice queries may be called a comparative message generator; it examines and compares the rank elements produced by the evaluation functions to determine what roles they play in the selection of the chosen component, and then it creates a,opropriate messages, The message generators used to answer the why-fsct and why.</Paragraph> <Paragraph position="3"> line.item clueries may be called link-dependent message generators: they examine the facts and the links between facts to determine what relations hold among them, and then they create appropriate messages.</Paragraph> <Paragraph position="4"> Explanations produced by both the comparative message generator and the link-dependent message generators are certain to be accurate because they always originate from the contenfs of working memory. Special steps had to be taken to ensure the directness of the link-dependent message generators.</Paragraph> <Paragraph position="5"> however. Those steps will be discussed in the following sections. which describe the workings of the lipk-dependent message generators in some detail. Discussion of the comparative message generator and the surface generator will be reserved for other occasions.</Paragraph> <Paragraph position="6"> 3. Link-dependent Message Generation 3.1. Generic vs. Relational Explanations Both of the link-dependent message generators are capable of operating in two modes, generic mode and relational mode. (The user can toggle between modes by typing &quot;explain generic&quot; or &quot;explain relational&quot;.) The explanations shown above in Figures 1-4 and 1-5 are relational explanations: they explicate the relations that hold between facts. Some of those relations are arithmetic relations, such as sum and product, and some are abstract relations, such as satisfaction and allocation relations. Contrast the relational explanation for the query &quot;why q total-disk-space&quot; shown in Figure 3-1 with the generic explanation for the same query shown in Figure 1-4. Generic explanations do not explicate the relations that hold between facts; they simply state that some generic dependencies exist. The same message generator is used to generate both generic and relational explanations. (Notice that the same queuing mechanism is used to explain subsequent terms in both generic and relational explanations.) The difference between generic and relational explanations results from the fact that there are two different tyoes of links in XSEL's memory, qeneric links and relational links. Both types of links establish -~ connectton between two or more facts. The difference is that generic links are ~lways unnamed, binary links, whereas relational links are always named, n.ary links, where the name may be an arithmetic relation such as sum or product, or an abstract relation, such as satisfaction or allocation. Both types of links au'e deposited into Rgu re 3-1: Sample Generic Explanation XSEL's working memory by the re;lsoning rules that fire during program execution. As links are de;)osited during XSEL's execution, two dynamically growing networks are built up; the generic network is a sim0le dependency network, and the relational network is an augmented semantic network. These networks are the mare source of knowledge for the link-dependent message generators.</Paragraph> <Paragraph position="7"> A generic link is a very sJmple memory element consisting of only two attributes, a source attribute and a sink attribute. The value of the source attribute is the token (i.e., unique identifier) of some fact that entered into the inference of the resultant fact; the value of the sink attribute is the token of the resultant fact. For example, the rules that fire to infer a value for the fact total-disk- null space will deposit into working memory at lea.st five generic links, each having the token of the fact total-disk-space in its sink attribute and each having the token of a fact that entered into the calculation of the value for total-disk-space, such aS totalapplication-disk-space, programmer-disk-space, etc., in its source attribute. An example of a generic link is shown in Figure 3-2. A relational link is a sJightly richer memory element which not only names the relation that holds between two or more facts, but also categorizes it. Figure 3-3 displays one arithmetic relational link and one abstract relation link.</Paragraph> <Paragraph position="9"> The network formed by relational links is in some ;)laces more dense and in other ;)laces less dense than the network formed by genenc links; arithmetic relational links create more levels thus making the relaUonal network denser, while abstract links tend to bridge long chains of facts, thus making the network sparser. To see this distinction, consider the arithmetic formula used by XSEL to calculate the total-disk-space requirement:</Paragraph> <Paragraph position="11"> + sum of system.disk.space + sum of page-and.swap-space The rules that execute this formula create at least five generic links linking total-disk.space to total-application-disk-space, programmer-disk-space, total-data-file-disk-space, one or more system-disk-sp,3ce facts, and one or more page-and-swap-space facts. At the same time they create one relational link linking total-disk-space to three new intermediate level facts, total-userdisk-space, sum.of-system-disk-space, and sum-of-page-andswap.space, and they create additional relational links linking each of the intermediate facts to their subfacts. Total.user-diskspace is a newly created intermediate fact, and a relational link, with rrelation percent, is created linking it to two more new intermediate facts, user-disk-space and percent.for-expansion.</Paragraph> <Paragraph position="12"> Another relational link is in turn created linking user-disk-space to the three facts total-application-disk-space, programmer-diskspace, and total-data-file-disk-space.</Paragraph> <Paragraph position="13"> On the other hand, the rules that determine how many RA60 disk drives are needed, for example, create a dense generic network linking all the facts that enter into the calculation of total-disk-space to the facts that allocate some portion of that amount to fixed-disk-space. From there the network would get even denser as fixed-disk-space is linked tO the fixed.disk.unit.</Paragraph> <Paragraph position="14"> capabihty and quantity-of-fixed-disks facts for each candidate. In fact, these generic links are not currently created due to limitations of working memory space. In contrast to the potentially dense generic network, the relational network contains only a few abstract relation links, such as satisfaction and allocation links, that bridge many of the generic links, thus resulting in a sparser network (and in more direct explanations).</Paragraph> <Paragraph position="15"> There are good reasons for the existence of two complete networks. Essentially, the tradeoff is that while generic links are trivial tO create, they do not facilitate satisfying explanations. On the other hand, the creation of relatil)nal links often requires manual intervention, lout relational links facilitate direct explanations. Compare again the generic explanation in Figure 3- I to its corresponding relational explanation in Figure 1.4.</Paragraph> <Paragraph position="16"> Generic links require little effort to create because they simply incorporate the tokens of the facts that are used in an inference rule. In fact, an automatic rule generator was developed for automatically creating most of XSEL's backward.chaining fact-gathering rules from simple arithmetic formulas such as the formula for total-disk-spsce discussed above.lit was a trivial task to have the automatic rule generator include the actions required to have the inference rules create the generic links.</Paragraph> <Paragraph position="17"> The task of augmenting the fact-gathering rules to create arithmetic relational links was also automatable, for the most part. An automatic link-creator was written to parse the arithmetic formulas that were input to the rule generator and create the appropriate links. This parser identified the main arithmetic operations, created names for intermediate facts, and modified XSEL's rules to have them create the arithmetic relational links.</Paragraph> <Paragraph position="18"> The output of the automatic link-creator required only minor manual retouching in those cases where its heuristics for creating names for intermediate facts fell short. 2 But the task of augmenting the component selection rules to create the abstract relational links between facts has so far resisted an automatic solution. These links are now being added manually. They require the effort of someone who understands the workings of XSEL and recognizes what explanations might be called for and.</Paragraph> <Paragraph position="19"> consequently, which rules should be modified to create relational links.</Paragraph> </Section> <Section position="2" start_page="234" end_page="234" type="sub_section"> <SectionTitle> 3.2. Overview of Processing </SectionTitle> <Paragraph position="0"> The processing of a query by a link-dependent message generator goes as follows. When the initial query is input, a query-interpretation context is entered. In this context some rules fire tO identify and locate the fact in question, to create a query-term with the same token as the fact. and to place that query-term in the query-queue. Following query-interpretation, a message generation cycle consisting roughly of the following five steps reiterates: 1) focus on the next query-term in the queue, 2) locate the links related to that query-term, 3) select an explanation schema 3 based on the links found, 4) create 1XSEL's automatic ride gammer was v~ten by Samly Marcus.</Paragraph> <Paragraph position="1"> 2XSEL's auSommic link-creatm ~S vmtmen by kTr.ttaet ~w~ additional query-terms and messages suggested by the selected schema, and 5) turn control over to the surface generator. Each time a new query-term is created, queue-control rules decide whether to place it in the query-queue, depending on such factors as whether the term has already been explained and how many levels of explanation the user has requested. As long as the query-queue is not empty, the message generation cycle is reiterated.</Paragraph> <Paragraph position="2"> When the message generator is in generic mode, it b constrained to locating generic links during step 2 of the cycle, and it is constrained to selecting the generic schema during step 3 of the cycle. A simplified version of the generic schema is depicted in Figure 3.4. The first directive of the generic schema directs the message generator to create additional query.terms for all the facts that are linked to the current query-term. The second directive directs the message generator to create one message with the predicate &quot;IS-DEPENDENT&quot; and with the focus-token of term1, which is the current query.term. The surface realization of this message will be the clause &quot;THE VALUE OF 3600 MEGABYTES FOR TOTAL-DISK-SPACE IS DEPENDENT &quot;. The third directive of the generic schema directs the message generator to create one additional message with the predicate &quot;ON&quot; and the focus.token of terror for each of the link terms found. These messages will emerge as prepositional phrases in their surface form, such as &quot; ON 1424 KILOBYTES</Paragraph> </Section> </Section> <Section position="7" start_page="234" end_page="235" type="metho"> <SectionTitle> SPACE .&quot; </SectionTitle> <Paragraph position="0"> When the message generator is in relational mode, it is constrained to locating relational links and using relational schemas. There are a variety of each. Currently, relational links are categorized as being either reasons, elaborations, or arithmetic links. During step 2 of the message-generation cycle, the message generator searches first for reason links, next for elaboration links, and finally for arithmetic links. In some cases, the search for arithmetic links may be suppressed. For example, some links whose relation is allocation are subcategorized as being arithmetic operations, as in &quot;75 percent of the total.disk. space requirement was allocated to removable-pack disks&quot;. In these cases, expressing the arithmetic relation also would be redundant.</Paragraph> <Paragraph position="1"> When a relational link is located, a corresponding schema is selected. In contrast to the single generic schema, there are a variety of arithmetic and abstract relational ~chemas. Figure 3-5 illustrates the arithmetic &quot;plus&quot; schema that was used to generate the messages for the first paragraph of the &quot;why quantity totaJ-disk-space&quot; relational explanation shown in Figure 1-4. It contains five directives, one to create the new query-terms found in the arithmetic reasoning trace and four to create messages. The second message creation directive will create as many messages as are needed to account for at least 80 percent of the total value of the fact being explained. (The 80 percent factor was implemented in order to filter out insignificant facts, thus making the explanation more concise. Another process that contributes to more readable explanations is the conversion of all units in different clauses of the explanation to the same highest common denominator, eg. megabytes.) Following that, two additional messages will be created, one to mention that the remainder of the total is accounted for by other terms, and another to give an example.</Paragraph> <Paragraph position="2"> Figure 3-6 illustrates the &quot;setisfactJon&quot; schema that was u~=d to create the massages for the first sentence of the &quot;why quantity RA60&quot; explanation shown in Figure 1-5. It contains one directive to create an extra query-term matching the token of the new term identified in the &quot;satisfaction&quot; link, and three actions making the three messages which surface as three clauses of text in the explanation.</Paragraph> </Section> class="xml-element"></Paper>