<?xml version="1.0" standalone="yes"?>
<Paper uid="P92-1049">
  <Title>ELABORATION IN OBJECT DESCRIFFIONS THROUGH EXAMPLES</Title>
  <Section position="4" start_page="315" end_page="316" type="metho">
    <SectionTitle>
AN EXAMPLE
</SectionTitle>
    <Paragraph position="0"> Consider for inst,'mce, the example in Figure 1, from a well known introductory book on the programming language LISP. It describes an object (a data structure) called a &amp;quot;fist.&amp;quot; There are a number of issues that can be immediately seen to be relevant: I. Should the system choose to elaborate on the object attributes in text, or through the use of examples? For instance, the information in Figure I could also have been expressed textually as: &amp;quot;A list always begins with a left parenthesis. Then come zero or more pieces of data (called the elements of a list), and a right parenthesis. Data elements can be of any LISP type, including numbers, symbols and strings&amp;quot;. In the figure, the examples arc used to elaborate on two aslaeCtS of the data-elements: the variable number of the elements, and the different types of which these elements may belong to. In some contexts, the examples tend to re-iterate certain aspects (in this case, the number was mentioned in the explanation as well), while in others, the examples tend to elaborate on aspects that are not mentioned explicitly in the description (in our case, the type information).</Paragraph>
    <Paragraph position="1">  2. Should the system use one example, or multiple examples? Consider for instance, the following example of a LISP list: (FORMAT T &amp;quot;~2% ~ A ~ A - A&amp;quot; 12345678 ' James ' Smith (address person) )  It is not entirely obvious that single examples of the type above arc always the most appropriate ones, A list always begins with a left parenthesis. Then come zero or more pieces of data (called the elements of a list) and a right parenthesis. Some examples of lists  even though such examples are frequently seen in technical reference material. The system must therefore be able to make reasonable decisions regarding the granularity of information to be included in each example and structure its presentation accordingly.</Paragraph>
    <Paragraph position="2"> 3. If there are multiple examples that are to be presented, their order of presentation is important too. Studies has shown that users tend to take into account the sequence of the examples as a source of implicit information about the examples (Carnine, 1980; Litchfield, IMiscoll &amp; Dempsey, 1990; Tennyson, Steve &amp; Boutwell, 1975). For instance, in Figure 1, the first and second examples taken together illustrate the point that the number of data elements is not important.</Paragraph>
    <Paragraph position="3"> 4. When are 'prompts' necessary? Examples often have attention focusing devices such as arrows, marks, or as in the Figure 1, extra text, associated with them. These help the user disambiguate the salient from the irrelevant. What information should be included in the prompts, and in the case of text, how should be be phrased? 5. How should the example be positioned with respect to the text? Studies of instructional texts reveal that examples can occur before the text (and the text elaborates upon the example), within the text, or (as in our figure), after the text (Feldman, 1972).</Paragraph>
    <Paragraph position="4"> There are other issues that need to be considered in an integrated framework - some of these that affect most of the issues raised above are the audience-type, the knowledge-type (whether the concept being described is a noun or a relation for instance) and the text-type (tutorial vs. reference vs. report, ete). The</Paragraph>
    <Paragraph position="6"/>
    <Paragraph position="8"> examples.</Paragraph>
    <Paragraph position="9"> issue of how the examples are selected (generated vs. retrieved is also an important issue, but we shall not discuss that here.</Paragraph>
  </Section>
  <Section position="5" start_page="316" end_page="316" type="metho">
    <SectionTitle>
STATUS OF WORK
</SectionTitle>
    <Paragraph position="0"> We are investigating these issues by implementing a system that can generate examples within explanatory contexts (within theEES framework (Neches, Swartout &amp; Moore, 1985; Swartout &amp; Smoliar, 1987)) using the Moore-Paris planner (1992, 1991 ) for discourse generation. Our initial system is for the automatic generation of documentation for small sub-sets of programming languages. One reason for this choice is that it allows us to study a variety of example-rich texts in a relatively unambiguous domain. A partial text-plan generated by our planner for the description given in Figure 1 is given in Figures 2 and 3. It shows some of the communicative goals that the planner needs to be able to satisfy in order to generate some of the simple object descriptions in our application. These descriptions can make use of examples (instead of tex0 to list and describe feature elaborations, or use them in conjunction with a textual description to clarify and illustrate various points.</Paragraph>
    <Paragraph position="1"> Among issues that we plan to study are the differences between opportunistic generation of examples and top-down planning of text with examples, and the effects arising from differences in the knowledge type, the text-type and other sources of information.</Paragraph>
  </Section>
class="xml-element"></Paper>