Abstract

The W3C Voice Browser working group aims to develop specifications to enable access to the Web using spoken interaction. This document is part of a set of requirements studies for voice browsers, and provides details of the requirements for natural language processing.

Status of this document

This document describes the requirements for natural language processing for voice browsers, as a precursor to starting work on specifications. Related requirement drafts are linked from the introduction. The requirements are being released as working drafts but are not intended to become proposed recommendations.

This specification is a Working Draft of the Voice Browser working group for review by W3C members and other interested parties. This is the first public version of this document. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress".

Publication as a Working Draft does not imply endorsement by the W3C membership, nor of members of the Voice Browser working groups. This is still a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite W3C Working Drafts as other than "work in progress."

This document has been produced as part of the W3C Voice Browser Activity, following the procedures set out for the W3C Process. The authors of this document are members of the Voice Browser Working Group. This document is for public review. Comments should be sent to the public mailing list <[email protected]> (archive) by 14th January 2000.

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.

Introduction

The main goal of this subgroup is to establish a prioritized list of requirements for   natural language processing in a voice browser environment.

The process will consist of the following steps:

1. Collect requirements on natural language processing.
2. Prioritize these requirements.
3. Distribute requirements to, and take feedback from, relevant groups working on natural language in spoken dialog systems.
4. Define specifications for natural language processing components, based on the feedback received.

0.1 Scope

This document specifies requirements that define the capabilities of any component of a voice browser system which performs natural language interpretation, that is, the task of determining and representing the content of a natural language input from a user. Interpretation components include both stand-alone natural language understanding (NLU) components which receive text string results from a speech recognizer or keyboard as well as speech recognizers that incorporate natural language understanding functionality by returning  interpretations rather than, or in addition to, text strings.

0.2 Interaction with Other Groups

The activities of the Natural Language  Requirements Subgroup will be coordinated with the activities of the Grammar Representation Subgroup, the Synthesis Markup Subgroup, and the Dialog Subgroup.

  General Requirements

The NLU system should be able to:

1. Return a message stating that it cannot interpret an input at all. (must specify)
2. Return multiple pieces of information from multi-functional utterances (must specify)
3. Return partial information if it is unable to completely process an input. (must specify)
4. If partial information is returned, indicate how much of the input was left unanalyzed. (nice to specify)
5. Be extensible in the sense that it should be possible to add new types of utterances to the NLU specification. Specifically, the system should be able to incorporate modular subdialogs. (must specify)
6. Return a score reflecting its confidence in the overall interpretation. The exact format of confidence scores remains to be determined. It could be a rough scale or it could be probabilities, for example. (should specify)
7. Return a score for each attribute, reflecting its confidence in the interpretation of that attribute. (should specify)
8. Return multiple analyses (n-best) (nice to specify)

Input Requirements

A standalone (i.e., not integrated with a speech recognizer) NLU system should be able to:

1. Accept N-best ASR output with or without acoustic scores for either the whole utterance, each word in an utterance or both. (must specify)
2. Accept ASR output with out of vocabulary markers.(should specify)
3. Accept an ASCII text representation of an utterance (should specify)
4. Accept a word lattice as input.(must specify)
5. Accept prosodic notations on the ASR output. (nice to specify)

Any NLU system should be able to:

1. Dynamically switch to a different task model (must specify)
2. Dynamically modify the task model; e.g. add or remove possible choices from a slot (must specify)
3. Accept sequential multi-modal input (must specify)
4. Accept uncoordinated simultaneous multi-modal input (should specify)
5. Accept coordinated simultaneous multi-modal input. For example, the  NLU system should be able to represent or interpret a representation of  the context  so that anaphoric expressions in the user's utterances which refer to items in the context can be interpreted. The context can include the speech context, including the system's utterances, as well as the external context (e.g. I'll take one of these (click)). (nice to specify)
6. Return ASR timing information to the dialog controller (nice to specify).
7. Accept multi-modal time-stamped information (should specify)

Task-specific information

These requirements are intended to insure that the natural language component is capable of representing results of processing task-specific utterances.

An NLU system should be able to:

Represent task information:

1. Represent values for slots in a task model: I want five lines. (must specify)
2. Support hierarchical attributes in task model:  e.g. a slot can itself be a frame. (must specify)
3. Represent interpretations of sentences with anaphora and ellipsis. I want two hamburgers, one with ketchup and one without. (must specify)
4. Represent deictic utterances, which require reference to the non-linguistic context for their interpretation. I want this. (must specify).

Represent meta-task information (all nice to specify)

1. Represent a request for a definition: What does 'access code' mean?
2. Represent a request for the status of a filled slot: How many lines did I ask for?
3. Represent information about a slot: How many lines am I allowed to ask for?
4. Represent a request for the possible fillers of a slot: What are my choices? Can I schedule a call on Sunday?
5. Represent a request for the status of all slots. What have I ordered so far?
6. Represent questions about possible, desirable, necessary and conditional situations. Can you pay my electric bill? Should I order the chicken? Do I have to get a drink with the special? If I stay over Saturday night will I get a lower fare?
7. Represent requests for explanation of a system response. Why?
8. Represent request for the amount of task remaining. What else do you need to know? Am I almost finished?

Generic Information about the Communication Process

An NLU system should be able to represent meta-dialog information having to do with the communication process.(all nice to specify except as noted)

1. Represent utterances about the dialog: I want to revisit my previous answer. That's what I just said.
2. Represent a request for help.(must specify)
3. Represent a request to have the last prompt repeated
4. Represent requests to make the output louder, quieter, faster, slower, change languages.
5. Represent requests to pause the dialog.
6. Represent utterances indicating that the user:
   • Didn't hear the prompt (must have)
   • Didn't understand the prompt (must have)
   • Refuses to supply the answer to a prompt.
   • Doesn't know the answer to the prompt

Dialog Control

The NLU system should be able to represent: (all must specify except as noted)

1. A confirmation
2. A request to change the value of a slot due to a speech recognition error, a user error, or the user changing his/her mind. I meant p.m.
3. A request to empty a slot that's already been filled. (forget X)
4. A request to stop or end the dialog
5. A request to start over.
6. A request to transfer to an operator.
7. A request to suspend and resume a dialog
8. An explicit request to switch to another task.
9. An implicit request to switch to another task. (nice to specify).

Appendix: Sample Dialog with examples of a possible approach to NLU representation.

This is an example of a banking application with the user's utterances annotated with an example of a possible NLU representation, based on the following task model.

Task Model/Frame:

      Identification:
            Name:
            Address:
                Street:
            City:
            Zip Code:
                Phone:

      Action:
            Transfer:
            Source_account:
            Destination_account:
            Amount:
        Value:
                Currency:
      Balance:
            Account:

Acknowledgments

Subgroup Members

Mike Brown, Lucent
Carolina Di Cristo, Telecom Italia
Deborah Dahl, Unisys
Linda Dorrian, Productivity Works
Robert Keiller, Canon
Bill Ledingham, SpeechWorks
Stephen Potter, Entropic
Dave Raggett, HP and W3C
Ramesh Sarukkai, Lernout and Hauspie
Volker Steinbliss, Philips