File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/intro/98/w98-0608_intro.xml
Size: 7,924 bytes
Last Modified: 2025-10-06 14:06:43
<?xml version="1.0" standalone="yes"?> <Paper uid="W98-0608"> <Title>Coreference in Knowledge Editing</Title> <Section position="2" start_page="0" end_page="57" type="intro"> <SectionTitle> 1 Introduction </SectionTitle> <Paragraph position="0"/> <Section position="1" start_page="0" end_page="56" type="sub_section"> <SectionTitle> 1.1 Editing knowledge by WYSIWYM </SectionTitle> <Paragraph position="0"> WYSIWYM is a method of editing knowledge bases in which the user interacts with a feedback text generated by a natural language generation system (e.g. Power and Scott 1998). The idea of WYSIWYM editing is to provide an interface to a knowledge base that can be used easily by an author who is a domain expert but not necessarily an expert in knowledge representation. The feedback text serves two purposes: it shows the knowledge that has already been specified; and it shows the options for adding new knowledge. These options are marked by anchors. By clicking on an anchor, the user obtains a pop-up menu from which a semantic option can be selected. The acronym WYSIWYM stands for 'What You See Is What You Meant': a natural language text ('what you see') presents a knowledge base that the author has built by purely semantic decisions ('what you meant').</Paragraph> <Paragraph position="1"> This method was first implemented in DRAFTElZ-II (Power et al, 1998), a re-engineered version of DRAFTER (Paris et al, 1995) which is designed for use by the technical authors who produce software documentation. By interacting with the feedback text, the author defines a procedure for performing a task, e.g. the task of saving a document in a word processor.</Paragraph> <Paragraph position="2"> When a new knowledge base is created, DRAFTER-II assumes that its root will be some kind of procedure. A procedure instance is created, and assigned an identifier (for internal use only), e.g. procl. The definition of the concept procedure specifies that every procedure has two attributes: a goal, and a method. The g0al must be some kind of action, and the method must be a list of actions. This information is conveyed to the author through a feedback text Achieve this goal by applying this method.</Paragraph> <Paragraph position="3"> with several special features.</Paragraph> <Paragraph position="4"> * Undefined attributes are shown through anchors marked by the use of boldface or italics.</Paragraph> <Paragraph position="5"> * A boldface anchor indicates that the attribute is obligatory: its value must be specified. An italicized anchor indicates that the attribute is optional.</Paragraph> <Paragraph position="6"> * All anchors are mouse-sensitive. By clicking on an anchor, the author obtains a pop-up menu listing the permissible values of the attribute; by selecting one of these options, the author updates the knowledge base.</Paragraph> <Paragraph position="7"> Although the anchors may be tackled in any order, we will assume that the author proceeds from left to right. Clicking on this goal yields a pop-up menu that lists all the types of actions that the system knows about: (to save space, some options are omitted), from which the author selects 'save'. Although apparently selecting a word, the author is really selecting an option for editing the knowledge base. The program responds by creating a new instance, of type save, and adding it to the knowledge base as the value of the goal attribute on procl: procedure (procl).</Paragraph> <Paragraph position="8"> goal(procl, savel).</Paragraph> <Paragraph position="9"> save (savel).</Paragraph> <Paragraph position="10"> From the updated knowledge base, the generator produces a new feedback text Save this data by applying this method.</Paragraph> <Paragraph position="11"> including an anchor representing the undefined actee attribute on the savel instance. Note that this text has been completely regenerated. It was not produced from the previous text merely by replacing the anchor this goal by a longer string. By continuing to make choices at anchors, the author might expand the knowledge base in the following sequence: * Save the document by applying this method.</Paragraph> <Paragraph position="12"> * Save the document by performing this action (further actions).</Paragraph> <Paragraph position="13"> * Save the document by clicking on this object (further actions).</Paragraph> <Paragraph position="14"> * Save the document by clicking on the button with this label (further actions). null * Save the document by clicking on the Save button (further actions).</Paragraph> <Paragraph position="15"> At this point the knowledge base is potentially complete (no boldface anchors remain), so an output text can be generated and incorporated into the software manual.</Paragraph> <Paragraph position="16"> To save the document, click on the Save button.</Paragraph> <Paragraph position="17"> To delete information, the author opens a pop-up menu on any span of the feedback text that presents a defined attribute. For instance, the span 'the document' presents the actee attribute on the instance savel. Clicking on this span in the feedback text, the author obtains the menu If 'Cut' is selected, the instance that is currently the value of the actee attribute is removed to a buffer, leaving the attribute undefined. The resulting feedback text introduces an anchor in place of 'the document'.</Paragraph> <Paragraph position="18"> Save this data by clicking on the Save button (further actions).</Paragraph> <Paragraph position="19"> When the buffer is full, the pop-up menus that open on anchors contain a 'Paste' option if the instance in the buffer is a suitable value for the relevant attribute.</Paragraph> </Section> <Section position="2" start_page="56" end_page="57" type="sub_section"> <SectionTitle> 1.2 Limitations of DI:tAFTER-II </SectionTitle> <Paragraph position="0"> In the DRAFTER-II implementation of WYISYWM, the attribute value that is added at an anchor is always a new instance of the specified concept, never an existing instance. Suppose the author has developed the feedback text Save the document by entering the name of this object (.further actions).</Paragraph> <Paragraph position="1"> while aiming at the output text To save the document, enter its name and click on the Save button.</Paragraph> <Paragraph position="2"> The current (incomplete) state of the knowledge base is procedure (proc 1).</Paragraph> <Paragraph position="3"> goal(procl, savel).</Paragraph> <Paragraph position="4"> save (save 1).</Paragraph> <Paragraph position="5"> actee(savel, docl).</Paragraph> <Paragraph position="6"> document (docl).</Paragraph> <Paragraph position="7"> method(procl, listl).</Paragraph> <Paragraph position="8"> list (list ~).</Paragraph> <Paragraph position="9"> first(listl, enterl).</Paragraph> <Paragraph position="10"> enter (enterl).</Paragraph> <Paragraph position="11"> actee(enterl, namel).</Paragraph> <Paragraph position="12"> name (name I).</Paragraph> <Paragraph position="13"> The author now expands the anchor this object, which marks the owner attribute on namel. This can be done in two ways: opening a pop-up menu on the anchor and choosing 'document', or choosing 'Copy' on the earlier phrase 'the document' and pasting the copied material on to the anchor. In either case, the current implementation creates a new instance doc2 of the concept document instead of using the existing instance docl. In other words, it adds the two assertions owner(namel, doc2).</Paragraph> <Paragraph position="14"> document (doc2).</Paragraph> <Paragraph position="15"> instead of the single assertion owner(namel, docl).</Paragraph> <Paragraph position="16"> Our aim in this paper is to outline a way of overcoming this limitation, so that the author will be able to specify whether two similar descriptions are coreferential.</Paragraph> </Section> </Section> class="xml-element"></Paper>