[RavenclawDev 198] Re: bypassing the parser

[Svetlana Stenchikova]

Thank you Dan, binding to the h3_hypothesis worked.
That's good because it saves me from doing more work  :)

Good luck on your interviews!

Svetlana


On 11/25/06, Dan Bohus <dbohus at cs.cmu.edu> wrote:
>
>  Hi Svetlana,
>
>
>
> RavenClaw can bind on any of the attributes in the input. For instance, if
> you look at the "new input arrived" line in a dialog log, below it you will
> have a dump of all the attributes of the input and their values. You will
> notice that there are things there which represent the various parse
> fragments such as [Yes] or [Query.location] (which you normally bind on
> the dialog task). At the same time, there are a number of other attributes
> starting with h3_ … these are the various features that helios3 in fact uses
> in the confidence annotation process. They are passed all the way to the DM.
> Among them, h3_hypothesis contains the actual text of the recognition and
> h3_parse_str contains the full parse of the current decoded result. You can
> therefore bind on [h3_hypothesis] to get the text of the recognition.
>
>
>
> Hope this helps, but let me know if you have other questions.
>
> Dan
>
>
>  ------------------------------
>
> *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:* Thursday, November 09, 2006 9:40 AM
> *To:* Antoine Raux
> *Cc:* ravenclaw-developers at cs.cmu.edu
> *Subject:* [RavenclawDev 188] Re: bypassing the parser
>
>
>
> Hi Antoine (or Dan),
>
> did you, by any chance, remember the syntax for the grammar mapping to get
> text instead of a parse in a request/expect agent?
>
> Thank you
> 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/20061126/a30c55c7/attachment-0001.html