GotSpeech.Net Podcast Show #4 Pizza Tutorial: Grammars
The show:
Some other stats: Visits: 10,642; Pageviews: 61,660; Posts: 1330
"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."
Enabling Speech Recognition with Grammars - Front page with links much of the grammar content on MSDN.
Speech Grammar Editor - GUI Tool for creating grammars.
Speech Application SDK Tutorial
Creating Grammars
Creating Grammar Files - How to create a new grammar file, working with files and rules.
Speech Recognition Grammar Specification (SRGS) Version 1.0 (W3C)
Grammar Overview Speech Grammars
Grammar Design Tips
Semantic Interpretation (We will talk about this on a later podcast)
*Note I incorrectly state that Semantic Markup Language (defined SML) can be found on the W3C site. I think this is a Microsoft standard and is actually found here on MSDN.
Here are some helpful design tips for creating grammars from MSDN:
- 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.
Best Practices in Designing Speech User Interfaces.
Creating .Net Applications That Talk (Sample chapter of Sara Morgan Rea's book: Building Intelligent .NET Applications: Agents, Data Mining, Rule-Based Systems, and Speech Processing)
One tip she gives is to compile your grammars to increase the performance of your application using the grammar compiler (SrGSGc.exe) to compile your grammars into .cfg files. The latest Microsoft Speech Newsletter gives a tip for this as well.
How to Build Grammars for Speech-enabled Applications - Find out how to build grammars by walking through the process of building a grammar for an order status retrieval system that lets callers retrieve orders by voice. Has a section on building dynamic grammars.
Use Dynamic Grammars when Content is Unkown or Changes Often - One of Sara Morgan Rea's top ten tips for Designing Telephony Applications.
Debugging Dynamic Grammars
GotSpeech.Net Dynamic Grammar Visual Studio Solution
Be careful when creating dynamic grammars that have query string parameters - the SALT interpreter won't let you modify the DOM.
Get the podcast
[iTunes] Subscribe to the Podcast directly in iTunes (MP3).
[RSS] Add the GotSpeech.Net Podcast feed to your RSS aggregator and have the show delivered automatically (MP3).
[MP3] Download the show (MP3).
Format:
24:03, 22.0 MB, MP3
LISTEN (MP3)
Technorati Tags: Microsoft Speech Server