VoiceXML 2.1 Development Guide

Home | Frameset Home

Subgrammars

| TOC

SubDialogs

Tutorial: GSL Grammar Weighting

This tutorial is based on the things you accomplished in earlier Lessons. If you have not completed those tutorials, you'll need to go through them first.

In this Lesson, we will:

learn the syntax to incorporate probability into our GSL grammar files
extend hello world so that the different values the GSL grammar file could match are weighted
include event handling for 'missed' and non-matching user utterances within a voice recognition field
upload the new app and try it out

Step 1: creating our initial VoiceXML structure

From our previous tutorials, we now recognize the following structure as a normal starting point:


<?xml version="1.0" encoding="UTF-8"?>
<vxml version = "2.1">
  <meta name="maintainer" content="yourEmail@here.com"/>

</vxml>

Step 2: writing the prompts

The <form> and <field> tags should also be familiar by now. The grammar file will be called "dogs.grammar" and within that file, we reference a specific top-level grammar called "DOGS".


<?xml version="1.0" encoding="UTF-8"?>
<vxml version = "2.1">
 <meta name="maintainer" content="yourEmail@here.com"/>

  <form id="dogs">
    <field name="dogbreed">

      <grammar src="dogs.grammar#DOGS" type="text/gsl"/>
      <prompt>
        What breed of dog do you have?
      </prompt>

      <noinput>
         <prompt>
          I did not hear you. Please try again. 
        </prompt>
       <reprompt/>
      </noinput>

      <nomatch>
       <prompt>
         I did not understand. Please try again. 
       </prompt>
       <reprompt/>
      </nomatch>

    </field>
    <filled>
      <prompt>
        You said 
        <value expr="dogbreed" />
      </prompt>
    </filled>
  </form>
</vxml>

Now our document is ready for the grammar file.

Step 3: creating our grammar file

A grammar file is a separate file from our VoiceXML document, so open up a new window in your favorite text editor. First, write the top-level grammar that returns a value to the field "dogbreed" in the VoiceXML document. Again, we covered the concept of top -level and sub-level grammar rules in our last tutorial.


DOGS [
  BREEDS:d {<dogbreed $d>}
]

Now we fill in the utterances for our sub-level rule, "BREEDS". You should be familiar with this concept from our previous tutorial, but just to refresh your memory a bit, we will cover the basics of GSL syntax. Square brackets enclosing a possible utterance indicates an "or" condition - if the grammar matches one of the values within the brackets, it will execute the return statement. Parentheses indicate an "and" condition - the grammar must match every word inside the parentheses to return a match. A question mark indicates an utterance value is entirely optional.

For example:

[ toy poodle ] - the grammar will match either "poodle" or "toy."

( toy poodle ) - the grammar will only match "toy poodle."

( ?toy poodle ) - the grammar must match "poodle," but could match either "poodle" or "toy poodle."

So "( ?[ bearded border ] collie )" will match "collie," "bearded collie," and "border collie."


BREEDS [
  [ none ( no breed ) mutt ]      {return("none")}
  ( basset hound )      {return("basset hound")}
  beagle      {return("beagle")}
  boxer      {return("boxer")}
  ( ?french bulldog )      {return("bulldog")}
  chihuahua      {return("chihuahua")}
  ( ?[ bearded border ] collie )      {return("collie")}
  dachshund      {return("dachshund")}
  dalmatian      {return("dalmatian")}
  ( german shepherd )      {return("german shepherd")}
  greyhound      {return("greyhound")}
  pekingese      {return("pekingese")}
  ( ?toy poodle )      {return("poodle")}
  ( ?[   
      ( chesapeake bay ) 
      ( [ curly flat ] coated ) 
      golden 
      labrador 
  ] retriever )      {return("retriever")}
  ( saint bernard )      {return("saint bernard")}
  ( ?chinese ( shar pei ) )      {return("shar pei")}
  ( ?[   
      belgian 
      [ ?old english ] 
      shetland 
  ] sheepdog )      {return("sheepdog")}
  ( ?siberian husky )      {return("husky")}
  ( ?[   
      ( [ american irish ] water ) 
      ( ?english [ cocker springer toy ] ) 
      field 
      sussex 
  ] spaniel )      {return("spaniel")}
  ( ?[   
      border 
      boston 
      bull 
      cairn 
      ( jack russell )
      lakeland 
      ( ?toy manchester ) 
      scottish 
      skye 
      welsh 
      yorkshire ] 
      terrier )      {return("terrier")}
  ( ?welsh corgi )      {return("corgi")}
]

Now, we have a subgrammar that recognizes a variety of dog breeds and returns the name of the breed. Go ahead and save our file as "dogs.grammar".

Step 4: incorporating probability into our grammar file

So our grammar file can recognize everything from "chihuahua" to "jack russell terrier," but some of those breeds are much more common than others. Since we know that a caller is more likely to claim a mutt than a shar pei, how do we reflect that in the grammar file?

In the Nuance Grammar Specification Language (GSL), you indicate probability with a tilde '~' immediately after the value. For example, collies are quite popular dogs, while dachshunds simply don't get the recognition they deserve. Let's set the percentage for collies at 90%, and estimate dachshunds at 25%. So we can write:


  ( ?[ bearded border ] collie )~.9      {return("collie")}
  dachshund~.25      {return("dachshund")}

Pretty simple, yes? We will put this concept to use by assigning some grammar probabilities based on absolutley nothing concrete. In a 'real world' application, such grammar tuning would take place after arduous user testing and grammar confidence score logging, but for the purposes of illustration, we are simply going to assign some values based on the commonality of doggy breeds.

Step 5: putting it all together

Our script is now complete. The VoiceXML document appears above, and the grammar file, with probabilities (somewhat randomly), assigned, should somehting look like this:


BREEDS [
  [ none ( no breed ) mutt ]~1.0      {return("none")}
  ( basset hound )~.4      {return("basset hound")}
  beagle~.35      {return("beagle")}
  boxer~.7      {return("boxer")}
  ( ?french bulldog )~.55      {return("bulldog")}
  chihuahua~.1      {return("chihuahua")}
  ( ?[ bearded border ] collie )~.9      {return("collie")}
  dachshund~.25      {return("dachshund")}
  dalmatian~.15      {return("dalmatian")}
  ( german shepherd )~.85      {return("german shepherd")}
  greyhound      {return("greyhound")}
  pekingese~.2      {return("pekingese")}
  ( ?toy poodle )~.6      {return("poodle")}
  ( ?[   
      ( chesapeake bay ) 
      ( [ curly flat ] coated ) 
      golden 
      labrador 
  ] retriever )~.8      {return("retriever")}
  ( saint bernard )~.5      {return("saint bernard")}
  ( ?chinese ( shar pei ) )~.05      {return("shar pei")}
  ( ?[   
      belgian 
      [ ?old english ] 
      shetland 
  ] sheepdog )~.65      {return("sheepdog")}
  ( ?siberian husky )~.3      {return("husky")}
  ( ?[   
      ( [ american irish ] water ) 
      ( ?english [ cocker springer toy ] ) 
      field 
      sussex 
  ] spaniel )~.75      {return("spaniel")}
  ( ?[   
      border 
      boston 
      bull 
      cairn 
      ( jack russell )
      lakeland 
      ( ?toy manchester ) 
      scottish 
      skye 
      welsh 
      yorkshire ] 
  terrier )~.95      {return("terrier")}
  ( ?welsh corgi )~.45      {return("corgi")}
]

Step 6: upload, and try it out

All that remains now is to upload your new VoiceXML application. We might save these files as http://myserver.com/dogs.xml and http://myserver.com/dogs.grammar, or you can just as easily use the Voxeo File Manager to upload the application and grammar files to your Voxeo filespace.

Now you can provision a number to our simple voice recognition application and call the associated number to hear the results.

Download the Code!

Source code

What we covered:

learned how write grammar files that specify confidence scores
revisitied GSL grammar and subgrammar syntax
uploaded a new hello world application

ANNOTATIONS: EXISTING POSTS

darrenj

2/8/2006 6:00 PM (EST)

The prompt tag within the noinput tag is not properly closed and thus doesn't work.

MattHenry

2/8/2006 6:04 PM (EST)

Sorry about that typo, darren...hope it didnt cause too much frustration. I'll have this fixed for you in a jiffy.

~Matt

jorgemcpaulo

4/12/2006 12:34 PM (EDT)

I expected the sum of probabilities of all grammar items to be exactly 100% :|

MattHenry

4/12/2006 2:35 PM (EDT)

Hello Jorge,

I am not at all certain what it is that you are asking....did you require assistance with this at all?

~Matthew Henry

West02

1/22/2007 1:43 PM (EST)

Hello,

I do not understand why the sum of all the probabilities listed in the example are not equal to 100% ?

(In other words I do not understand how to assign probabilities and how they will be interpreted when the sum of all the probabilities is greater than 100%)

Thank you.

MattHenry

1/22/2007 3:29 PM (EST)

Hi there,

I think that the nomenclature might be throwing you off here. Note that the specified values are multiplication factors that influence the likelihood of a phrase, which in turn causes the reco engine to favor certain phrases over others. From the Nuance Grammar Guide, take these two sample utterances:

[one fifteen]
[one fifty]

Assuming that this is an excerpt from time grammar, we can reasonably expect that the former might have a higher probability for user utterance, (as it is a quarter-hour interval), we would likely assign a higher score for "one fifteen", as it will be more common.

Hope this helps,

~Matthew henry

davidt

2/17/2007 12:37 AM (EST)

When I download and run the Motorola source code on your hosted system (not Prophecy), I get "Sorry, that constant has an internal error." The following appears in the log:

...VoiceException: error.noresource MRCP Recognition Error Dialog stack trace: State (Dialog) URL (Document) -------------- ------------------------------ dogs http://webhosting.voxeo.net/18395/www/south.xml?voxeoVxmlSpeakErrors=true&...

If I remove all the probabilities from the grammar, the example runs fine (but without the weights, of course.)

Also, I'm curious: Is it OK to assign weights to only some terms and not others? Is there a default weight (like ~0.5)?

VoxeoTony

2/17/2007 12:35 PM (EST)

Hello,

Thanks for writing in. It is ok to assign weights only to some terms. If you do not assign weights the grammar will give the same probability to each match.

The MRCP error you received is normally due to the browser recognizing an error in the grammar structure. An error in of this nature would require some trouble shooting outside of the scope of this forum post. If you would like to have this investigated further please post a ticket from your account.

Tony~

sabushadi

2/25/2007 12:15 PM (EST)

On 2/17/2007 at 12:37 AM (EST) davidt asked:

Is it OK to assign weights to only some terms and not others? Is there a default weight (like ~0.5)?

On 2/17/2007 at 12:35 PM (EST) VoxeoTony answered:

It is ok to assign weights only to some terms. If you do not assign weights the grammar will give the same probability to each match.

But I don't think that answers davidt's question.

How does the following behave?

( ?[ bearded border ] collie )~.9 {return("collie")}
dachshund {return("dachshund")}

Notice that dachshund has NO weight while collie has a high weight.

I believe davidt was asking: does dachshund get a default weight of ~0.5 and, if not, how is it handled relative to collie? is it also a weight of ~0.9 as one possible interpretation of what VoxeoTony suggests: If you do not assign weights the grammar will give the same probability to each match.

And if it is as VoxeoTony suggests, then what about this case:

( ?[ bearded border ] collie )~.9 {return("collie")}
dachshund {return("dachshund")}
myhund~.2 {return("myhund")}

where there are more than one "other weights" assigned ... again, what weight is dachshund given in this case? is it higher than ~.2 and lower than ~.9 or something else? is it an average ... like a middle ground? is it 1.0 by default? is it .5 by default?

i think that's what davidt was asking.

if not, then it's what i'm asking :)

thanks!

MattHenry

2/27/2007 7:31 PM (EST)

Hi there,

As we have several significant questions to address here, I'm going to reprint them, and answer each one independently:

Q: "Is it OK to assign weights to only some terms and not others? Is there a default weight (like ~0.5)?"
[b]A: Technically, not really your question per-se, but one I'd like to answer anyhow. If we have a grammar construct like this...[/b]

[color=blue]
MYRULE [
(foo)~.1 {return("1")}
(bar)~.2 {return("2")}
(foobar) {return("2")}
]
[/color]

[b]...then the "implied" weight the "bar" utterance will be set to is "1.0". Any utterance that doesn't have a weight assigned explicitly will be given this default weight value.[/b]

Q: "How does the following behave?"
[color=blue]
( ?[ bearded border ] collie )~.9 {return("collie")}
dachshund {return("dachshund")}
[/color]

[b]A: Well, we are kind of talking apples and oranges here, as the utterances are both pretty unique. Realistically speaking, this is kind of a bad example from our docs, and I'll again refer to my analogy posted previously where "one-fifteen" was compared against "one-fifty": Grammar weighting should only be used as a tool to disambiguate like-sounding utterances, and help the recognizer pick the most likely utterance.

Now, to directly answer your "what happens" question, the answer is that both utterances should be able to be recognized without any problem, or misrecognition. This doesn't mean that even if a caller says "dachshund" that there is only a 10% chance of the system recognizing it, nor is there any chance of the bearded border collie, (a majestic animal), utternace overshadowing valid reco in this scenario.[/b]

Q: "then what about this case?"

[color=blue]
( ?[ bearded border ] collie )~.9 {return("collie")}
dachshund {return("dachshund")}
myhund~.2 {return("myhund")}
[/color]

[b]A: I know, kind of redundant based on my last answer. All the same, never let it be said that we shirk our duties when asked a techincal question.

=^)

Lets instead consider this grammar so that we can make a point:[/b]

[color=blue]
MYRULE [
(foo)~.1 {return("1")}
(foo)~ 1.9 {return("2")}
(foo) {return("3")}
]
[/color]

[b]Considering this admittedly contrived grammar fragment, the chances of us receiving a "1" interpretatioin value is slim-to-none: The fact that the second entry has a significantly higher weight means that we are much, much more likely to receive a "2", or maybe even a "3" value instead.[/b]

I hope that this helps to better explain grammar weighting to your satisfaction, but if you have any additional questions, I'm glad to help out.

~Matthew henry

hemanthvasa

8/8/2007 6:57 AM (EDT)

Hi all,
i worte a grammar to recognize numbers ranging from 1 to 999999999. when i run the my application i am getting the below error.

[08/08/07 03:15:42] ERROR "Grammar compilation error: parse error 'multiple expressions defined (should some be subgrammars?)' at offset 2152: '[\u000d\u000a [(Millions:m Thousands:t)] {return (add($m $t))}'\u000a" at <field> tag (line 62, column 4 in file

can you please help me on this. my grammar file is as below
--------------------------------------------------------------------

;; file_name : fractional_shares.gsl
;;

[
; voice options
[(IntegralPart:ip ?shares)] {<option $ip>}
]
IntegralPart[
[TensAndDigits:td] {return ($td)}
[HundredsAll:ha] {return ($ha)}
[ThousandsAll:ta] {return ($ta)}
[MillionTensAndDigits:mtd] {return ($mtd)}
[MillionsHundreds:mh] {return ($mh)}
[MillionsThousands:mt] {return ($mt)}
]
TensAndDigits[
[(OneToNine:on)] {return ($on)}
[(TenToNineteen:tn)] {return ($tn)}
[(Tens:t)] {return ($t)}
[(Tens:t OneToNine:on)] {return (add($t $on))}
]
HundredsAll[
[(Hundreds:h)] {return ($h)}
[(Hundreds:h ?and OneToNine:on)] {return (add($h $on))}
[(Hundreds:h ?and Tens:t)] {return (add($h $t))}
[(Hundreds:h ?and Tens:t OneToNine:on)] {return (add($h add($t $on)))}
]
ThousandsAll[
[(Thousands:ts)] {return ($ts)}
[(Thousands:ts OneToNine:on)] {return (add($ts $on))}
[(Thousands:ts Tens:t)] {return (add($ts $t))}
[(Thousands:ts Hundreds:h)] {return (add($ts $h))}
[(Thousands:ts Tens:t OneToNine:on)] {return (add($ts add($t $on)))}
[(Thousands:ts Hundreds:h Tens:t)] {return (add($ts add($h $t)))}
[(Thousands:ts Hundreds:h OneToNine:on)] {return (add($ts add($h $on)))}
[(Thousands:ts Hundreds:h Tens:t OneToNine:on)] {return (add($ts add($h add($t $on))))}
]
MillionTensAndDigits[
[(Millions:m)] {return ($m)}
[(Millions:m OneToNine:on)] {return (add($m $on))}
[(Millions:m Tens:t)] {return (add($m $t))}
[(Millions:m Tens:t OneToNine:on)] {return (add($m add($t $on)))}
]
MillionsHundreds[
[(Millions:m Hundreds:h)] {return (add($m $h))}
[(Millions:m Hundreds:h Tens:t)] {return (add($m add($h $t)))}
[(Millions:m Hundreds:h OneToNine:on)] {return (add($m add($h $on)))}
[(Millions:m Hundreds:h Tens:t OneToNine:on)] {return (add($m add($h add($t $on))))}
]
MillionsThousands[
[(Millions:m Thousands:t)] {return (add($m $t))}
[(Millions:m Thousands:t OneToNine:on)] {return (add($m (add($t $on))))}
[(Millions:m Thousands:ts Tens:t)] {return (add($m (add($ts $t))))}
[(Millions:m Thousands:ts Hundreds:h )] {return (add($m add($ts $h)))}
[(Millions:m Thousands:ts Tens:t OneToNine:on)] {return (add($m add($ts add($t $on))))}
[(Millions:m Thousands:ts Hundreds:h Tens:t OneToNine:on)] {return (add($m add($ts add($h add($t $on)))))}
]
Millions[
[(OneToNine:onm million)] {return(mul($onm 1000000))}
[(TenToNineteen:tnm million)] {return(mul($tnm 1000000))}
[(Tens:tm million)] {return(mul($tm 1000000))}
[(Tens:tm OneToNine:onm million)] {return(mul(add($tm $onm) 1000000))}
[(Hundreds:hm Tens:tm OneToNine:onm million)] {return(mul(add($hm add($tm $onm)) 1000000))}
]
Thousands [
[(thousand)] {return(1000)}
[(OneToNine:ont thousand)] {return(mul($ont 1000))}
[(TenToNineteen:tnt thousand)] {return(mul($tnt 1000))}
[(Tens:tt thousand)] {return(mul($tt 1000))}
[(Hundreds:ht Tens:tt thousand)] {return(mul(add($ht $tt) 1000))}
[(Hundreds:ht thousand)] {return(mul($ht 1000))}
[(Tens:tt OneToNine:ont thousand)] {return(mul(add($tt $ont) 1000))}
[(Hundreds:ht Tens:tt OneToNine:ont thousand)] {return(mul(add($ht add($tt $ont)) 1000))}
]
Hundreds [
[(hundred)] {return(100)}
[(OneToNine:onh hundred)] {return(mul($onh 100))}
[(TenToNineteen:tnh hundred)] {return(mul($tnh 100))}
]
Tens [
twenty {return(20)}
thirty {return(30)}
forty {return(40)}
fifty {return(50)}
sixty {return(60)}
seventy {return(70)}
eighty {return(80)}
ninety {return(90)}
]
TenToNineteen [
[ten ( ten )] {return(10)}
[( eleven ) eleven ] {return(11)}
[ ( twelve ) twelve ] {return(12)}
[ ( thirteen ) thirteen ] {return(13)}
[ ( fourteen ) fourteen ] {return(14)}
[ ( fifteen ) fifteen ] {return(15)}
[ ( sixteen ) sixteen ] {return(16)}
[ ( seventeen ) seventeen ] {return(17)}
[ ( eighteen ) eighteen ] {return(18)}
[ ( nineteen ) nineteen ] {return(19)}
]
OneToNine [
[one (oh one) oh_one] {return(1)}
[two (oh two) oh_two] {return(2)}
[three (oh three) oh_three] {return(3)}
[four (oh four) oh_four] {return(4)}
[five (oh five) oh_five] {return(5)}
[six (oh six) oh_six] {return(6)}
[seven (oh seven) oh_seven] {return(7)}
[eight (oh eight) oh_eight] {return(8)}
[nine (oh nine) oh_nine] {return(9)}
]

MattHenry

8/8/2007 8:11 PM (EDT)

Hi there,

Not sure if you are aware of this or not, but we already have a grammar pre-written that you can use as a basis for this project that would likely save you quite a bit of time. Check the below link:

http://evolution.voxeo.com/library/grammar/library.jsp

I'd think that what you really would want would be the 'numbers2sixteen.grammar' file, but you may also want to take a gander at the "bigMoney.grammar" file to use as your base. However, if you are committing to using the grammar structure that you have outlined below, we can help with some suggestions:

* Strip out all utterances in each rule except one; this makes for a more manageable test case

* Starting from the bottom and working your way up, test each rule seperately, by commenting out the ones above it. When you finally do encounter an error, you will then know where the probelmatic rule is at, and you can then compare it to the structure that is defined in the grammars referenced above

* For what it is worth, I find it much easier to leverage the existing logic in the aformentioned grammars as my starting point for writing GSL subgrammars rather thaqn starting completely from scratch. No sense in reinventing the wheel, you know?

Let me know if this doesn't help you out,

~Matthew Henry

Subgrammars

| TOC

SubDialogs