As to robustness, in the ongoing VM-evaluation, the dialogue act based translation that uses this functionality was the only track that works at least partially when the recognizers deliver bad results. As to scalability and reusability, we think that in the currently manageable domains of NL applications, the approach scales quite well and is reusable. When extending the domain from scheduling to travel planning etc., we could use the existing knowledge sources as building blocks that could be extended. Not in the sense of ideal universal knowledge sources like a universal grammar, that produces nice trees or graphs, of course. The dialogue script generator is described in most detail and is the most convincing application from my point of view.
Translation needs context data.
This is undisputed. The Kontext module answers direct disambiguation requests by the semantic transfer module. Now, our main contribution to this kind of context is our sending content and time objects to the Kontext module which they try to integrate in their overall representation of dialogue context. Kontext itself extracts content info from the syntactic-semantic representation that is used for transfer. Could mean, for example, use of the dialogue module in different systems or for different domains, applications, languages.