<?xml version="1.0" standalone="yes"?>
<Paper uid="P84-1087">
  <Title>LEXICAL SEMANTICS IN HUMAN-COMPUTER COMMUNICATION</Title>
  <Section position="4" start_page="428" end_page="429" type="metho">
    <SectionTitle>
2. Names for Objects
</SectionTitle>
    <Paragraph position="0"> In addition to studies of command names, there have been a number of interesting studies of how users (or system designers} denote objects. One version of this has been called the &amp;quot;Yellow Pages problem:&amp;quot; how does a user or a computer describe a given object in a given context? Naming objects. Furnas et al. (1983} asked subjects to describe or name objects in various domains so that other people would be able to identify what they were talking about. The subjects were either to use key words or normal discourse. It was found that the average likelihood of any two people using the same main content word in describing the same object ranged from about 0.07 to 0.18 for the different domains studied.</Paragraph>
    <Paragraph position="1"> Carroll 11982) studied how people named their files on an \[BM CMS system (CMS filenames are limited to 18 characters and are thus usually abbreviated). Subjects gave him a list of their files along with a description of their contents, and from this, Carroll inferred what the &amp;quot;unabbreviated&amp;quot; filenames were. He found that 85 percent of the filenames used simple organizing paradigms, two of which involved the concepts of congruence and hierarchicalness discussed above.</Paragraph>
    <Paragraph position="2"> Naming categories. Dumais and Landauer'11983} describe two major problems in naming and describing categories in computer systems. The first is that of inaccurate category names: a name for a category may not be very descriptive, or people's interpretation of it may differ radically. The second problem is that of inaccurate classification: categories may be fuzzy or overlapping, or there may be many different dimensions by which an object may be classified. Dumais and Landauer examined whether categories which are hard to describe could be better named simply by giving example of their members. They found that presenting three examples worked as well as using a description, or a description plus examples. In another study involving people's descriptions of objects (Dumais and Landauer, 1982} they found that their subjects' descriptions were often vague, and rarely used negations. The most common paradigm for  describing objects was to give a superordinate term followed by several of the item's distinctive features.</Paragraph>
    <Paragraph position="3"> Deixis. The pragmatic issue of deixis should be mentioned, since some systems allow context-dependent references in some contexts such as history mechanisms. For example, in INTERLISP the variable IT refers to the value of the user's last evaluated top-level expression, but sometimes this interpretation does not map exactly onto the one the user has. Physical pointing devices such as the &amp;quot;mouse&amp;quot; allow deixis as a more natural way of denoting objects, actions, and properties in cases where it is difficult or tedious to indicate the referent by a referring expression.</Paragraph>
    <Paragraph position="4"> There are, of course, many other aspects of the lexica\[ semantics of command languages which cannot be covered here, such as abbreviations {Benbasat and Wand, 1984}, automatic spelling correction of user inputs (Durham et al., 1983}, and generic names (Rosenberg and Moran, 1984}.</Paragraph>
  </Section>
  <Section position="5" start_page="429" end_page="429" type="metho">
    <SectionTitle>
3. A Featural Framework
</SectionTitle>
    <Paragraph position="0"> While the above results are interesting: they are disappointing in two respects. To the designer of computer systems they are disappointing because it is not clear how they are related to each other: there are no general principles to use in deciding how to name commands or objects, or what similarities or tradeoffs there are among the different aspects of naming in computer systems. To the linguist or psycholinguist they are disappointing because there is no theory or analytic framework for describing what is happening. In my own work (Rosenberg, 1983} \[ have tried to formulate a simple featural framework in which to place these disparate results. My intention has been to develop a simple analysis which can be used in design, rather than a linguistic theory, but linguists will easily recognize its mixed parentage. At least a framework using semantic features has the advantage of simplicity, and can be converted into a more sophisticated theory if desired.</Paragraph>
    <Paragraph position="1"> In such a featural approach the features of a name or action can be thought of as properties falling into four major classes: Semantic features are those elemental components of meaning usually treated in discussions of lexical semantics.</Paragraph>
    <Paragraph position="2"> For example, insert has the semantic feature + ADD.</Paragraph>
    <Paragraph position="3"> Pragmatic features are meaning components which are context dependent in some sense, involving phenomena such as deixis or presuppositions. For example, an anaphorie referent like it has some sort of pragmatic feature, however one wishes to describe it. \[t goes without saying that the distinction between semantic and pragmatic features is not a clear one, but for practical purposes that is not terribly important.</Paragraph>
    <Paragraph position="4"> Syntactic features are the sorts of selection restrictions, etc. which coordinate the lexical item into larger linguistic units such as entire commands. For example, substitute requires that the new object be specified before the old one.</Paragraph>
    <Paragraph position="5"> t, Surface features are perceptual properties such as sound or shape. The usefulness of including them in the analyis is seen in the discussion of non-words as names.</Paragraph>
    <Paragraph position="6"> As Bolinger {1965l pointed out long ago, names and actions have a potentially infinite number of features, but in the restricted world of command languages we can consider them to have a finite, even relatively small number. Furthermore, only some features of a name or action are relevant at given time due to the particular contexts involved: the task context is that of the task the user is performing (e.g., text editing vs. database querying); the name context is that of the other names being used; and the action context is that of the other actions in the system. These three kinds of context emphasize some features of the names and actions and make others irrelevant.</Paragraph>
    <Paragraph position="7"> Applying this framework to system naming, we can represent system actions and objects and their names as sets of features.</Paragraph>
    <Paragraph position="8"> The most important aspect of these feature representations is their similarity (or, conversely, their distinctiveness}. This featural similarity has been formally defined in work by Tversky {1977, 1979}.</Paragraph>
    <Paragraph position="9"> Within these two domains of names and actions (or objects}, distinctiveness is of primary importance, since it prevents confusion. Between the two domains, similarity is of primary importance, since it makes for a better mapping between items in the two domains. Although the details of this process vary among the different phenomena, this paradigm serves to unify a number of different results.</Paragraph>
    <Paragraph position="10"> For example, suggestiveness and memorability may both be interpreted in terms of a high degree of similarity between the features of a name and its referent, with high distinctiveness among names and referents reducing the possibilities of confusivn on either end. And the analysis easily extends to include nonwords, since those without semantics map their surface features onto the semantic features of their referents.</Paragraph>
    <Paragraph position="11"> The role of syntactic and pragmatic features is analogous, but the issue there is not simply one of how similar the two sets of features are, but also of how, for example, the selection restrictions of a name mesh with the rules of the command language. Where the analysis will lead in those domains is a question I am currently pursuing.</Paragraph>
  </Section>
class="xml-element"></Paper>