[RavenclawDev 197] Re: bypassing the parser

[Dan Bohus]

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/20061125/95953544/attachment.html