Partager via

Grammar Design

  • Article
  Microsoft Speech Technologies Homepage

Grammars help transform a standard ASP.NET Web application into a speech-enabled ASP.NET Web application. Speech applications that are built using the Microsoft Speech Application SDK Version 1.1 (SASDK) combine a speech recognition engine with grammars to recognize user speech. Grammars are the key components that a developer requires to enable speech functionality in speech applications for the SASDK.

Grammars define all of the words or phrases that a user can say to an application. Without grammars, a speech recognition engine could not recognize user speech. In addition to defining the guidelines for user speech, grammars implement semantic interpretation to associate spoken words or phrases with meaningful application data.

Adding Speech Functionality to a Web Application

Add speech functionality to a regular ASP.NET Web application by binding grammars to the QA, Command, or Listen Microsoft ASP.NET Speech Controls in Speech Control Editor. Bind grammars to Speech Controls by attaching individual grammar files, or by typing inline grammar text.

Grammar Tools

Speech Grammar Editor, included in the SASDK, provides a graphical interface for creating and maintaining the rules that comprise grammar files. To help grammar authors create rule definitions, Speech Grammar Editor uses drag-and-drop graphical elements that map to recognition functionality.

Design Tips

  • Design separate grammars for each dialog turn. This improves recognition performance, simplifies semantic processing, and ensures correct handling of responses that might be correct at one point in the dialog, but not correct at the current point in the dialog.
  • Add semantic information only to words that represent data that is meaningful to the application. In an application presenting automobile models, the sentence "Please show me a two-door Coho," the phrase "two-door" and the word "Coho" may be meaningful. Assign semantic property names and values to them so scripts can extract them. Two-door may get a property name of "size" and a property value of "compact." Coho may get a property name of "make" and a property value of "Contoso." Do not add semantic information to preamble words or phrases like “Could I have” and “I'd like”.
  • Create grammars that account for all words or phrases a user might possibly speak to an application. If a user says Oh, I guess today I'd like a large ice cream, thank you and the grammars do not account for the wandering preamble Oh, I guess today I'd like a, the recognition engine will not recognize the user's speech. The grammars should also account for optional ending phrases like the thank you in this example. These insignificant words are sometimes called polite/garbage. In Speech Grammar Editor, all garbage utterances are actually words that are supported by the recognition engine as representing general speech. Use the Wildcard element to represent general speech only at semantically irrelevant parts of a rule.
  • Build modular rules containing polite/garbage words. Re-use these rules by referencing or including them in separate grammar files.
  • Create command words or phrases, like Help, Repeat, Cancel and Exit in a separate grammar. Use the Command control to enable users to issue these commands. Use the Scope property of the Command control to ensure that commands are available throughout the session by adding all or most of the QA controls to the Command control's scope. This allows the author to define a command grammar once and use it easily throughout the application.
  • Account for prompt echo. In normal speech a user may not actually say The city I want to fly to is Memphis. However, this is a common response in a question and answer dialog to the question "What city do you want to fly to?" This answer mimics, or echoes, the syntax of the prompt. Analyze application prompts and ensure that the grammars will recognize prompt echo.
  • Build a separate grammar to recognize corrections such as No, could I have soy milk please, I didn't want vanilla thanks, or I said iced coffee. This separate grammar should include alternative preamble phrases such as No, Could I have, I didn't want, or I said. Unlike normal preamble speech, corrections have some semantic meaning.
  • The SASDK installs with two compiled grammar files—cmnrules.cfg and dtmfrules.cfg. The cmnrules.cfg file contains common rule definitions for items such as times, dates, and numbers. The dtmfrules.cfg file contains common rule definitions for dual tone multi-frequency (DTMF) keypresses. Reference these preexisting rules instead of creating grammars that redefine them. If the SASDK is installed to the default location, these files can be found at this path: %SystemDrive%\Inetpub\wwwroot\aspnet_speech\%Version%\client_script\1033.

See Also

Designing Speech Applications | Creating Grammars | Enabling Speech Recognition