<?xml version="1.0" standalone="yes"?>
<Paper uid="P83-1024">
  <Title>Knowledge Structures in UC, the UNIX* Consultantt</Title>
  <Section position="3" start_page="159" end_page="159" type="metho">
    <SectionTitle>
3. The Choice
</SectionTitle>
    <Paragraph position="0"> Many different representation schemes were considered for UC. In the past, expert systems have used relations in a database (e.g. the UCC system of Douglass and Hegner, 1982), production rules and/or predicate calculus, for knowledge representation. Although these formats have their strong points, it was felt that none provided the flexibility needed for the variety of tasks in UC.</Paragraph>
    <Paragraph position="1"> Relations in a database are good for large amounts of data, but the database query languages which must be used for access to the knowledge are usually poor representation languages. Production rules encode procedural knowledge in an easy to use format, but do not provide much help for representing declarative knowledge. Predicate calculus provides built-in inference mechanisms, but do not provide sufficient mechanism for representing the linguistic forms found in natural language. Also considered were various representation languages, in particular KL-one (Schmolze and Brachman, 1981). However at the time, these did not seem to provide facilities for efficient access in very large knowledge bases. The final decision was to use a frame-like representation where some of the contents are based on Schank's conceptual dependencies, and to store the knowledge structures in PEARL databases (PEARL is an AI package developed at Berkeley that provides efficient access to Lisp representations through hashing mechanisms, c.f. Deering, et. al., 1981 and 1982).</Paragraph>
  </Section>
  <Section position="4" start_page="159" end_page="161" type="metho">
    <SectionTitle>
4. The Implementation
</SectionTitle>
    <Paragraph position="0"> Based on Minsky's theory of frames, the knowledge structures in UC are frames which have a slot-filler format.</Paragraph>
    <Paragraph position="1"> The idea is to store all relevant information about a particular entity together for efficient access. For example the following representation for users has the slots userid, home-directory, and group which are filled by a userid, a directory, and a set of group-id's respectively.</Paragraph>
    <Paragraph position="2"> (create expanded person user</Paragraph>
    <Paragraph position="4"> In addition, users inherit the slots of person frames such as a person's name.</Paragraph>
    <Paragraph position="5"> To see how the knowledge structures are actually used, it is instructive to follow the processing of queries in some detail. UC first parses the English input into an internal representation. For instance, the query of example one is parsed into a question frame with the single slot, cd, which is filled by a planfor frame. The question asks what is the plan for (represented as a planfor with an unknown method) achieving the result of changing the write protection (mesg state) of a terminal (terminall which is actually a frame that is not shown).</Paragraph>
    <Paragraph position="6"> (question (cd (planfor (result (state-change (actor terminall)</Paragraph>
    <Paragraph position="8"> Once the input is parsed, UC which is a data driven program looks in its data base to find out what to do with the representation of the input. An assertion frame would normally result in additions to the database and an Imperative might result in actions (depending on the goal analysis}. In this case, when UC sees a question with a planfor where the method is unknown, it looks in its database for an out-planfor with a query slot that matches the result slot of the planfor in the question.</Paragraph>
    <Paragraph position="9"> This knowledge is encoded associatively in a memory-association frame where the recall-key is the associative component and the cluster slot contains a set of structures which are associated with the structure in the recall-key slot.</Paragraph>
    <Paragraph position="11"> The purpose of the memory-association frame is to simulate the process of reminding and to provide very flexible control flow for UC's data driven processor. After the question activates the memory-association, a new out-pianfor is created and added to working memory. This out-planfor in turn matches and activates the following knowledge structure in UC's database: (out-planfor (query (state-change (actor terminal)</Paragraph>
    <Paragraph position="13"> The meaning of this out-planfor is that if a query about a state-change involving the mesg state of a terminal is ever encountered, then the proper response is the output frame in the plan slot. All output frames in UC are passed to the generator* The above output frame contains the planfors numbered 67 and 68: planfor67:</Paragraph>
    <Paragraph position="15"> This planfor states that a plan for changing the mesg state of a terminal from on to off is for the user co send the command rnes~I to UNIX with the argument &amp;quot;y&amp;quot;.</Paragraph>
    <Paragraph position="16"> Planfor 68 is similar, only with the opposite result and with argument &amp;quot;n&amp;quot;. In general, UC contains many of these planfors which define the purpose (result slot) of a plan (method slot). The plan is usually a simple command although there are more complex meta plans for constructing sequences of simple commands such as might be found in a UNIX pipe or in conditionals.</Paragraph>
    <Paragraph position="17"> In UC, out-planfors represent &amp;quot;compiled&amp;quot; answers in an expert consultant where the consultant has encountered a particular query so often that the consultant already has a rote answer prepared* Usually the question that is in the query slot of the out-planfor is similar to the result of the planfor that is in the output frame in the plan slot of the out-planfor. However this is not necessarily the case, since the out-planfor may have anything in its plan slot.</Paragraph>
    <Paragraph position="18"> For example some queries invoke UC's interface with UNIX (due to Margaret Butler} to obtain specific information for the user.</Paragraph>
    <Paragraph position="19"> The use of memory-associations and out-planfors in UC provides a direct association between common user queries and their solutions. This direct link enables UC to process commonplace queries quickly. When UC encounters a query that cannot be handled by the outplanfors, the planning component of UC (PANDORA, c.f.</Paragraph>
    <Paragraph position="20"> Faletti, 1982) is activated* The planner component uses the information in the UC databases to create individualized plans for specific user queries. The description of that proems is beyond the scope of this paper.</Paragraph>
    <Paragraph position="21"> The representation of definitions requires a different approach than the above representations for actions and plans. Here one can take advantage of the practicality of terminology in a specialized domain such as UNIX.</Paragraph>
    <Paragraph position="22"> Specifically, objects in the UNIX domain usually have definite functions which serve well in the definition of the object. In example two, the type declaration of a search-path includes a use slot for the search-path which contains information about the main function of search paths. The following declaration defines a searc:.-~n as a kind of functional-object with a path slot that contains a set of directories and a ~zse slot which says that search paths are used in searching for programs by UNL~.</Paragraph>
    <Paragraph position="24"> Additional information useful in generating a definition can be found the slots of a concept's declaration. These slots describe the parts of a concept and are ordered in terms of importance. Thus in the example, the fact tha~ a search-path is composed of a set of directories was used in the definition given in the examples.</Paragraph>
    <Paragraph position="25"> Other useful information for building definitions i~ encoded in the hierarchical structure of concepts in UC.</Paragraph>
    <Paragraph position="26"> This is not used in the above example since a search-path is only an expanded version of the theoretical concept, functional-object. However with other objects such a.~ directory, the fact that directory is an expanded version of a file {a directory is a file which is ,sed to store other files) is actually used in the definition.</Paragraph>
    <Paragraph position="27"> The third type of query involves failed preconditions of plans or missing steps in a plan. In UC the preconditions of a plan are listed in a preeonds frame. For instance, in example 3 above, the relevant preconds frame is:  This states that one of the preconditions for removing a directory is that it must be empty. In analyzing the example, UC first finds the goal of the user, namely to  delete the directory Trap. Then from this goal, UC looks for a plan for that goal among planfors which have that goal in their result slots. This plan is shown above.</Paragraph>
    <Paragraph position="28"> Once the plan has been found, the preconds for that plan are checked which in this case leads to the fact that a directory must be empty before it can be deleted. Here UC actually checks with UNIX, looking in the user's area for the directory Trap and discovers that this precondition is indeed violated. If UC had not been able to find the directory, UC would suggest that the user personally check for the preconditions. Of course if the first precondition was found to be satisfied, the next would be checked and so on. In a multi-step plan, UC would also verify that the steps of the plan had been carried out in the proper sequence by querying the user or checking with UNIX.</Paragraph>
  </Section>
  <Section position="5" start_page="161" end_page="161" type="metho">
    <SectionTitle>
5. Storage for Efficient Access
</SectionTitle>
    <Paragraph position="0"> The knowledge structures in UC are stored in PEARL databases which provide efficient access by hash indexing.</Paragraph>
    <Paragraph position="1"> Frames are indexed by combinations of the frame type and/or the contents of selected slots. For instance, the planfor of example one is indexed using a hashing key based on the state-change in the planfor's result slot.</Paragraph>
    <Paragraph position="2"> This planfor is stored by the fact that it is a planfor for the state-change of a terminal's mesg state. This degree of detail in the indexing scheme allows this planfor to be immediately recovered whenever a reference is made to a state-change in a terminars mesg state.</Paragraph>
    <Paragraph position="3"> Similarly, a memory-association is indexed by the filler of the recall-key slot, an out-planfor is indexed using the contents of the query slot of the out-planfor, and a preconds is indexed by the plan in the plan slot of the preconds. Indeed all knowledge structures in UC have associated with them one or more indexing schemes which specify how to generate hashing keys for storage of the knowledge structure in the UC databases. These indexing methods are specified at the time that the knowledge structures are defined. Thus although care must be taken to choose good indexing schemes when defining the structure of a frame, the indexing scheme is used automatically whenever another instance of the frame is ~dded to the UC databases. Also, even though the indexing schemes for large structures like planfors involve many levels of embedded slots and frames, simpler knowledge structures usually have simpler indexing schemes. For example, the representation for users in UC are stored in two ways: by the fact that they are users and have a specific account name, and by the fact that they are users and have some given real name.</Paragraph>
    <Paragraph position="4"> The basic idea behind using these complex indexing schemes is to simulate a real associative memory by using the hashing mechanisms provided in Pearl databases.</Paragraph>
    <Paragraph position="5"> This associative memory mechanism fits well with the data-driven control mechanism of UC and is usel'ul for a great variety of tasks. For example, goal analysis of speech acts can be done through this associative mechanism: null (memory-association (recall-key (assertion (cd (goal (planner ?person} (objective ?obj )))) (cluster ((out-pianfor (cd ?obi))))) In the above example {provided by Jim Mayfield), UC * analyzes the user's statement of wanting to do something as a request for UC to explain how to achieve that goal.</Paragraph>
  </Section>
  <Section position="6" start_page="161" end_page="161" type="metho">
    <SectionTitle>
6. Conclusions
</SectionTitle>
    <Paragraph position="0"> The knowledge structures developed for UC have so far shown good efficiency in both access time and space usage within the limited domain of processing queries to a Unix Consultant. The knowledge structures fit well in the framework of data-driven programming used in UC.</Paragraph>
    <Paragraph position="1"> Ease of use is somewhat subjective, but beginners have been able to add to the UC knowledge base after an introductory graduate course in AI. Efforts underway to extend UC in such areas as dialogue will further test the merit of this representation scheme.</Paragraph>
  </Section>
  <Section position="7" start_page="161" end_page="161" type="metho">
    <SectionTitle>
7. Technical Data
</SectionTitle>
    <Paragraph position="0"> UC is a working system which is still under development.</Paragraph>
    <Paragraph position="1"> In size, UC is currently two and a half megabytes of which half a megabyte is FRANZ lisp. Since the knowledge base is still growing, it is uncertain how much of an impact even more knowledge will have on the system especially when the program becomes too large to fit in main memory. In terms of efficiency, queries to UC take between two and seven seconds of CPU time on a V.~X 11/780. Currently, all the knowledge in UC is hand coded, however efforts are under way to aatomate the process.</Paragraph>
  </Section>
class="xml-element"></Paper>