<?xml version="1.0" standalone="yes"?>
<Paper uid="H94-1037">
  <Title>PEGASUS: A Spoken Language Interface for On-Line Air Travel Planning I</Title>
  <Section position="3" start_page="201" end_page="202" type="metho">
    <SectionTitle>
SYSTEM DESCRIPTION
Overview
</SectionTitle>
    <Paragraph position="0"> Figure 1 shows a block diagram of PEGASUS. The speech understanding component makes use of much of the original ATIS system to process user queries \[5, 6\]. The segment-based SUMMIT speech recognition component \[7\] produces a list of the top ten sentence hypotheses, which are then filtered by the probabilistic TINA natural language component \[8\]. The particular version of TINA employs a robust parsing strategy \[9\] that attempts to piece together parsable fragments, which is often necessary for spontaneous speech containing disfluencies. A semantic frame representation is used to encode the meaning efficiently. The entire speech understanding system, with a working vocabulary of approximately 1300 words, performs in near real-timeusing a high-end workstation with no additional hardware. As for its performance, our ATIS system achieved the second lowest error rate for both text and speech input in the last two annual ARPA spoken language systems common evaluations measuring the systems' ability to extract relevant information from the database \[3, 4\]. In the most recent evaluation, our system achieved an error rate of 12.5% and 14.2% on all answerable queries, when the transcription and the speech signal were provided as input, respectively.</Paragraph>
    <Section position="1" start_page="201" end_page="202" type="sub_section">
      <SectionTitle>
Meaning Representation
</SectionTitle>
      <Paragraph position="0"> Through our previous experience in developing spoken language systems, we have learned that simplicity of form is an important principle in building effective meaning representations. Our view on the appropriate structural units of a semantic frame has evolved over time. Our present view is that all major constituents in a sentence can be classified as one of only three distinct categories, which we label as \[clause\], \[topic\], and \[predicate\]. Thus, verbs, adjectives, prepositions and modifier nouns are all considered to be predicates. Furthermore, grammatical constituents such as &amp;quot;subject&amp;quot; and &amp;quot;direct object&amp;quot; are not explicitly marked in the semantic frame. We have applied this new formalism successfully across several languages in our VOYAGER domain \[10\], and we are also using it in PEGASUS. An example semantic frame for the sentence, &amp;quot;Is there a United flight connecting in Denver,&amp;quot; is shown in Figure 2.</Paragraph>
    </Section>
    <Section position="2" start_page="202" end_page="202" type="sub_section">
      <SectionTitle>
System Manager
</SectionTitle>
      <Paragraph position="0"> During the design phase of our project, we made a commitment not to alter the interface and protocols of EAASY SABRE. We see no benefit, nor do we feel competent, in making changes to a proven system used by many users. In fact, PEGASUS's interface to EAASY SABRE is identical to that of a user on a PC or a travel agent EAASY SABRE cannot distinguish between a user speaking a natural utterance (such as &amp;quot;I want to go from Boston to San Francisco on October 21&amp;quot;) or typing to the system in cryptic codes (such as/schedule, B0S, SF0,210CT, 1).</Paragraph>
      <Paragraph position="1"> Thus the first task of the System Manager is to transform the semantic frame into the appropriate EAASY SABRE command. When necessary, the System Manager engages in a clarification dialogue with the user until enough information is available to construct a complete EAASY SABRE command, thus preempting EAASY SABRE's original menu-based clarification protocol.</Paragraph>
      <Paragraph position="2"> In response to a command, EAASY SABRE generally returns both formatted tables and additional options available by menu selection (such as &amp;quot;5: Show Seat Assignment&amp;quot; or &amp;quot;12: Show more flights&amp;quot;). The data stream (i.e., raw text) returned from EAASY SABRE must be parsed, filtered, and reformatted by the System Manager for display to the user. The tables and menu options extracted from the database are temporarily stored in a local cache.</Paragraph>
      <Paragraph position="3"> Menu options are selectively made available to the user, thus allowing the system, for example, to map a user's explicit request for seat assignment into the appropriate menu key. Tables can be postprocessed to apply constraints beyond those available through EAASY SABRE, such as &amp;quot;serving dinner, .... nonstop,&amp;quot; or &amp;quot;leaving in the afternoon.&amp;quot; In addition to providing the displays, the System Manager also provides a paraphrase of the relevant information. Some users have found this feature to be extremely beneficial to help detect the system's understanding errors. The user can also type natural language queries to PEGASUS, an appropriate action when speech recognition errors persist.</Paragraph>
    </Section>
  </Section>
  <Section position="4" start_page="202" end_page="203" type="metho">
    <SectionTitle>
DIALOGUE MANAGEMENT
</SectionTitle>
    <Paragraph position="0"> Before discussing the dialogue management aspects of PEGASUS, we thought it would be instructive to examine the log of an actual round-trip booking, shown in Figure 3. In this example, one of the authors used PEGASUS to make a reservation in order to attend a workshop in the San Francisco area. Like a travel agent, PEGASUS needs to know the source, destination, and date before it can provide the flight information. The user utilized additional constraints to narrow down the choices before settling on a particular flight. It took two exchanges to arrive at the appropriate fare, and three more to book the return flight. The entire booking took nine exchanges, and lasted approximately 5 minutes. Note that a large fraction of the time is spent waiting for EAASY SABRE to respond.</Paragraph>
    <Paragraph position="1"> The dialogue component of PEGASUS is significantly more complicated than that of the original ATIS system \[11\]. This is in large part due to the fact that it must monitor not only the user's dialogue state and the degree of completion of the booking, but also the state of the EAASY SABRE system. For instance, it must preprocess fare restrictions, warning the user of limits imposed on return dates for restricted fares, screening selected fares for possible constraint failure, and confirming availability on selected flights before attempting to issue bookings. Otherwise, the EAASY SABRE system would invoke a complex subdialogue which we wish to avoid.</Paragraph>
    <Paragraph position="2"> The system keeps a record of the most recently displayed sets of flights and fares, as well as a ticket frame where slots (e.g., fare class) are periodically updated upon user specification. This information is also displayed to the user as a ticket. The system must consult all of these sources of information in addition to the user's queries in deciding its next move.</Paragraph>
    <Paragraph position="3"> The dialogue is managed as a set of more than thirty distinct dialogue states. Any particular dialogue exchange consists of a response phase followed by an initiative phase. During the response phase, the system may have to consult the dialogue state to properly interpret the query. For instance, there are several different states that can provoke a &amp;quot;yes/no&amp;quot; response, and the system must also be prepared for the user not to comply, but instead to ask a completely independent question. While processing the user's query the system may need to update the dialogue state, and upon completing the response phase it consults the state to determine what if any initiative action is appropriate at this time.</Paragraph>
    <Paragraph position="4"> There are several meta-level commands that have led to a more usable system. A request for help can be issued at any time, and the response it invokes is dependent upon the current state of the dialogue. For instance, at the very beginning of a dialogue, a request for help causes the system to provide an organized list of the cities it knows. There are also two meta-level commands that erase previous information. A &amp;quot;scratch that&amp;quot; command causes the system to erase the preceding query from context, restoring the discourse content to its former state. In the event that this query involved a booking request, the system must also issue a cancellation request to EAASY SABRE. The &amp;quot;scratch that&amp;quot; capability is particularly valuable to recover from damaging recognition errors. A more drastic &amp;quot;clear history&amp;quot; command allows the user to start completely afresh. We feel that the availability of these erasure commands allows the system to be more aggressive in taking action, without having to repeatedly ask for confirmation of user requests.</Paragraph>
    <Paragraph position="5">  logue using PEGASUS. Due to space limitations, irrelevant parts of the system's responses have been omitted. U--user, P----PEGASUS.</Paragraph>
  </Section>
class="xml-element"></Paper>