Compiling Grammar-based Speech Application ... - CiteSeerX

4 Introduction
2 This work
Interactive speech applications are still often written in low-level, platformspecific
languages, which require much duplicated work throughout the system.
Our aim is to make construction of interactive speech applications easier by
compiling high-level specifications to the low-level code used in the running system.
GF is “the working programmer’s grammar formalism”. In this spirit, the
approach that we have taken is to use techniques borrowed from programming
language implementation to automatically generate system components from
grammars.
In the early days of computer programming, programs were written in machine
code or assembly languages, very low-level languages which give the programmer
full control, but make programs hard to write, limited to a single
machine architecture, and difficult to maintain. Today, programs are written in
high-level languages which give less control, but make programs easier to write,
portable across different machines and operating systems, and easier to maintain.
Programs written in high-level languages are compiled to code in low-level
languages, which can be run by machines.
The approach to development of interactive speech applications which we
describe here is grammar-based, since we use high-level grammars to define major
parts of the functionality. Several different components used in interactive
speech applications can be generated automatically from the grammars. The
systems which we generate are rule-based, rather than statistical. In an experiment
by Rayner et al. (2005a), a rule-based speech understanding system
was found to outperform a statistical one, and the advantage of the rule-based
system increased with the users’ familiarity with the system.
In our description of the components which we generate, we consider interactive
speech applications which can be implemented as pipelines. The system
receives input, which is processed step by step, and in the end output is produced.
A multimodal dialogue system may have components such as speech
recognition, multimodal fusion, semantic interpretation, dialogue management,
domain resources, output generation, linearization, multimodal fission, speech
synthesis. Figure 3 shows a schematic view of such a system. In a speech translator,
the dialogue management and domain resources may be replaced by a
semantic transfer component, as shown in Figure 4. Larger systems, such as the
Spoken Language Translator (Rayner et al. 2000), are more complex with more
components and a architecture which is not a simple pipeline. The individual
components that we generate can be used in more complex architectures, as has
been done in experimental dialogue systems (Ericsson et al. 2006) which use the
GoDiS (Larsson 2002) implementation of issue-based dialogue management.
2.1 Advantages
This work addresses the problems listed in Section 1.1 in the following ways:
Duplicated work The duplicated work involved in developing multiple com-