File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/88/j88-4003_metho.xml
Size: 163,546 bytes
Last Modified: 2025-10-06 14:12:10
<?xml version="1.0" standalone="yes"?> <Paper uid="J88-4003"> <Title>THE BERKELEY UNIX CONSULTANT PROJECT</Title> <Section position="3" start_page="0" end_page="0" type="metho"> <SectionTitle> 1.2 UC OLD AND NEW </SectionTitle> <Paragraph position="0"> We initially built a prototype version of UC consisting largely of off-the-shelf components (Wilensky, Arens, and Chin 1984). While this system seemed to suggest that our goal was feasible, it was deficient in many ways. There were whole components that needed to be included but were not. For example, the initial system made few inferences and was not capable of planning its own actions. In addition, each individual component was in need of much refinement.</Paragraph> <Paragraph position="1"> Probably the most important deficiency was in the area of knowledge representation. The initial prototype of UC was implemented in PEARL (Deering, Faletti, and Wilensky 1981). PEARL is an AI language and database management package that supports framelike structures similar to those employed by other representation languages, with perhaps some more attention given to efficient retrieval. However, we found that our underlying representational system was inadequate.</Paragraph> <Paragraph position="2"> Unfortunately, the problems with our system were not unique to it, but were shared by most other efforts to represent and organize knowledge.</Paragraph> <Paragraph position="3"> Much of the focus of our recent work has been to address and rectify these problems of knowledge representation. Our critiques of existing knowledge represen- null tation schemes, along with our new prescription for these deficiencies, can be found in Wilensky (1986).</Paragraph> <Paragraph position="4"> That report contains a description of KODIAK, the knowledge representation system that our work has led us to, and upon which our current implementation of the UNIX Consultant is based.</Paragraph> <Paragraph position="5"> Since one's knowledge representation is generally fundamental to the structure of most of the modules of one's systems, developing a new one means redesigning each component around a new representational system.</Paragraph> <Paragraph position="6"> This report is a description of a new prototype of UC so designed.</Paragraph> </Section> <Section position="4" start_page="0" end_page="0" type="metho"> <SectionTitle> 1.3 REASONABLE AGENTS VERSUS INTELLIGENT INTERFACES </SectionTitle> <Paragraph position="0"> Our goal in building UC is to simulate a human consultant. As a result, the system has a structure that is more complex than other so-called intelligent interfaces. Indeed, we feel that looking at such a system as an interface is misleading. Instead, we prefer the metaphor of a reasonable agent. Unlike an interface, which is a conduit through which information flows, an agent is a participant in a situation. In particular, an agent has explicit goals of its own, and a reasonable agent must be able to make obvious inferences and display judgment in making decisions. Typically, a consultant constructed along the lines of a reasonable agent will make a user's goals its own in trying to help that user.</Paragraph> <Paragraph position="1"> However, a reasonable agent is not always compelled to do so. Human consultants will not obligingly give out information to which a user is not entitled or which they suspect will be put to ill use. Similarly, a good consultant might deflect a user's request because the consultant feels that the user does not have an adequate grasp of the domain, has a particular misconception, or is lacking some particular fact. In addition, a good consultant might do something more than simply answer a question. He might take the opportunity to show the user how to do a more general task of which the user's particular request is merely a special case. In all these situations, an action other than simply responding to a request is warranted.</Paragraph> <Paragraph position="2"> A reasonable agent is ideally suited to handle such a broad class of situations. It does so by deciding what its goals should be in the given situation, and then planning for them. For example, when UC is asked how to crash the system, it forms two goals, one of helping the user to know what he or she wants, and one of protecting the integrity of the system. It then realizes that these two goals are in conflict, and eventually decides the conflict in favor of the latter goal.</Paragraph> <Paragraph position="3"> Of course, it is possible to achieve by other means various parts of the functionality here attributed to the model of a reasonable agent. For example, one can simply build one component that tries to detect misconceptions, another that checks for requests having to do with crashing the system, yet another to capitalize on opportunities to educate the user, etc. However, the reasonable agent framework provides a single, flexible control structure in which to accomplish all these tasks, and, in particular, deal with interactions between them.</Paragraph> <Paragraph position="4"> That is its engineering motivation. Our primary reason for adopting it is that it is our theory about how humans function in consulting situations.</Paragraph> </Section> <Section position="5" start_page="0" end_page="0" type="metho"> <SectionTitle> 1.4 OVERVIEW </SectionTitle> <Paragraph position="0"> The structure of this report is as follows. First, we present an outline of the structure of the current version of our consultation system. We follow this with a brief description of KODIAK. The next sections constitute the bulk of this report and are essentially a detailed description of a trace of a rather simple sentence through UC's components. In doing so, the mechanisms of those components that are primarily responsible for UC's agentlike qualities are described. Finally, we conclude with some discussion of the deficiencies of our current design.</Paragraph> </Section> <Section position="6" start_page="0" end_page="0" type="metho"> <SectionTitle> 1.4.1 OUTLINE OF UC'S STRUCTURE </SectionTitle> <Paragraph position="0"> UC is comprised of a number of components, which are invoked in a more or less serial fashion.</Paragraph> </Section> <Section position="7" start_page="0" end_page="0" type="metho"> <SectionTitle> 1. LANGUAGE ANALYSIS (ALANA) </SectionTitle> <Paragraph position="0"> Language analysis is that component of the understanding process that computes a representation of the content of an utterance. ALANA, written by Charles Cox, produces a KODIAK representation of the content of an utterance. This representation generally contains only what can be determined from the words and linguistic structures present in the utterance.</Paragraph> <Paragraph position="1"> In our theoretical framework, we call such an analysis of an utterance its primal content. The concept of primal content is related to what is usually described as the literal meaning or sentence meaning of an utterance.</Paragraph> <Paragraph position="2"> However, unlike literal meaning, the primal content of an utterance involves certain idiomatic interpretations (i.e., it is not necessarily composed from words and general grammatical constructions). Also, the primal content of an utterance may be rather abstract, perhaps so much so that it may not be a suitable candidate for a meaning. For example, the literal meaning of &quot;The cat is on the mat&quot; is generally taken to be a conventional situation in which a cat is resting upon a mat. However, the primal content of this sentence would be more abstract, where the contribution of &quot;on&quot; is identical to that in the primal content of &quot;The light fixture is on the ceiling&quot; or &quot;The notice is on the bulletin board.&quot; Presumably, this conveys some sort of support relation.</Paragraph> <Paragraph position="3"> Note that such an abstract content appears never to be in itself the meaning of such an utterance (cf. Searle 1979).</Paragraph> <Paragraph position="4"> In contrast to primal content is the actual content of an utterance. The actual content is context dependent, generally requires some amount of inference based on world knowledge, and is a suitable candidate for the meaning of an utterance. For example, the actual con-Computational Linguistics, Volume 14, Number 4, December 1988 37 Robert Wilensky, David N. Chin, Marc Luria, .James Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project tent of &quot;The cat is on the mat,&quot; without a further context specified, is what the literal meaning of this sentence is generally taken to be. Computing this content from the primal content requires pragmatic knowledge about the kind of support relation a cat and a mat are likely to be in, and requires makinlg an inference that cannot be justified by the meanings of the terms and the grammatical constructions,present in l:he utterance. The primal/actual content distinction is elaborated on in Wilensky (1987).</Paragraph> </Section> <Section position="8" start_page="0" end_page="0" type="metho"> <SectionTitle> 2. INFERENCE (CONCRETION MECHANISM) </SectionTitle> <Paragraph position="0"> The particular kind of inference needed to go from a primal content to an actual content sometimes involves a process known as concretion (Wilensky 1983). Concretion is the process of inferring a more specific interpretation of an utterance than is justified by language alone. Concretion may involve finding a more specific default interpretation or some other interpretation based on the context. For example, in the example &quot;The cat is on the mat&quot; above, the actual content computed is the default support relation between a cat and a mat. In some compelling context, a quite different actual content may be computed from the same primal content.</Paragraph> <Paragraph position="1"> (There are other possible relations between primal and actual content besides the latter being a more specific interpretation of the former. For example, a conventionalized metaphor might have a primal content that more closely resembles its literal interpretation but an actual content resembling its metaphoric interpretation. Thus one analysis of a sentence like &quot;John gave Mary a kiss&quot; will have as its primal content an instance of giving, but as its actual content an instance of kissing. We will not pursue further the details of the primal/ actual content distinction here. This is largely because, in UC, the need for concretion is widespread, and our handling of other kinds of primal/actual content computations is more haphazard.) In UC, concretion is needed primarily because we need to organize knowledge about more specific interpretations of utterances than can be arrived at through linguistic knowledge alone. For example, if UC is asked the question &quot;How can I delete a file?&quot;, ALANA can represent that this is a question about how to delete a file. But it would not have any reason to assume that deleting a file is a specific kind of deleting. Determining that this is so is likely to be important for several reasons. For example, knowledge about how to delete a file will be found associated with the concept of &quot;file deletion&quot;, say, but not with the concept of deletion in general. Thus UC must infer that &quot;deleting a file&quot; refers to the specific kind of deletion having to do with computer storage in order to perform subsequent tasks like finding plans for accomplishing the user's request.</Paragraph> <Paragraph position="2"> In UC, concretion is the function of a special mechanism designed specifically for that purpose by Dekai Wu. The output of the concretion mechanism is another KODIAK representation, generally one containing more :specific concepts than that produced by ALANA.</Paragraph> <Paragraph position="3"> Having a specific concretion mechanism is a pragmatic concession. We feel it is unlikely that such a specific mechanism is theoretically warranted. A more justifiable position is that a general inference mechanism should be exploited here, concretion being only one of the kinds of inference such a mechanism accomplishes.</Paragraph> <Paragraph position="4"> A unified text-inference mechanism that accomplishes concretion as well as other forms of inference has been built (Norvig 1987). It is our belief that some mechanism akin to Norvig's should be used in UC in place of a specialized concretion engine, but no attempt has yet been made to do so.</Paragraph> </Section> <Section position="9" start_page="0" end_page="0" type="metho"> <SectionTitle> 3. GOAL ANALYSIS (PAGAN) </SectionTitle> <Paragraph position="0"> Having computed an actual content for an utterance, UC then tries to hypothesize the plans and goals under which the user is operating. This level of analysis is performed by PAGAN, written by James Mayfield.</Paragraph> <Paragraph position="1"> PAGAN performs a sort of speech act analysis of the utterance. The result of this analysis is a KODIAK representation of the network of plans and goals the user is using with respect to UC.</Paragraph> <Paragraph position="2"> Goal analysis is important in many ways for UC. As is generally well known, an analysis of this sort is necessary to interpret indirect speech acts, such as &quot;Do you know how to delete a file?&quot;, or &quot;Could you tell me how to delete a file?&quot;. Furthermore, goal analysis helps to provide better answers to questions such as &quot;Does Is -r recursively list subdirectories?&quot;. An accurate response to the literal question might simply be, &quot;No.&quot; But a better response is, &quot;No, it reverses the order of the sort of directory listing; Is -R recursively lists subdirectories.&quot; To produce such a response, one needs to realize that the goal underlying the asking of this question is either to find out what 'Is -r' does, or to find out how to recursively list subdirectories. It is the job of the goal analyzer to recognize that such goals are likely to be behind such a question.</Paragraph> </Section> <Section position="10" start_page="0" end_page="0" type="metho"> <SectionTitle> 4. AGENT (UCEGO) </SectionTitle> <Paragraph position="0"> Having hypothesized what the user wants of it, we would expect a system like UC to do what the user requested. But, as mentioned above, this is not always appropriate. UC should not aid and abet a user trying to perform malicious mischief; it might need to correct an errant user or it might decide to supply unasked-for information to one diagnosed as not knowing an important fact.</Paragraph> <Paragraph position="1"> In order to deal with such situations UC is constructed as an agent. This agent reacts to users' requests by forming goals and acting on them. The central mechanism of UC is called UCEgo, and has been developed by David Chin.</Paragraph> <Paragraph position="2"> In a typical transaction, UCEgo will simply adopt the goal of having the user know what the user wants to know. However, as the example above illustrates, UCEgo may adopt other goals as well, such as protecting the integrity of the system. It may also have to detect conflicts between these goals. Sometimes, UCEgo, attempting to be educational, may adopt a somewhat different goal from the user's. Thus, if the user asks UC to actually perform some request, such as telling the user who is on the system, UC will decide to tell the user how to perform such a function, rather than do what the user requested.</Paragraph> <Paragraph position="3"> UCEgo implements much of the agentlike character of UC. While interfaces are generally thought of as passive conduits through which information flows, UC is an agent that listens to the user and is generally helpful. But it has its own agenda, and the requests of the user are merely a source of input to it.</Paragraph> </Section> <Section position="11" start_page="0" end_page="0" type="metho"> <SectionTitle> 5. USER MODELING (KNOME) </SectionTitle> <Paragraph position="0"> Several of UC's components may need information about the user to make an effective choice. For example, an expert user certainly knows how to delete a file. Thus such a user uttering &quot;Do you know how to delete a file?&quot; is unlikely to be asking for this information-more likely this user is testing the consultant's knowledge. null Assessing the knowledge state of the user is the function of a user modeling program called KNOME, developed by David Chin. It is exploited by several components, including the &quot;expression mechanism&quot; described below.</Paragraph> </Section> <Section position="12" start_page="0" end_page="0" type="metho"> <SectionTitle> 6. DOMAIN PLANNER (KIP) </SectionTitle> <Paragraph position="0"> Typically, UCEgo tries to help the user. This usually requires determining a fact that the user would like to know. This task is accomplished by KIP. KIP is a &quot;domain planner&quot; developed by Marc Luria. While UCEgo infers its own goals, and plans to act on them, KIP is given a task by UCEgo of determining how to accomplish what the user wants to accomplish. KIP tries to determine how to accomplish this task, using knowledge about UNIX and knowledge about the user's likely goals. KIP returns a plan, represented in KO-DIAK. For example, UCEgo may give KIP the task of determining how to move a file to another machine, if this is something the user wants to know. Here, KIP would come up with the plan of copying the file to the target machine and then deleting the original.</Paragraph> <Paragraph position="1"> Since UCEgo is also a planner, UC in effect has two planners within it. Again, this is probably not theoretically justifiable, although the two planners have ended up focusing on rather different aspects of planning. It remains to be seen whether a single mechanism might accommodate both functions.</Paragraph> </Section> <Section position="13" start_page="0" end_page="0" type="metho"> <SectionTitle> 7. EXPRESSION MECHANISM (UCEXPRESS) </SectionTitle> <Paragraph position="0"> Having gotten KIP to compute a plan for the user's request, UCEgo now tries to communicate this plan to the user. To do so, it must determine which aspects of the plan are worthy of communication and how best to communicate them. For example, if it is likely that the user knows how to use commands in general, it might be sufficient just to specify the name of the command. In contrast, it might be helpful to illustrate a general command with a specific example.</Paragraph> <Paragraph position="1"> UCExpress is an expression mechanism written by David Chin. It edits out those parts of the conceptual answer returned by KIP that, for various reasons, appear unnecessary to communicate. UCExpress may also choose to illustrate an answer in several formats.</Paragraph> <Paragraph position="2"> For example, it might illustrate a general answer by generating a specific example, or it might explain one command in terms of another, simpler, command.</Paragraph> <Paragraph position="3"> The result of UCExpress is an annotated KODIAK network, where the annotation specifies which part of the network is to be generated.</Paragraph> <Paragraph position="4"> 8. LANGUAGE PRODUCTION (UCGEN) Once UC has decided what to communicate, it has to put it into words. This is done by a generation program called UCGen. UCGen is a simple generator, programmed by Anthony Albert and Marc Luria. It takes the marked KODIAK network produced by UCExpress and, using knowledge of English, produces sentences to complete the transaction with the user.</Paragraph> </Section> <Section position="14" start_page="0" end_page="0" type="metho"> <SectionTitle> 9. LEARNING MECHANISM (UCTEACHER) </SectionTitle> <Paragraph position="0"> Since it is intended that UC be an extensible system, a mechanism has been developed to add new knowledge to the system by talking to it in natural language. This mechanism, called UCTeacher, is the work of James Martin. UCTeacher has capabilities to extend both UC's knowledge base of UNIX facts as well as its knowledge of English vocabulary.</Paragraph> <Paragraph position="1"> Note that several UC components deal with goals and plans, but in rather different ways. To minimize confusion, we emphasize the different tasks that these programs perform: PAGAN hypothesizes goals of the user with respect to UC; UCEgo reacts to the user by forming goals of its own and then trying to accomplish them; and KIP is given the goal of solving some underlying UNIX problem. Thus PAGAN is a goal analyzer, i.e., a program that attempts to determine someone else's goals, while UCEgo and KIP are planners, i.e., programs that determine and produce plans for their own goals.</Paragraph> <Paragraph position="2"> UCEgo and KIP exist as two separate programs primarily for pragmatic reasons. It may be possible that a single planner could accomplish the tasks of both UCEgo and KIP. Such an integration will have to await a revision of our system.</Paragraph> </Section> <Section position="15" start_page="0" end_page="0" type="metho"> <SectionTitle> 1.5 UC EXAMPLES </SectionTitle> <Paragraph position="0"> The first set of examples illustrates the scope of the current UC prototype. They are intended to show the kind of requests the system can handle, as well as its scope. The second set demonstrates some more complex capabilities.</Paragraph> <Paragraph position="1"> Computational Linguistics, Volume 14, Number 4, December 1988 39 Robert Wilensky, David N. Chin, Marc Luria, ,lames Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project Each sentence below preceded by the prompt '#' is supplied by the user. The rest of the text is a computer-generated response. Note that the system handles a variety of request forms, some direct and some indirect.</Paragraph> <Paragraph position="2"> Also, the responses to general questions will cause an example to be generated. Finally, the reader may notice that the vocabulary used to respond to a request is often different from that used in the request itself. For example, a question about file protection is answered in terms of file permission; a question about changing a directory is answered in terms of connecting to a directory. This is because the representations used to encode the system's knowledge are kept in a canonical form, so that different expressions of the same meaning are mapped to the same internal representation. Upon generating a response, the system use,.; only this internal representation, which, coupled with its generating biases, causes an expression of an answer that is largely independent of the vocabulary that appeared in the request.</Paragraph> </Section> <Section position="16" start_page="0" end_page="0" type="metho"> <SectionTitle> 1.5.1 SIMPLE EXAMPLES % UC </SectionTitle> <Paragraph position="0"> Welcome to UC (Unix Consultant) version 3.23 To a UC '#' prompt, please type in your questions about the Unix file system in English.</Paragraph> <Paragraph position="1"> To leave, just type a 'AD' or '(exit)'.</Paragraph> <Paragraph position="2"> Hi.</Paragraph> <Paragraph position="3"> How can I help you? # Can you tell me how to move a file? Use mv.</Paragraph> <Paragraph position="4"> For example, to move the file named foo to the file named fool, type 'mv foo fool'.</Paragraph> <Paragraph position="5"> # Do you know how to delete a file named dekai? Type 'rm dekai'.</Paragraph> <Paragraph position="6"> # Do you know how to delete a file? Use rm.</Paragraph> <Paragraph position="7"> For example, to delete the file named foo, type 'rm foo'.</Paragraph> <Paragraph position="8"> # How can I delete the file charlie? Type 'rm charlie'.</Paragraph> <Paragraph position="9"> # How can I delete the file named tony? Type 'rm tony'.</Paragraph> <Paragraph position="10"> # How can I get rid of the file named boob? Type 'rm boob'.</Paragraph> <Paragraph position="11"> # I want to delete a file named peter. Type 'rm peter'.</Paragraph> <Paragraph position="12"> # I want to delete a file.</Paragraph> <Paragraph position="13"> Use rm.</Paragraph> <Paragraph position="14"> For example, to delete the file named foo, type 'rm foo'.</Paragraph> <Paragraph position="15"> # I want to delete the file dave. Type 'rm dave'.</Paragraph> <Paragraph position="16"> # How can I add read permission to a file? Use chmod.</Paragraph> <Paragraph position="17"> For example, to add individual read permission to the file named foo, type 'chmod u+r foo'. # Elow can I add the owner execute permission to a file'! Use', chmod.</Paragraph> <Paragraph position="18"> For example, to add individual execute permission to the file named foo, type 'chmod u+x foo'. # How can I change the group execute permission of a file? Use chmod.</Paragraph> <Paragraph position="19"> For example, to remove group execute permission from the file named foo, type 'chmod g-x foo'. # How can I change the user read permission of a file? Use chmod.</Paragraph> <Paragraph position="20"> For example, to remove individual read permission from the file named foo, type 'chmod u-r foo'. # How can I remove the group write permission from the file named bimbo? Type 'chmod g-w bimbo'.</Paragraph> <Paragraph position="21"> # ltow do I change the protection of a file? Use chmod.</Paragraph> <Paragraph position="22"> For example, to remove individual read permission from the file named foo, type 'chmod u-r foo'. # How can I compact a file? Use compact.</Paragraph> <Paragraph position="23"> For example, to compact the file named foo, type 'compact foo'.</Paragraph> <Paragraph position="24"> # How can I create a directory? Use mkdir.</Paragraph> <Paragraph position="25"> For example, to create the directory named foo, type 'mkdir foo'.</Paragraph> <Paragraph position="26"> # How can I find a file? Use whereis.</Paragraph> <Paragraph position="27"> For example, to find the file named foo, type 'where</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> Use mv. </SectionTitle> <Paragraph position="0"> For example, to move the file named foo to the file named blah, type 'mv foo blah'.</Paragraph> <Paragraph position="1"> # How can I move the file junk? Use mv.</Paragraph> <Paragraph position="2"> For example, to move the file named junk to the file named foo, type 'mv junk foo'.</Paragraph> <Paragraph position="3"> # How do I move a file? Use mv.</Paragraph> <Paragraph position="4"> For example, to move the file named foo to the file named fool, type 'mv foo fool'.</Paragraph> <Paragraph position="5"> # How do I change my directory? Use cd.</Paragraph> <Paragraph position="6"> For example, to connect to the directory named foo, type 'cd foo'.</Paragraph> <Paragraph position="7"> # How do I copy a file? Use cp.</Paragraph> <Paragraph position="8"> For example, to copy the file named foo to the file named fool, type 'cp foo fool'.</Paragraph> <Paragraph position="9"> # How do I copy the file foo to the file blah? Type 'cp foo blah'.</Paragraph> <Paragraph position="10"> # How do I create a directory? Use mkdir.</Paragraph> <Paragraph position="11"> For example, to create the directory named foo, type 'mkdir foo'.</Paragraph> <Paragraph position="12"> # How do I print a file named info? Type 'lpr info'.</Paragraph> <Paragraph position="13"> # I want to print a file.</Paragraph> <Paragraph position="14"> Use lpr.</Paragraph> <Paragraph position="15"> For example, to print the file named foo, type 'lpr foo'.</Paragraph> <Paragraph position="16"> # I want to change my working directory. Use cd.</Paragraph> <Paragraph position="17"> For example, to connect to the directory named foo, type 'cd foo'.</Paragraph> <Paragraph position="18"> # I want to copy the file named rick. Use cp.</Paragraph> <Paragraph position="19"> For example, to copy the file named rick to the file named foo, type cp 'rick foo'.</Paragraph> <Paragraph position="20"> # I want to delete a directory.</Paragraph> <Paragraph position="21"> Use rmdir.</Paragraph> <Paragraph position="22"> For example, to delete the directory named foo, type 'rmdir foo'.</Paragraph> <Paragraph position="23"> # I want to remove a directory.</Paragraph> <Paragraph position="24"> Use rmdir.</Paragraph> <Paragraph position="25"> For example, to delete the directory named foo, type 'rmdir foo'.</Paragraph> <Paragraph position="26"> # What's the best way to delete a directory? Use rmdir.</Paragraph> <Paragraph position="27"> For example, to delete the directory named foo, type 'rmdir foo'.</Paragraph> <Paragraph position="28"> # I want to display a file.</Paragraph> <Paragraph position="29"> Use more.</Paragraph> <Paragraph position="30"> For example, to display the file named foo, type 'more foo'.</Paragraph> <Paragraph position="31"> # I want to edit a file.</Paragraph> <Paragraph position="32"> Use vi.</Paragraph> <Paragraph position="33"> For example, to edit the file named foo, type 'vi foo'. # I want to find out Joe's address. Type 'finger joe'.</Paragraph> <Paragraph position="34"> # I want to remove a directory named junk. Type 'rmdir junk'.</Paragraph> <Paragraph position="35"> # What's the command to compact a file? Use compact.</Paragraph> <Paragraph position="36"> For example, to compact the file named foo, type 'compact foo'.</Paragraph> <Paragraph position="37"> # What is a directory? A directory is a file that is used to contain files. # What is a file? A directory is a container that is used to contain text, code or files.</Paragraph> <Paragraph position="38"> # What is arm? Rm is a command that is used to delete files. # What is a search path? A search path is a list of directories that is used by the csh to search for programs to execute.</Paragraph> </Section> </Section> <Section position="17" start_page="0" end_page="0" type="metho"> <SectionTitle> 1.5.2 MORE COMPLEX EXAMPLES % UC </SectionTitle> <Paragraph position="0"> Welcome to UC (Unix Consultant) version 3.23 To a UC '#' prompt, please type in your questions about the Unix file system in English.</Paragraph> <Paragraph position="1"> To leave, just type a 'AD' or '(exit)'.</Paragraph> <Paragraph position="2"> Hi.</Paragraph> <Paragraph position="3"> How can I help you? # Is rn used to rename files? No, rn is used to read news.</Paragraph> <Paragraph position="4"> To rename a file to another file, use mv. For example, to rename the file named foo to the file named fool, type 'mv foo fool'.</Paragraph> <Paragraph position="5"> In this example, UC hypothesized that the user asked the question in order to get an answer to some underlying question. In particular, PAGAN hypothesized possible goals of wanting to know how to rename a file and wanting to know what rn does. Since the answer to the direct question is negative, UCEgo realizes that the underlying goals are not addressed by this answer, and, therefore, attempts to answer them. This results in the extended answer.</Paragraph> <Paragraph position="6"> # How can I crash the system? I'm sorry, I cannot tell you.</Paragraph> <Paragraph position="7"> In this example, UC detected a conflict between its goal of helping the user and that of preserving the integrity of the system. It resolved this conflict in favor of the latter Computational Linguistics, Volume 14, Number 4, December 1988 41 Robert Wilensky, David N. Chin, Marc Luria, James Martin, James Mayfield, and. Dekai Wu The Berkeley UNIX Consultant Project goals. However, since it could not accommodate the user's request, it attempts to be polite by apologizing to the user.</Paragraph> <Paragraph position="8"> # What does Is -v do? Ls does not have a -v option.</Paragraph> <Paragraph position="9"> Here, the user asks about a nonexistent command option. Actually, the UNIX 'Is' command ignores options that it does not recognize, so the consultant could have answered truthfully by saying that 'Is -v' causes one's directory to be listed. It did not, because PAGAN interpreted the request as a question about the function associated with the command. UCEgo reasons that, since (1) it doesn't know about such an option, and (2) it knows all the options to all simple commands, and (3) Is is a simple command, the user must have a misconception. It then generates the goals of correcting the misconception, which results in the answer shown.</Paragraph> <Paragraph position="10"> Note that UC uses an open-world hypothesis together with metaknowledge to determine whether it knows some facts about UNIX.</Paragraph> <Paragraph position="11"> In the next example, two different sessions with two different users are represented.</Paragraph> </Section> <Section position="18" start_page="0" end_page="0" type="metho"> <SectionTitle> % UC </SectionTitle> <Paragraph position="0"> Welcome to UC (Unix Consultant) version 3.23 To a UC '#' prompt, please type in your questions about the Unix file system in English.</Paragraph> <Paragraph position="1"> To leave, just type a 'AD' or '(exit)'.</Paragraph> <Paragraph position="2"> Hi.</Paragraph> <Paragraph position="3"> How can I help you? # How can I delete a file? Use rm.</Paragraph> <Paragraph position="4"> For example, to delete the file named foo, type 'rm foo'.</Paragraph> <Paragraph position="5"> # What does rwho do? Rwho is used to list all users on the network, the users' tty, the users' login time, and the users' idle time.</Paragraph> </Section> <Section position="19" start_page="0" end_page="0" type="metho"> <SectionTitle> % UC </SectionTitle> <Paragraph position="0"> Welcome to UC (Unix Consultant)version 3.23 To a UC '#' prompt, please type in your questions about the Unix file system in English.</Paragraph> <Paragraph position="1"> To leave, just type a 'AD' or '(exit)'.</Paragraph> <Paragraph position="2"> Hi.</Paragraph> <Paragraph position="3"> How I can I help you? # How can I find out the inode of a file? Use Is -i.</Paragraph> <Paragraph position="4"> # What does rwho do? Rwho is like who, except rwho lists all users on the network.</Paragraph> <Paragraph position="5"> Because he asked such a simple question, the first user was diagnosed by KNOME as being a novice user. This resulted in the answer to his first question being illustrated by an example, and the extended format of his answer to the second. In contrast, the second user asked about a relatively technical aspect of UNIX. Thus this user is likely to be a relatively sophisticated user. As a result, the answer to that user's first question was not illustrated with an example. For the same reason, UC presumes that the second user knows about the 'who' command, and takes advantage of this knowledge in generating the response.</Paragraph> <Paragraph position="6"> Note this example also illustrates UC's ability to generate different types of responses. This example was able to use a simile format, because the command to be generated was thought to be sufficiently close to one UC believes the user to already know. Formating is discussed in section 8.</Paragraph> <Paragraph position="7"> The next example illustrates some aspects of UC's ability to generate plans.</Paragraph> <Paragraph position="8"> # How do I print Jim's file on the lineprinter? Use lpr. This plan will not work if you don't have read permission on Jim's file.</Paragraph> <Paragraph position="9"> In this example, KIP, UC's domain planner, suspects that the plan it is suggesting might fail. This is because the plan involves printing someone else's file, and KIP knows that the lack of appropriate permission in such cases is a likely source of plan failure. However, since it does not know a more certain plan, it delivers the suspect one, but warns the user of the possible problem. A fact about a possible problem with a plan is called a concern. Concerns are explicitly represented in UC's knowledge base. At this stage, UC's knowledge of concerns is fragmentary. Thus questions above that have the same structure as this one may not cause any warnings to be generating simply because the requisite knowledge is lacking. Concerns are discussed further in Section 7.2.3 below.</Paragraph> <Paragraph position="10"> # Who is on the system? I'm sorry, I don't know. Use users to find out who is on the system.</Paragraph> <Paragraph position="11"> Here, UC fails to answer the user's question, because it does not have any way of running UNIX commands itself. Its failure causes it to apologize. UC then forms the goal of the user knowing how to determine the requested information. It addresses this goal, which leads to the second part of the response.</Paragraph> </Section> <Section position="20" start_page="0" end_page="0" type="metho"> <SectionTitle> 2 KODIAK </SectionTitle> <Paragraph position="0"> The knowledge used by UC is represented in KODIAK, as are the various stages of the processing of an utterance. KODIAK (Keystone to Overall Design for Integration and Application of Knowledge) is an implementation of CRT (Cognitive Representation Theory), an approach to knowledge representation that bears similarities to numerous other systems, but especially those of Schank (1975), Schubert (1976), Shapiro (1979), and Brachman and Schmolze (1985). KODIAK differs from these systems in significant ways; however, here we shall try to trivialize rather than accentuate these differences so that the reader can relate our representa42 Computational Linguistics, Volume 14, Number 4, December 1988 Robert Wilensky, David N. Chin, Marc Luria, James Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project tions to more familiar ones. The reader should consult Wilensky (1986) for a more detailed account and justification of this representation system.</Paragraph> <Paragraph position="1"> KODIAK is a relation-oriented rather than object-oriented system. In an object-oriented system, one thinks of objects as having slots, and the representational weight is carried by such structured objects. In a relation-oriented system, objects are thought of as atomic elements, and knowledge is captured by the relations in which these objects participate.</Paragraph> <Paragraph position="2"> For example, suppose we want to represent a concept like &quot;state change&quot;, i.e., an event in which some state is thought of as changing into another state.</Paragraph> <Paragraph position="3"> Among other things, we would like to capture the fact that any state change has an initial state and a final state. In KODIAK, we would represent this by first creating objects corresponding to the concepts STATE-CHANGE and STATE. Then we would indicate that a relation, say, INITIAL-STATE, holds between each instance of a state change and some instance of a state.</Paragraph> <Paragraph position="4"> Similarly, another relation, say, FINAL-STATE, holds between each state change and some state.</Paragraph> <Paragraph position="5"> This description sounds equivalent to saying that INITIAL-STATE and FINAL-STATE are slots of STATE-CHANGE. For the purposes of this paper, we will not strenuously resist this interpretation. However, the underlying philosophy (and actual representation) is different. In particular, rather than accounting for the relatedness of STATE-CHANGE and INITIAL-STATE and FINAL-STATE by creating a primitive notion of slot and asserting that the latter two items are slots in the former, this relatedness is simply attributed to the fact that every STATE-CHANGE participates in an INITIAL-STATE relation and a FINAL-STATE relation. On the other hand, we think of these relations as being less closely related to STATE because not every state participates in these relations.</Paragraph> <Paragraph position="6"> In our terminology, we refer to objects like STATE and STATE-CHANGE as absolutes, and the relations in which they participate, such as INITIAL-STATE and FINAL-STATE, as aspectuals. The motivation for having a more fine grain representation than objects with slots is described in Wilensky (1986). However, here we shall use a more conventional notation for the sake of exposition. For example, we will write the above facts about state changes using the following notation:</Paragraph> <Paragraph position="8"> This diagram should be interpreted as follows: the individual instances of the concept STATE-CHANGE always participate in two relations, one called INITIAL-STATE and one called FINAL-STATE. That is, if we ever encountered an individual of the concept STATE-CHANGE, it will be in an INITIAL-STATE and a FINAL STATE relation to something. The circles themselves represent the idea of being in a given relation to something. Thus they correspond most closely to the roles of other systems.</Paragraph> <Paragraph position="9"> Of course, there is much more to say about state changes. For example, we have not yet expressed the fact that the other argument to both INITIAL-STATE and FINAL-STATE must always be a state. Also, the state that is in a INITIAL-STATE relation to a state change always occurs before the state that is in the FINAL-STATE relation. STATE-CHANGE itself is a type of event. We will now describe how such facts are represented.</Paragraph> <Paragraph position="10"> We represent individuals of a concept, and subtypes of a concept, using KL-ONE-Iike structured inheritance technique. For example, to represent an instance of a state change, we would create the following structure:</Paragraph> <Paragraph position="12"> The instantiate (I) link states that STATE-CHANGE 1 is an individual STATE-CHANGE. Initial-statel should be interpreted as the assertion that the initial state relation holds between STATE-CHANGEI and some (as yet unspecified) value; the surrounding circle represents the idea of being in the initial state relation to STATE-CHANGE1. We sometimes say that initial-state l plays the role of the initial-state relation with respect to STATE-CHANGE1.</Paragraph> <Paragraph position="13"> Note that role-play is a relation between a relation and its use, not a relation between a role and its filler. Indeed, the values to which initial-state and final-state connect STATE-CHANGE1 have not yet been de-Computational Linguistics, Volume 14, Number 4, December 1988 43 Robert Wilensky, David N. Chin, Marc Luria, James Martin, James Mayfieid, and Dekai Wu The Berkeley UNIX Consultant Project picted. To include these values in our representation, we use the value (V) link. Thus we would typically find instances like the above elaborated to include the following: state and final-state must be an instance of a STATE, we would ,draw a constrain (C) link from the circles labeled initial-state and final-state to a box labeled STATE, as in the following diagram:</Paragraph> <Paragraph position="15"> That is, the initial-state relation holds between STATE-CHANGE1 and something called STATE1, and the final-state relation holds between STATE-CHANGE1 and something called STATE2. In other terminology, the object at the end of the value link represents the filler, and the object at the source, the slot. Presumably, we would also include what other information we knew about STATEI and STATE2, namely, what categories they are instances of, etc.</Paragraph> <Paragraph position="16"> We can abbreviate this notation if we have no need for the showing the slots of an individual, but merely their fillers. We do this by drawing a labeled link directly to the target of the value link. For example, we could simplify the above two diagrams by drawing a link labeled initial-state between STATE-CHANGE1 and STATE1, and one labeled final-state between STATE-CHANGE1 and STATE2. Thus it is sometimes convenient to draw the following.</Paragraph> <Paragraph position="18"> initial-state final-state These links would be interpreted as saying that any object in a Value relation with a use of initial state or final state must be of type STATE.</Paragraph> <Paragraph position="19"> Subtypes are represented using a Dominate (D) link instead of an Instantiate (I) link. The aspectuals are created for the subtype that play the role of the aspectuals of the parent. These are typically differentiated from those of the parent concept by being subject to a further constraint. For example, we can begin to define dying as a kind of state change as follows:</Paragraph> <Paragraph position="21"> Usually, the aspectuals of a concept are constrained so that their other argument must be of a certain type. For example, to indicate that the other argument to initial-We have represented DEATH-EVENT as being a kind of STATE-CHANGE in which the initial state is con44 Computational Linguistics, Volume 14, Number 4, December 1988 Robert Wilensky, David N. Chin, Marc Luria, James Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project st.,. o cate objec, s / \ * I degEA &quot; EWN I state strained to be a state of something being alive, and the final state to be that of something being dead.</Paragraph> <Paragraph position="22"> In this diagram, we have not bothered to show the constraints on the aspectuals of STATE-CHANGE. In general, we will only show those parts of previous concepts that are pertinent to the knowledge being represented. Also, we introduced a new aspectual, dier, which specializes patient. Patient is inherited from some quite abstract absolute, which ultimately dominates STATE-CHANGE, and which has the meaning &quot;event that affects an object&quot;. Also, since patient is an aspectual of some concept dominating STATE-CHANGE, we should have specialized it at STATE-CHANGE, say, to state-change-object. However, when such specialized versions of relations are not substantially differentiated from their ancestors, we will use the ancestor's name instead. The KODIAK interpreter understands the occurrence of an inherited relation as being the most specific inheritable specialization of that relation, so using the more abstract name has the same semantics of using the more specialized one.</Paragraph> <Paragraph position="23"> One item missing from this diagram is the fact that the fellow who dies is the same fellow as the one who was alive and then was dead. This fact can be captured with the aid of the Equate (=) link. This is similar to KL-ONE's role chains. For example, we can improve our representation for dying by creating a state of being alive and a state of being dead, and then using Equate links to state the relationships between their components.</Paragraph> <Paragraph position="24"> In the diagram above, we state that the dier of DEATH-EVENT is the same as the is-alive-object of some IS-ALIVE state, and also the same as the is-deadobject of some is-dead state.</Paragraph> <Paragraph position="25"> The Equate links belong to a particular absolute. For example, in the diagram above, the Equate links emanating from dier belong to DEATH-EVENT. The significance of this fact is that it is true of dying that there must be an associated event of being alive, but it is not true of being alive that there must be a death event. We represent this aspect of Equates by the direction of the arrows in the diagram.</Paragraph> <Paragraph position="26"> Having defined DEATH-EVENT, it is easy to represent a concept like killing, assuming an analysis in which killing is a kind of causing in which the thing caused is a kind of death event.</Paragraph> <Paragraph position="27"> Here we define KILL as being a subtype of CAUS-Computational Linguistics, Volume 14, Number 4, December 1988 45 Robert Wilensky, David N. Chin, Marc Luria, James Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project</Paragraph> <Paragraph position="29"> ~/~~'~ patient caus~ AL-EVENT. CAUSAL-EVENT is a concept shown as participating in an effect and a cause relation. KILL is also shown as participating in a kill-effect and a kill-cause relation. Because effect and cause are written on the links to these relations, we know that kill-effect is just a specialized version of the effect relation, and that kill-cause is a specialized version of cause. To differentiate KILL from CAUSAL-EVENT, we need to capture the fact that the effect of a kill is a death event. The additional semantics of kill-effect (and thereby, of KILL) come from the constrain link on kill-effect. This says that the effect of a KILL is a DEATH-EVENT.</Paragraph> <Paragraph position="30"> Finally, we use an Equate link to state that the person killed is the same one as the one who died.</Paragraph> <Paragraph position="31"> Of course, many parts of the meaning of these simple concepts have been omitted from these diagrams. For example, we have not stated any information about time, such as the fact that the initial state precedes the final state. In general, the diagrams presented in this paper have been simplified to present the crucial knowledge needed without being even more complex than they already are.</Paragraph> <Paragraph position="32"> KODIAK has additional features that are not described herein. The reader is referred to Wilensky (1986) for a more complete description. A summary of all the KODIAK features used in this report is found in the legend in Figure I.</Paragraph> <Paragraph position="33"> Note that the legend contains one additional abbreviation, namely, that drawing a link bearing the name of a relation between two categories is interpreted as stating that the individuals of the domain category participate in that relation with some member of the range category.</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 2.1 UNIX KNOWLEDGE IN UC </SectionTitle> <Paragraph position="0"> The KODIAK knowledge representations used in UC include several rather general notions, such as state change, goal, and action, plus many specific facts about UNIX. The complete collection is too lengthy to include here. (UC is currently constructed from approximately 200 KODIAK diagrams, consisting of about 1,000 absolutes and 2,000 relations. While a scope of a diagram is to some degree arbitrary, diagrams roughly correspond to definitions of meaningful entities, like the definition a particular command.) Some more important concepts used in modeling the domain will be explained in the individual sections of this report.</Paragraph> <Paragraph position="1"> To facilitate understanding the KODIAK diagrams that follow, consider the representation that the UC's knowledge base contains about the UNIX rm command. This is used to delete a file named by its argument. The following diagram shows how knowledge about deletion is represented in UC.</Paragraph> <Paragraph position="2"> The central node in this diagram is DELETE-EF-FECT. DELETE-EFFECT is shown as being a kind of STATE-CHANGE that causes a something to go from existence to nonexistence. (The notions of existence and negation do play a special role in KODIAK, but also exist as ordinary states, as is the case here. From the point of view of this example, these are just like any other states.) DELETE-EFFECT specifies the minimal deletion event. For example, it says nothing about the cause of such an event, or who the actor of it may be. In UC in particular and in CRT in general, such state changes are the bases from which we build more elaborate concepts.</Paragraph> <Paragraph position="3"> For example, the action of deleting something is represented as an action that causes something to be deleted. The argument to O is constrained to be of type \[CATEGORY . The value of the argument to O is ~.</Paragraph> <Paragraph position="4"> The first aspectual is constrained to have the same value as the second.</Paragraph> <Paragraph position="5"> O is an aspectual of CATEGORY, and O specializes rel, an aspectual of some concept dominating CATEGORY.</Paragraph> <Paragraph position="6"> Each member of CATEGORYI participates in re! with some member of CATEGORY2.</Paragraph> <Paragraph position="8"> Computational Linguistics, Volume 14, Number 4, December 1988 47 Robert Wilensky, David N. Chin, Marc Luria, James Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project</Paragraph> <Paragraph position="10"> This is encoded by showing DELETE-EFFECT to be the effect of DELETE-ACTION.</Paragraph> <Paragraph position="11"> Using names like DELETE-EFFECT may be somewhat misleading. In particular, DELETE-EFFECT is not required to be the effect of anything--while DELETE-ACTION is defined as having DELETE-EFFECT as its result, this statement imposes a requirement on DELETE-ACTION, not on DELETE-EF-FECT. We call such concepts effects rather than events, say, to emphasize that we me, an to include only the most essential elements of the concept, i.e., just a specialized state change.</Paragraph> <Paragraph position="12"> DELETE-FILE-EFFECT is a specialized version of DELETE-EFFECT in which the object deleted is constrained to be a file. DELETE-ACTION is correspondingly specialized to DELETE-FILE-ACTION. It is also shown as being a kind of TRANSITIVE-ACTION. This is a very general category denoting any action that acts upon an object.</Paragraph> <Paragraph position="13"> This sort of structure, in which there exists parallel effect and action hierarchies, with the effect hierarchy carrying most of the semantic weight, is typical of the representation that appear in UC.</Paragraph> <Paragraph position="14"> The figure above connects this general knowledge about deletion with knowledge about UNIX.</Paragraph> <Paragraph position="15"> Here we state how to achieve a DELETE-FILE-EFFECT. This accomplished by the node labeled PLANFOR2, which points to EXECUTE-UNIX-RM-COMMAND and to DELETE-FILE-EFFECT. A PLANFOR indicates that something is conceptualized as a plan for a particular goal (PLANFORs are discussed below). In other words, this notation represents the particular fact that the 'rm' command (i.e., the command whose name is &quot;rm&quot;) is used to achieve the effect of deleting a file. Again, this structure is typical of that seen in UC--most of the information about a command is represented as information about the use of that command; the intended function of the use of a command is represented by a planfor between a node representing the use of the command and some effect.</Paragraph> <Paragraph position="16"> The rest of the diagram specifies the format of the command. In particular, the Equate link specifies that, to delete a particular file, its name must be the same as that of the argument supplied to 'rm.' A TOUR THROUGH UC The following sections describe the components of UC in more detail. To aid in understanding how these components contribute to the processing of an individual utterance, we show how each section processes the example sentence &quot;Do you know how to print a file on the imagen \[a kind of laser printer used at our site\]?&quot; In most cases, a module is capable of doing a great deal more than is required for this example, and such capabilities are attested to. However, the example is useful for illustrating the kind of processing that is performed for a typical request.</Paragraph> <Paragraph position="17"> In order to produce a paper of reasonable length, we 48 Computational Linguistics, Volume 14, Number 4, December 1988 Robert Wilensky, David N. Chin, Marc Luria, James Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project</Paragraph> </Section> </Section> <Section position="21" start_page="0" end_page="0" type="metho"> <SectionTitle> ACTION \[ </SectionTitle> <Paragraph position="0"/> <Paragraph position="2"> reduced considerably the description of some of UC's modules. We have focused on those processes that contribute to UC's agentlike nature, while some more conventional modules, such as the conceptual analyzer, are mentioned only in passing. References are given to descriptions of these neglected components, which have all appeared elsewhere in print, should the reader find the account herein dissatisfying.</Paragraph> </Section> <Section position="22" start_page="0" end_page="0" type="metho"> <SectionTitle> 3 THE ANALYZER </SectionTitle> <Paragraph position="0"> A conceptual analyzer maps a string of words into a meaning representation. ALANA (Augmentable LANguage Analyzer), the conceptual analyzer for UC, takes as input a sentence typed by a user, and builds a conceptual representation using the KODIAK knowledge representation language. ALANA constructs the primal content of the input utterance. The primal content is the interpretation that can be computed from grammatical and lexical knowledge; it is generally rather abstract. ALANA's results are further interpreted and refined by other parts of the system, such as the concretion mechanism, to produce an actual content, and the goal analyzer, to produce a representation of the intentions underlying the utterance.</Paragraph> <Paragraph position="1"> ALANA is a descendent of PHRAN (Wilensky and Arens 1980), the front end natural language component for the original UC (Wilensky, Arens, and Chin 1984).</Paragraph> <Paragraph position="2"> Like PHRAN, ALANA reads the user's input and forms a concept that the other UC components can use for their tasks. Also like PHRAN, the ALANA uses as its primitive knowledge unit the pattern-concept pair, which relates a natural language structure to a conceptual structure. UC has a total of 476 patterns and knows 284 words.</Paragraph> <Paragraph position="3"> ALANA differs from PHRAN in its generality.</Paragraph> <Paragraph position="4"> ALANA generalizes on the idea of pattern concept pair analysis, while making it easier than it was with PHRAN for a knowledge adder to add new patterns to the system. Since a more detailed description of ALANA can be found in Cox (1986), we will not elaborate on it here. Instead, we merely show in Figure 2 the output produced by ALANA upon reading the sentence &quot;Do you know how to print a file on the imagen?&quot;.</Paragraph> <Paragraph position="5"> This diagram may be interpreted as follows: The entire request is summarized as ASKll, i.e., some asking event. What is asked for is verification of some item, QUESTIONll, whose content is KNOW3, i.e., an instance of knowing. The knower of the item is UC, and the fact is ACTION6. ACTION6 is interpreted as something that is the cause of a printing action PRINT-ACTION0, which is itself an action whose effect (PRINT-EFFECT0) is to cause a file (FILE6) to be printed on an imagen printer (IMAGEN0).</Paragraph> <Paragraph position="6"> Some of the nodes in this diagram point to a node labeled HYPOTHETICAL. This is a tentative convention used to indicate that the knowing and printing event, etc., are not real events, but merely hypothetical ones.</Paragraph> </Section> <Section position="23" start_page="0" end_page="0" type="metho"> <SectionTitle> 4 THE CONCRETION MECHANISM 4.1 INTRODUCTION </SectionTitle> <Paragraph position="0"> A concretion inference is a kind of inference in which a more specific interpretation of an utterance is made Computational Linguistics, Volume 14, Number 4, December 1988 49 Robert Wilensky, David N. Chin, Marc Luria, arames Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project than can be sustained on a strictly logical basis (Norvig 1983, Wilensky 1983). Examination of contextual clues provides the means to determine which of many possible interpretations are likely candidates. An example of a simple type of concretion inference occurs in understanding that &quot;to use a pencil&quot; means to write with a pencil, whereas &quot;to use a dictionary&quot; means to look up a word.</Paragraph> <Paragraph position="1"> Concretion differs classification such as that of KL-ONE (Schmolze and Lipkis 1983, Brachman and Schmolze 1985) in that a concretion inference may be incorrect. Ordinarily, &quot;to use a pencil&quot; implies writing; however, in a particular context, it may refer to propping a door open with a pencil. Nevertheless, in the absence of compelling evidence to the contrary, the natural interpretation is writing. Thus concretion may be thought of as defeasible classification.</Paragraph> <Paragraph position="2"> A process that performs concretion is called a concretion mechanism. A concretion mechanism attempts to find clues in a set of general concepts to generate concepts that are more specific. Writing, for instance, is a specific type of using, in which the tool being used may be a pencil. The use of such a mechanism permits a straightforward approach to manipulating hierarchical knowledge structures. The initial interpretation of an utterance may include concepts too general for the utterance to be considered understood. Such general concepts embody the common features of their descendent concepts, but for some reason insufficiently specify the meaning of the utterance. Thus the concretion mechanism is responsible for making an appropriate interpretation of a concept by selecting one of its subconcepts, found lower in the hierarchy.</Paragraph> <Paragraph position="3"> In deciding when concretion operations should be performed, it is critical to consider how specific a concept's representation must be to be understood.</Paragraph> <Paragraph position="4"> Different levels of categorization are considered adequate from situation to situation. For instance, it is perfectly acceptable in most circumstances to leave the interpretation of&quot;eating&quot; as &quot;eating some food&quot;. However, in a context involving picnics, a more specific interpretation is likely to be made, namely, that the eating involved paper plates, that people sat on the ground or at a picnic table, that the food was of a certain type, and so forth. In general, in cases where a more specific category than usual is requisite, often some feature of the prototype of the supercategory is violated, resulting in a higher probability of selecting a subcategory where this feature is accommodated.</Paragraph> <Paragraph position="5"> It is important that the mechanism be able to recognize from a wide variety of clues when there is sufficient evidence to concrete, as well as when an ambiguity needs to be resolved. A uniform method of representing the rules by which a concretion may be made is required. Naturally, wrong inferences can occasionally be made, and some means must therefore be provided to find and correct them when contradictory facts are learned.</Paragraph> </Section> <Section position="24" start_page="0" end_page="0" type="metho"> <SectionTitle> 4.2 CONCRETION IN UC </SectionTitle> <Paragraph position="0"> As mentioned previously, our theoretical posture is that concretion is but one of a number of inference processes that can be accomplished by a single mechanism. However, in UC, for reasons of efficiency, and for pragmatic advantages, a separate concretion mechanism was implemented (by Dekai Wu). This mechanism currently does rather straightforward classification.</Paragraph> <Paragraph position="1"> The mechanism concretes by using information about inheritance and value constraints, as well as by considering relation information between concepts. A concept represented as an instance of a category is passed to the concretion mechanism. Its eligibility for membership in a more specific subcategory is determined by its ability to meet the constraints imposed on the subcategory by its associated relations and aspectual constraints. If all applicable conditions are met, the concept becomes an instance of the subcategory. At the same time, the relations in which the concept participates may be concreted to reflect the more specific relations of the new category of which it is inferred to be a member.</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.3 EXAMPLE </SectionTitle> <Paragraph position="0"> Consider the example &quot;Do you know how to print a file on the Imagen?&quot;. The subpart &quot;print a file on the Imagen&quot; is parsed into the representation shown in Figure 3. Parts of the representation of printing are shown in Figure 4.</Paragraph> <Paragraph position="1"> Besides the printing of the contents of a computer file, PRINT-EFFECT is in principle applicable to other types of printing, such as printing a newspaper or a book. The concretion mechanism checks each of the more specific concepts dominated by PRINT-EFFECT, searching for one whose constraints can be satisfied by the input. It finds PRINT-FILE-EFFECT, whose only additional constraint is that its print-object must be a</Paragraph> <Paragraph position="3"> file. Since PRINT-EFFECT0 is in print-object relation with the object FILE6, which is indeed an instance of file, the process can descend to this node. The concretion process will continue until it can concretize no further.</Paragraph> <Paragraph position="4"> Of course, it is perfectly plausible just to preclude from UC on engineering grounds interpretations of words that do not occur in the UNIX domain. As we suggested earlier, it is our preference not to do so, since we wish to address, rather than finesse, fundamental language issues. However, doing so would not really eliminate the need for concretion. Even if we do not include concepts of non-computer printing in our knowledge base, we would still have many different kinds of printing, e.g., printing ASCII files versus binary files or printing on the lineprinter versus the laser printer. A query about each of these kinds of printing requires a different response, although the term &quot;printing&quot; applies to all of these. A system like UC needs to concrete the concept of printing in general to the particular kinds of printing that it knows about, in order to find the knowledge needed to answer the question. Thus eliminating interpretations that lie outside the domain simplifies the problem somewhat, but it does not change its essential nature.</Paragraph> <Paragraph position="5"> In general, when concretion occurs, some node is reclassified as being an instance of a more specific category, and, in addition, the relations predicated about that node are also reclassified. For example, here we concretize PRINT-EFFECT0 to an instance of PRINT-FILE-EFFECT. At the same time, we should concrete the relation print-object predicated about it to a use of the more specific relation print-file-object.</Paragraph> <Paragraph position="6"> Similarly, print-dest is concreted to print file-dest.</Paragraph> <Paragraph position="7"> Computational Linguistics, Volume 14, Number 4, December 1988 51 Robert Wilensky, David N. Chin, Marc Luria, James Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project</Paragraph> <Paragraph position="9"/> <Paragraph position="11"> Continuing in this fashion, the mechanism can move from PRINT-EFFECT to LASER-PRINT-EFFECT, and finally to IMAGEN-PRINT-EFFECT, since the print-dest of the input is IMAGEN0, which is an instance of IMAGEN. At the same time, the relation print-dest is concreted to imagen-dest. In parallel with this concretion, the node PRINT-ACTION0 gets concretized to an instance of IMAGEN-PRINT-ACTION.</Paragraph> <Paragraph position="12"> The final result is shown in Figure 5.</Paragraph> </Section> </Section> <Section position="25" start_page="0" end_page="0" type="metho"> <SectionTitle> 5 THE GOAL ANALYZER </SectionTitle> <Paragraph position="0"> Once an utterance has been converted to a KODIAK representation by ALANA, and has been further refined by the concretion mechanism, this internal representation is passed to PAGAN (Plan and Goal ANalyzer). PAGAN's task is to determine what goals the speaker is addressing in making the utterance. For example, when given a representation of the utterance 1. Do you know how to print a file on the Imagen? asked by a naive user, PAGAN should infer that the user was using the utterance to address the goal of knowing how to print a file on the Imagen. Note that PAGAN is not responsible for detecting goals that are held by the speaker, but that are not conveyed by the speaker's utterances. This problem is addressed by the ego mechanism and by the planner.</Paragraph> <Paragraph position="1"> To successfully do goal analysis, at least two questions must be answered. The first concerns the utterance in isolation.</Paragraph> <Paragraph position="2"> Q1. What kind of act does this utterance constitute? This question has traditionally fallen under the rubric of speech-act theory (Austin 1962, Searle 1969). For example, (1) potentially has both a direct and indirect interpretation, which PAGAN must choose between.</Paragraph> <Paragraph position="3"> The second question a goal analysis mechanism must answer examines the role of the utterance in conversation. null Q2. How does this utterance relate to other utterances? null By virtue of being an action, an utterance always occurs within a context. This context includes such diverse factors as the identities of the speaker and of the audience, the social relationship between them, the physical locale, the task the conversation is supple- null menting if any, and so on. One feature of this context that is salient to goal analysis is the presence of conventional, multi-utterance sequences. Consider the exchange: null 2. Do you have write permission on the parent directory? 3. Yes.</Paragraph> <Paragraph position="4"> The ability to understand the full meaning of (3) is contingent on the realization that it relates directly and conventionally to (2). Thus PAGAN will require knowledge of such sequences to correctly determine the goal underlying utterances such as (3).</Paragraph> <Paragraph position="5"> 52 Computational Linguistics, Volume 14, Number 4, December 1988 Robert Wilensky, David N. Chin, Marc Luria, James Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project</Paragraph> </Section> <Section position="26" start_page="0" end_page="0" type="metho"> <SectionTitle> 5.1 KNOWLEDGE REPRESENTATION FOR PAGAN </SectionTitle> <Paragraph position="0"> A planfor is a relation between a goal and a sequence of steps (called a plan) that constitutes a possible method of achieving that goal. All PAGAN's knowledge of conversation is stored as planfors.</Paragraph> <Paragraph position="1"> Planfors provide a means to address the questions posed above. First, indirect speech acts can be expressed as planfors. For example, the generic indirect speech act underlying (3) can be expressed as: PLANFOR1 GOAL: Speaker ask hearer how to perform task PLAN: Speaker ask hearer whether hearer knows how to perform task Second, planfors provide a means to express conventionalized relationships between utterances. Utterance 1 and its answer can be represented as: GOAL: Speaker know how to perform task PLAN: Speaker ask hearer how to perform task Hearer tell speaker how to perform task (In general, steps of a plan that are to be executed by someone other than the planner are interpreted as the planner waiting for that event to happen.) Representing both speech act knowledge and conversational knowledge with planfors has two advantages. First, it allows a single mechanism to handle the processing of both phenomena. The goal analysis mechanism described below does just this. Second, it allows the two forms of knowledge to be combined into a single structure. For example, the two preceding planfors can be combined to express both the indirect speech act and the question and answer sequence.</Paragraph> <Paragraph position="2"> PLANFOR3 GOAL: Speaker know how to perform task PLAN: Speaker ask hearer whether hearer knows how to perform task Hearer tell speaker how to perform task The KODIAK representation of a planfor is shown in Figure 6. Figure 7 depicts PLANFOR3 in its KODIAK form. (It is called PLANFOR34 in the knowledge base). It is a planfor whose goal is to know a fact which is itself a plan for some goal. (The names of the aspectuals not used to make a predication have been omitted from the diagram.) The plan of PLANFOR34 is for the person who wants to know this action to ask someone whether that person knows the action sought, and then, to have that same person tell the asker what was desired. Note that planfors do not represent fundamental knowledge of causality. There is usually a causal relationship between a plan and a goal that are connected by a planfor. However, the planfor itself does not represent the causality. What a planfor does represent is a notion of typicality. It indicates that its plan is one that is typically or conventionally used to achieve its goal. For example, the UNIX 'rm' command may cause a file to be deleted. It may also cause the disk arm to be moved. It would be a mistake though to say that 'rm' should be connected to the goal of moving the disk arm by a planfor relation; 'rm' is not typically used to move the disk arm. On the other hand, 'rm' should be connected to the goal of deleting a file by a planfor relation, since this goal is what 'rm' is typically used for.</Paragraph> <Paragraph position="3"> Traditional approaches to dialog understanding have focused on the process of plan inference. Under this approach, utterances are viewed as steps of plans. Such plans may themselves be parts of higher-level plans, and so on. Allen and Perrault (1980) developed a system that exemplifies this approach. Their system handled direct and indirect speech acts by plan analysis. Carberry (1983) extended this paradigm to deal more thoroughly with domain plans. Litman and Allen (1984) used the notion of metaplans (Wilensky 1983) to facilitate the comprehension of subdialogs. Grosz and Sidner (1985) pointed out the need for attentional knowledge in understanding discourse. One problem that has persisted in the literature is an inadequate representation of the relationship between goals and plans. Planfors provide such a representation.</Paragraph> <Paragraph position="4"> Planfors allow a goal analysis mechanism to combine certain inferences that should be kept together. First, inferences about plans may be made at the same time as those about goals. This is in contrast with systems such as Wilensky's PAM system (1983) that use separate representations for inferring plans and goals. Second, inferences about plan recognition and inferences about intended response recognition may be combined by including the intended response in the plan and associating this entire plan with a single goal. This is in contrast with systems such as Sidner's (1985) that first do plan recognition and then worry about what response was intended. The ability to do both kinds of inference simultaneously conforms to the intuition that no extra processing is required to determine, for example, that an answer is required once the realization is made that a question has been asked. Finally, planfors allow inferences about linguistic goals and about domain goals to be handled by a single inference engine. The separation of goal analysis into linguistic goal reasoning and Computational Linguistics, Volume 14, Number 4, December 1988 53 Robert Wilensky, David N. Chin, Marc Luria, James Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project</Paragraph> <Paragraph position="6"> task goal reasoning (cf. Alien, Frisch, and Litman 1982) is unnecessary, since the only difference between the two is the type of action that may comprise plan steps.</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 5.2 GOAL ANALYSIS </SectionTitle> <Paragraph position="0"> When knowledge of goals and plans is represented with planfors, goal analysis is the task of matching the representations produced by the language analyzer against the steps of plans stored in memory. The goal held by a speaker in making an utterance is then the goal that is associated with the matched plan via the planfor relation.</Paragraph> <Paragraph position="1"> In the absence of any previous conversational context, an utterance to be analyzed is compared with the first plan step of each planfor that PAGAN knows about. When a match is found, the corresponding goal is taken to be the goal the speaker had in mind in making the utterance.</Paragraph> <Paragraph position="2"> Several phenomena complicate this view of goal analysis. First, a speaker may intend a single utterance to be a part of more than one plan. For example, (1) is a plan for the goal of knowing how to print a file.</Paragraph> <Paragraph position="3"> Achieving this goal may in turn be part of a plan for actmdly printing a file. To handle such situations, PAGAN must apply the matching process recursively on each inferred goal. This matching process is repeated until no further higher-level goals can be inferred.</Paragraph> <Paragraph position="4"> Second, preceding conversational events may set up expectations in relation to which an utterance is designed to be understood. For example, (3) cannot be readily interpreted when viewed in isolation. However, if it is used in response to a question such as (2), its interpretation is clear. Two additions must be made to the matching algorithm to handle this and similar cases. First, before matching the utterance to plans in the planfor knowledge base, the utterance must be matched against the next step of any active planfor (i.e., any planfor already inferred but not yet completed). In this example, the representation of (3) would be matched against the second step of the question and answer plan started by (2) to determine if it is a response to the question. Second, when a match with a new planfor is</Paragraph> </Section> </Section> <Section position="27" start_page="0" end_page="0" type="metho"> <SectionTitle> 54 Comput~ttional Linguistics, Volume 14, Number 4, December 1988 </SectionTitle> <Paragraph position="0"> Robert Wilensky, David N. Chin, Marc Luria, James Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project found, PAGAN may also need to infer that the speaker has adopted the matched planfor. Suppose UC says (2) to the user. Here, UC is initiating a plan for the goal of knowing whether the user holds the indicated permission. But, at the moment, this goal is held only by UC; it is reasonable that the user might not address the goal at all. For example, the user might reply 4. Does it matter? instead of answering the question. If the user's response can be construed as an answer to the question, we say that the user has adopted the planfor, and we may then expect any additional steps in the plan to be pursued by the user.</Paragraph> <Paragraph position="1"> Third, PAGAN may find more than one planfor in its long-term memory that matches the utterance. This is called planfor ambiguity. Planfor ambiguity is handled in one of two ways. If an alternative matches an expectation, as described in the previous paragraph, then that alternative is chosen as the correct interpretation. If no expectation is matched, PAGAN tries to reject an alternative as implausible. A planfor is implausible if PAGAN believes that the user believes that its goal already holds, if its goal does not appear to lead to some appreciable benefit for the user, or if PAGAN believes that the user believes that one of its plan steps could not be achieved.</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 5.3 PROCESSING OVERVIEW </SectionTitle> <Paragraph position="0"> 1. This utterance wasn't expected.</Paragraph> <Paragraph position="1"> 2. This utterance wasn't an adopted plan.</Paragraph> <Paragraph position="2"> 3. Matching ASK0 pattern against ASK11.</Paragraph> <Paragraph position="3"> 4. Could not match KNOW23 pattern to ACTION6 because of category KNOW.</Paragraph> <Paragraph position="4"> 5. Match failed--try the next one.</Paragraph> <Paragraph position="5"> 6. Matching ASK34 pattern against ASK11. 7. Match found.</Paragraph> <Paragraph position="6"> 8. Matching ASK39 pattern against ASKI 1. 9. Match found.</Paragraph> <Paragraph position="7"> 10. Attempting to resolve ambiguity in the interpretation of ASK11.</Paragraph> <Paragraph position="8"> I 1. The alternatives are: KNOW34 KNOW39. 12. Trying to determine whether KNOW34 was expected. null 13. KNOW34 was not expected.</Paragraph> <Paragraph position="9"> 14. Trying to determine whether KNOW39 was expected. null 15. KNOW39 was not expected.</Paragraph> <Paragraph position="10"> 16. The goal KNOW39 is implausible, since the speaker probably believes that it already holds. 17. ASKll is explained by the goal KNOW34. 18. Creating new HAS-GOAL node: HAS-GOAL-ga0. 19. Returning goal KNOW-ga0.</Paragraph> <Paragraph position="11"> how to print a file on the Imagen?&quot; At PAGAN's core is a matching program that matches two KODIAK structures against one another. Two structures are said to match if they are isomorphic (i.e., they have the same link structure) and each pair of corresponding nodes matches. For two nodes to match, one must be equal to or an ancestor of the other. For example, Imagen would match Imagen or laser printer, and laser printer would match Imagen, but Imagen would not match Laserwriter.</Paragraph> <Paragraph position="12"> PAGAN first tries to determine whether the utterance was expected. This is done by matching the representation of the utterance against those plan steps that have been inferred but not yet witnessed. Such expectations are stored in a separate structure to speed the matching process. Failing this, PAGAN attempts to match the representation of the utterance to the first steps of planfors stored in memory. If a single such match is found, this planfor is copied, forming a new planfor with the observed utterance as its first step. If more than one planfor is found to match, the resultant ambiguity is resolved either by matching its goal to an expected action or by consulting the user model to determine whether that goal and plan are plausible given what is known about the user.</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 5.4 EXAMPLE </SectionTitle> <Paragraph position="0"> This section traces the processing performed by PAGAN to handle Utterance 1. The input to PAGAN is the structure built by the analyzer from this utterance and refined by the concretion mechanism. A trace of PAGAN as it processes this structure is shown in Figure 8.</Paragraph> <Paragraph position="1"> The first step performed by PAGAN is to determine whether the utterance is the continuation of a conversational plan already in effect. For this to be the case, there would need to be some previous dialog to provide the necessary context. This dialog would take one of two forms. It might be a plan that UC believed the user to be pursuing before the current utterance was encountered. Alternatively, it could be a plan introduced by UC that the user has adopted, that UC believes the user to be pursuing only after witnessing the current utterance. Since there is no previous context in the example we are tracing, neither of these possibilities is found to hold (1-2).</Paragraph> <Paragraph position="2"> Next, PAGAN tries to match the utterance against the first steps of plans in its planfor knowledge base.</Paragraph> <Paragraph position="3"> The first possibility is compared with the Input Structure 3, but one pair of corresponding nodes is found not to match (4-5). The second possibility, one that does match the utterance, is then compared with the Input Structures 6-7. This planfor corresponds to the indirect interpretation of the utterance. This is the planfor that is shown in Figure 7. A third possibility, corresponding to the direct interpretation of the utterance, also matches the Input Structures 8-9. An attempt to resolve this ambiguity is now made (10-11). Since neither goal matches an expected goal (12-15), the planfors are examined for plausibility. The direct interpretation is Computational Linguistics, Volume 14, Number 4, December 1988 55 Robert Wilensky, David N. Chin, Marc Luria, James Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project</Paragraph> <Paragraph position="5"> discarded, because the user model indicates that it is likely that the user knows that UC knows how to print a file on the Imagen (16). (The contribution of the user model is described in Section 6.) Thus the planfor representing the indirect interpretation is selected (17).</Paragraph> <Paragraph position="6"> Once the utterance has been matched to the first step of this planfor, an instance of a PLANFOR is created with the goals determined from the input. In addition, an instance of the HAS-GOAL-STATE is built (18). The planner of this state is the user, and the goal is the goal of the PLANFOR. This HAS-GOAL represents the goal that UC believes the user had in mind in making the utterance, and is returned by PAGAN as its result (19).</Paragraph> <Paragraph position="7"> It is shown in Figure 9.</Paragraph> <Paragraph position="8"> In this figure, note that PAGAN has created a node labeled ACTION7, whose actor is the user. This represents the inference made by the goal analyzer that, if a user wants to know an action to achieve some goal, then the user intends to be the actor of that action.</Paragraph> </Section> </Section> <Section position="28" start_page="0" end_page="0" type="metho"> <SectionTitle> 6 ThE EGO MECHANISM </SectionTitle> <Paragraph position="0"/> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 6.1 UCEGO </SectionTitle> <Paragraph position="0"> UCEgo is the component of UC that determines UC's own goals and attempts to achieve those goals. The input to UCEgo are the user's statements as interpreted by UC's conceptual analyzer and concretion mechanism, and the user's goals and plans as inferred by UC's goal analyzer. UCEgo draws on the UNIX planner component of UC to produce plans for doing things in UNIX. It passes the results to UC's expression mechanism, which prepares the conceptual information for generation into natural language.</Paragraph> <Paragraph position="1"> The processing in UCEgo can be divided into two main phases: goal detection and plan selection. In goal detection (Wilensky 1983), UCEgo considers the current situation and detects appropriate goals for UC. The plan selection phase of UCEgo takes UC's goals and tries to produce a plan for satisfying them. The process of executing the plan normally results in a collection of concepts that are to be communicated to the user.</Paragraph> <Paragraph position="2"> UCEgo also includes an explicit user model, which encodes the user's knowledge state for use in goal detection and answer expression. Each of these sub-components is described in greater detail below. A more substantial description of these subcomponents is described in Chin (1988).</Paragraph> </Section> </Section> <Section position="29" start_page="0" end_page="0" type="metho"> <SectionTitle> 6.1.1 THEMES AND GOALS </SectionTitle> <Paragraph position="0"> In UCEgo, goal detection is implemented by if-detected demons, if-detected demons are similar to the implication rules found in many semantic network type systems. If-detected demons contain two subparts, a detection net and an addition net. Both of these are networks of KODIAK concepts. Whenever the detection net of an if-detected demon matches what is in UC' s memory, the addition net of the if-detected demon is copied into UC's memory. The detection and addition nets may share concepts, that is, share nodes in their networks. Here, the concepts that match the detection net are used in place of the corresponding concepts in the addition net. Thus all the links in the addition net are preserved in making the copy, but some of the absolutes are from the result of the match. As described below, the matching process, which is somewhat different from that used by the goal analyzer, allows certain nodes to match instances of the concepts they specify. Therefore, these nodes function like the typed variables found in other systems.</Paragraph> <Paragraph position="2"> if-detected demon represents the situation in which the goal should be detected, and the addition net of the if-detected demon contains the goal. Figure 10 shows an if-detected demon used in goal detection. This if-detected demon encodes the information that if UC has the goal (UC-HAS-GOAL3 in the diagram) of helping (HELP1) someone (PERSON4), and that person has the goal (HAS-GOAL0) of knowing something, then a plan for helping that person is for UC to satisfy (SATISFY1) the person's need to know.</Paragraph> <Paragraph position="3"> Figure 10 shows an if-detected demon with an intersecting detection and addition net. In these diagrams, the detection net is designated by unlabeled arrows coming into the doubled circle labeled &quot;if-detected&quot;. The net includes all those concepts plus all children of those concepts. The addition net is composed of those concepts pointed to by the if-detected double circle plus all their children. In the figure, the detection net consists of UC-HAS-GOAL3, HAS-GOAL0, and their child nodes. The addition net consists of PLANFOR3 plus all its child nodes. (UC-HAS-GOAL is a subtype of HAS-GOAL in which the planner is constrained to be UC, thus obviating the need to specify UC as the planner in each demon.) Thus, when PAGAN has inferred that the user wants to know something, and UC has the goal of helping the user (a recurrent goal that arises from UCEgo's computer-consultant-role theme), UCEgo will detect the goal of satisfying the user's goal of knowing.</Paragraph> <Paragraph position="4"> The use of demons in UCEgo is intended to represent its procedural knowledge of what to do in particular situations. For example, while a planfor structure used in both UCEgo and PAGAN might encode that some plan is appropriate for some goal, a demon is needed to cause UC to intend to use that plan in a situation in which that goal is present. Thus demons represent the actions to be taken in a given situation, although both the situations and actions are described in declarative KODIAK format.</Paragraph> <Paragraph position="5"> To capture generalizations effectively, the number of demons should be kept to the minimum and as much as possible should be represented as declarative KODIAK knowledge. For example, it is possible to have one demon for each situation in which a particular goal suggests adopting a particular plan; then we might be able to dispense with representing knowledge in planfors. However, doing so would not capture the generalization common to all these situations, namely, that expressed by the demon in Figure 10.</Paragraph> <Paragraph position="6"> While we have attempted to keep the number of demons small, this version of UC certainly does not go as far as we would like in this direction. There are about 70 demons in the current version. We expect that a careful examination of them could result in reducing this number somewhat making the program more declaratively based.</Paragraph> <Paragraph position="7"> UCEgo needs a complex control structure, because it has more varied tasks to perform than most of the other parts of UC. Indeed, to accommodate its needs, UCEgo uses a slightly different matching algorithm than some of the other components. In particular, the question marks in the diagrams are significant to the demon interpreter during both matching and copying. In matching, the question mark in a node means that the interpreter should look not just for exact matches, but also for any concepts that are members of the same categories as the node or specializations of those categories. For example, PERSON4? will be matched by any instances of either PERSON or specializations of PER-SON such as USER. In copying the addition net, the interpretation of the question marks is to use the matched concept if the node is also a part of the detection net, or to create a new concept that is an instance of the same categories as the node. Nodes without question marks are used directly without copying. null These rules of interpretation extend only to using demons, and are purely a part of UCEgo's implement.</Paragraph> <Paragraph position="8"> That is, assertions made using these rules, when entered in the KODIAK knowledge base, have the same syntax and semantics as elsewhere in UC.</Paragraph> </Section> <Section position="30" start_page="0" end_page="0" type="metho"> <SectionTitle> 6.1.2 EXTENDED GOAL DETECTION </SectionTitle> <Paragraph position="0"> Besides situations where UCEgo simply adopts the user's goal of knowing, UCEgo also handles situations where it does not adopt the user's goal, such as when the user asks, &quot;How do I crash the system?&quot; or &quot;How can I delete UC?&quot; The cases where UCEgo does not tell the user the Computational Linguistics, Volume 14, Number 4, December 1988 57 Robert Wilensky, David N. Chin, Marc Luria, James Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project answer include examples of goal conflict where UCEgo's goal of wanting the user to know something conflicts with another of UCEgo's goals. For example, consider what happens when the user asks, &quot;How do I crash the system?&quot; By normal processing, UCEgo arrives at the goal of wanting the user to know how to crash the system. However, crashing the system conflicts with UCEgo's recurrent goal of preserving the system, which arose from UCEgo's life theme of staying alive (Schank & Abelson 1977). This theme is operationalized by yet another if-detected demon, which looks for the user wanting to crash the system, and results in UC having the goal of preventing the user from doing so. (This is one of only a few such states pertaining to the staying-alive theme that UCEgo has knowledge about.) Of course, it is the job of PAGAN to determine that the user wants to crash the system from the user asking how to crash the system.</Paragraph> <Paragraph position="1"> Figure 11 shows the if-detected demon that detects goal competition between UCEgo's goal of preserving something (SOMETHING1 in the diagram) and someone's goal (PERSON1 in the diagram) of altering it. In this example, UC-HAS-GOAL1 would be matched by UCEgo's recurrent goal of preserving the system, which arises from UCEgo's life theme of staying alive.</Paragraph> <Paragraph position="2"> HAS-GOAL2 would be matched by the user's goal of crashing (a specialization of altering) the system. As a result, UCEgo adopts the subgoal of preventing the user from crashing the system.</Paragraph> <Paragraph position="3"> Next, the goal of preventing the user from crashing the system, with the information (inferred by UC's KNOME, cf. section 6.2) that the user does not know how to crash the system and the information that the user wants to know how (inferred by PAGAN), causes a new goal for UCEgo, namely, preventing the user from knowing how to crash the system. Figure 12 shows the if-detected demon responsible. This demon detects situations where UCEgo has a goal of preventing something from happening and where the person who desires this does not know how to do it and wants to know how.</Paragraph> <Paragraph position="4"> Here, UCEgo adopts the goal of preventing the person from knowing.</Paragraph> <Paragraph position="5"> After detecting the subgoal of preventing the user from knowing how to crash the system, UCEgo will detect a goal conflict when it tries to adopt the usual goal of having the user know, in order to help the user. Figure 13 shows the if-detected demon that detects goal-conflict situations where UCEgo both has a particular goal and has the goal of preventing that goal. In such cases, UCEgo adopts the recta-goal (Wilensky 1983) of resolving the goal conflict. The general mechanism of dealing with such recta-goals is described in the next section. The eventual result of this mechanism here is that the goal of preventing the user from knowing is maintained and the other conflicting goal is abandoned. null After UCEgo has detected the appropriate goals, it then tries to satisfy these goals. This is done in the plan selection phase of UCEgo. Plan selection in UCEgo is implemented using planfors, as described in Section 5, on PAGAN. In UCEgo, planfors are indexed using if-detected demons. The if-detected demons serve to suggest application of a particular planfor whenever an appropriate situation arises. Such situations always include the goal of the planfor, and may include other factors relevant to the planfor. For example, Figure 14 shows an if-detected demon that suggests the plan of telling the user the answer whenever it detects a situation where UC wants the user to know the answer to a query and there is an answer for that query.</Paragraph> <Paragraph position="6"> Besides encoding the situations when UCEgo should be reminded of particular planfors, the if-detected demons also provide a unification service. For plan selection, unification serves to specialize the general plans stored in the planfors to fit the activating situations. For example, consider the demon shown in Figure 14. After the detection net of the demon is matched, UCEgo will create a new planfor with a plan of telling the user the particular proposition that matched SOMETHING2, which is the answer for the user's query.</Paragraph> <Paragraph position="7"> After finding a plan, adopts the intention of executing that plan. An intention to execute a plan means that UCEgo has scheduled the plan for execution. UC's notion of intention is similar to that of Cohen and Levesque (1987), although UC is not concerned with Figure 12. If-detected Demon for Preventing Someone from Knowing How to do Something. issues of its own beliefs, since performing actions accidentally or unknowingly is not a real possibility for the system. Figure 15 shows the basic knowledge used by UCEgo to adopt a plan for execution.</Paragraph> <Paragraph position="8"> This if-detected demon states that whenever UC has some goal and UC knows that there is a plan for that goal, then UC adopts the intention of performing the plan.</Paragraph> <Paragraph position="9"> If UC had to choose between a number of plans for a goal, this demon would have to be replaced by something more complex. The idea behind our scheme is that, with a rich enough description of situations for which plans are appropriate, a planner will not typically consider many plans at any given junction. So far, UCEgo has been able to function by simply intending to perform the first plan it finds, and with no ability for eventually needed, we would realize it by having a more sophisticated mechanism for forming intentions. For example, the presence of multiple recalled plans could be represented as a situation in which a meta-goal of choosing between them is to be detected.</Paragraph> <Paragraph position="10"> After UCEgo has finished forming intentions to perform some actions, it attempts to execute them. UCEgo has some procedural knowledge about which intention to tend to first. For example, it will try to execute meta-plans before non-meta-plans, and subgoals before their parent goals. If there remain unfulfilled conditions</Paragraph> <Paragraph position="12"> of a plan, its execution will not be attempted. Otherwise, the selection among intentions is random.</Paragraph> <Paragraph position="13"> Having selected a plan, UCEgo proceeds to execute the plan. UCEgo's demon interpreter calls the proper subcomponent to perform the action. An example of this is when UCEgo calls UCExpress to perform a TELL action.</Paragraph> <Paragraph position="14"> In the case of executing a meta-plan for a meta-goal, the procedure called by the interpreter typically alters the plan structure itself. For example, in the previous section, UCEgo had inferred the meta-goal of resolving a conflict between two goals, one of helping the user and one of protecting itself. In plan selection, a demon would propose a meta-plan called ABANDON-GOAL to use to address this meta-goal. This meta-plan would cause a procedure to be invoked that resolves the conflict by abandoning the less valuable goal. To determine which goal is less important, ABANDON-GOAL first searches the data base for an explicit HAS-PRE-CEDENCE relation between the two goals. If such a fact cannot be found, ABANDON-GOAL examines the parent goals of the goals in question for such a fact. If that fails, the ultimate sources of the goals, usually some themes, are examined. All of UC's themes are in an explicit precedence relation. Thus most conflicts can be resolved by appeal to the priority of themes. In the example from the previous section, UC's staying alive theme is found to have a higher precedence than its consultant theme, thus causing the latter goal to be abandoned and the former retained.</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 6.2 KNOME---UC'S USER MODEL </SectionTitle> <Paragraph position="0"> KNOME is a program that maintains UC's model of the user. This model represents UC's understanding of the user's knowledge of UNIX. No attempt is made to determine other user attributes, such as personality traits (Rich 1979), user preferences (Morik and Rollinger 1985), or user performance (Brown and Burton 1976). This knowledge state is exploited by the goaldetection phase of UCEgo's processing and by KIP and UCExpress.</Paragraph> <Paragraph position="1"> KNOME separates users into four categories or stereotypes, corresponding to different levels of expertise: novice, beginnner, intermediate, and expert. Each category encodes information about the knowledge state of users that belong to that category. Conflicting information about an individual user's knowledge state can be encoded explicitly, and will override inheritance from the user's stereotype category. Thus the user categories are prototypes that are used as reference points for inference (Rosch 1978).</Paragraph> <Paragraph position="2"> Besides separating users according to expertise, KNOME also categorizes commands, command formats, terminology, and other relevant knowledge.</Paragraph> <Paragraph position="3"> These objects are grouped according to their typical location on the learning curve (i.e., when the average user would learn the information). The categories include simple, mundane, and complex. A further category, esoteric, exists for those concepts that do not consistently lie on any one area of the learning curve.</Paragraph> <Paragraph position="4"> These concepts are usually related to special purpose requirements, and only users that require that special purpose will learn those concepts. Thus esoteric concepts may be known by novices and beginners as well as by intermediate or expert users, although advanced users are still more likely to know more esoteric items simply because they have been using UNIX longer.</Paragraph> <Paragraph position="5"> The double stereotype system described above is extremely space efficient. The core of KNOME's general knowledge of users is summarized in the five statements shown in Figure 16 (although the information is stored as assertions in KODIAK).</Paragraph> </Section> </Section> <Section position="31" start_page="0" end_page="0" type="metho"> <SectionTitle> 6.2.1 INFERRING THE USER'S LEVEL </SectionTitle> <Paragraph position="0"> During a session, KNOME builds a profile of the user and infers the user's level of expertise. This proceeds in a two-step process. First, KNOME infers particular facts about what the user does or does not know from the dialog, i.e., from what the user actually said and from the output of the goal analyzer. Next, these facts are combined to infer the user's level of expertise.</Paragraph> <Paragraph position="1"> Inferring particular facts about what the user does or does not know is implemented using if-detected demons as a rule-based system. An example of such a rule is: the user wants to know ?x --* the user does not know ?x Expert users know all simple or mundane facts and most complex facts.</Paragraph> <Paragraph position="2"> Intermediate users know all simple, most mundane, and a few complex facts.</Paragraph> <Paragraph position="3"> Beginner users know most simple facts and a few mundane facts.</Paragraph> <Paragraph position="4"> Novice users know at most a few simple facts (e.g., the login command).</Paragraph> <Paragraph position="5"> Any user may or may not know any esoteric facts, but more experienced users are more likely to know more esoteric facts.</Paragraph> <Paragraph position="6"> Figure 16. Summary of KNOME's General Model of Users This rule is implemented using the if-detected demon shown in Figure 17.</Paragraph> <Paragraph position="7"> KNOME currently distinguishes seven classes of inference rules. These are summarized as follows: Claim--inferences based on what the user claims to know; Goal--inferences based on what the user wants; Usage--inferences based on the user's usage; Background--inferences based on the user's background; null Query-reply--inferences based on user's replies to questions; No-clarify--inferences based on the user's not asking for clarification Claims cover such items as the statement by a user that he or she knows some fact. Examples of goal inference are that, if a user asks how to do something, then it is reasonable to assume that the user does not know how to do that thing, and is also unfamiliar with the command that does it. Usage inferences include such notions as that the user can be assumed to know the commands the user has used. Background inferences mean that, should UC know the user's background and have a stereotype for that background, UC should assume that the user knows what is indicated by that background. Query-reply refers to the possibility that UC asks the user for information about the user's knowledge state. Finally, no-clarify inferences are assumptions that the user knows the items to which UC's terminology refers if the user does not ask for clarification of them.</Paragraph> <Paragraph position="8"> Based on its understanding about what the user does or does not know, KNOME can infer the user's level of expertise. An example of such an inference rule is: the user does not know a SIMPLE fact ~ it is LIKELY that the user is a NOVICE, it is UN-LIKELY that the user is a BEGINNER, and it is FALSE that the user is an INTERMEDIATE or an</Paragraph> </Section> <Section position="32" start_page="0" end_page="0" type="metho"> <SectionTitle> EXPERT </SectionTitle> <Paragraph position="0"> Such evidence is combined to arrive at a likelihood that the user have a given level of expertise. Such ranking is updated continually as the interaction with a given user Computational Linguistics, Volume 14, Number 4, December 1988 61 Robert Wilensky, David N. Chin, Marc Luria, ,lames Martin, James Mayfield, aud~ Deka~ Wu The Berkeley UNIX Consultant Project</Paragraph> <Paragraph position="2"> level is the one the user is assumed to be at. For more details on this and other issues addressed in UC's KNOME (e.g., dealing with the inherent uncertainty of information encoded in the model, representing individual users, etc.), see Chin (1986, 1988).</Paragraph> <Paragraph position="3"> The user model is exploited in many places in UC. For example, to decide whether some goal involving the state of the user's knowledge is plausible, PAGAN will check to see if the user already knows the fact in question. If the user does, PAGAN will not attribute the goal to the user. Thus, if the user asks a question with both a possible direct and indirect interpretation, like &quot;Do you know how to print a file on the imagen?&quot; and the KNOME concludes that the user knows how to print a file on the imagen, it will reject the indirect interpretation.</Paragraph> <Paragraph position="4"> KNOME is also used extensively by UCExpress, UC's expression mechanism. For example, generating a response to simple question once the answer is known is a function of the knowledge state of the user. In particular, UCExpress will illustrate a response with an example only if it believes the user is a novice. Also, UCExpress will use its simile format, i.e., using one command to illustrate another command, only when it believes the user knows the first command. Of course, establishing such a belief is the job of KNOME. UCExpress is described further in Section 8.</Paragraph> </Section> <Section position="33" start_page="0" end_page="0" type="metho"> <SectionTitle> 6.2.2.1 DETECTING MISCONCEPTIONS </SectionTitle> <Paragraph position="0"> One of the more interesting uses of KNOME in UCEgo is to detect user misconceptions. A misconception occurs when the user believes something that UC believes is false. An example of a user misconception occurs when the user asks, &quot;What does Is -v do?&quot; Here, the user believes that there is an 'Is' command, that '-v' is an option of the 'Is' command, and that there is a goal for the plan of 'Is -v.' Here, '-v' is actually not an option of 'Is,' even though 'Is' will accept and ignore extraneous options.</Paragraph> <Paragraph position="1"> KNOME is responsible for detecting what the user believes, comparing this with UC's knowledge, and then either deducing that the user knows the fact if what the user believes coincides with UC's knowledge, that the user has a misconception if the user's belief contradicts UC's knowledge, or that the user may know something that UC is unfamiliar with. The last possibility, namely, that UC does not know everything about UNIX, means that the system cannot use a simple closed-world hypothesis (which implies that if a fact cannot be deduced from the data base, then it must be false) such as is used in other misconception detection systems (e.g., Mays 1980, Kaplan 1983, Webber and Mays 1983, and McCoy 1983). The other possibility is an open-world hypothesis, where if a fact cannot be deduced from the data base, then the system has no information about it. Using a pure open-world hypothesis, a system would have to encode complete information about what cannot be the case, in order to detect misconceptions. This is inefficient at best and at worst not possible.</Paragraph> <Paragraph position="2"> What KNOME does instead is to augment an open-world hypothesis with meta-knowledge. Here, the term meta-knowledge is used to denote knowledge that KNOME has about what UC itself does or does not know. For example, KNOME contains the information that UC knows all the command options of all simple commands. Hence, if a particular option is not represented in UC's knowledge base as a possible option for a particular simple command, then that is not a legal 62 Computational Linguistics, Volume 14, Number 4, December 1988 Robert Wflensky, David N. Chin, Marc Luria, James Martin, James Mayfield, and Dekai Wu ii The Berkeley UNIX Consultant Project option for that command. Using such meta-knowledge, KNOME is able to infer that '-v' is not an option of 'Is,' hence, that the user has a misconception. This fact is passed on to UCEgo, which adopts the goal of correcting the user's misconception.</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 6.3 EXAMPLE </SectionTitle> <Paragraph position="0"> To see how UCEgo works in more detail, consider again the example &quot;Do you know how to print a file on the Imagen?&quot;. Recall that thus far in the processing, UC has parsed and understood the question, and the goal analyzer has asserted that the user has the goal of knowing a plan for printing a file on the imagen. At this point, UCEgo's processing begins.</Paragraph> <Paragraph position="1"> The first part of the annotated trace below shows the goal detection phase of UCEgo. The explanatory comments that have been added to the trace are printed in italics.</Paragraph> <Paragraph position="2"> UCEgo detects the following concepts: (UC HAS GOAL 19 (goal = (HELP2(helpee =* USER*)(helper= UC))))</Paragraph> <Paragraph position="4"> and asserts the following concept into the data base:</Paragraph> <Paragraph position="6"> US HAS GOAL19 represents UC's goal of helping the user (HELP2).</Paragraph> <Paragraph position="7"> HAS GOAL-gaO, which is also shown in Figure 9, is the user's goal of knowing (KNOW-gaO) how to print a file on the Imagen.</Paragraph> <Paragraph position="8"> PLANFOR29 represents the fact that a plan for helping the user (HELP2) is for UC to satisfy KNOW-gaO, which is the user knowing how to print a file on the Imagen.</Paragraph> <Paragraph position="9"> UCEgo detects the following concepts:</Paragraph> <Paragraph position="11"> and asserts the following concept into the data base: with UC's goal of helping the user (UC-HAS-GOAL19, present in UC's initial state) to activate the detection net of the if-detected demon shown in Figure 10. On activation, the if-detected demon adds a copy of its addition net to UC's memory. Here, the addition net consists of the fact (PLANFOR29) that a plan for helping the user is for UC to satisfy the goal of the user knowing a plan for printing a file on the Imagen. Next, this planfor combines with UC's goal of helping the user (UC-HAS-GOAL19) to make UCEgo adopt the intention (UC-HAS-INTENTION6) of satisfying the goal of &quot;the user knowing a plan /'or printing a file on the Imagen&quot;. This intention arises as a result of UCEgo's if-detected demon for plan selection, which is shown in Figure 15. Finally, UCEgo adopts the user's goal as its own. This subgoal (UC-HAS-GOAL20) is the result of UCEgo's goal detection process.</Paragraph> <Paragraph position="12"> After UCEgo has detected the goal of &quot;the user knowing a plan for printing a file on the Imagen&quot;, the plan selection phase of UCEgo attempts to select a plan to satisfy this goal. The following annotated trace shows this part of the processing (additional explanations are in italics).</Paragraph> <Paragraph position="13"> Computational Linguistics, Volume 14, Number 4, December 1988 63 Robert Wilensky, David N. Chin, Marc Luria, .lames Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project UCEgo detects the following concepts:</Paragraph> <Paragraph position="15"> and asserts the following concept into the data base: (UNIX-planner 1 (user goals = PRINT-EFFECT0)) UC HAS GOAL20 is UC' s goal of knowing (KNOW-gaO) ACTION7, which represents the plan part of the planfor (PLANFOR-gal) for printing a file on the Imagen (PRINT-EFFECTO).</Paragraph> <Paragraph position="16"> UNIX-plannerl represents a call to KIP.</Paragraph> <Paragraph position="17"> The planner is passed:</Paragraph> <Paragraph position="19"> COMMANDO, which entails using the command lpr -Pip on the name of the file to be printed.</Paragraph> <Paragraph position="20"> UCEgo detects the following concepts:</Paragraph> <Paragraph position="22"> and asserts the following concept into the data base:</Paragraph> <Paragraph position="24"> (KNOW-gaO) is for UC to tell (TELL4) the user PLANF'OR70.</Paragraph> <Paragraph position="25"> UCEgo detects the following concepts:</Paragraph> <Paragraph position="27"> and asserts the following concept into the data base:</Paragraph> <Paragraph position="29"> UCexpressl represents a call to UCExpress to execute TELL4.</Paragraph> <Paragraph position="30"> Annotated Trace of UCEgo's Plan Selection Process.</Paragraph> <Paragraph position="31"> The first step of the plan is to call KIP, the planner component of UC. Figure 18 shows the if-detected demon that calls KIP. KIP is called whenever UC has the goal of knowing a plan for something in the trace, UC-HAS-GOAL20 and PLANFOR-gal combine to cause a call to KIP (UNIX plannerl in the trace). KIP, as is described in the next section, comes back with an answer (PLANFOR70), which is an answer (ANSWER-FOR1) to the user's question. Then the if-detected demon shown in Figure 14 detects the plan of telling the user the answer (PLANFOR30 in the trace). This plan, with UC's goal (UC-HAS-GOAL20) of the user knowing the answer leads to UC's intention to tell the user the answer (UC-HAS-INTENTION7) via the if-detected demon shown in Figure 15. Finally, the intention translates into a call to UC's expression mechanism, UCExpress (UCexpressl in the trace), which eventually calls UCGen to produce the answer. KIP, UCExpress, and UCGen are described in the following sections. /O oan er goa, I P' ANFdegR' I</Paragraph> </Section> </Section> <Section position="34" start_page="0" end_page="0" type="metho"> <SectionTitle> 7 THE PLANNER 7.1 INTRODUCTION </SectionTitle> <Paragraph position="0"> This section describes KIP (Luria 1985), a knowledgebased, commonsense planner (Wilensky 1983). KIP includes: plans) to determine which plans to suggest. KIP uses the same knowledge base as the rest of UC. In principle, it could be used to do the planning required by UCEgo. As mentioned previously, this was not attempted mostly for pragmatic reasons. In addition, the planning done by UCEgo is much more straightforward and does not require recourse to the same magnitude of knowledge as does KIP. Thus it seems reasonable to use a much simpler planner for communicative functions. null</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 7.2 PLANNING PROCESS IN KIP </SectionTitle> <Paragraph position="0"> The basic structure of KIP is similar to that of UCEgo.</Paragraph> <Paragraph position="1"> However, KIP is a more elaborate planner. It must be able to plan for unanticipated goals of the user, and must be concerned with adverse consequences of the plans it proposes. In general, KIP has to iterate through the planning process a number of times to arrive at an adequate plan.</Paragraph> <Paragraph position="2"> The following are the steps of the iterative process that KIP uses.</Paragraph> <Paragraph position="3"> 1. Goal detection---decide what goals to work on * Start with the goals input from UCEgo * Detect new goals that might arise from use of pro- null 2. Plan selection--select a possible plan * Try to find a stored plan that is related to the user's goals * Propose a new plan if necessary based on knowledge in the system 3. Projection--test whether plan would be executed successfully * Check for conditions that are likely not to be met * Notice bad side effects * Detect goals needed to address discovered problems 4. Plan evaluation---decide whether plan is acceptable * Reject plan if impossible * Accept if unproblematic * Create warning if possible but problematic The iterative structure described here is implemented by a series of meta-plans (Wilensky 1983). The underlying meta-plan is to find a particular plan that the user can use; these steps are parts of that process. KIP begins with the user's domain goals, passed to it by UCEgo. As it proceeds with the planning process, other goals may be detected. These fall into the following categories: a condition that KIP believes is unmet and whose omission would cause the plan to fail becomes a new goal (i.e., a subgoal of a current goal). Another kind of goal arises when some current plan being considered impinges upon an interest of the user. An interest is some situation, real or hypothetical, toward which the user has a positive stance. In UNIX, examples of interests are having access to files and maintaining a low system load average.</Paragraph> <Paragraph position="4"> In UC, interests generally give rise to goals of defending against a threat to that interest. Since such a threat is generally the inadvertent consequence of some plan under consideration, there is often a goal conflict between a user goal and the goal resulting from the threatened interest. As in UCEgo, such conflicts are handled by detecting a meta-goal of resolving that conflict. For example, if a proposed plan involves deleting a file, this goal might conflict with the goal of having access to that file. The meta-goal of resolving this conflict is therefore detected.</Paragraph> <Paragraph position="5"> Plan selection is the process of determining a potential plan to satisfy the user's goals. This potential plan is then examined during the rest of the planning process. If the plan is judged adequate, it is returned to UCEgo; otherwise, this plan is modified or another plan is selected.</Paragraph> <Paragraph position="6"> One simple method for performing plan selection is to choose a stored plan that is indexed in the knowledge base as addressing the goal to be achieved. This is done by using the same matching procedure used by PAGAN to examine knowledge structures relating plans to goals, using the same representational format used by PA-GAN. Such knowledge structures are used to represent only the conventional functions associated with commands, e.g., that 'rm' is a plan to delete a file, or that 'lpr -Px' prints on the printer x.</Paragraph> </Section> </Section> <Section position="35" start_page="0" end_page="0" type="metho"> <SectionTitle> 7.2.2.1 NEW PLANS </SectionTitle> <Paragraph position="0"> When KIP has no stored plan for a particular goal, it employs a kind of means-ends analysis strategy (Newell and Simon 1972). KIP assumes that the best way to reduce the difference between the user's goal and the present state is by determining the goal most similar to the current goal, and trying to fulfill that goal. KIP finds a similar goal by using its taxonomy of goals to locate a goal that is dominated by the same parents as the user's goal. This algorithm for finding a plan is called the Goal Similarity Matching Algorithm (GSMA).</Paragraph> <Paragraph position="1"> For example, there is no command in UNIX for moving a file to another machine. This goal is represented as achieving the conditions of having a file of the given name and contents on the target machine, and not having such a file on the source machine. In this case, KIP searches for a plan of a goal most similar to the goal of moving a file to another machine. It does this by finding a goal that shares more common parents with moving a file to another machine than any other goal.</Paragraph> <Paragraph position="2"> Since moving a file to another machine is dominated by goals, KIP searches for plans of goals that are dominated by these two goals. Figure 19 shows that one command, 'rcp', falls in this category. This command is used to copy a file from one machine to another.</Paragraph> <Paragraph position="3"> KIP selects the plan of using the 'rcp' command as a potential plan to move a file to another machine. When this plan is tested in a subsequent phase of the planning process, it will be found not to satisfy all the goals of the user, since the goal of not having such a file on the source machine is left unaddressed. Plans for these remaining goals will be selected by subsequent iterations of the planning algorithm.</Paragraph> </Section> <Section position="36" start_page="0" end_page="0" type="metho"> <SectionTitle> 7.2.2.2 PLAN SPECIFICATION </SectionTitle> <Paragraph position="0"> Once a plan has been selected, KIP makes a copy of the plan with specific values filled in. For example, the user asks: How do I delete the file named junk from my directory? The general plan for this planning situation is to use the rm command. This is stored in the knowledge base as shown in Figure 20.</Paragraph> <Paragraph position="1"> During plan specification, KIP creates a new instance of the EXECUTE-UNIX-COMMAND and fills in the appropriate specific values of its arguments by looking at the general plan. This specific plan, shown in Figure 21, specifies that the value of the del-object (the file to be deleted) is FILE1 (whose filename is junk) and the value of the argument to the 'rm' command is the string &quot;junk&quot;. In other words, this represents that the 'rm' command with the argument &quot;junk&quot; is a plan for deleting a file whose name is junk. It is this specific plan that is tested during the rest of the planning process.</Paragraph> </Section> <Section position="37" start_page="0" end_page="0" type="metho"> <SectionTitle> 7.2.3 PROJECTION </SectionTitle> <Paragraph position="0"> It is next necessary to test whether the plan as developed so far would actually execute successfully. Potential problems in the plan include both conditions that must be satisfied and goal conflicts that must be resolved because of the effects of the plan.</Paragraph> <Paragraph position="1"> While detailed descriptions of all UNIX commands are in the knowledge base, KIP does not actually check to see that all the conditions of success are met or that no goal conflict is possible. First, there are too many conditions to check, even in very simple situations.</Paragraph> <Paragraph position="2"> Second, UC usually does not have the information to determine the answer. For example, in order to print a file, the printer must be in working order, there must be a continual supply of electricity, the user must have an account, etc. Rather than checking all such conditions, it would be desirable to check only those that seem to constitute a reasonable cause for concern.</Paragraph> <Paragraph position="3"> Computational Linguistics, Volume 14, Number 4, December 1988 67 This is done in KIP by storing a knowledge structure called a concern. A concern represents an aspect of a plan that should be considered a potential cause of plan failure. These encode some user's experience. For example, presumably, the printer's being in working order is not a frequent obstacle to printing a file, but having read permission might be if the file to be printed belongs to someone else.</Paragraph> <Paragraph position="4"> There are two basic kinds of concerns in KIP, condition concerns and goal conflict concerns. Condition concerns specify those conditions of a plan that are likely to be unmet, while goal conflict concerns specify the consequences of a plan that are likely to threaten a user's interest. KIP examines only those aspects highlighted by a concern in determining whether to accept a plan. In general, concerns that are judged insignificant are ignored, those judged highly significant lead to plan failure, and moderate concerns are passed on to be expressed as warnings to the user. For example, in the following transaction, a moderate condition concern is found.</Paragraph> <Paragraph position="5"> # How do I print out Jim's file named testl? Type 'lpr testl'. This plan will not work if you don't have read permission on Jim's file.</Paragraph> <Paragraph position="6"> Since not having read permission on someone else's file is stored as a moderate cause for concern, the planner accepts the plan, but passes along the concern to the expression mechanism. Doing so leads to the warning statement following the suggestion to use the particular plan.</Paragraph> <Paragraph position="7"> Note that in the example above, the concern is retrieved only because the user made a request that involves access to someone else's files. It is typical of concerns that some are appropriate only when a default condition is violated. KIP believes that the default for using UNIX is to access one's own files, so it retrieves concerns about access only when this situation does not pertain.</Paragraph> <Paragraph position="8"> KIP makes considerable use of default knowledge in processing concerns. Also, concerns may be attached to plans at any point in the hierarchy, so that they will be accessed only for the specific conditions in which they might apply. For example, KIP knows that the Apple printer has a small paper tray and often runs out of paper. Thus, without additional knowledge of the state of the printer, UC will produce the following interaction: null # How do I print a file on the apple printer? Use 'lpr -Pap'.</Paragraph> <Paragraph position="9"> But first, fill the printer with paper.</Paragraph> <Paragraph position="10"> In contrast, if we explicitly assert to the user model that the printer is full of paper, we get the following response: null # How do I print a file on the apple printer? Use 'lpr -Pap'.</Paragraph> <Paragraph position="11"> A goal conflict concern is illustrated by the following example: # How can I free up disk space? Use rm. However, any file that is removed cannot be recovered.</Paragraph> <Paragraph position="12"> In this example, the only plan KIP can come up with to free up disk space is to delete files. However, a goal conflict concern informs the planner that this plan is likely to conflict with the user's of preserving access to his or her files. KIP therefore generates a warning to accompany this plan.</Paragraph> <Paragraph position="13"> file on the imagen?&quot;: Print effect0 and Important Links Another example of the use of concerns occurs in the following interaction: # How do I find out the files in the directory named /usr/local on my sun? Type 'ls/usr/local r more'.</Paragraph> <Paragraph position="14"> However, you should first change the current directory to the directory named/usr/local, by typing cd /usr/local.</Paragraph> <Paragraph position="15"> Here, KIP detects two concerns. One pertains to a bug in the SUN implementation of the UNIX 'Is' command, in which asking for a listing of a directory mounted on a different disk than one's current directory occasionally causes no output to result. This bug has been made into a concern about using the 'Is' command in such a situation. The concern causes the planner to issue a warning to change one's current directory. The second concern is that listing large directories may cause output to scroll off the screen. Since the directory in question is typically large, PAGAN alters its plan to pipe the output through the 'more' filter. This example also makes use of default knowledge in that KIP assumes that the user might not be connected to the same place as/usr/local, and that this directory is large.</Paragraph> <Paragraph position="16"> KIP has a rather elaborate taxonomy of concerns and a method of processing them. In addition to classifying concerns by whether they are appropriate to violated defaults or not, or to conditions or goal conflicts, whether the effect of a command is intended by the user is important for generating a concern. For example, it is probably inappropriate to generate a warning about not being able to recover files if the user asked to delete a file, for example. The details of KIP and how it handles concerns are described in Luria (1987, 1988).</Paragraph> <Paragraph position="17"> 7.3 EXAMPLE AND TRACE OUTPUT OF KIP The example being considered throughout this paper does not require much work by KIP. This is because UC's knowledge base contains a plan for the goal of printing a file on the imagen. Also, there are no concerns associated with this particular plan. (Had the input referred to printing the file of another user, or printing on another printer, KIP would have retrieved concerns about not being about to access another person's files, or about the peculiarities of the type of printer, respectively.) Thus the planner simply ends up retrieving the stored plan, making an instance of it, and passing it on. The input to the planner from UCEgo is PRINT-EFFECT0, which we show in Figure 22 along with its most pertinent connections. Following that is an annotated trace of KIP's processing for this example.</Paragraph> </Section> <Section position="38" start_page="0" end_page="0" type="metho"> <SectionTitle> COMMAND </SectionTitle> <Paragraph position="0"> The planner checks to see if it has achieved the exact same goal before. When it fails, as is the case here, it looks up the hierarchy. In this example, it looks first at the category IPRINT-EFFECT, of which PRINT-EFFECT0 is represented as being an instance. KIP finds in the knowledge base PLANFOR7 (not shown in the trace) that connects IPRINT-EFFECT with EXE-CUTE-UNIX-IPR-COMMAND. This knowledge is shown in Figure 23.</Paragraph> <Paragraph position="1"> There are no concerns retrieved within this particular plan, so KIP will simply produce an instance of it and return it to UCEgo.</Paragraph> <Paragraph position="2"> Note that KIP's retrieval of a plan for this goal is simplified by the concretion mechanism's having classifted the input as an instance of Imagen printing. Originally, ALANA represented the meaning of the input as an instance of printing. However, there are no plans associated with printing per se, but only with printing's more specific subcategories. Thus the planner would have to search for an appropriate plan had the concretion mechanism not done its job. In actuality, the planner starts at the most specific category that the input could be classified as, and works up the hierarchy. Therefore, the planner is guaranteed to find the most specific plan applicable to the situation.</Paragraph> <Paragraph position="3"> Making a new instance of IPR-FORMAT Making a new instance of NAME Making NAME6 an instance of HYPOTHETICAL Filling in aspectual ipr format-arg with value NAME6 Computational Linguistics, Volume 14, Number 4, December 1988 69 Robert Wilensky, David N. Chin, Marc Luria, ,lames Martin, James Mayfield, and Dekaii Wu The Berkeley UNIX Consultant Project</Paragraph> <Paragraph position="5"/> </Section> <Section position="39" start_page="0" end_page="0" type="metho"> <SectionTitle> COMMANDO </SectionTitle> <Paragraph position="0"> A copy of the plan has been made. Note that KIP has made NAME6 a hypothetical object, because it is the name of FILE6, which is itself hypothetical.</Paragraph> <Paragraph position="2"> No pertinent concerns are found, and there is nothing more to do, so the plan found is returned. The planner's output is shown in Figure 24.</Paragraph> </Section> <Section position="40" start_page="0" end_page="0" type="metho"> <SectionTitle> 8 THE EXPRESSION MECHANISM 8.1 INTRODUCTION </SectionTitle> <Paragraph position="0"> After UC has determined the correct conceptual response to the user, this response must be expressed to the user in a clear, concise manner. Consider the following example: User: What is a directory? AI: A directory is a file. A2: A directory is a file that is used to contain files.</Paragraph> <Paragraph position="1"> A3: A directory is a file. Only empty directories can be deleted. Directories cannot be edited. Directories contain files. Directories form a treelike structure. Directories always contain themselves and their parents. A directory can be listed by using the 'Is' command. The different replies are all correct, but contain differing amounts of information. The first answer does not give enough information to distinguish between files and directories. The second answer provides just enough information in a concise form and is the best answer in such a situation. The third answer is too verbose and overwhelms the user with irrelevant information. An answer like A3 would be more appropriate in cases where the user had requested, &quot;Tell me all you know about directories.&quot; This example illustrates the problem of determining how much of an answer to express to the user. This is similar to Luria's work (1982) on answering why-questions in a story-understanding system. He pointed out that answering why-questions requires two mechanisms, one to find the causal chain that represents the answer and another expression mechanism to determine how much of the causal chain to tell the user. Another problem in answer expression is deciding what format to use in presenting the answer. This problem corresponds to Grice's Maxim of Manner (Grice 1975). Consider the following scenario: User: AI: How can I move a file to another machine? To move a file to another machine, type 'rcp' followed by one or more spaces or tabs followed by the name of the file to be moved followed by one or more spaces or tabs followed by the name of the machine followed by a colon followed by the new name of the file on the other machine followed by a carriage return followed by 'rm' followed by one or more spaces or tabs followed by the name of the file.</Paragraph> <Paragraph position="2"> A2: Use 'rcp' to copy the file to another machine and then use 'rm' to delete it. For example, to move the file foo to the file foo2 on machine dali, type 'rcp foo dali:foo2.' The first answer is correct and general, but it is so verbose that it is undecipherable. On the other hand, the second answer is succinct and gives the user information in an easily readable form, but is considerably less general. The second answer is somewhat inaccurate, since it applies only to copying a file named foo to a file named foo2. It is up to the reader to apply analogous reasoning for other cases. Despite this lack of generality, the second answer form is superior to the first. Note that for a program to format the answer in the second form requires additional computation to transform the general solution into an example. A natural language system needs to incorporate knowledge about when and how to use special presentation formats like examples to more clearly convey information to the user.</Paragraph> <Paragraph position="3"> The concerns of how much information to present to the user and of what format to use correspond respectively to Grice's Maxims of Quantity and Quality (Grice 1975). Such considerations can be considered part of language generation; however, there are enough differences in both the necessary knowledge and the processing to separate such strategic concerns from the tactical problems of generation such as agreement and word selection. Such strategic problems are the domain of an expression mechanism.</Paragraph> <Paragraph position="4"> Computational Linguistics, Volume 14, Number 4, December 1988 71</Paragraph> <Paragraph position="6"/> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 8.2 APPROACH </SectionTitle> <Paragraph position="0"> UC's expression mechanism, UCExpress, uses a two-step process: pruning and formatting. In the pruning stage, UCExpress marks those concepts it does not wish to communicate to the user. In the formatting stage, the concepts are transformed by a planning process into more easily understood formats. The result is a set of concepts that are ready for generation into natural language.</Paragraph> <Paragraph position="1"> The guiding principle of the pruning process is to avoid telling the user anything that the user already knows. Currently, UC models two classes of such information. The first is semantic information about the user's knowledge of UNIX-related facts. Such knowledge is modeled by KNOME (cf. Section 6.2). The second class of information is episodic: knowledge from a model of the conversational context. The current conversational context is tracked by keeping an ordered list of the concepts that were communicated in the current session. Any concept that is already present in the conversational context or that KNOME deduces that the user already knows is marked and not communicated to the user.</Paragraph> <Paragraph position="2"> For example, suppose a user asked UC the following question: How can I compact a file? The conceptual answer passed to UCExpress is a rather complex network. If it were directly paraphrased into English, the result might be something like the following: null A plan for compacting a file is to use the 'compact' command with the format being 'compact' followed by the name of the file.</Paragraph> <Paragraph position="3"> However, UCExpress prunes the concepts corresponding to compacting a file, since they are already in the conversational context. If UC believes that the user is at least a beginner, then the format of the 'compact' command would be pruned as well, siince KNOME will deduce that the user knows this fact from its belief that such users know the format of simple commands. In this case, UC will eventually generate the following reply: Use compact.</Paragraph> <Paragraph position="4"> On the other hand, if the user were a novice, then UC could not assume that the user already knew this format and would have provided a more elaborate answer.</Paragraph> <Paragraph position="5"> However, rather than generate the answer as an abstract but more detailed description, UCExpress would favor the example format, as described below, and produce the following reply: Use compact. For example, to compact the file foo, type 'compact foo'.</Paragraph> <Paragraph position="6"> Indeed, for the examples in this paper, we have generally caused UC to believe that the user is a novice, in order to illustrate the formatting mechanism.</Paragraph> <Paragraph position="7"> After pruning, UCExpress enters the formatting phase, where it tries to apply different expository formats to express the concepts in a clearer manner.</Paragraph> <Paragraph position="8"> Currently, there are three format types: example, definition, and simile.</Paragraph> <Paragraph position="9"> Definition format is used to explain terminology.</Paragraph> <Paragraph position="10"> Generally, the need to do so is a result of the user asking a direct question, such as &quot;What is a directory?&quot;. The heuristic procedure used to satisfy such requests is to find a category dominating the one in the query, and then find information that distinguishes the subcategory from it. The following are examples of definition format. # What is a directory? A directory is a file that is used to contain files.</Paragraph> <Paragraph position="11"> # What is a file? A directory is a container that is used to contain text, code or files.</Paragraph> <Paragraph position="12"> # What is arm? Rm is a command that is used to delete files.</Paragraph> <Paragraph position="13"> # What is a search path? A search path is a list of directories that is used by the csh to search for programs to execute.</Paragraph> <Paragraph position="14"> A directory represented as a kind of file. Moreover, it is distinguished from other kinds of files in that it contains files. Similarly, a file is represented as a kind of container that is distinguished from other containers in that it contains some sort of information. The portion of the network pertaining to these concepts is used to generate the first two responses above.</Paragraph> <Paragraph position="15"> Simile format expresses information in terms of other information the user is believed to know. This format is invoked when UCExpress attempts to explain a command that has a sibling or a parent that the user is believed to know, and which is thought to be similar enough to the command to be expressed. The judgment of similarity is made by counting the number of concepts at which the two networks differ. If this is below some arbitrary threshold, the simile format is adopted. An example of the use of the simile format is the following: # What does ruptime do? Ruptime is like uptime, except ruptime is for all machines on the network.</Paragraph> <Paragraph position="16"> The most common expository format is the example format. Examples were shown by Rissland to be important for conveying information (Rissland 1983, Rissland et al. 1984). In UC, examples are used to illustrate plans such as those involving the format of UNIX commands. Unlike Rissland's examples, which are prestored and fetched, UC's example format requires additional computation to transform the general plan into an example. This is accomplished by stepping through a plan and transforming general categories into specific ones.</Paragraph> <Paragraph position="17"> First, if a category dominates other categories, one of those is chosen (at random); then, where the representation can be interpreted as stating that an individual is needed, an individual is created to replace general categories. Where an individual name is required, it is chosen from a list at random, taking care to avoid conflicts with existing names.</Paragraph> <Paragraph position="18"> Consider the following UC dialog: # How can I change the read permission of a file? Use chmod.</Paragraph> <Paragraph position="19"> For example, to remove group read permission from the file named foo, type 'chmod g-r foo'.</Paragraph> <Paragraph position="20"> In the conceptual answer, the last argument of chmod was a pointer to &quot;the name of the file whose protection is to be changed.&quot; To give an example, a concrete name for the file is needed, so foo was arbitrarily selected for use in the example. Since the user did not explicitly mention the type of permission (user, group, or other), this was specified to be group permission in the example. Similarly, &quot;change permission&quot; was further specified into &quot;remove permission.&quot; Since these items are not yet known to the user, they will cause expressions like &quot;the file named foo&quot; to be produced when the example is generated.</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 8.3 EXAMPLE </SectionTitle> <Paragraph position="0"> To see how UCExpress works in more detail, consider the example &quot;Do you know how to print a file on the Imagen?&quot;. After UCEgo, in conjunction with KIP, has determined the proper answer, it calls UCExpress to express it to the user. The input to UCExpress is shown in Figure 25. This input conceptual network is UCEgo's plan to tell the user the plan that KIP produced (Figure 26, Section 7.3). If the plan were to be directly generated into English, the result might be something like: A plan for printing a file on the Imagen printer is to use the lpr command with the Imagen printer option.</Paragraph> <Paragraph position="1"> The format of the command is lpr -Pip and followed by the name of the file to be printed on the Imagen printer.</Paragraph> <Paragraph position="2"> Instead, UCExpress prunes the output, and, since the user is suspected of being a novice, generates an example to illustrate the plan. The following trace illustrates the processing of UCExpress.</Paragraph> <Paragraph position="3"> Computational Linguistics, Volume 14, Number 4, December 1988 73 Robert Wilensky, David N. Chin, Marc Luria, James Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project Express: now expressing the PLANFOR,</Paragraph> <Paragraph position="5"> Express: not expressing PRINT-EFFECT0, since it is already in the context.</Paragraph> <Paragraph position="6"> Express: creating an examp!e for the incomplete plan, IPR-FORMAT0 Express: choosing a name, foo, for an example file.</Paragraph> <Paragraph position="7"> Express: created the example(s):</Paragraph> <Paragraph position="9"> Trace of UCExpress.</Paragraph> <Paragraph position="10"> The first phase of UCExpress is pruning, during which those concepts that the user already knows are marked so that the generator will not generate them. In this case, PRINT-EFFECT0, the goal of PLANFOR70, is pruned, as it is in the current context.</Paragraph> <Paragraph position="11"> In traversing the input conceptual network, UCExpress runs into the command format IPR-FORMAT0. Since this node is presumably not known to the user, UCExpress would normally not prune it. However, UCExpress specifically checks command formats to see if they are as specific as possible, and since FILE6 does not have a name, UCExpress schedules the creation of an example to explain the format, and prunes the original node. The rest of the network is passed without any pruning.</Paragraph> <Paragraph position="12"> In creating an example, UCExpress must specify all the parameters in the command format. Thus the name of the file, which was not specified by the user, is made explicit in the example. Here, the name &quot;foo&quot; was chosen arbitrarily from a list. The complete example is then turned into the proposition part of a TELL (TELL5 in the trace).</Paragraph> <Paragraph position="13"> Figure 26 shows the conceptual network after pruning and the addition of an example. Note that the exemplified of an example is automatically pruned, as it is always expressed by the expressing the generic response. The pruned and augmented conceptual network is next passed to the generator, described in the next section, which produces the following English output: Use lpr -Pip. For example, to print the file named foo on the Imagen printer, type 'lpr -Pip foo'.</Paragraph> <Paragraph position="14"> If the user had been judged to be at least a beginner in experience, then the command format also would have been pruned. This is because KNOME believes that users at the beginner level and up can be assumed to know that part of the command format. In such a case, the entire output would consist of the pruned version of TELL4, and the generated entire response would be: Use lpr -Pip.</Paragraph> </Section> </Section> <Section position="41" start_page="0" end_page="0" type="metho"> <SectionTitle> 9 THE GENERATOR 9.1 INTRODUCTION </SectionTitle> <Paragraph position="0"> After UCExpress formats an answer, the generator, UCGen, converts the conceptual response into text.</Paragraph> <Paragraph position="1"> The current version of UCGen has been customized to work with the types of responses that the system typically produces. It has been built to take advantage of the limited structure of these responses.</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 9.2 DESIGN </SectionTitle> <Paragraph position="0"> To convert a KODIAK representation of a concept into text, UCGen must associate some linguistic information with the concept. This is done by attaching to a concept a pattern that represents some linguistic form. For example, a concept often expressed is PLANFOR. This concept relates a plan for achieving a goal with the goal itself. A pattern for PLANFOR is: 'To (gen goals) comma (gen plan)'.</Paragraph> <Paragraph position="1"> This pattern might be used to generate the sentence: To delete a file, use rm.</Paragraph> <Paragraph position="2"> This is somewhat akin to the pattern concept pair construct in PHRED (Jacobs 1984) or to KING's REF links (Jacobs 1985), although the KODIAK representation accommodates different methods for fetching patterns. null Patterns mix words and punctuation with function calls. In the above example, 'gen' is a function that will be called with argument 'goals' and later with argument 'plan'. In general, the arguments to functions that are found in generator patterns are the aspectuals associated with the concept to which the pattern is attached. In this example, the aspectuals of PLANFOR, 'goals' and 'plan', are arguments to gen.</Paragraph> <Paragraph position="3"> The pattern given above for PLANFOR is the most general one for that concept. That is, it is the pattern used when both the goals and the plan are to be expressed. As described in the previous section on UCExpress, it is not always necessary to express both of these parts. For example, two answers to &quot;How do I delete a file?&quot; are: I. To delete a file, use rm.</Paragraph> <Paragraph position="4"> 2. Use rm.</Paragraph> <Paragraph position="5"> The expression mechanism puts a flag on each aspectual that it does not want expressed. Consequently, associated with each concept may be zero or more patterns, one for each combination of aspectuals that are to be expressed. Planfor is associated with the general pattern shown above, as is the pattern '(gen plan)', which is Computational Linguistics, Volume 14, Number 4, December 1988 75 Robert Wilensky, David N. Chin, Marc Luria, James Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project applicable to the case where only tlhe plan is to be expressed.</Paragraph> <Paragraph position="6"> When a concept to be output is given to the generator, those KODIAK concepts that either dominate or are categories for the concept are searched for one that has an attached generator pattern. If no pattern is found, and the concept is an aspectual, then the value for the aspectual is sent to the generator. The first pattern found is applied to the concept to be expressed to produce an English sentence. Words in the pattern are output as is. Punctuation and function calls must go through further processing. For example, in the pattern 'To (gen goals) comma (gen plan)', the word 'To' is output directly, whereas the (gen ...) function calls must be evaluated, and the 'comma' will be converted to a ','.</Paragraph> <Paragraph position="7"> This generator is easy to understand and extend, and is well integrated with the rest of UC; it shares the KODIAK representation and concepts used by the rest of the system. Some weaknesses are that the overall structure is top down; i.e., only those concepts that are expected to exist are expressed. In general, a generator should be able to handle arbitrary permutations of conceptual relationships. Also, this generator uses little linguistic knowledge. With more complicated utterances, the simple pattern strategies employed so far would become inadequate.</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 9.3 EXAMPLE </SectionTitle> <Paragraph position="0"> This section describes how the output is delivered by UC in response to the question, 'Do you know how to print a file on the Imagen?' . A trace produced while generating this output is given in Figure 27. A diagram of some of the relevant knowledge structures is given in Figure 28.</Paragraph> <Paragraph position="1"> The expression mechanism of UCEgo first passes TELL4 to the generator. Only the proposition part of the TELL will be expressed, so its value, PLANFOR70, is passed to the generator's main routine, 'gen'. PLANFOR70 is dominated by PLANFOR, so the pattern for PLANFOR is retrieved. Since the goals aspectual of PLANFOR70 is marked to be omitted from the response by the expression mechanism, only the plan will be expressed. The pattern found is '(gen plan)'. The value of the plan aspectual, EXECUTE-UNIX-IPR-COMMAND0, is sent to gen. The pattern for this concept is found under execute file-command and is 'use (gen execute command)'. The value of execute-command aspectual of EXECUTE-UNIX-IPR-COMMANDO is 'lpr -Pip'. The first response is therefore: null Use lpr -Pip.</Paragraph> <Paragraph position="2"> Next, the generator is passed TELL5. Once again, only the proposition is to be expressed, so EXAMPLE0 is to be generated. The pattern, found under EXAMPLE, is 'for example comma (gen exampler)'. This sets up a Pattern for PLANFOR70 is: ((gen plan)) Value for plan is: UNIX IPR COMMANDO (print (las-pr-file-obj) on the (las-pr-dest-obj)) Value for las-pr-file-obj is: FILE0 Pattern for FILE0 is: (file named (gen name)) Value for name is: foo Phrase derived from (file named (gen name)) is: (file named foo) Phrase derived from (las-pr-file-obj) is: (the file named foo) Value for las-pr-dest-obj is: IMAGEN0 Pattern for IMAGEN0 is: (imagen) Phrase derived from (las-pr-dest-obj) is: (the imagen) Phrase derived from (gen goals) is: (print the file named foo on the imagen) Value for plan is: TYPE-ACTION0 Pattern for TYPE-ACTION0 is: (type lquote (gen type string) rquote) Value for type-string is: CONCAT-STR0 Pattern for CONCAT-STR0 is: ((gen step) (gen next)) Value for step is: lpr -Pip Pattern for lpr -Pip is: (lpr -Pip) Phrase derived from (gen step) is: (lpr -Pip) Value for next is: foo is: (foo) from (gen next) is: (foo) from (gen type-string) is: (lpr -Pip foo) from (gen plan) is: (type lquote lpr -Pip Phrase derived from (gen exampler) is: (to print the file named foo on the Imagen comma type lquote lpr -Pip foo rquote) For example, to print the file named foo on the Imagen, type lpr -Pip foo.</Paragraph> <Paragraph position="3"> Figure 27. UCGen Trace for the Example Question. recursive call to gen with the value of the exampler relation as argument. This value is PLANFOR31. Once again, a PLANFOR is to be generated. This time, however, both the plan and goals will be expressed. The pattern is 'to (gen goals) comma (gen Computational Linguistics, Volume 14, Number 4, December 1988 77 Robert Wilensky, David N. Chin, Marc Luria, James Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project plan)'. The value of the goals aspectual is PRINT-EFFECT1. The pattern is found under LAS-PR-EFFECT; and is 'print (las-pr-file-obj) on the (las-prdest-obj)'. null The las-pr-file-obj specification causes the generator to find an object in this relation to PRINT-EFFECT1, in this case, FILE0. One of the patterns for FILE is 'file named (gen name)'. This pattern is applicable if the object in question has a name. Here, FILE0 has the name 'foo'. When UCGen is generating the name of an object, it uses a heuristic to decide which, if any article to precede the object description with. In general, UCGen will use definite articles if it can.</Paragraph> <Paragraph position="4"> The other part of the output from the goals aspectual is from the second half of the pattern: 'on the (las-prdest-obj)'. Here the value found is IMAGEN0. The pattern for IMAGEN0 is just 'imagen'. Again, the generator will supplement this description with a definite article.</Paragraph> <Paragraph position="5"> The value of the 'plan' aspectual for PLANFOR31 is TYPE-ACTION0. The pattern for this concept is from TYPE-ACTION and is 'type lquote (gen type-string) rquote'. The value for the type string aspectual of TYPE-ACTION0 is CONCAT-STR0. The pattern is from sequence and is '(gen step) (gen next)'. Here, the step is 'lpr -Pip' (i.e., the stringl of CONCAT-STR0), and the next is the name of the file, 'foo' (the string2 of CONCAT-STR0). Thus the output for this call to the generator is: For example, to print the file named foo on the imagen, type lpr -Pip foo.</Paragraph> </Section> </Section> <Section position="42" start_page="0" end_page="0" type="metho"> <SectionTitle> 10 KNOWLEDGE ACQUISITION 10.1 INTRODUCTION </SectionTitle> <Paragraph position="0"> UC is knowledge dependent. It is the task of the knowledge-acquisition system to facilitate the construction and subsequent extension of the, knowledge base.</Paragraph> <Paragraph position="1"> The traditional approach to knowledge acquisition has been to provide the system implementers with special purpose software tools such as text editors, form systems, and graphic network editors (van Melle 1981).</Paragraph> <Paragraph position="2"> These approaches require that the person adding the knowledge have detailed knowledge of the knowledge representation language being used and of the overall design of the system. The typical situation, however, is that the people with the domain knowledge do not have the knowledge necessary to add information to a complex knowledge base. The system builders must therefore extract the information from the experts and then program it in themselves. This is a tedious, error prone process that is only viable as long as the system builder is in contact with the program. If the system is in use in a real environment, the knowledge base is essentially frozen.</Paragraph> </Section> <Section position="43" start_page="0" end_page="0" type="metho"> <SectionTitle> 10.2 THE UC APPROACH </SectionTitle> <Paragraph position="0"> Our solution to this problem is to provide a mechanism to allow the., interactive transfer of knowledge from the domain expert to the knowledge base using natural language. This is similar to the approach taken in the Nano-KLAUS system (Haas and Hendrix 1980). UCTeacher (Martin 1985) is the system being built to provide this facility for UC. The UNIX expert can engage UCTeacher in a mixed initiative dialogue to add more information to UC's knowledge base.</Paragraph> <Paragraph position="1"> UCTeacher provides both the acquisition of UNIX domain knowledge, and the acquisition of linguistic knowledge. In particular, UCTeacher has a mechanism that allows it to guess the metaphoric use of a term in UNIX, based on its knowledge of the metaphoric use of this term outside of UNIX. In this report, we focus largely on domain knowledge acquisition. The mechanism of metaphor extension is beyond the scope of this report, and is described only briefly.</Paragraph> </Section> <Section position="44" start_page="0" end_page="0" type="metho"> <SectionTitle> 10.3 ACQUIRING DOMAIN KNOWLEDGE </SectionTitle> <Paragraph position="0"> In the following examples of UCTeacher, the knowledge base of UC is set up so as not to contain knowledge of the commands to be illustrated. Also, the prompt 'UCT>' is used to distinguish an interaction with UCTeacher from one with UC proper.</Paragraph> <Paragraph position="1"> UCT> Use compact to compress a file.</Paragraph> <Paragraph position="2"> You mean that typing 'compact filename' will compress the file named filename.</Paragraph> <Paragraph position="3"> UCT> Yes.</Paragraph> <Paragraph position="4"> UCTeacher uses ALANA and the concretion mechanism to produce a representation of the initial utterance by the expert. In a typical interaction, the initial utterance will provide very sketchy information. The main job of UCTeacher is realize what information is needed, determine what it is, and use it to flesh out the representation. When it believes it has enough information, UCTeacher will paraphrase its understanding to the user for conformation. The user then has the opportunity to confirm or correct UCTeacher's understanding. UCTeacher has three main sources of knowledge: 78 Computational \]Linguistics, Volume 14, Number 4, December 1988 Robert Wilensky, David N. Chin, Marc Luria, James Martin, James Mayfield, and Dekai Wu The Berkeley UNIX Consultant Project the user's utterance, the contents of UC's knowledge base, and a store of meta-knowledge associated with concepts in the knowledge base. This use of knowledge plus meta-knowledge makes the knowledge acquisition process a knowledge-based task (Davis 1976).</Paragraph> <Paragraph position="5"> UCTeacher uses these three sources of knowledge to acquire all the necessary information from the expert in as natural a dialog as possible. In Example 1, we see the system generating appropriate questions to acquire information that the expert has not initially provided. This ability frees the expert from having to know all the relevant information that must be provided. The system will prompt for all the necessary items. Examples 2 and 3 show the system making full use of the expert's utterance to avoid asking redundant questions.</Paragraph> </Section> class="xml-element"></Paper>