[RavenclawDev 174] Re: bypassing the parser

[Antoine Raux]

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