[RavenclawDev 228] Re: swapping grammars for the ASR

[Svetlana Stenchikova]

Th INPUT_LINE_CONFIGURATION directive sends set_config message now (at
least in my version of the DM)

To send the complete agenda to the sphinx server, add to config file:

broadcast_state = sphinx.set_dialog_state

and implement set_dialog_state in the sphinx server

-Svetlana


On 2/27/07, Svetlana Stenchikova <svetastenchikova at gmail.com> wrote:
> Dan and Antoine,
>
> Thank you for your answer and suggestions.
>
>
> Could you please elaborate a little more on the two methods that I could use
> if I want to build grammar dynamically from the expectation agenda:
>
> Method 1: using GetInputLineConfiguration()
>
> When does the AudioServer receive this message?
>
> I am just trying to trace what happens when GetInputLineConfiguration():
>
> CDMCoreAgent::updateInputLineConfiguration()  calls
> etInputLineConfiguration() and logs
>
> Log(DMCORE_STREAM, "Input line configuration dumped below.\n%s",
>
> it always seems to be empty in my logs. Is it not used now?
>
>
> or
>
> Method 2: have RC actually send the whole expectation agenda to AudioServer.
>
> Via which method and in what format does it send the expectation
> agenda to Helios now?
> What is RC? (Did you mean DM?)
>
> thank you
> Svetlana
>
>
> On 2/22/07, Dan Bohus <dbohus at cs.cmu.edu> wrote:
> > Hi Svetlana,
> >
> > Thanks Antoine for the detailed response. Just wanted to add a short bit
> > to this... I think the idea of dynamically generating the grammar from
> > the expectation agenda is a really interesting research issue, and we've
> > kept saying for a while that someone should try that :) People generally
> > use state-specific language models or grammars, but generating it from
> > the expectation agenda is potentially more interesting, because it (can)
> > provide more fine-grained and dynamic control... for instance if you get
> > in the same dialog state through different paths in the dialog plan, the
> > expectation agenda might in fact look different. I think it's an
> > interesting path to explore. You could of course consider weighting
> > things based on how deep they are in the agenda (something near the top
> > is probably more likely that something near the bottom), and of course
> > you could think of all sorts of learning setups there, etc.
> >
> > In any case, if you go down that path, I'd be really curious to see what
> > happens. Keep us posted.
> >
> > Cheers,
> > Dan.
> >
> > -----Original Message-----
> > From: ravenclaw-developers-bounces at LOGANBERRY.srv.cs.cmu.edu
> > [mailto:ravenclaw-developers-bounces at LOGANBERRY.srv.cs.cmu.edu] On
> > Behalf Of Antoine Raux
> > Sent: Thursday, February 22, 2007 8:22 AM
> > To: ravenclaw-developers at cs.cmu.edu
> > Subject: [RavenclawDev 225] Re: swapping grammars for the ASR
> >
> > Hi Svetlana,
> >
> > Note that we are already using state-specific (statistical) LMs in our
> > current systems. The way we switch between LMs is through the
> > INPUT_LINE_CONFIGURATION directive which is generally used in REQUEST
> > agents
> > and agencies, as in the following example from Let's Go:
> >
> > INPUT_LINE_CONFIGURATION( "set_lm=time, set_dtmf_len=1")
> >
> > The specific syntax of the configuration string is dependent on
> > AudioServer
> > (RavenClaw just sends the slot-value pairs to AudioServer). Right now,
> > you
> > use set_lm to specify the LM name for the Sphinx 2/3 recognizers, and
> > set_dtmf_len to specify how many digits your DTMF recognizer should
> > expect.
> > Of course, you could add new directives, as long as you modify
> > AudioServer
> > so that it does the right thing (which is most likely sending the
> > directives
> > to each individual recognition engine).
> >
> > So the current way to implement what you're proposing is to add an
> > INPUT_LINE_CONFIGURATION directive to all request agents that indicates
> > all
> > the rules that should be active at that time.
> > Now, it might be interesting to have a default behavior that does what
> > you're saying (i.e. automatically building the LM configuration from the
> > expectation agenda). This could be achieved by overloading the
> > CDialogAgent
> > virtual method GetInputLineConfiguration, so it (optionally) constructs
> > a
> > list of active rules when called (it's already written so that it
> > inherits
> > unspecified slots from its parent agent, in addition to parsing the
> > string
> > specified in its own INPUT_LINE_CONFIGURATION). Another option is to
> > have RC
> > actually send the whole expectation agenda to AudioServer (it's already
> > sending it to Helios), but then you have to modify AudioServer to allow
> > it
> > to parse the full agenda.
> >
> > Hope this helps...
> >
> > antoine
> >
> >
> >
> > -----Original Message-----
> > From: ravenclaw-developers-bounces at LOGANBERRY.srv.cs.cmu.edu
> > [mailto:ravenclaw-developers-bounces at LOGANBERRY.srv.cs.cmu.edu] On
> > Behalf Of
> > Svetlana Stenchikova
> > Sent: Wednesday, February 21, 2007 10:38 PM
> > To: ravenclaw-developers at cs.cmu.edu
> > Subject: [RavenclawDev 224] swapping grammars for the ASR
> >
> > Hi,  we are using JSGF grammars with sphinx 4 recognizer.
> > The grammar of sphinx 4 is generated by converting the grammar of the
> > phoenix parser.
> > We would like  to be able to swap Sphinx 4 grammars during the
> > runtime. This functionality is supported by sphinx 4.
> >
> >
> > One of the solutions that we consider is to modify the dialog system
> > specific part of the DM:  create execute agents that call
> > enable/disable grammars on the ASR and place these agents manually in
> > the dialog tree. This is not a good solution because there will be a
> > duplication between what is passed to ASR and what is set in the
> > GRAMMAR_MAPPING directive on the dialog manager.
> >
> > Another idea is to use the implementation of the GRAMMAR_MAPPING
> > directive  to make a call to the ASR component notifying it to change
> > the grammar.
> > >From looking at the code  CMAExpect::DeclareExpectations and
> > CMARequest::DeclareExpectations, each agent has a list of expected
> > grammatical rules.
> >
> > So, when an agent is activated(or executed) it could potentially make
> > a call to the ASR component to notify it of the grammar in the current
> > state of the DM and to enable the rules that should be active at this
> > point of the dialog.
> > This would ensure the synchrony between the DM grammar and the ASR
> > grammar. This requires a 1-to-1 mapping between phoenix and ASR
> > grammars, which we comply with because ASR grammar is a conversion
> > from phoenix grammar.
> >
> > Can you please tell us what do you think of this idea?
> > This functionality is currently not present in ravenclaw, right?
> > How difficult would it be to implement this?
> > Could you please give any pointers or suggestions for the
> > implementation?
> >
> >
> > Thank you
> >
> > Svetlana
> >
> >
> >
> >
>