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