[RavenclawDev 227] Re: swapping grammars for the ASR

[Svetlana Stenchikova]

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
>
>
>
>