[RavenclawDev 176] Re: bypassing the parser

[Svetlana Stenchikova]

Antoine, I think this would be still useful for me.
Even if I use another server for recording,  I  still need to bind
recognized text to a concept.
So, in case you remember how to do it with changes just in DM, please let me
know.

thank you,
Svetlana

On 11/5/06, Svetlana Stenchikova <svetastenchikova at gmail.com> wrote:
>
> Thank you Dan and Antoine for your quick response.
>
> Antoine, your suggestion sounds interesting. DM does get called even if
> there is no parse found (I did not think it was)
>
> So, the change would be in a RequestAgent, right?
>
> I will probably still go for the "second parser" because eventually we
> will want to record and save the audio, where, I guess, the audio input will
> go directly to this "parser" which will output the location of the saved
> file.
>
> Thanks!
> Svetlana
>
>
> On 11/5/06, Antoine Raux <antoine at cs.cmu.edu> wrote:
> >
> > Hi Svetlana,
> >
> > RavenClaw actually has access to the (recognized) text corresponding to
> > each input, whether it's parsable or not. It's part of the set of
> > features that Helios passes to the DM. I forgot exactly how to access
> > these features but I believe it's basically a grammar mapping with a
> > special prefix that indicates that you're not binding a grammar slot but
> > a Helios input structure slot. Sorry I don't remember the exact syntax
> > now... If nobody else (Dan?) replies with more precision, I'll find it
> > out and email that later in the week. In any case, you might be able to
> > get what you want (the text of the input) without modifying anything at
> > all but your task specification (grammar mappings)...
> >
> > Otherwise, the second approach you are proposing (basically adding a
> > second "parser") sounds definitely much better than the first one, in
> > the sense that it preserves the integrity of the input line (which is
> > important for many things in the DM like grounding, reference to
> > previous turns....).
> >
> > I hope Dan will come up with a more precise answer soon :)
> >
> > antoine
> >
> > Svetlana Stenchikova wrote:
> >
> > > I just thought of another way to implement this without changing
> > > RavenClaw:
> > >
> > > Add another server ProcessRawData which receives the raw data input
> > > (in parallel with the parser)
> > > ProcessRawData outputs the input text in the format of the Parser:
> > >
> > > [RawText] ( the typed in text )
> > >
> > > The output is  passed  to the DialogManager.process_parse message
> > >
> > > The the text will bind to all concept that are expected in the
> > > [RawText] grammar mapping.
> > >
> > > Please let me know your thoughts on this.
> > >
> > > thank you
> > > Svetlana
> > >
> > >
> > > On 11/5/06, *Svetlana Stenchikova* <svetastenchikova at gmail.com
> > > <mailto:svetastenchikova at gmail.com>> wrote:
> > >
> > >     Dan, thank you for  your answer. I have another question.
> > >
> > >     We are interested in the functionality where a free text can be
> > >     entered through TTY (or through free speech recognition).
> > >
> > >     For example, a user can be asked to describe the event. The
> > >     grammar for this description is not available, so we want to store
> >
> > >     all of the typed ( or recognized) text, and/or a URL of the
> > >     recorded speech  into the concept in a dialog manager.
> > >
> > >     We need to bypass the parser. I would need to make changes to the
> > >     RavenClaw to accommodate this, right?
> > >
> > >     Currently the user input from the TTY (or ASR)  is processed by
> > >     the parser.
> > >
> > >      The control flow is determined by the .pgm file. This entry
> > >     causes it to call process_parse when an output from the parser is
> > >     available:
> > >
> > >
> > >
> > >     ;; If we have a confidence annotated hypothesis, but
> > >     ;; no parse, call phoenix to parse it
> > >     ;; ---
> > >     RULE: :confhyps & !:parses --> phoenix.phoenixparse
> > >     IN: :confhyps :npow :pow :clip_info
> > >     OUT: :total_numparses :parses :input_source
> > >     LOG_OUT: :parses
> > >
> > >
> > >
> > >     So I plan to add another entry:
> > >
> > >      ;; If we have a confidence annotated hypothesis, but
> > >     ;; no parse, call DM directly
> > >     ;; ---
> > >     RULE: :confhyps & !:parses --> DM.process_raw
> > >     IN: :confhyps :npow :pow :clip_info
> > >     OUT:
> > >     LOG_OUT:
> > >
> > >
> > >
> > >     Add process_raw() to
> > >
> > >     Libraries/RavenClaw/DMInterfaces/GalaxyInterfaceFunctions.h&
> > >     implement in GalaxyInterface.cpp
> > >
> > >
> > >     process_raw() function will be called whenever an output from the
> > >     TTY (or ASR) is received. So, this output will go to both parser
> > >     and DialogManager.process_raw.
> > >     process_raw()  assigns the text to a concept (but only in the case
> > >     when the concept is currently expected):
> > >     For every expected concept as compiled by
> > >     CDMCoreAgent::compileExpectationAgenda():
> > >     If a concept is a "raw speech" concept,  set its value to the raw
> > >     text received in an  input frame  to process_raw
> > >     I would have to add a type to a concept to indicate that it allows
> >
> > >     "raw text" input.
> > >
> > >
> > >     Does this implementation plan make sense?
> > >
> > >     Could you please make any suggestions?
> > >
> > >     Jahanzeb must have done something similar because his application
> > >     can record user's input. Do you know how that was implemented?
> > >
> > >
> > >
> > >     Thank you,
> > >     Svetlana
> > >
> > >
> > >
> > >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.srv.cs.cmu.edu/pipermail/ravenclaw-developers/attachments/20061105/06e78db9/attachment.html