<?xml version="1.0" standalone="yes"?>
<Paper uid="P81-1033">
  <Title>A Construction-Specific Approach to Focused Interaction in Flexible Parsing</Title>
  <Section position="2" start_page="0" end_page="0" type="intro">
    <SectionTitle>
1. Introduction
</SectionTitle>
    <Paragraph position="0"> There has been considerable interest recently in the topic of flexible parsing, i.e. the parsing of input that deviates to a greater or lesser extent from the grammar expected by the parsing system. This iriterest springs from very practical concerns with the increamng use of natural language in computer interfaces. When people attempt to use such interfaces, they cannot be expected always to conform strictly to the interfece's grammar, no matter how loose and accomodating that grammar may be.</Paragraph>
    <Paragraph position="1"> Whenever people spontaneously use a language, whether natural or artificial, it is inevitable that they will make errors of performance.</Paragraph>
    <Paragraph position="2"> Accordingly, we \[3\] and other researchers including Weischedel and Black \[6\], and Kwasny and Sondheimer \[5\], have constructed flexible parsers which accept ungrammatical input, correcting the errors whenever possible, generating several alternative interpretations if more than one correction is plausible, and in cases where the input cannot be massaged into lull grammaticality, producing as complete a partial parse as possible.</Paragraph>
    <Paragraph position="3"> If a flexible parser being used as part of an interactive system cannot correct ungrammatical input with total, certainty, then the system user must be involved in the resolution of the difficulty or the confirmation of the parser's Correction. The approach taken by Weischedel and Black \[6\] in such situations is to inform the user about the nature of the difficulty, in the expectation that he will be able to use this information to produce a more acceptable input next time, but this can involve the user in substantial retyping. A related technique, adopted by the COOP system \[4\], is to paraphrase back tO the user the one or more parses that the system has produced from the user!s input, and to allow the user to confirm the parse or select one of the ambiguous alternatives, This approach still means a certain amount of work for the user. He must check the paraphrase to see if the system has interpreted what he said correctly and without omission, and in the case of ambiguity, he must compare the several paraphrases to see which most ClOsely corresponds  eJther exl~'e~eC/l or =mDlieO. ol the Air Force Ollice of ScicmlifiC/ Researcll or the US Government to what he meant, a non-trivial task if the input is lengthy and the differences small.</Paragraph>
    <Paragraph position="4"> Experience with our own flexible parser suggests that the way requests for clarification in such situations are phrased makes a big difference to the ease and accuracy with which the user can correct his errors, and that the user is most helped by a request which focuses as tightly as possible on the exact source and nature of the difficulty.</Paragraph>
    <Paragraph position="5"> Accordingly, we have adopted the following simple principle for the new flexible parser we are presently constructing: when the parser cannot uniquely resolve a problem in its input, it should as/( the user for a correction in as direct and focused a manner as l~ossible.</Paragraph>
    <Paragraph position="6"> Furthermore, this request for clarification should not prejudice the processing of the rest of the input, either before or after the problem occurs, in other words, if the system cannot parse one segment of the input, it should be able to bypass it, parse the remainder, and then ask the user to restate that and only that segment of the input. Or again, if a small part of the input' is missing or garbled and there are a limited number of possibilities for what ought to be there, the parser should be able to indicate the list of possibilities together with the context from which the information is missing rather than making the user compare several complete paraphrases of the input that differ only slightly.</Paragraph>
    <Paragraph position="7"> In what follows, we examine some of the implications of these ideas.</Paragraph>
    <Paragraph position="8"> We restrict our attention to cases in which a flexible parser can correct an input error or ungrammaticaUty, but only to within a constrained set of alternatives. We consider how to produce a focused ambiguity resolution request for the user to distinguish between such a set of corrections. We conclude that: * the problem must be tackled on a construction.specific basis, * and special representations must be devised for all the structural ambiguities that each construction type can give rise to.</Paragraph>
    <Paragraph position="9"> We illustrate these arguments with examples involving case constructions. There are additional independent reasons for adopting a construction,specific approach to flexible parsing, including increased efficiency and accuracy in correcting ungrammaticality, increased efficiency in parsing grammatical input, and ease of task.specific language definition. The first two of these are discussed in \[2\], and this paper gives details of the third.</Paragraph>
  </Section>
class="xml-element"></Paper>