<?xml version="1.0" standalone="yes"?>
<Paper uid="P84-1087">
  <Title>LEXICAL SEMANTICS IN HUMAN-COMPUTER COMMUNICATION</Title>
  <Section position="3" start_page="0" end_page="428" type="intro">
    <SectionTitle>
0. Introduction
</SectionTitle>
    <Paragraph position="0"> Most research on the language used in human-computer communication has focused on issues of syntax and discourse; it is hoped that eke day computers will understand a large subset of natural language, and the most obvious problems thus appear to be in parsing and understanding sequences of utterances. The constraints provided by the sublanguages used in current natural language interfaces provide a means for making these issues tractable. Until computers can easily understand these sublanguages, we must continue to use artificial command languages, although the increasing richness of these languages brings them closer and closer to being sublanguages themselves.</Paragraph>
    <Paragraph position="1"> This fact suggests that we might profitably view the command languages of computer systems as natural languages, having the same three levels of syntax, semantics, and pragmatics {perhaps also morpho-phonemics, if one considers the form in which the interaction takes place with the system: special keys, variant characters, etc.).</Paragraph>
    <Paragraph position="2"> A particularly interesting and, till recently, neglected area of investigation is the lexical semantics of command languages.</Paragraph>
    <Paragraph position="3"> What the objects and actions of a system are called is not only practically important but also as theoretically interesting as the lexical phenomena of natural languages. In the field of natural language interfaces there has been some study of complex references, such as Appelt's (1983) work on planning referring expressions, and Finin's (1982) work on parsing complex noun phrases, but individual lexical items have not been treated in much detail. In contrast, the human factors research on command languages and user-interface design has looked at lexical semantics in great detail, though without much linguistic sophistication. In addition, much of this research is psycholinguistic rather than strictly linguistic in character, involving phenomena such as the learning and remembering of names as much as their semantic relations. Nevertheless, a linguistic analysis may shed some light on these psycholinguistic phenomena. In this paper l will present an overview of the kinds of research that have been done in this area and suggest a simple featural framework in which they may be placed.</Paragraph>
    <Paragraph position="4"> I. Names for Actions By far the greatest amount of research on lexical semantics in command languages has been done with names for actions. It is easy to find instances of commands whose names are cryptic or dangerously misleading (such as Unix's cat for displaying a file, and Tenex's list for printing), or ones which are quite unmemorable (as are most of those in the EMACS editor).</Paragraph>
    <Paragraph position="5"> Consequently, there have been a number of studies examining the suggestiveness of command names, their learnability and memorability, their compositional structure, and their interaction with the syntax of the command language.</Paragraph>
    <Paragraph position="6"> Suggestiveness. In my own research (Rosenberg, 1982) \[ have looked at how the meaning of a command name in ordinary English may or may not suggest its meaning in a text editor. This process of suggestiveness may be viewed as a mapping from the semantics of the ordinary word to the semantics of the system action, in which the user, given the name of command, attempts to predict what it does. This situation is encountered most often when first learning a system, and in the use of menus. A few simple experiments showed that if one obtains sets of features for the names and actions, a straightforward calculation of their similarity can predict people's guesses of what particular command names denote.</Paragraph>
    <Paragraph position="7"> Memorability. If we look at the converse mapping from actions to names, i.e., when, given a system action, ,me attempts to remember its name, we find a number of studies reporting similar results. Barnard et al. (19821 had subjects learn a ~et of either specific or general commands, and found that suhject~ learning the less distinctive, general names used a help menu of the commands and their definitions more el'ten, were less confident in recalling the names, and were less able to recall the actions of the commands. Black and Moran (1982) found that high-frequency (and thus more general) words were less well  remembered than low-frequency ones, and so were more &amp;quot;'discriminable&amp;quot; names Iones having a greater similarity to their eorrespondLng actions}. Seapin {1981l also found that general names like select and read were less well recalled than computeroriented ones like search and display. Both Black and Moran { 1982} and Landauer et al. ( i9831 found that users varied widely in the names they preferred to give to system actions, and that user-provided names tended to be more general and thus less memorable, Congruence and hierarchicalness. Carroll (1982) has demonstrated two important properties of command name semantics: congruence and hierarchicalness. Two names are congruent if their relations are the same as those of the actions onto which they are mapped Thus the inverse actions of adding and subtracting text are best named by a pair of inverses such as insert and delete. As might be expected, then, Carroll found that congruent names like raise-lower are easier to learn than noncongruent ones like reach-down.</Paragraph>
    <Paragraph position="8"> Hierarchicalness has to do with the compositionality of semantic components and their surface realization. System actions may have common semantic components along with additional, distinguishing, ones (e.g., moving vs. copying, deleting a character vs. deleting a word}. The degree of commonality may range from none (all actions are mutually disjoint} to total (all actions are vectors in some n-dimensional matrix). Furthermore, words or phrases naming such hierarchical actions may or may not have some of their semantic components realized on the surface: for example, while both advance and move forward may have the semantic t'eatures + MOVE and + FORWARD, only the latter has them realized on the surface. Thus, in hierarchical names the semantic components and their relationships are more readily perceived, thus enhancing their distinctiveness. Not surprisingly, Carroll has found that hierarchical names, such as move forward-move backward, are easier to learn than non-hierarchical synonyms such as advance-retreat. Similar results on the effect of hierarchical structuring are reported by Scapin ( 1982}.</Paragraph>
    <Paragraph position="9"> Names and the command language syntax. There are two obvious ways in which the choice of names for commands can interact with the syntax of the command language. The first involves selection restrictions associated with the name. For example, one usually deletes objects, but stops processes: thus one wouldn't normally expect a command named delete to take both files and process-identifiers as objects.</Paragraph>
    <Paragraph position="10"> The second kind of interaction involves the syntactic frames associated with a word. For example, the sentence frame for substitute {&amp;quot;substitute x for y&amp;quot;} requires that the new information be specified before the old, while the frame for replace (&amp;quot;replace y with x&amp;quot;) is just the opposite. A name whose syntactic frame is inconsistent with the command language syntax will thus cause errors. It should be noted that Barnard et al. {1981} have shown that total syntactic consistency can override this constraint and allow users to avoid confusion, but their results may be due to the fact that the set of two-argument commands they studied always had one argument in common, thus encouraging a consistent placement. Landauer et ol. (1983) found that using the same name for semantically similar but syntactically different commands created problems.</Paragraph>
    <Paragraph position="11"> Non-words as names. Some systems use non-words such as special characters or icons as commands, either partly or entirely. Hemenway (1982) has shown that the issues involved in contructing sets of command icons are much the same as with verbal names. There are two basic types of non-words: those with some semantics {e.g., '?' or pictorial icons} and those with little or none (e.g., control characters or abstract icons}. Non-words with some semantics behave much like words (so, for example, '?' is usually used as a name for a query command}. Meaningless non-words must have some surface property such as their shape mapped onto their actions. For example, an abstract line-drawing icon in a graphics program (a &amp;quot;brush&amp;quot;) might have its shape serve as an indicator of what kind of line it draws. Control characters are often mapped onto names for actions which begin with the same letter (e.g., CONTROL-F might mean &amp;quot;move the cursor Forward one character&amp;quot;}. Similar considerations hold for the use of non-words to denote objects.</Paragraph>
  </Section>
class="xml-element"></Paper>