mirror of
https://github.com/GrammaticalFramework/gf-core.git
synced 2026-05-20 00:22:51 -06:00
more rm in doc
This commit is contained in:
aarne
@@ -1,490 +0,0 @@
|
|||||||
<html>
|
|
||||||
|
|
||||||
<body bgcolor="#FFFFFF" text="#000000">
|
|
||||||
|
|
||||||
<center>
|
|
||||||
|
|
||||||
<h1>Grammatical Framework Version 2</h1>
|
|
||||||
|
|
||||||
Highlights, versions 2.0, 2.1, and 2.2 (2.2 coming soon)
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
13/10/2003 - 25/11 - 2/4/2004 - 18/6 - 13/10 - 16/2/2005
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
<a href="http://www.cs.chalmers.se/~aarne">Aarne Ranta</a>
|
|
||||||
|
|
||||||
</center>
|
|
||||||
|
|
||||||
|
|
||||||
<h2>Syntax of GF</h2>
|
|
||||||
|
|
||||||
An accurate <a href="DocGF.pdf">language specification</a> is now available.
|
|
||||||
|
|
||||||
|
|
||||||
<h2>Summary of novelties in Versions 2.0 to 2.2</h2>
|
|
||||||
|
|
||||||
<h4>Module system</h4>
|
|
||||||
|
|
||||||
<li> Separate modules for <tt>abstract</tt>,
|
|
||||||
<tt>concrete</tt>, and <tt>resource</tt>.
|
|
||||||
<li> Replaces the file-based <tt>include</tt> system
|
|
||||||
<li> Name space handling with qualified names
|
|
||||||
<li> Hierarchic structure (single inheritance <tt>**</tt>) +
|
|
||||||
cross-cutting reuse (<tt>open</tt>)
|
|
||||||
<li> Separate compilation, one module per file
|
|
||||||
<li> Reuse of <tt>abstract</tt>+<tt>concrete</tt> as <tt>resource</tt><br>
|
|
||||||
<b>Version 2.2</b>: separate <tt>reuse</tt> modules no longer needed
|
|
||||||
<li> Parametrized modules:
|
|
||||||
<tt>interface</tt>, <tt>instance</tt>, <tt>incomplete</tt>.
|
|
||||||
<li> New experimental module types: <tt>transfer</tt>,
|
|
||||||
<tt>union</tt>.
|
|
||||||
<li> Version 2.1: multiple inheritance in module extension.
|
|
||||||
|
|
||||||
<h4>Canonical format GFC</h4>
|
|
||||||
|
|
||||||
<li> The target of GF compiler; to reuse, just read in.
|
|
||||||
<li> Readable by Haskell/Java/C++/C applications.
|
|
||||||
<li> Version 2.1: Java interpreter available for GFC (by Björn Bringert).
|
|
||||||
<li> <b>Version 2.2</b>: new optimizations to reduce the size of GFC files
|
|
||||||
|
|
||||||
|
|
||||||
<h4>New features in expression language</h4>
|
|
||||||
|
|
||||||
<li> Disjunctive patterns <tt>P | ... | Q</tt>.
|
|
||||||
<li> String patterns <tt>"foo"</tt>.
|
|
||||||
<li> Binding token <tt>&+</tt> to glue separate tokens at unlexing phase,
|
|
||||||
and unlexer to resolve this.
|
|
||||||
<li> New syntax alternatives for local definitions: <tt>let</tt> without
|
|
||||||
braces and <tt>where</tt>.
|
|
||||||
<li> Pattern variables can be used on lhs's of <tt>oper</tt> definitions.
|
|
||||||
<li> New Unicode transliterations (by Harad Hammarström).
|
|
||||||
<li> Version 2.1: Initial segments of integers
|
|
||||||
(<tt>Ints</tt><i>n</i>) available as parameter types.
|
|
||||||
|
|
||||||
|
|
||||||
<h4>New shell commands and command functionalities</h4>
|
|
||||||
|
|
||||||
<li> <tt>pi</tt> = <tt>print_info</tt>: information on an identifier in scope.
|
|
||||||
<li> <tt>h</tt> = <tt>help</tt> now in long or short form,
|
|
||||||
and on individual commands.
|
|
||||||
<li> <tt>gt</tt> = <tt>generate_trees</tt>: all trees of a given
|
|
||||||
category or instantiations of a given incomplete term, up to a
|
|
||||||
given depth.
|
|
||||||
<li> <tt>gr</tt> = <tt>generate_random</tt> can now be given
|
|
||||||
an incomplete term as an argument, to constrain generation.
|
|
||||||
<li> <tt>so</tt> = <tt>show_opers</tt> shows all <tt>ope</tt>
|
|
||||||
operations with a given value type.
|
|
||||||
<li> <tt>pm</tt> = <tt>print_multi</tt> prints the multilingual
|
|
||||||
grammar resident in the current state to a ready-compiles
|
|
||||||
<tt>.gfcm</tt> file.
|
|
||||||
<li> <b>Version 2.2</b>: several new command options
|
|
||||||
<li> <b>Version 2.2</b>: <tt>vg</tt> visializes the module dependency graph
|
|
||||||
<li> All commands have both long and short names (see help). Short
|
|
||||||
names are easier to type, whereas long names
|
|
||||||
make scripts more readable.
|
|
||||||
<li> Meaningless command options generate warnings.
|
|
||||||
|
|
||||||
|
|
||||||
<h4>New editor features</h4>
|
|
||||||
|
|
||||||
<li> Active text field: click the middle button in the focus to send
|
|
||||||
in refinement through the parser.
|
|
||||||
<li> Clipboard: copy complex terms into the refine menu.
|
|
||||||
<li> <b>Version 2.2</b>: text corresponding to subtrees with constraints marked with red colour
|
|
||||||
|
|
||||||
|
|
||||||
<h4>Improved implementation</h4>
|
|
||||||
|
|
||||||
<li> Haskell source code is organized into subdirectories.
|
|
||||||
<li> BNF Converter is used for defining the languages GF and GFC, which also
|
|
||||||
give reliable LaTeX documentation.
|
|
||||||
<li> Lexical rules sorted out by option <tt>-cflexer</tt> for efficient
|
|
||||||
parsing with large lexica.
|
|
||||||
<li> GHC optimizations and strictness flags are used for improving performance.
|
|
||||||
<li> <b>Version 2.2</b>: started <a
|
|
||||||
href="http://www.haskell.org/haddock">haddock</a> documentation
|
|
||||||
by using uniform module headers
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<h4>New parser (work in progress)</h4>
|
|
||||||
|
|
||||||
<li> By Peter Ljunglöf, based on MCFG.
|
|
||||||
<li> Much more efficient for morphology and discontinuous constituents.
|
|
||||||
<li> Treatment of cyclic rules.
|
|
||||||
<li> Version 2.1: improved generation of speech recognition
|
|
||||||
grammars (by Björn Bringert).
|
|
||||||
<li> Version 2.1: output of Labelled BNF files readable by the
|
|
||||||
BNF Converter.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<!-- NEW -->
|
|
||||||
|
|
||||||
<h2>Abstract, concrete, and resource modules</h2>
|
|
||||||
|
|
||||||
Judgement forms are sorted as follows:
|
|
||||||
<ul>
|
|
||||||
<li> abstract:
|
|
||||||
<tt>cat</tt>, <tt>fun</tt>, <tt>def</tt>, <tt>data</tt>, <tt>flags</tt>
|
|
||||||
<li> concrete:
|
|
||||||
<tt>lincat</tt>, <tt>cat</tt>, <tt>printname</tt>, <tt>flags</tt>
|
|
||||||
<li> resource:
|
|
||||||
<tt>param</tt>, <tt>oper</tt>, <tt>flags</tt>
|
|
||||||
<li>
|
|
||||||
</ul>
|
|
||||||
Example:
|
|
||||||
<pre>
|
|
||||||
abstract Sums = {
|
|
||||||
cat
|
|
||||||
Exp ;
|
|
||||||
fun
|
|
||||||
One : Exp ;
|
|
||||||
plus : Exp -> Exp -> Exp ;
|
|
||||||
}
|
|
||||||
|
|
||||||
concrete EnglishSums of Sums = open ResEng in {
|
|
||||||
lincat
|
|
||||||
Exp = {s : Str ; n : Number} ;
|
|
||||||
lin
|
|
||||||
One = expSg "one" ;
|
|
||||||
sum x y = expSg ("the" ++ "sum" ++ "of" ++ x.s ++ "and" ++ y.s) ;
|
|
||||||
}
|
|
||||||
|
|
||||||
resource ResEng = {
|
|
||||||
param
|
|
||||||
Number = Sg | Pl ;
|
|
||||||
oper
|
|
||||||
expSG : Str -> {s : Str ; n : Number} = \s -> {s = s ; n = Sg} ;
|
|
||||||
}
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<!-- NEW -->
|
|
||||||
|
|
||||||
<h2>Opening and extending modules</h2>
|
|
||||||
|
|
||||||
A <tt>concrete</tt> or <tt>resource</tt> can <b>open</b> a
|
|
||||||
<tt>resource</tt>. This means that
|
|
||||||
<ul>
|
|
||||||
<li> the names defined in <tt>resource</tt> can be used ("become visible")
|
|
||||||
<li> but: these names are not included in ("exported from") the opening module
|
|
||||||
</ul>
|
|
||||||
A module of any type can moreover <b>extend</b> a module of the same type.
|
|
||||||
This means that
|
|
||||||
<ul>
|
|
||||||
<li> the names defined in the extended module can be used ("become visible")
|
|
||||||
<li> and also: these names are included in ("exported from") the extending module
|
|
||||||
</ul>
|
|
||||||
Examples of extension:
|
|
||||||
<pre>
|
|
||||||
abstract Products = Sums ** {
|
|
||||||
fun times : Exp -> Exp -> Exp ;
|
|
||||||
}
|
|
||||||
-- names exported: Exp, plus, times
|
|
||||||
|
|
||||||
concrete English of Products = EnglishSums ** open ResEng in {
|
|
||||||
lin times x y = expSg ("the" ++ "product" ++ "of" ++ x.s ++ "and" ++ y.s) ;
|
|
||||||
}
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
Opening, but not extension, can be <b>qualified</b>:
|
|
||||||
<pre>
|
|
||||||
concrete NumberSystems of Systems = open (Bin = Binary), (Dec = Decimal) in {
|
|
||||||
lin
|
|
||||||
BZero = Bin.Zero ;
|
|
||||||
DZero = Dec.Zero
|
|
||||||
}
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
<b>Version 2.1</b> introduces <tt>multiple inheritance</tt>: a module
|
|
||||||
can extend several modules at the same time, for instance,
|
|
||||||
<pre>
|
|
||||||
abstract Dialogue = User, System ** { ...}
|
|
||||||
</pre>
|
|
||||||
may be used to put together "User's moves" and "System's moves" into
|
|
||||||
one Dialogue System grammar.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<!-- NEW -->
|
|
||||||
|
|
||||||
<h2>Compiling modules</h2>
|
|
||||||
|
|
||||||
Separate compilation assumes there is <b>one module per file</b>.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
The <b>module header</b> is the beginning of the module code up to the
|
|
||||||
first left bracket (<tt>{</tt>). The header gives
|
|
||||||
<ul>
|
|
||||||
<li> the module type: <tt>abstract</tt>, <tt>concrete</tt> (<tt>of</tt> <i>A</i>),
|
|
||||||
or <tt>resource</tt>
|
|
||||||
<li> the name of the module (next to the module type keyword)
|
|
||||||
<li> the names of extended modules (between <tt>=</tt> and <tt>**</tt>)
|
|
||||||
<li> the names of opened modules
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
<b>filename</b> = <b>modulename</b> <tt>.</tt> <b>extension</b>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
File name extensions:
|
|
||||||
<ul>
|
|
||||||
<li> <tt>gf</tt>: GF source file (uses GF syntax, is type checked and compiled)
|
|
||||||
<li> <tt>gfc</tt>: canonical GF file (uses GFC syntax, is simply read
|
|
||||||
in instead of compiled; produced from all kinds of modules)
|
|
||||||
<li> <tt>gfr</tt>: GF resource file (uses GF syntax, is only read in; produced from
|
|
||||||
<tt>resource</tt> modules)
|
|
||||||
<li> <tt>gfcm</tt>: canonical multilingual GF file
|
|
||||||
(uses GFC syntax, is only read in; produced
|
|
||||||
from a set of <tt>abstract</tt> and <tt>conctrete</tt> modules)
|
|
||||||
</ul>
|
|
||||||
Only <tt>gf</tt> files should ever be written/edited manually!
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
What the make facility does when compiling <tt>Foo.gf</tt>
|
|
||||||
<ol>
|
|
||||||
<li> read the module header of <tt>Foo.gf</tt>, and recursively all headers from
|
|
||||||
the modules it <b>depends</b> on (i.e. extends or opens)
|
|
||||||
<li> build a dependency graph of these modules, and do topological sorting
|
|
||||||
<li> starting from the first module in topological order,
|
|
||||||
compare the modification times of each <tt>gf</tt> and <tt>gfc</tt> file:
|
|
||||||
<ul>
|
|
||||||
<li> if <tt>gf</tt> is later, compile the module and all modules depending on it
|
|
||||||
<li> if <tt>gfc</tt> is later, just read in the module
|
|
||||||
</ul>
|
|
||||||
</ol>
|
|
||||||
Inside the GF shell, also time stamps of modules read into memory are
|
|
||||||
taken into account. Thus a module need not be read from a file if the
|
|
||||||
module is in the memory and the file has not been modified.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
If the compilation of a grammar fails at some module, the state of the
|
|
||||||
GF shell contains all modules read up to that point. This makes it
|
|
||||||
faster to compile the faulty module again after fixing it.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
Use the command <tt>po</tt> = <tt>print_options</tt> to see what
|
|
||||||
modules are in the state.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
To force compilation:
|
|
||||||
<ul>
|
|
||||||
<li> The flag <i>-src</i> in the import command forces compilation from
|
|
||||||
source even if more recent object files exist. This is useful
|
|
||||||
when testing new versions of GF.
|
|
||||||
<li> The flag <i>-retain</i> in the import command forces reading in
|
|
||||||
<tt>gfr</tt> files in addition to <tt>gfc</tt> files. This is useful
|
|
||||||
when testing operations with the <tt>cc</tt> command.
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<!-- NEW -->
|
|
||||||
|
|
||||||
<h3>Compiler optimizations</h3>
|
|
||||||
|
|
||||||
<b>Version 2.2</b>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
The sometimes exploding size of generated <tt>gfc</tt> and
|
|
||||||
<tt>gfr</tt> files has made it urgent to find optimizations
|
|
||||||
that reduce the size of the code. There are five
|
|
||||||
combinations optimizations that can be chosen, as the value of the
|
|
||||||
<tt>optimize</tt> flag:
|
|
||||||
<ul>
|
|
||||||
<li> <tt>share</tt>: group tables so that common branch values are shared
|
|
||||||
by the use of disjunctive patterns.
|
|
||||||
<li> <tt>parametrize</tt>: if table branches differ at most at the
|
|
||||||
occurrence of the pattern, replace the expanded table by a one-branch
|
|
||||||
table with a variable. If this fails, perform <tt>share</tt>.
|
|
||||||
<li> <tt>values</tt>: only show the values of table branches, not the
|
|
||||||
patterns.
|
|
||||||
<li> <tt>all</tt>: try <tt>parametrize</tt>; if this fails, do <tt>values</tt>.
|
|
||||||
<li> <tt>none</tt>: don't do any optimizations
|
|
||||||
</ul>
|
|
||||||
The <tt>share</tt> and <tt>parametrize</tt> optimizations are always
|
|
||||||
just good, whereas the <tt>values</tt> optimization may slow down the
|
|
||||||
use of the table. However, it is very good for grammars mostly consisting
|
|
||||||
of the inflection tables of lexical items: it can reduce the file size
|
|
||||||
by the factor of 4.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
An optimization can be selected individually for each
|
|
||||||
<tt>resource</tt> and <tt>concrete</tt> module by including
|
|
||||||
the judgement
|
|
||||||
<pre>
|
|
||||||
flags optimize=(share|parametrize|values|all|none) ;
|
|
||||||
</pre>
|
|
||||||
in the module body. These flags can be overridden by a flag given
|
|
||||||
in the <tt>i</tt> command, e.g.
|
|
||||||
<pre>
|
|
||||||
i -src -optimize=none Foo.gf
|
|
||||||
</pre>
|
|
||||||
Notice that the option <tt>-src</tt> is needed if there already are
|
|
||||||
generated files created with other optimization flags.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<!-- NEW -->
|
|
||||||
|
|
||||||
<h2>Module search paths</h2>
|
|
||||||
|
|
||||||
Modules can reside in different directories. Use the <tt>path</tt>
|
|
||||||
flag to extend the directory search path. For instance,
|
|
||||||
<pre>
|
|
||||||
-path=.:../resource/russian:../prelude
|
|
||||||
</pre>
|
|
||||||
enables files to be found in three different directories.
|
|
||||||
By default, only the current directory is included.
|
|
||||||
If a <tt>path</tt> flag is given, the current directory
|
|
||||||
<tt>.</tt> must be explicitly included if it is wanted.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
The <tt>path</tt> flag can be set in any of the following
|
|
||||||
places:
|
|
||||||
<ul>
|
|
||||||
<li> when invoking GF: <tt>gf -path=xxx</tt>
|
|
||||||
<li> when importing a module: <tt>i -path=xxx Foo.gf</tt>
|
|
||||||
<li> as a pragma in a topmost file: <tt>--# -path=xxx</tt>
|
|
||||||
</ul>
|
|
||||||
A flag set on a command line overrides ones set in files.
|
|
||||||
|
|
||||||
|
|
||||||
<!-- NEW -->
|
|
||||||
|
|
||||||
<h2>How to use GF 1.* files</h2>
|
|
||||||
|
|
||||||
Backward compatibility with respect to old GF grammars has been
|
|
||||||
a central goal. All GF grammars, from version 0.9, should work in
|
|
||||||
the old way in GF2. The main exceptions are some features that
|
|
||||||
are rarely used.
|
|
||||||
<ul>
|
|
||||||
<li> The <tt>package</tt> system introduced in GF 1.2, cannot be
|
|
||||||
interpreted in the module system of GF 2.0, since packages are in
|
|
||||||
mutual scope with the top level.
|
|
||||||
<li> <tt>tokenizer</tt> pragmas are cannot be parsed any more. In GF
|
|
||||||
1.2, they are already replaced by <tt>lexer</tt> flags.
|
|
||||||
<li> <tt>var</tt> pragmas cannot be parsed any more.
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
Very old GF grammars (from versions before 0.9), with the completely
|
|
||||||
different notation, do not work. They should be first converted to
|
|
||||||
GF1 by using GF version 1.2.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
The import command <tt>i</tt> can be given the option <tt>-old</tt>. E.g.
|
|
||||||
<pre>
|
|
||||||
i -old tut1.Eng.g2
|
|
||||||
</pre>
|
|
||||||
But this is no more necessary: GF2 detects automatically if a grammar
|
|
||||||
is in the GF1 format.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
Importing a set of GF2 files generates, internally, three modules:
|
|
||||||
<pre>
|
|
||||||
abstract tut1 = ...
|
|
||||||
resource ResEng = ...
|
|
||||||
concrete Eng of tut1 = open ResEng in ...
|
|
||||||
</pre>
|
|
||||||
(The names are different if the file name has fewer parts.)
|
|
||||||
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
The option <tt>-o</tt> causes GF2 to write these modules into files.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
The flags <tt>-abs</tt>, <tt>-cnc</tt>, and <tt>-res</tt> can be used
|
|
||||||
to give custom names to the modules. In particular, it is good to use
|
|
||||||
the <tt>-abs</tt> flag to guarantee that the abstract syntax module
|
|
||||||
has the same name for all grammars in a multilingual environmens:
|
|
||||||
<pre>
|
|
||||||
i -old -abs=Numerals hungarian.gf
|
|
||||||
i -old -abs=Numerals tamil.gf
|
|
||||||
i -old -abs=Numerals sanskrit.gf
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
The same flags as in the import command can be used when invoking
|
|
||||||
GF2 from the system shell. Many grammars can be imported on the same command
|
|
||||||
line, e.g.
|
|
||||||
<pre>
|
|
||||||
% gf2 -old -abs=Tutorial tut1.Eng.gf tut1.Fin.gf tut1.Fra.gf
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
To write a GF2 grammar back to GF1 (as one big file), use the command
|
|
||||||
<pre>
|
|
||||||
> pg -old
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
|
|
||||||
GF2 has more reserved words than GF 1.2. When old files are read, a preprocessor
|
|
||||||
replaces every identifier that has the shape of a new reserved word
|
|
||||||
with a variant where the last letter is replaced by <tt>Z</tt>, e.g.
|
|
||||||
<tt>instance</tt> is replaced by <tt>instancZ</tt>. This method is of course
|
|
||||||
unsafe and should be replaced by something better.
|
|
||||||
|
|
||||||
|
|
||||||
<!-- NEW -->
|
|
||||||
|
|
||||||
<h2>Missing features of GF 1.2 (13/10/2004)</h2>
|
|
||||||
|
|
||||||
Generally, GF1 grammars can be automatically translated to GF2, although the
|
|
||||||
result is not as good
|
|
||||||
as manual, since indentation and comments are destroyed.
|
|
||||||
The results can be
|
|
||||||
saved in GF2 files, but this is not necessary.
|
|
||||||
Some rarely used GF1 features are no longer supported (see next section).
|
|
||||||
It is also possible to write a GF2 grammar back to GF1, with the
|
|
||||||
command <tt>pg -printer=old</tt>.
|
|
||||||
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
Resource libraries
|
|
||||||
and some example grammars have been
|
|
||||||
converted. Most old example grammars work without any changes.
|
|
||||||
However, there is a new resource API with
|
|
||||||
many new constructions, and which is recommended.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
Soundness checking of module depencencies and completeness is not
|
|
||||||
complete. This means that some errors may show up too late.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
Latex and XML printing of grammars do not work yet.
|
|
||||||
|
|
||||||
|
|
||||||
</body>
|
|
||||||
</html>
|
|
||||||
@@ -1,173 +0,0 @@
|
|||||||
<html>
|
|
||||||
|
|
||||||
<body bgcolor="#FFFFFF" text="#000000">
|
|
||||||
|
|
||||||
<center>
|
|
||||||
|
|
||||||
<h1>Grammatical Framework Version 2.2</h1>
|
|
||||||
|
|
||||||
Highlights of GF version 2.2.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
9/5/2005
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
<a href="http://www.cs.chalmers.se/~aarne">Aarne Ranta</a>
|
|
||||||
|
|
||||||
</center>
|
|
||||||
|
|
||||||
|
|
||||||
<h2>Summary of novelties in Version 2.2 in comparison to 2.1</h2>
|
|
||||||
|
|
||||||
<li> New optimizations to reduce the size of GFC files
|
|
||||||
<li> Improved parsing algorithms
|
|
||||||
<li> Lots of bug fixes
|
|
||||||
<li> Separate <tt>reuse</tt> modules no longer needed
|
|
||||||
<li> Several new command options
|
|
||||||
<li> New documentation:
|
|
||||||
<ul>
|
|
||||||
<li> <a href="gf-modules.html">module system document</tt>
|
|
||||||
<li> <a href="tutorial/gf-tutorial2.html">new tutorial</a>, based on the module system (unfinished)
|
|
||||||
</ul>
|
|
||||||
<li> New resource libraries
|
|
||||||
<li> New example grammars
|
|
||||||
<li> Visualization of module dependency graph
|
|
||||||
<li> In the editor GUI, text corresponding to subtrees with constraints marked with red colour
|
|
||||||
<li> Hierarchic modules used in the source code
|
|
||||||
<li> <a href="http://www.haskell.org/haddock">haddock</a> documentation available for source code
|
|
||||||
<li> Optimizations to reduce GF's memory footprint when using large grammars.
|
|
||||||
<li> The <tt>pm</tt> command can now convert identifiers in the grammar to UTF-8.
|
|
||||||
|
|
||||||
|
|
||||||
<h3>Compiler optimizations</h3>
|
|
||||||
|
|
||||||
The sometimes exploding size of generated <tt>gfc</tt> and
|
|
||||||
<tt>gfr</tt> files has made it urgent to find optimizations
|
|
||||||
that reduce the size of the code. There are five
|
|
||||||
combinations optimizations that can be chosen, as the value of the
|
|
||||||
<tt>optimize</tt> flag:
|
|
||||||
<ul>
|
|
||||||
<li> <tt>share</tt>: group tables so that common branch values are shared
|
|
||||||
by the use of disjunctive patterns.
|
|
||||||
<li> <tt>parametrize</tt>: if table branches differ at most at the
|
|
||||||
occurrence of the pattern, replace the expanded table by a one-branch
|
|
||||||
table with a variable. If this fails, perform <tt>share</tt>.
|
|
||||||
<li> <tt>values</tt>: only show the values of table branches, not the
|
|
||||||
patterns.
|
|
||||||
<li> <tt>all</tt>: try <tt>parametrize</tt>; if this fails, do <tt>values</tt>.
|
|
||||||
<li> <tt>none</tt>: don't do any optimizations
|
|
||||||
</ul>
|
|
||||||
The <tt>share</tt> and <tt>parametrize</tt> optimizations are always
|
|
||||||
just good, whereas the <tt>values</tt> optimization may slow down the
|
|
||||||
use of the table. However, it is very good for grammars mostly consisting
|
|
||||||
of the inflection tables of lexical items: it can reduce the file size
|
|
||||||
by the factor of 4.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
An optimization can be selected individually for each
|
|
||||||
<tt>resource</tt> and <tt>concrete</tt> module by including
|
|
||||||
the judgement
|
|
||||||
<pre>
|
|
||||||
flags optimize=(share|parametrize|values|all|none) ;
|
|
||||||
</pre>
|
|
||||||
in the module body. These flags can be overridden by a flag given
|
|
||||||
in the <tt>i</tt> command, e.g.
|
|
||||||
<pre>
|
|
||||||
i -src -optimize=none Foo.gf
|
|
||||||
</pre>
|
|
||||||
Notice that the option <tt>-src</tt> is needed if there already are
|
|
||||||
generated files created with other optimization flags.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
<b>Important notice</b>: If you use the
|
|
||||||
<a href="http://www.cs.chalmers.se/~bringert/gf/gf-java.html">
|
|
||||||
Embedded GF Interpreter</a>,
|
|
||||||
or the improved parsing algorithms described below,
|
|
||||||
only the values <tt>none</tt>,
|
|
||||||
<tt>share</tt> and <tt>values</tt> can be used; the stronger optimizations are not
|
|
||||||
supported yet.
|
|
||||||
Also note that currently, GF aborts and reports an error if the stronger optimizations are used
|
|
||||||
when creating the grammar for the Embedded GF Interpreter, or when trying to parse.
|
|
||||||
|
|
||||||
|
|
||||||
<h3>Improved parsing algorithms</h3>
|
|
||||||
|
|
||||||
We have implemented some of the suggested parsing algorithms described in
|
|
||||||
Peter Ljunglöf's <a href="http://www.cs.chalmers.se/~peb/pubs.html">PhD thesis</a>.
|
|
||||||
So now there are the following options for parsing:
|
|
||||||
<ul>
|
|
||||||
<li>The default parser. It uses a (possibly) very overgenerating context-free grammar, and filters the resulting parse trees by type-checking.
|
|
||||||
<li>The <tt>-cfg</tt> flag. It uses a much less overgenerating context-free grammar, and filters as above.
|
|
||||||
<li>The <tt>-mcfg</tt> flag. It uses an even less overgenerating <em>multiple context-free grammar</em>.
|
|
||||||
If the abstract syntax is context-free, meaning that there are no dependent types and only first-order functions,
|
|
||||||
the trees do not have to be filtered at all.
|
|
||||||
</ul>
|
|
||||||
The option <tt>-parser=X</tt> selects the parsing strategy. The default parser has the strategies
|
|
||||||
<tt>chart</tt>, <tt>bottomup</tt>, <tt>topdown</tt>, <tt>old</tt>, with the first one being the default.
|
|
||||||
The <tt>-cfg</tt> and <tt>-mcfg</tt> parsers only recognize the <tt>bottomup</tt> and <tt>topdown</tt> strategies.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
<b>Note</b> that the <tt>-cfg</tt> and <tt>-mcfg</tt> parsers can take a very long time on their first call, since
|
|
||||||
they have to convert the GF grammar. This will only happen once in a GF run, provided the GF files are not changed.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
<b>Tips</b> for choosing the best parser for your grammar. Try with the default parser; if it is too slow, try the other two.
|
|
||||||
Remember that the first time you parse they will be very slow, since they have to build parsing information.
|
|
||||||
the <tt>-cfg</tt> parser is best on grammars with many parameters and inflection tables, and
|
|
||||||
The <tt>-mcfg</tt> parser is even better when the grammar also has discontinuous constituents.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
|
|
||||||
Here is a small example from the resource library:
|
|
||||||
<pre>
|
|
||||||
> i -src -optimize=share lib/resource/english/LangEng.gf
|
|
||||||
> p -cat=S ""
|
|
||||||
> p -cat=S -cfg ""
|
|
||||||
> p -cat=S -mcfg ""
|
|
||||||
{Comment: Just some dummy parsing calls to calculate the parsing information}
|
|
||||||
|
|
||||||
> p -cat=S -rawtrees=200000 "you will be running"
|
|
||||||
{Comment: Nr of unfiltered trees: 169296 -- 99,996% av the trees are ill-typed}
|
|
||||||
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP thou_NP (IPredV AAnter run_V))
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP thou_NP (IPredV ASimul run_V))
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP ye_NP (IPredV AAnter run_V))
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP ye_NP (IPredV ASimul run_V))
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP you_NP (IPredV AAnter run_V))
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP you_NP (IPredV ASimul run_V))
|
|
||||||
|
|
||||||
17730 msec
|
|
||||||
|
|
||||||
> p -cat=S -cfg "you will be running"
|
|
||||||
{Comment: Nr of unfiltered trees: 246 -- 97,5% of the trees are ill-typed}
|
|
||||||
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP thou_NP (IPredV AAnter run_V))
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP thou_NP (IPredV ASimul run_V))
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP ye_NP (IPredV AAnter run_V))
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP ye_NP (IPredV ASimul run_V))
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP you_NP (IPredV AAnter run_V))
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP you_NP (IPredV ASimul run_V))
|
|
||||||
|
|
||||||
1580 msec
|
|
||||||
|
|
||||||
> p -cat=S -mcfg "you will be running"
|
|
||||||
{Comment: Nr of unfiltered trees: 6 -- all trees are type-corrent}
|
|
||||||
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP thou_NP (IPredV AAnter run_V))
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP thou_NP (IPredV ASimul run_V))
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP ye_NP (IPredV AAnter run_V))
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP ye_NP (IPredV ASimul run_V))
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP you_NP (IPredV AAnter run_V))
|
|
||||||
UseCl (PosTP TFuture ASimul) (SPredProgVP you_NP (IPredV ASimul run_V))
|
|
||||||
|
|
||||||
470 msec
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
</body>
|
|
||||||
</html>
|
|
||||||
BIN
doc/gfcc.pdf
BIN
doc/gfcc.pdf
Binary file not shown.
@@ -1,56 +0,0 @@
|
|||||||
Grammars and Types
|
|
||||||
|
|
||||||
==Historical introduction==
|
|
||||||
|
|
||||||
Stoics ?
|
|
||||||
|
|
||||||
Port-Royal ?
|
|
||||||
|
|
||||||
Lyons
|
|
||||||
|
|
||||||
Frege
|
|
||||||
|
|
||||||
Ajdukiewicz
|
|
||||||
|
|
||||||
Bar-Hillel
|
|
||||||
|
|
||||||
Lambek
|
|
||||||
|
|
||||||
Curry
|
|
||||||
|
|
||||||
Montague
|
|
||||||
|
|
||||||
PATR, HPSG
|
|
||||||
|
|
||||||
LFG
|
|
||||||
|
|
||||||
GF
|
|
||||||
|
|
||||||
ACG, HOG
|
|
||||||
|
|
||||||
|
|
||||||
==Syntactic and semantic grammars==
|
|
||||||
|
|
||||||
in GF
|
|
||||||
|
|
||||||
==Cross-linguistic types==
|
|
||||||
|
|
||||||
generalizations over type systems, parametrized modules
|
|
||||||
|
|
||||||
|
|
||||||
==Grammatical concepts formalized==
|
|
||||||
|
|
||||||
POS, category
|
|
||||||
|
|
||||||
inherent and parametric features
|
|
||||||
|
|
||||||
agreement
|
|
||||||
|
|
||||||
rection
|
|
||||||
|
|
||||||
endocentric and exocentric concepts
|
|
||||||
|
|
||||||
(see Lyons and Jespersen for more)
|
|
||||||
|
|
||||||
a core syntax (latin.gf)
|
|
||||||
|
|
||||||
@@ -1,511 +0,0 @@
|
|||||||
|
|
||||||
|
|
||||||
==Coverage==
|
|
||||||
|
|
||||||
The GF Resource Grammar Library contains grammar rules for
|
|
||||||
10 languages (in addition, 2 languages are available as incomplete
|
|
||||||
implementations, and a few more are under construction). Its purpose
|
|
||||||
is to make these rules available for application programmers,
|
|
||||||
who can thereby concentrate on the semantic and stylistic
|
|
||||||
aspects of their grammars, without having to think about
|
|
||||||
grammaticality. The targeted level of application grammarians
|
|
||||||
is that of a skilled programmer with
|
|
||||||
a practical knowledge of the target languages, but without
|
|
||||||
theoretical knowledge about their grammars.
|
|
||||||
Such a combination of
|
|
||||||
skills is typical of programmers who, for instance, want to localize
|
|
||||||
software to new languages.
|
|
||||||
|
|
||||||
The current resource languages are
|
|
||||||
- ``Ara``bic (incomplete)
|
|
||||||
- ``Cat``alan (incomplete)
|
|
||||||
- ``Dan``ish
|
|
||||||
- ``Eng``lish
|
|
||||||
- ``Fin``nish
|
|
||||||
- ``Fre``nch
|
|
||||||
- ``Ger``man
|
|
||||||
- ``Ita``lian
|
|
||||||
- ``Nor``wegian
|
|
||||||
- ``Rus``sian
|
|
||||||
- ``Spa``nish
|
|
||||||
- ``Swe``dish
|
|
||||||
|
|
||||||
|
|
||||||
The first three letters (``Eng`` etc) are used in grammar module names.
|
|
||||||
The incomplete Arabic and Catalan implementations are
|
|
||||||
enough to be used in many applications; they both contain, amoung other
|
|
||||||
things, complete inflectional morphology.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
==A first example==
|
|
||||||
|
|
||||||
To give an example application, consider a system for steering
|
|
||||||
music playing devices by voice commands. In the application,
|
|
||||||
we may have a semantical category ``Kind``, examples
|
|
||||||
of ``Kind``s being ``Song`` and ``Artist``. In German, for instance, ``Song``
|
|
||||||
is linearized into the noun "Lied", but knowing this is not
|
|
||||||
enough to make the application work, because the noun must be
|
|
||||||
produced in both singular and plural, and in four different
|
|
||||||
cases. By using the resource grammar library, it is enough to
|
|
||||||
write
|
|
||||||
```
|
|
||||||
lin Song = mkN "Lied" "Lieder" neuter
|
|
||||||
```
|
|
||||||
and the eight forms are correctly generated. The resource grammar
|
|
||||||
library contains a complete set of inflectional paradigms (such as
|
|
||||||
``mkN`` here), enabling the definition of any lexical items.
|
|
||||||
|
|
||||||
The resource grammar library is not only about inflectional paradigms - it
|
|
||||||
also has syntax rules. The music player application
|
|
||||||
might also want to modify songs with properties, such as "American",
|
|
||||||
"old", "good". The German grammar for adjectival modifications is
|
|
||||||
particularly complex, because adjectives have to agree in gender,
|
|
||||||
number, and case, and also depend on what determiner is used
|
|
||||||
("ein amerikanisches Lied" vs. "das amerikanische Lied"). All this
|
|
||||||
variation is taken care of by the resource grammar function
|
|
||||||
```
|
|
||||||
mkCN : AP -> CN -> CN
|
|
||||||
```
|
|
||||||
(see the table in the end of this document for the list of all resource grammar
|
|
||||||
functions). The resource grammar implementation of the rule adding properties
|
|
||||||
to kinds is
|
|
||||||
```
|
|
||||||
lin PropKind kind prop = mkCN prop kind
|
|
||||||
```
|
|
||||||
given that
|
|
||||||
```
|
|
||||||
lincat Prop = AP
|
|
||||||
lincat Kind = CN
|
|
||||||
```
|
|
||||||
The resource library API is devided into language-specific
|
|
||||||
and language-independent parts. To put it roughly,
|
|
||||||
- the lexicon API is language-specific
|
|
||||||
- the syntax API is language-independent
|
|
||||||
|
|
||||||
|
|
||||||
Thus, to render the above example in French instead of German, we need to
|
|
||||||
pick a different linearization of ``Song``,
|
|
||||||
```
|
|
||||||
lin Song = mkN "chanson" feminine
|
|
||||||
```
|
|
||||||
But to linearize ``PropKind``, we can use the very same rule as in German.
|
|
||||||
The resource function ``mkCN`` has different implementations in the two
|
|
||||||
languages (e.g. a different word order in French),
|
|
||||||
but the application programmer need not care about the difference.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
==Note on APIs==
|
|
||||||
|
|
||||||
From version 1.1 onwards, the resource library is available via two
|
|
||||||
APIs:
|
|
||||||
- original ``fun`` and ``oper`` definitions
|
|
||||||
- overloaded ``oper`` definitions
|
|
||||||
|
|
||||||
|
|
||||||
Introducing overloading in GF version 2.7 has been a success in improving
|
|
||||||
the accessibility of libraries. It has also created a layer of abstraction
|
|
||||||
between the writers and users of libraries, and thereby makes the library
|
|
||||||
easier to modify. We shall therefore use the overloaded API
|
|
||||||
in this document. The original function names are mainly interesting
|
|
||||||
for those who want to write or modify libraries.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
==A complete example==
|
|
||||||
|
|
||||||
To summarize the example, and also give a template for a programmer to work on,
|
|
||||||
here is the complete implementation of a small system with songs and properties.
|
|
||||||
The abstract syntax defines a "domain ontology":
|
|
||||||
```
|
|
||||||
abstract Music = {
|
|
||||||
|
|
||||||
cat
|
|
||||||
Kind,
|
|
||||||
Property ;
|
|
||||||
fun
|
|
||||||
PropKind : Kind -> Property -> Kind ;
|
|
||||||
Song : Kind ;
|
|
||||||
American : Property ;
|
|
||||||
}
|
|
||||||
```
|
|
||||||
The concrete syntax is defined by a functor (parametrized module),
|
|
||||||
independently of language, by opening
|
|
||||||
two interfaces: the resource ``Syntax`` and an application lexicon.
|
|
||||||
```
|
|
||||||
incomplete concrete MusicI of Music =
|
|
||||||
open Syntax, MusicLex in {
|
|
||||||
lincat
|
|
||||||
Kind = CN ;
|
|
||||||
Property = AP ;
|
|
||||||
lin
|
|
||||||
PropKind k p = mkCN p k ;
|
|
||||||
Song = mkCN song_N ;
|
|
||||||
American = mkAP american_A ;
|
|
||||||
}
|
|
||||||
```
|
|
||||||
The application lexicon ``MusicLex`` is an interface
|
|
||||||
opening the resource category system ``Cat``.
|
|
||||||
```
|
|
||||||
interface MusicLex = Cat ** {
|
|
||||||
oper
|
|
||||||
song_N : N ;
|
|
||||||
american_A : A ;
|
|
||||||
}
|
|
||||||
```
|
|
||||||
It could also be an abstract syntax that extends ``Cat``, but
|
|
||||||
this would limit the kind of constructions that are possible in
|
|
||||||
the interface
|
|
||||||
|
|
||||||
Each language has its own concrete syntax, which opens the
|
|
||||||
inflectional paradigms module for that language:
|
|
||||||
```
|
|
||||||
interface MusicLexGer of MusicLex =
|
|
||||||
CatGer ** open ParadigmsGer in {
|
|
||||||
oper
|
|
||||||
song_N = mkN "Lied" "Lieder" neuter ;
|
|
||||||
american_A = mkA "amerikanisch" ;
|
|
||||||
}
|
|
||||||
|
|
||||||
interface MusicLexFre of MusicLex =
|
|
||||||
CatFre ** open ParadigmsFre in {
|
|
||||||
oper
|
|
||||||
song_N = mkN "chanson" feminine ;
|
|
||||||
american_A = mkA "américain" ;
|
|
||||||
}
|
|
||||||
```
|
|
||||||
The top-level ``Music`` grammars are obtained by
|
|
||||||
instantiating the two interfaces of ``MusicI``:
|
|
||||||
```
|
|
||||||
concrete MusicGer of Music = MusicI with
|
|
||||||
(Syntax = SyntaxGer),
|
|
||||||
(MusicLex = MusicLexGer) ;
|
|
||||||
|
|
||||||
concrete MusicFre of Music = MusicI with
|
|
||||||
(Syntax = SyntaxFre),
|
|
||||||
(MusicLex = MusicLexFre) ;
|
|
||||||
```
|
|
||||||
Both of these files can use the same ``path``, defined as
|
|
||||||
```
|
|
||||||
--# -path=.:present:prelude
|
|
||||||
```
|
|
||||||
The ``present`` category contains the compiled resources, restricted to
|
|
||||||
present tense; ``alltenses`` has the full resources.
|
|
||||||
|
|
||||||
To localize the music player system to a new language,
|
|
||||||
all that is needed is two modules,
|
|
||||||
one implementing ``MusicLex`` and the other
|
|
||||||
instantiating ``Music``. The latter is
|
|
||||||
completely trivial, whereas the former one involves the choice of correct
|
|
||||||
vocabulary and inflectional paradigms. For instance, Finnish is added as follows:
|
|
||||||
```
|
|
||||||
instance MusicLexFin of MusicLex =
|
|
||||||
CatFin ** open ParadigmsFin in {
|
|
||||||
oper
|
|
||||||
song_N = mkN "kappale" ;
|
|
||||||
american_A = mkA "amerikkalainen" ;
|
|
||||||
}
|
|
||||||
|
|
||||||
concrete MusicFin of Music = MusicI with
|
|
||||||
(Syntax = SyntaxFin),
|
|
||||||
(MusicLex = MusicLexFin) ;
|
|
||||||
```
|
|
||||||
More work is of course needed if the language-independent linearizations in
|
|
||||||
MusicI are not satisfactory for some language. The resource grammar guarantees
|
|
||||||
that the linearizations are possible in all languages, in the sense of grammatical,
|
|
||||||
but they might of course be inadequate for stylistic reasons. Assume,
|
|
||||||
for the sake of argument, that adjectival modification does not sound good in
|
|
||||||
English, but that a relative clause would be preferrable. One can then use
|
|
||||||
restricted inheritance of the functor:
|
|
||||||
```
|
|
||||||
concrete MusicEng of Music =
|
|
||||||
MusicI - [PropKind]
|
|
||||||
with
|
|
||||||
(Syntax = SyntaxEng),
|
|
||||||
(MusicLex = MusicLexEng) **
|
|
||||||
open SyntaxEng in {
|
|
||||||
lin
|
|
||||||
PropKind k p = mkCN k (mkRS (mkRCl which_RP (mkVP p))) ;
|
|
||||||
}
|
|
||||||
```
|
|
||||||
The lexicon is as expected:
|
|
||||||
```
|
|
||||||
instance MusicLexEng of MusicLex =
|
|
||||||
CatEng ** open ParadigmsEng in {
|
|
||||||
oper
|
|
||||||
song_N = mkN "song" ;
|
|
||||||
american_A = mkA "American" ;
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
==Lock fields==
|
|
||||||
|
|
||||||
//This section is only relevant as a guide to error messages that have to do with lock fields, and can be skipped otherwise.//
|
|
||||||
|
|
||||||
FIXME: this section may become obsolete.
|
|
||||||
|
|
||||||
When the categories of the resource grammar are used
|
|
||||||
in applications, a **lock field** is added to their linearization types.
|
|
||||||
The lock field for a category ``C`` is a record field
|
|
||||||
```
|
|
||||||
lock_C : {}
|
|
||||||
```
|
|
||||||
with the only possible value
|
|
||||||
```
|
|
||||||
lock_C = <>
|
|
||||||
```
|
|
||||||
The lock field carries no information, but its presence
|
|
||||||
makes the linearization type of ``C``
|
|
||||||
unique, so that categories
|
|
||||||
with the same implementation are not confused with each other.
|
|
||||||
(This is inspired by the ``newtype`` discipline in Haskell.)
|
|
||||||
|
|
||||||
For example, the lincats of adverbs and conjunctions are the same
|
|
||||||
in ``CatEng`` (and therefore in ``GrammarEng``, which inherits it):
|
|
||||||
```
|
|
||||||
lincat Adv = {s : Str} ;
|
|
||||||
lincat Conj = {s : Str} ;
|
|
||||||
```
|
|
||||||
But when these category symbols are used to denote their linearization
|
|
||||||
types in an application, these definitions are translated to
|
|
||||||
```
|
|
||||||
oper Adv : Type = {s : Str ; lock_Adv : {}} ;
|
|
||||||
oper Conj : Type = {s : Str} ; lock_Conj : {}} ;
|
|
||||||
```
|
|
||||||
In this way, the user of a resource grammar cannot confuse adverbs with
|
|
||||||
conjunctions. In other words, the lock fields force the type checker
|
|
||||||
to function as grammaticality checker.
|
|
||||||
|
|
||||||
When the resource grammar is ``open``ed in an application grammar,
|
|
||||||
and only functions from the resource are used in type-correct way, the
|
|
||||||
lock fields are never seen (except possibly in type error messages).
|
|
||||||
If an application grammarian has to write lock fields herself,
|
|
||||||
it is a sign that the guarantees given by the resource grammar
|
|
||||||
no longer hold. But since the resource may be incomplete, the
|
|
||||||
application grammarian may occasionally have to provide the dummy
|
|
||||||
values of lock fields (always ``<>``, the empty record).
|
|
||||||
Here is an example:
|
|
||||||
```
|
|
||||||
mkUtt : Str -> Utt ;
|
|
||||||
mkUtt s = {s = s ; lock_Utt = <>} ;
|
|
||||||
```
|
|
||||||
Currently, missing lock field produce warnings rather than errors,
|
|
||||||
but this behaviour of GF may change in future.
|
|
||||||
|
|
||||||
|
|
||||||
==Parsing with resource grammars?==
|
|
||||||
|
|
||||||
The intended use of the resource grammar is as a library for writing
|
|
||||||
application grammars. It is not designed for parsing e.g. newspaper text. There
|
|
||||||
are several reasons why this is not practical:
|
|
||||||
- Efficiency: the resource grammar uses complex data structures, in
|
|
||||||
particular, discontinuous constituents, which make parsing slow and the
|
|
||||||
parser size huge.
|
|
||||||
- Completeness: the resource grammar does not necessarily cover all rules
|
|
||||||
of the language - only enough many to be able to express everything
|
|
||||||
in one way or another.
|
|
||||||
- Lexicon: the resource grammar has a very small lexicon, only meant for test
|
|
||||||
purposes.
|
|
||||||
- Semantics: the resource grammar has very little semantic control, and may
|
|
||||||
accept strange input or deliver strange interpretations.
|
|
||||||
- Ambiguity: parsing in the resource grammar may return lots of results many
|
|
||||||
of which are implausible.
|
|
||||||
|
|
||||||
|
|
||||||
All of these problems should be solved in application grammars.
|
|
||||||
The task of resource grammars is just to take care of low-level linguistic
|
|
||||||
details such as inflection, agreement, and word order.
|
|
||||||
|
|
||||||
It is for the same reasons that resource grammars are not adequate for translation.
|
|
||||||
That the syntax API is implemented for different languages of course makes
|
|
||||||
it possible to translate via it - but there is no guarantee of translation
|
|
||||||
equivalence. Of course, the use of functor implementations such as ``MusicI``
|
|
||||||
above only extends to those cases where the syntax API does give translation
|
|
||||||
equivalence - but this must be seen as a limiting case, and bigger applications
|
|
||||||
will often use only restricted inheritance of ``MusicI``.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
=To find rules in the resource grammar library=
|
|
||||||
|
|
||||||
==Inflection paradigms==
|
|
||||||
|
|
||||||
Inflection paradigms are defined separately for each language //L//
|
|
||||||
in the module ``Paradigms``//L//. To test them, the command
|
|
||||||
``cc`` (= ``compute_concrete``)
|
|
||||||
can be used:
|
|
||||||
```
|
|
||||||
> i -retain german/ParadigmsGer.gf
|
|
||||||
|
|
||||||
> cc mkN "Schlange"
|
|
||||||
{
|
|
||||||
s : Number => Case => Str = table Number {
|
|
||||||
Sg => table Case {
|
|
||||||
Nom => "Schlange" ;
|
|
||||||
Acc => "Schlange" ;
|
|
||||||
Dat => "Schlange" ;
|
|
||||||
Gen => "Schlange"
|
|
||||||
} ;
|
|
||||||
Pl => table Case {
|
|
||||||
Nom => "Schlangen" ;
|
|
||||||
Acc => "Schlangen" ;
|
|
||||||
Dat => "Schlangen" ;
|
|
||||||
Gen => "Schlangen"
|
|
||||||
}
|
|
||||||
} ;
|
|
||||||
g : Gender = Fem
|
|
||||||
}
|
|
||||||
```
|
|
||||||
For the sake of convenience, every language implements these five paradigms:
|
|
||||||
```
|
|
||||||
oper
|
|
||||||
mkN : Str -> N ; -- regular nouns
|
|
||||||
mkA : Str -> A : -- regular adjectives
|
|
||||||
mkV : Str -> V ; -- regular verbs
|
|
||||||
mkPN : Str -> PN ; -- regular proper names
|
|
||||||
mkV2 : V -> V2 ; -- direct transitive verbs
|
|
||||||
```
|
|
||||||
It is often possible to initialize a lexicon by just using these functions,
|
|
||||||
and later revise it by using the more involved paradigms. For instance, in
|
|
||||||
German we cannot use ``mkN "Lied"`` for ``Song``, because the result would be a
|
|
||||||
Masculine noun with the plural form ``"Liede"``.
|
|
||||||
The individual ``Paradigms`` modules
|
|
||||||
tell what cases are covered by the regular heuristics.
|
|
||||||
|
|
||||||
As a limiting case, one could even initialize the lexicon for a new language
|
|
||||||
by copying the English (or some other already existing) lexicon. This would
|
|
||||||
produce language with correct grammar but with content words directly borrowed from
|
|
||||||
English - maybe not so strange in certain technical domains.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
==Syntax rules==
|
|
||||||
|
|
||||||
Syntax rules should be looked for in the module ``Constructors``.
|
|
||||||
Below this top-level module exposing overloaded constructors,
|
|
||||||
there are around 10 abstract modules, each defining constructors for
|
|
||||||
a group of one or more related categories. For instance, the module
|
|
||||||
``Noun`` defines how to construct common nouns, noun phrases, and determiners.
|
|
||||||
But these special modules are seldom or never needed by the users of the library.
|
|
||||||
|
|
||||||
TODO: when are they needed?
|
|
||||||
|
|
||||||
Browsing the libraries is helped by the gfdoc-generated HTML pages,
|
|
||||||
whose LaTeX versions are included in the present document.
|
|
||||||
|
|
||||||
|
|
||||||
==Special-purpose APIs==
|
|
||||||
|
|
||||||
To give an analogy with the well-known type setting software, GF can be compared
|
|
||||||
with TeX and the resource grammar library with LaTeX.
|
|
||||||
Just like TeX frees the author
|
|
||||||
from thinking about low-level problems of page layout, so GF frees the grammarian
|
|
||||||
from writing parsing and generation algorithms. But quite a lot of knowledge of
|
|
||||||
//how// to write grammars is still needed, and the resource grammar library helps
|
|
||||||
GF grammarians in a way similar to how the LaTeX macro package helps TeX authors.
|
|
||||||
|
|
||||||
But even LaTeX is often too detailed and low-level, and users are encouraged to
|
|
||||||
develop their own macro packages. The same applies to GF resource grammars:
|
|
||||||
the application grammarian might not need all the choices that the resource
|
|
||||||
provides, but would prefer less writing and higher-level programming.
|
|
||||||
To this end, application grammarians may want to write their own views on the
|
|
||||||
resource grammar.
|
|
||||||
|
|
||||||
|
|
||||||
==Browsing by the parser==
|
|
||||||
|
|
||||||
A method alternative to browsing library documentation is
|
|
||||||
to use the parser.
|
|
||||||
Even though parsing is not an intended end-user application
|
|
||||||
of resource grammars, it is a useful technique for application grammarians
|
|
||||||
to browse the library. To find out which resource function implements
|
|
||||||
a particular structure, one can just parse a string that exemplifies this
|
|
||||||
structure. For instance, to find out how sentences are built using
|
|
||||||
transitive verbs, write
|
|
||||||
```
|
|
||||||
> i english/LangEng.gf
|
|
||||||
|
|
||||||
> p -cat=Cl "she loves him"
|
|
||||||
PredVP (UsePron she_Pron) (ComplV2 love_V2 (UsePron he_Pron))
|
|
||||||
```
|
|
||||||
The parser returns original constructors, not overloaded ones. Overloaded
|
|
||||||
constructors can be returned, so far with experimental heuristics, by using
|
|
||||||
the grammar ``api/toplevel/OverLangEng.gf`` and a special flag:
|
|
||||||
```
|
|
||||||
> i api/toplevel/OverLangEng.gf
|
|
||||||
|
|
||||||
> p -cat=Cl -overload "she loves him"
|
|
||||||
mkCl (mkNP she_Pron) love_V2 (mkNP he_Pron)
|
|
||||||
```
|
|
||||||
Parsing with the English resource grammar has an acceptable speed, but
|
|
||||||
with most languages it takes just too much resources even to build the
|
|
||||||
parser. However, examples parsed in one language can always be linearized into
|
|
||||||
other languages:
|
|
||||||
```
|
|
||||||
> i italian/LangIta.gf
|
|
||||||
|
|
||||||
> l PredVP (UsePron she_Pron) (ComplV2 love_V2 (UsePron he_Pron))
|
|
||||||
lo ama
|
|
||||||
```
|
|
||||||
Therefore, one can use the English parser to write an Italian grammar, and also
|
|
||||||
to write a language-independent (incomplete) grammar. One can also parse strings
|
|
||||||
that are bizarre in English but the intended way of expression in another language.
|
|
||||||
For instance, the phrase for "I am hungry" in Italian is literally "I have hunger".
|
|
||||||
This can be built by parsing "I have beer" in ``OverLangEng`` and then writing
|
|
||||||
```
|
|
||||||
lin IamHungry =
|
|
||||||
let beer_N = mkN "fame" feminine
|
|
||||||
in
|
|
||||||
mkCl (mkNP i_Pron) have_V2 (mkNP massQuant beer_N)
|
|
||||||
```
|
|
||||||
which uses ``ParadigmsIta.mkN``.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
==Example-based grammar writing==
|
|
||||||
|
|
||||||
The technique of parsing with the resource grammar can be used in GF source files,
|
|
||||||
endowed with the suffix ``.gfe`` ("GF examples"). The suffix tells GF to preprocess
|
|
||||||
the file by replacing all expressions of the form
|
|
||||||
```
|
|
||||||
in Module.Cat "example string"
|
|
||||||
```
|
|
||||||
by the syntax trees obtained by parsing "example string" in ``Cat`` in ``Module``.
|
|
||||||
For instance,
|
|
||||||
```
|
|
||||||
lin IamHungry =
|
|
||||||
let beer_N = mkN "fame" feminine
|
|
||||||
in
|
|
||||||
(in LangEng.Cl "I have beer") ;
|
|
||||||
```
|
|
||||||
will result in the rule displayed in the previous section. The normal binding rules
|
|
||||||
of functional programming (and GF) guarantee that local bindings of identifiers
|
|
||||||
take precedence over constants of the same forms. Thus it is also possible to
|
|
||||||
linearize functions taking arguments in this way:
|
|
||||||
```
|
|
||||||
lin
|
|
||||||
PropKind car_N old_A = in LangEng.CN "old car" ;
|
|
||||||
```
|
|
||||||
However, the technique of example-based grammar writing has some limitations:
|
|
||||||
- Ambiguity. If a string has several parses, the first one is returned, and
|
|
||||||
it may not be the intended one. The other parses are shown in a comment, from
|
|
||||||
where they must/can be picked manually.
|
|
||||||
- Lexicality. The arguments of a function must be atomic identifiers, and are thus
|
|
||||||
not available for categories that have no lexical items.
|
|
||||||
For instance, the ``PropKind`` rule above gives the result
|
|
||||||
```
|
|
||||||
lin
|
|
||||||
PropKind car_N old_A = AdjCN (UseN car_N) (PositA old_A) ;
|
|
||||||
```
|
|
||||||
However, it is possible to write a special lexicon that gives atomic rules for
|
|
||||||
all those categories that can be used as arguments, for instance,
|
|
||||||
```
|
|
||||||
fun
|
|
||||||
cat_CN : CN ;
|
|
||||||
old_AP : AP ;
|
|
||||||
```
|
|
||||||
and then use this lexicon instead of the standard one included in ``Lang``.
|
|
||||||
|
|
||||||
|
|
||||||
@@ -1,863 +0,0 @@
|
|||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
||||||
<HTML>
|
|
||||||
<HEAD>
|
|
||||||
<META NAME="generator" CONTENT="http://txt2tags.sf.net">
|
|
||||||
<TITLE>Demonstrative Expressions and Multimodal Grammars</TITLE>
|
|
||||||
</HEAD><BODY BGCOLOR="white" TEXT="black">
|
|
||||||
<P ALIGN="center"><CENTER><H1>Demonstrative Expressions and Multimodal Grammars</H1>
|
|
||||||
<FONT SIZE="4">
|
|
||||||
<I>Author: Aarne Ranta <aarne (at) cs.chalmers.se></I><BR>
|
|
||||||
Last update: Mon Jan 9 20:29:45 2006
|
|
||||||
</FONT></CENTER>
|
|
||||||
|
|
||||||
<P></P>
|
|
||||||
<HR NOSHADE SIZE=1>
|
|
||||||
<P></P>
|
|
||||||
<UL>
|
|
||||||
<LI><A HREF="#toc1">Abstract</A>
|
|
||||||
<LI><A HREF="#toc2">Multimodal grammars</A>
|
|
||||||
<UL>
|
|
||||||
<LI><A HREF="#toc3">Representing demonstratives in semantics and grammar</A>
|
|
||||||
<LI><A HREF="#toc4">Asynchronous syntax in GF</A>
|
|
||||||
<LI><A HREF="#toc5">Example multimodal grammar: abstract syntax</A>
|
|
||||||
<LI><A HREF="#toc6">Digression: discontinuous constituents</A>
|
|
||||||
<LI><A HREF="#toc7">From grammars to dialogue systems</A>
|
|
||||||
</UL>
|
|
||||||
<LI><A HREF="#toc8">Adding multimodality to a unimodal grammar</A>
|
|
||||||
<UL>
|
|
||||||
<LI><A HREF="#toc9">The multimodal conversion</A>
|
|
||||||
<LI><A HREF="#toc10">An example of the conversion</A>
|
|
||||||
<LI><A HREF="#toc11">Multimodal conversion combinators</A>
|
|
||||||
</UL>
|
|
||||||
<LI><A HREF="#toc12">Multimodal resource grammars</A>
|
|
||||||
<UL>
|
|
||||||
<LI><A HREF="#toc13">Resource grammar API</A>
|
|
||||||
<LI><A HREF="#toc14">Multimodal API: functions for building demonstratives</A>
|
|
||||||
<LI><A HREF="#toc15">Multimodal API: functions for building sentences and phrases</A>
|
|
||||||
<LI><A HREF="#toc16">Language-independent implementation: examples</A>
|
|
||||||
<LI><A HREF="#toc17">Multimodal API: interface to unimodal expressions</A>
|
|
||||||
<LI><A HREF="#toc18">Instantiating multimodality to different languages</A>
|
|
||||||
<LI><A HREF="#toc19">Language-independent reimplementation of TramDemo</A>
|
|
||||||
<LI><A HREF="#toc20">The order problem</A>
|
|
||||||
<LI><A HREF="#toc21">A recipe for using the resource library</A>
|
|
||||||
</UL>
|
|
||||||
</UL>
|
|
||||||
|
|
||||||
<P></P>
|
|
||||||
<HR NOSHADE SIZE=1>
|
|
||||||
<P></P>
|
|
||||||
<A NAME="toc1"></A>
|
|
||||||
<H2>Abstract</H2>
|
|
||||||
<P>
|
|
||||||
This document shows a method to write grammars
|
|
||||||
in which spoken utterances are accompanied by
|
|
||||||
pointing gestures. A computer application of such
|
|
||||||
grammars are <B>multimodal dialogue systems</B>, in
|
|
||||||
which the pointing gestures are performed by
|
|
||||||
mouse clicks and movements.
|
|
||||||
</P>
|
|
||||||
<P>
|
|
||||||
After an introduction to the notions of
|
|
||||||
<B>demonstratives</B> and <B>integrated multimodality</B>,
|
|
||||||
we will show by a concrete example
|
|
||||||
how multimodal grammars can be written in GF
|
|
||||||
and how they can be used in dialogue systems.
|
|
||||||
The explanation is given in three stages:
|
|
||||||
</P>
|
|
||||||
<OL>
|
|
||||||
<LI>How to write a multimodal grammar by hand.
|
|
||||||
<LI>How to add multimodality to a unimodal grammar.
|
|
||||||
<LI>How to use a multimodal resource grammar.
|
|
||||||
</OL>
|
|
||||||
|
|
||||||
<A NAME="toc2"></A>
|
|
||||||
<H2>Multimodal grammars</H2>
|
|
||||||
<P>
|
|
||||||
<B>Demonstrative expressions</B> are an old idea. Such
|
|
||||||
expressions get their meaning from the context.
|
|
||||||
</P>
|
|
||||||
<BLOCKQUOTE>
|
|
||||||
<I>This train</I> is faster than <I>that airplane</I>.
|
|
||||||
</BLOCKQUOTE>
|
|
||||||
<P></P>
|
|
||||||
<BLOCKQUOTE>
|
|
||||||
I want to go from <I>this place</I> to <I>this place</I>.
|
|
||||||
</BLOCKQUOTE>
|
|
||||||
<P></P>
|
|
||||||
<P>
|
|
||||||
In particular, as in these examples, the meaning
|
|
||||||
can be obtained from accompanying pointing gestures.
|
|
||||||
</P>
|
|
||||||
<P>
|
|
||||||
Thus the meaning-bearing unit is neither the words nor the
|
|
||||||
gestures alone, but their combination. Demonstratives
|
|
||||||
thus provide an example of <B>integrated multimodality</B>,
|
|
||||||
as opposed to parallel multimodality. In parallel
|
|
||||||
multimodality, speech and other modes of communication
|
|
||||||
are just alternative ways to convey the same information.
|
|
||||||
</P>
|
|
||||||
<A NAME="toc3"></A>
|
|
||||||
<H3>Representing demonstratives in semantics and grammar</H3>
|
|
||||||
<P>
|
|
||||||
When formalizing the semantics of demonstratives, we can combine syntax with coordinates:
|
|
||||||
</P>
|
|
||||||
<BLOCKQUOTE>
|
|
||||||
I want to go from this place to this place
|
|
||||||
</BLOCKQUOTE>
|
|
||||||
<P></P>
|
|
||||||
<P>
|
|
||||||
is interpreted as something like
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
want(I, go, this(place,(123,45)), this(place,(98,10)))
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
Now, the same semantic value can be given in many ways, by performing
|
|
||||||
the clicks at different points of time in relation to the speech:
|
|
||||||
</P>
|
|
||||||
<BLOCKQUOTE>
|
|
||||||
I want to go from this place CLICK(123,45) to this place CLICK(98,10)
|
|
||||||
</BLOCKQUOTE>
|
|
||||||
<P></P>
|
|
||||||
<BLOCKQUOTE>
|
|
||||||
I want to go from this place to this place CLICK(123,45) CLICK(98,10)
|
|
||||||
</BLOCKQUOTE>
|
|
||||||
<P></P>
|
|
||||||
<BLOCKQUOTE>
|
|
||||||
CLICK(123,45) CLICK(98,10) I want to go from this place to this place
|
|
||||||
</BLOCKQUOTE>
|
|
||||||
<P></P>
|
|
||||||
<P>
|
|
||||||
How do we build the value compositionally in parsing?
|
|
||||||
Traditional parsing is sequential: its input is a string of tokens.
|
|
||||||
It works for demonstratives only if the pointing is adjacent to
|
|
||||||
the spoken expression. In the actual input, the demonstrative word
|
|
||||||
can be separated from the accompanying click by other words. The two
|
|
||||||
can also be simultaneous.
|
|
||||||
</P>
|
|
||||||
<A NAME="toc4"></A>
|
|
||||||
<H3>Asynchronous syntax in GF</H3>
|
|
||||||
<P>
|
|
||||||
What we need is a notion of <B>asynchronous parsing</B>, as opposed to
|
|
||||||
sequential parsing (where demonstrative words and clicks must be
|
|
||||||
adjacent).
|
|
||||||
</P>
|
|
||||||
<P>
|
|
||||||
We can implement asynchronous parsin in GF by exploiting the generality
|
|
||||||
of <B>linearization types</B>. A linearization type is the type of
|
|
||||||
the <B>concrete syntax objects</B> assigned to semantic values.
|
|
||||||
What a GF grammar defines is a relation
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
abstract syntax trees <---> concrete syntax objects
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
When modelling context-free grammar in GF,
|
|
||||||
the concrete syntax objects are just strings.
|
|
||||||
But they can be more structured objects as well - in general, they are
|
|
||||||
<B>records</B> of different kinds of objects. For example,
|
|
||||||
a demonstrative expression can be linearized into a record of two strings.
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
{s = "this place" ;
|
|
||||||
this place (coord 123 45) <---> p = "(123,45)"
|
|
||||||
}
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
The record
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
{s = "I want to go from this place to this place" ;
|
|
||||||
p = "(123,45) (98,10"
|
|
||||||
}
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
represents any combination of the sentence and the clicks, as long
|
|
||||||
as the clicks appear in this order.
|
|
||||||
</P>
|
|
||||||
<A NAME="toc5"></A>
|
|
||||||
<H3>Example multimodal grammar: abstract syntax</H3>
|
|
||||||
<P>
|
|
||||||
A simple example of a multimodal GF grammar is the one called
|
|
||||||
the Tram Demo grammar. It was written by Björn Bringert within
|
|
||||||
the TALK project as a part of a dialogue system that
|
|
||||||
deals with queries about tram timetables. The system interprets
|
|
||||||
a speech input in combination with mouse clicks on a digital map.
|
|
||||||
</P>
|
|
||||||
<P>
|
|
||||||
The abstract syntax of (a minimal fragment of) the Tram Demo
|
|
||||||
grammar is
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
cat
|
|
||||||
Input, Dep, Dest, Click ;
|
|
||||||
fun
|
|
||||||
GoFromTo : Dep -> Dest -> Input ; -- "I want to go from x to y"
|
|
||||||
DepHere : Click -> Dep ; -- "from here" with click
|
|
||||||
DestHere : Click -> Dest ; -- "to here" with click
|
|
||||||
|
|
||||||
CCoord : Int -> Int -> Click ; -- click coordinates
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
An English concrete syntax of the grammar is
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
lincat
|
|
||||||
Input, Dep, Dest = {s : Str ; p : Str} ;
|
|
||||||
Click = {p : Str} ;
|
|
||||||
|
|
||||||
lin
|
|
||||||
GoFromTo x y = {s = ["I want to go"] ++ x.s ++ y.s ; p = x.p ++ y.p} ;
|
|
||||||
DepHere c = {s = ["from here"] ; p = c.p} ;
|
|
||||||
DestHere c = {s = ["to here"] ; p = c.p} ;
|
|
||||||
|
|
||||||
CCoord x y = {p = "(" ++ x.s ++ "," ++ y.s ++ ")"} ;
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
When the grammar is used in the actual system, standard parsing methods
|
|
||||||
are used for interpreting the integrated speech and click input.
|
|
||||||
Parsing appears on two levels: the speech input parsing
|
|
||||||
performed by the Nuance speech recognition program (without the clicks),
|
|
||||||
and the semantics-yielding parser sending input to the dialogue manager.
|
|
||||||
The latter parser just attaches the clicks to the speech input. The order
|
|
||||||
of the clicks is preserved, and the parser can hence associate each of
|
|
||||||
the clicks with proper demonstratives. Here is the grammar used in the
|
|
||||||
two parsing phases.
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
cat
|
|
||||||
Query, -- whole content
|
|
||||||
Speech ; -- speech only
|
|
||||||
fun
|
|
||||||
QueryInput : Input -> Query ; -- the whole content shown
|
|
||||||
SpeechInput : Input -> Speech ; -- only the speech shown
|
|
||||||
|
|
||||||
lincat
|
|
||||||
Query, Speech = {s : Str} ;
|
|
||||||
lin
|
|
||||||
QueryInput i = {s = i.s ++ ";" ++ i.p} ;
|
|
||||||
SpeechInput i = {s = i.s} ;
|
|
||||||
</PRE>
|
|
||||||
<P></P>
|
|
||||||
<A NAME="toc6"></A>
|
|
||||||
<H3>Digression: discontinuous constituents</H3>
|
|
||||||
<P>
|
|
||||||
The GF representation of integrated multimodality is
|
|
||||||
similar to the representation of <B>discontinous constituents</B>.
|
|
||||||
For instance, assume <I>has arrived</I> is a verb phrase in English,
|
|
||||||
which can be used both in declarative sentences and questions,
|
|
||||||
</P>
|
|
||||||
<BLOCKQUOTE>
|
|
||||||
she <I>has arrived</I>
|
|
||||||
</BLOCKQUOTE>
|
|
||||||
<P></P>
|
|
||||||
<BLOCKQUOTE>
|
|
||||||
<I>has</I> she <I>arrived</I>
|
|
||||||
</BLOCKQUOTE>
|
|
||||||
<P></P>
|
|
||||||
<P>
|
|
||||||
In the question, the two words are separated from each other. If
|
|
||||||
<I>has arrived</I> is a constituent of the question, it is thus discontinuous.
|
|
||||||
To represent such constituents in GF, records can be used:
|
|
||||||
we split verb phrases (<CODE>VP</CODE>) into a finite and infinitive part.
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
lincat VP = {fin, inf : Str} ;
|
|
||||||
|
|
||||||
lin Indic np vp = {s = np.s ++ vp.fin ++ vp.inf} ;
|
|
||||||
lin Quest np vp = {s = vp.fin ++ np.s ++ vp.inf} ;
|
|
||||||
</PRE>
|
|
||||||
<P></P>
|
|
||||||
<A NAME="toc7"></A>
|
|
||||||
<H3>From grammars to dialogue systems</H3>
|
|
||||||
<P>
|
|
||||||
The general recipe for using GF when building dialogue systems
|
|
||||||
is to write a grammar with the following components:
|
|
||||||
</P>
|
|
||||||
<UL>
|
|
||||||
<LI>The abstract syntax defines the semantics (the "ontology")
|
|
||||||
of the domain of the system.
|
|
||||||
<LI>The concrete syntaxes define alternative modes of input and output.
|
|
||||||
</UL>
|
|
||||||
|
|
||||||
<P>
|
|
||||||
The engineering advantages of this approach have to do partly with
|
|
||||||
the declarativity of the description, partly with the tools provided
|
|
||||||
by GF to derive different components of the system:
|
|
||||||
</P>
|
|
||||||
<UL>
|
|
||||||
<LI>The type checker guarantees that all the input and output
|
|
||||||
modes match with the ontology.
|
|
||||||
<LI>The grammar compiler generates parsers for each input grammar
|
|
||||||
and generators for each output grammar.
|
|
||||||
<LI>Translators between GF's abstract syntax and other ontology
|
|
||||||
description languages enable communication with different
|
|
||||||
kinds of dialogue managers and cover e.g. Prolog terms and XML objects.
|
|
||||||
<LI>Translators from GF's concrete syntax to speech recognition formats
|
|
||||||
make it possible to generate e.g. Nuance grammars and ATK language
|
|
||||||
models.
|
|
||||||
</UL>
|
|
||||||
|
|
||||||
<P>
|
|
||||||
An example of this process is Björn Bringert's TramDemo.
|
|
||||||
More recently, grammars have been integrated to the GoDiS dialogue
|
|
||||||
manager by Prolog representations of abstract syntax.
|
|
||||||
</P>
|
|
||||||
<A NAME="toc8"></A>
|
|
||||||
<H2>Adding multimodality to a unimodal grammar</H2>
|
|
||||||
<P>
|
|
||||||
This section gives a recipe for making any unimodal grammar
|
|
||||||
multimodal, by adding pointing gestures to chosen expressions. The recipe
|
|
||||||
guarantees that the resulting grammar remains semantically well-formed,
|
|
||||||
i.e. type correct.
|
|
||||||
</P>
|
|
||||||
<A NAME="toc9"></A>
|
|
||||||
<H3>The multimodal conversion</H3>
|
|
||||||
<P>
|
|
||||||
The <B>multimodal conversion</B> of a grammar consists of seven
|
|
||||||
steps, of which the first is always the same, the second
|
|
||||||
involves a decision, and the rest are derivative:
|
|
||||||
</P>
|
|
||||||
<OL>
|
|
||||||
<LI>Add the category <CODE>`Point`</CODE> with a standard linearization type.
|
|
||||||
<PRE>
|
|
||||||
cat Point ;
|
|
||||||
lincat Point = {point : Str} ;
|
|
||||||
</PRE>
|
|
||||||
<LI>(Decision) Decide which constructors are demonstrative, i.e. take
|
|
||||||
a pointing gesture as an argument. Add a <CODE>Point`</CODE> as their last argument.
|
|
||||||
The new type signatures for such constructors <I>d</I> have the form
|
|
||||||
<PRE>
|
|
||||||
fun d : ... -> Point -> D
|
|
||||||
</PRE>
|
|
||||||
<LI>(Derivative) Add a <CODE>point</CODE> field to the linearization type <I>L</I> of any
|
|
||||||
demonstrative category <I>D</I>, i.e. a category that has at least one demonstrative
|
|
||||||
constructor:
|
|
||||||
<PRE>
|
|
||||||
lincat D = L ** {point : Str} ;
|
|
||||||
</PRE>
|
|
||||||
<LI>(Derivative) If some other category <I>C</I> has a constructor <I>d</I> that takes
|
|
||||||
demonstratives as arguments, make it demonstrative by adding a <I>point</I> field
|
|
||||||
to its linearization type.
|
|
||||||
<LI>(Derivative) Store the <CODE>point</CODE> field in the linearization <I>t</I> of any
|
|
||||||
constructor <I>d</I> that has been made demonstrative:
|
|
||||||
<PRE>
|
|
||||||
lin d x1 ... xn p = t x1 ... xn ** {point = p.point} ;
|
|
||||||
</PRE>
|
|
||||||
<LI>(Derivative) For each constructor <I>f</I> that takes demonstratives <I>D_1,...,D_n</I>
|
|
||||||
as arguments, collect the <I>point</I> fields of the arguments in the <I>point</I>
|
|
||||||
field of the value:
|
|
||||||
<PRE>
|
|
||||||
lin f x_1 ... x_m =
|
|
||||||
t x_1 ... x_m ** {point = x_d1.point ++ ... ++ x_dn.point} ;
|
|
||||||
</PRE>
|
|
||||||
Make sure that the pointings <CODE>x_d1.point ... x_dn.point</CODE> are concatenated
|
|
||||||
in the same order as the arguments appear in the <I>linearization</I> <I>t</I>,
|
|
||||||
which is not necessarily the same as the abstract argument order.
|
|
||||||
<LI>(Derivative) To preserve type correctness, add an empty
|
|
||||||
<CODE>point</CODE> field to the linearization <I>t</I> of any
|
|
||||||
constructor <I>c</I> of a demonstrative category:
|
|
||||||
<PRE>
|
|
||||||
lin c x1 ... xn = t x1 ... xn ** {point = []} ;
|
|
||||||
</PRE>
|
|
||||||
</OL>
|
|
||||||
|
|
||||||
<A NAME="toc10"></A>
|
|
||||||
<H3>An example of the conversion</H3>
|
|
||||||
<P>
|
|
||||||
Start with a Tram Demo grammar with no demonstratives, but just
|
|
||||||
tram stop names and the indexical <I>here</I> (interpreted as e.g. the user's
|
|
||||||
standing place).
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
cat
|
|
||||||
Input, Dep, Dest, Name ;
|
|
||||||
fun
|
|
||||||
GoFromTo : Dep -> Dest -> Input ;
|
|
||||||
DepHere : Dep ;
|
|
||||||
DestHere : Dest ;
|
|
||||||
DepName : Name -> Dep ;
|
|
||||||
DestName : Name -> Dest ;
|
|
||||||
|
|
||||||
Almedal : Name ;
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
A unimodal English concrete syntax of the grammar is
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
lincat
|
|
||||||
Input, Dep, Dest, Name = {s : Str} ;
|
|
||||||
|
|
||||||
lin
|
|
||||||
GoFromTo x y = {s = ["I want to go"] ++ x.s ++ y.s} ;
|
|
||||||
DepHere = {s = ["from here"]} ;
|
|
||||||
DestHere = {s = ["to here"]} ;
|
|
||||||
DepName n = {s = ["from"] ++ n.s} ;
|
|
||||||
DestName n = {s = ["to"] ++ n.s} ;
|
|
||||||
|
|
||||||
Almedal = {s = "Almedal"} ;
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
Let us follow the steps of the recipe.
|
|
||||||
</P>
|
|
||||||
<OL>
|
|
||||||
<LI>We add the category <CODE>Point</CODE> and its linearization type.
|
|
||||||
<LI>We decide that <CODE>DepHere</CODE> and <CODE>DestHere</CODE> involve a pointing gesture.
|
|
||||||
<LI>We add <CODE>point</CODE> to the linearization types of <CODE>Dep</CODE> and <CODE>Dest</CODE>.
|
|
||||||
<LI>Therefore, also add <CODE>point</CODE> to <CODE>Input</CODE>. (But <CODE>Name</CODE> remains unimodal.)
|
|
||||||
<LI>Add <CODE>p.point</CODE> to the linearizations of <CODE>DepHere</CODE> and <CODE>DestHere</CODE>.
|
|
||||||
<LI>Concatenate the points of the arguments of <CODE>GoFromTo</CODE>.
|
|
||||||
<LI>Add an empty <CODE>point</CODE> to <CODE>DepName</CODE> and <CODE>DestName</CODE>.
|
|
||||||
</OL>
|
|
||||||
|
|
||||||
<P>
|
|
||||||
In the resulting grammar, one category is added and
|
|
||||||
two functions are changed in the abstract syntax (annotated by the step numbers):
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
cat
|
|
||||||
Point ; -- 1
|
|
||||||
fun
|
|
||||||
DepHere : Point -> Dep ; -- 2
|
|
||||||
DestHere : Point -> Dest ; -- 2
|
|
||||||
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
The concrete syntax in its entirety looks as follows
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
lincat
|
|
||||||
Dep, Dest = {s : Str ; point : Str} ; -- 3
|
|
||||||
Input = {s : Str ; point : Str} ; -- 4
|
|
||||||
Name = {s : Str} ;
|
|
||||||
Point = {point : Str} ; -- 1
|
|
||||||
lin
|
|
||||||
GoFromTo x y = {s = ["I want to go"] ++ x.s ++ y.s ; -- 6
|
|
||||||
point = x.point ++ y.point
|
|
||||||
} ;
|
|
||||||
DepHere p = {s = ["from here"] ; -- 5
|
|
||||||
point = p.point
|
|
||||||
} ;
|
|
||||||
DestHere p = {s = ["to here"] : -- 5
|
|
||||||
point = p.point
|
|
||||||
} ;
|
|
||||||
DepName n = {s = ["from"] ++ n.s ; -- 7
|
|
||||||
point = []
|
|
||||||
} ;
|
|
||||||
DestName n = {s = ["to"] ++ n.s ; -- 7
|
|
||||||
point = []
|
|
||||||
} ;
|
|
||||||
Almedal = {s = "Almedal"} ;
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
What we need in addition, to use the grammar in applications, are
|
|
||||||
</P>
|
|
||||||
<OL>
|
|
||||||
<LI>Constructors for <CODE>Point</CODE>, e.g. coordinate pairs.
|
|
||||||
<LI>Top-level categories, like <CODE>Query</CODE> and <CODE>Speech</CODE> in the original.
|
|
||||||
</OL>
|
|
||||||
|
|
||||||
<P>
|
|
||||||
But their proper place is probably in another grammar module, so that
|
|
||||||
the core Tram Demo grammar can be used in different systems e.g.
|
|
||||||
encoding clicks in different ways.
|
|
||||||
</P>
|
|
||||||
<A NAME="toc11"></A>
|
|
||||||
<H3>Multimodal conversion combinators</H3>
|
|
||||||
<P>
|
|
||||||
GF is a functional programming language, and we exploit this
|
|
||||||
by providing a set of combinators that makes the multimodal conversion easier
|
|
||||||
and clearer. We start with the type of sequences of pointing gestures.
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
Point : Type = {point : Str} ;
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
To make a record type multimodal is to extend it with <CODE>Point</CODE>.
|
|
||||||
The record extension operator <CODE>**</CODE> is needed here.
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
Dem : Type -> Type = \t -> t ** Point ;
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
To construct, use, and concatenate pointings:
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
mkPoint : Str -> Point = \s -> {point = s} ;
|
|
||||||
|
|
||||||
noPoint : Point = mkPoint [] ;
|
|
||||||
|
|
||||||
point : Point -> Str = \p -> p.point ;
|
|
||||||
|
|
||||||
concatPoint : (x,y : Point) -> Point = \x,y ->
|
|
||||||
mkPoint (point x ++ point y) ;
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
Finally, to add pointing to a record, with the limiting case of no demonstrative needed.
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
mkDem : (t : Type) -> t -> Point -> Dem t = \_,x,s -> x ** s ;
|
|
||||||
|
|
||||||
nonDem : (t : Type) -> t -> Dem t = \t,x -> mkDem t x noPoint ;
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
Let us rewrite the Tram Demo grammar by using these combinators:
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
oper
|
|
||||||
SS : Type = {s : Str} ;
|
|
||||||
lincat
|
|
||||||
Input, Dep, Dest = Dem SS ;
|
|
||||||
Name = SS ;
|
|
||||||
|
|
||||||
lin
|
|
||||||
GoFromTo x y = {s = ["I want to go"] ++ x.s ++ y.s} **
|
|
||||||
concatPoint x y ;
|
|
||||||
DepHere = mkDem SS {s = ["from here"]} ;
|
|
||||||
DestHere = mkDem SS {s = ["to here"]} ;
|
|
||||||
DepName n = nonDem SS {s = ["from"] ++ n.s} ;
|
|
||||||
DestName n = nonDem SS {s = ["to"] ++ n.s} ;
|
|
||||||
|
|
||||||
Almedal = {s = "Almedal"} ;
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
The type synonym <CODE>SS</CODE> is introduced to make the combinator applications
|
|
||||||
concise. Notice the use of partial application in <CODE>DepHere</CODE> and
|
|
||||||
<CODE>DestHere</CODE>; an equivalent way to write is
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
DepHere p = mkDem SS {s = ["from here"]} p ;
|
|
||||||
</PRE>
|
|
||||||
<P></P>
|
|
||||||
<A NAME="toc12"></A>
|
|
||||||
<H2>Multimodal resource grammars</H2>
|
|
||||||
<P>
|
|
||||||
The main advantage of using GF when building dialogue systems is
|
|
||||||
that various components of the system
|
|
||||||
can be automatically generated from GF grammars.
|
|
||||||
Writing these grammars, however, can still be a considerable
|
|
||||||
task. A case in point are multilingual systems:
|
|
||||||
how to localize e.g. a system built in a car to
|
|
||||||
the languages of all those customers to whom the
|
|
||||||
car is sold? This problem has been the main focus of
|
|
||||||
GF for some years, and the solution on which most work has been
|
|
||||||
done is the development of <B>resource grammar libraries</B>.
|
|
||||||
These libraries work in the same way as program libraries
|
|
||||||
in software engineering, enabling a division of labour
|
|
||||||
between linguists and domain experts.
|
|
||||||
</P>
|
|
||||||
<P>
|
|
||||||
One of the goals in the resource grammars of different
|
|
||||||
languages has been to provide a <B>language-independent API</B>,
|
|
||||||
which makes the same resource grammar functions available for
|
|
||||||
different languages. For instance, the categories
|
|
||||||
<CODE>S</CODE>, <CODE>NP</CODE>, and <CODE>VP</CODE> are available in all of the
|
|
||||||
10 languages currently supported, and so is the function
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
PredVP : NP -> VP -> S
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
which corresponds to the rule <CODE>S -> NP VP</CODE> in phrase
|
|
||||||
structure grammar. However, there are several levels of abstraction
|
|
||||||
between the function <CODE>PredVP</CODE> and the phrase structure rule,
|
|
||||||
because the rule is implemented in so different ways in different
|
|
||||||
languages. In particular, discontinuous constituents are needed in
|
|
||||||
various degrees to make the rule work in different languages.
|
|
||||||
</P>
|
|
||||||
<P>
|
|
||||||
Now, dealing with discontinuous constituents is one of the demanding
|
|
||||||
aspects of multilingual grammar writing that the resource grammar
|
|
||||||
API is designed to hide. But the proposed treatment of integrated
|
|
||||||
multimodality is heavily dependent on similar things. What can we
|
|
||||||
do to make multimodal grammars easier to write (for different languages)?
|
|
||||||
There are two orthogonal answers:
|
|
||||||
</P>
|
|
||||||
<OL>
|
|
||||||
<LI>Use resource grammars to write a unimodal dialogue grammar and
|
|
||||||
then apply the multimodal
|
|
||||||
conversion to manually chosen parts.
|
|
||||||
<LI>Use <B>multimodal resource grammars</B> to derive multimodal
|
|
||||||
dialogue system grammars directly.
|
|
||||||
</OL>
|
|
||||||
|
|
||||||
<P>
|
|
||||||
The multimodal resource grammar library has been obtained from
|
|
||||||
the unimodal one by applying the multimodal conversion manually.
|
|
||||||
In addition, the API has been simplified
|
|
||||||
by leaving out structures needed in written technical documents
|
|
||||||
(the original application area of GF) but not in spoken dialogue.
|
|
||||||
</P>
|
|
||||||
<P>
|
|
||||||
In the following subsections, we will show a part of the
|
|
||||||
multimodal resource grammar API, limited to a fragment that
|
|
||||||
is needed to get the main ideas and to reimplement the
|
|
||||||
Tram Demo grammar. The reimplementation shows one more advantage
|
|
||||||
of the resource grammar approach: dialogue systems can be
|
|
||||||
automatically instantiated to different languages.
|
|
||||||
</P>
|
|
||||||
<A NAME="toc13"></A>
|
|
||||||
<H3>Resource grammar API</H3>
|
|
||||||
<P>
|
|
||||||
The resource grammar API has three main kinds of entries:
|
|
||||||
</P>
|
|
||||||
<OL>
|
|
||||||
<LI>Language-independent linguistic structures (``linguistic ontology''), e.g.
|
|
||||||
<PRE>
|
|
||||||
PredVP : NP -> VP -> S ; -- "Mary helps him"
|
|
||||||
</PRE>
|
|
||||||
<LI>Language-specific syntax extensions, e.g. Swedish and German fronting
|
|
||||||
topicalization
|
|
||||||
<PRE>
|
|
||||||
TopicObj : NP -> VP -> S ; -- "honom hjälper Mary"
|
|
||||||
</PRE>
|
|
||||||
<LI>Language-specific lexical constructors, e.g. Germanic <I>Ablaut</I> patterns
|
|
||||||
<PRE>
|
|
||||||
irregV : (sing,sang,sung : Str) -> V ;
|
|
||||||
</PRE>
|
|
||||||
</OL>
|
|
||||||
|
|
||||||
<P>
|
|
||||||
The first two kinds of entries are <CODE>cat</CODE> and <CODE>fun</CODE> definitions
|
|
||||||
in an abstract syntax. The multimodal, restricted API has
|
|
||||||
e.g. the following categories. Their names are obtained from
|
|
||||||
the corresponding unimodal categories by prefixing <CODE>M</CODE>.
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
MS ; -- multimodal sentence or question
|
|
||||||
MQS ; -- multimodal wh question
|
|
||||||
MImp ; -- multimodal imperative
|
|
||||||
MVP ; -- multimodal verb phrase
|
|
||||||
MNP ; -- multimodal (demonstrative) noun phrase
|
|
||||||
MAdv ; -- multimodal (demonstrative) adverbial
|
|
||||||
|
|
||||||
Point ; -- pointing gesture
|
|
||||||
</PRE>
|
|
||||||
<P></P>
|
|
||||||
<A NAME="toc14"></A>
|
|
||||||
<H3>Multimodal API: functions for building demonstratives</H3>
|
|
||||||
<P>
|
|
||||||
Demonstrative pronouns can be used both as noun phrases and
|
|
||||||
as determiners.
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
this_MNP : Point -> MNP ; -- this
|
|
||||||
thisDet_MNP : CN -> Point -> MNP ; -- this car
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
There are also demonstrative adverbs, and prepositions give
|
|
||||||
a productive way to build more adverbs.
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
here_MAdv : Point -> MAdv ; -- here
|
|
||||||
here7from_MAdv : Point -> MAdv ; -- from here
|
|
||||||
|
|
||||||
MPrepNP : Prep -> MNP -> MAdv ; -- in this car
|
|
||||||
</PRE>
|
|
||||||
<P></P>
|
|
||||||
<A NAME="toc15"></A>
|
|
||||||
<H3>Multimodal API: functions for building sentences and phrases</H3>
|
|
||||||
<P>
|
|
||||||
A handful of predication rules construct sentences, questions, and imperatives.
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
MPredVP : MNP -> MVP -> MS ; -- this plane flies here
|
|
||||||
MQPredVP : MNP -> MVP -> MQS ; -- does this plane fly here
|
|
||||||
MQuestVP : IP -> MVP -> MQS ; -- who flies here
|
|
||||||
MImpVP : MVP -> MImp ; -- fly here!
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
Verb phrases are constructed from verbs (inherited as such from
|
|
||||||
the unimodal API) by providing their complements.
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
MUseV : V -> MVP ; -- flies
|
|
||||||
MComplV2 : V2 -> MNP -> MVP ; -- takes this
|
|
||||||
MComplVV : VV -> MVP -> MVP ; -- wants to take this
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
A multimodal adverb can be attached to a verb phrase.
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
MAdvVP : MVP -> MAdv -> MVP ; -- flies here
|
|
||||||
</PRE>
|
|
||||||
<P></P>
|
|
||||||
<A NAME="toc16"></A>
|
|
||||||
<H3>Language-independent implementation: examples</H3>
|
|
||||||
<P>
|
|
||||||
The implementation makes heavy use of the multimodal conversion
|
|
||||||
combinators. It adds a <CODE>point</CODE> field to whatever the implementation of the unimodal
|
|
||||||
category is in any language. Thus, for example
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
lincat
|
|
||||||
MVP = Dem VP ;
|
|
||||||
MNP = Dem NP ;
|
|
||||||
MAdv = Dem Adv ;
|
|
||||||
|
|
||||||
lin
|
|
||||||
this_MNP = mkDem NP this_NP ;
|
|
||||||
-- i.e. this_MNP p = this_NP ** {point = p.point} ;
|
|
||||||
|
|
||||||
MComplV2 verb obj = mkDem VP (ComplV2 verb obj) obj ;
|
|
||||||
|
|
||||||
MAdvVP vp adv = mkDem VP (AdvVP vp adv) (concatPoint vp adv) ;
|
|
||||||
</PRE>
|
|
||||||
<P></P>
|
|
||||||
<A NAME="toc17"></A>
|
|
||||||
<H3>Multimodal API: interface to unimodal expressions</H3>
|
|
||||||
<P>
|
|
||||||
Using nondemonstrative expressions as demonstratives:
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
DemNP : NP -> MNP ;
|
|
||||||
DemAdv : Adv -> MAdv ;
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
Building top-level phrases:
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
PhrMS : Pol -> MS -> Phr ;
|
|
||||||
PhrMS : Pol -> MS -> Phr ;
|
|
||||||
PhrMQS : Pol -> MQS -> Phr ;
|
|
||||||
PhrMImp : Pol -> MImp -> Phr ;
|
|
||||||
</PRE>
|
|
||||||
<P></P>
|
|
||||||
<A NAME="toc18"></A>
|
|
||||||
<H3>Instantiating multimodality to different languages</H3>
|
|
||||||
<P>
|
|
||||||
The implementation above has only used the resource grammar API,
|
|
||||||
not the concrete implementations. The library <CODE>Demonstrative</CODE>
|
|
||||||
is a <B>parametrized module</B>, also called a <B>functor</B>, which
|
|
||||||
has the following structure
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
incomplete concrete DemonstrativeI of Demonstrative =
|
|
||||||
Cat, TenseX ** open Test, Structural in {
|
|
||||||
|
|
||||||
-- lincat and lin rules
|
|
||||||
|
|
||||||
}
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
It can be <B>instantiated</B> to different languages as follows.
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
concrete DemonstrativeEng of Demonstrative =
|
|
||||||
CatEng, TenseX ** DemonstrativeI with
|
|
||||||
(Test = TestEng),
|
|
||||||
(Structural = StructuralEng) ;
|
|
||||||
|
|
||||||
concrete DemonstrativeSwe of Demonstrative =
|
|
||||||
CatSwe, TenseX ** DemonstrativeI with
|
|
||||||
(Test = TestSwe),
|
|
||||||
(Structural = StructuralSwe) ;
|
|
||||||
</PRE>
|
|
||||||
<P></P>
|
|
||||||
<A NAME="toc19"></A>
|
|
||||||
<H3>Language-independent reimplementation of TramDemo</H3>
|
|
||||||
<P>
|
|
||||||
Again using the functor idea, we reimplement <CODE>TramDemo</CODE>
|
|
||||||
as follows:
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
incomplete concrete TramI of Tram = open Multimodal in {
|
|
||||||
|
|
||||||
lincat
|
|
||||||
Query = Phr ; Input = MS ;
|
|
||||||
Dep, Dest = MAdv ; Click = Point ;
|
|
||||||
lin
|
|
||||||
QInput = PhrMS PPos ;
|
|
||||||
|
|
||||||
GoFromTo x y =
|
|
||||||
MPredVP (DemNP (UsePron i_Pron))
|
|
||||||
(MAdvVP (MAdvVP (MComplVV want_VV (MUseV go_V)) x) y) ;
|
|
||||||
|
|
||||||
DepHere = here7from_MAdv ;
|
|
||||||
DestHere = here7to_MAdv ;
|
|
||||||
DepName s = MPrepNP from_Prep (DemNP (UsePN (SymbPN (MkSymb s)))) ;
|
|
||||||
DestName s = MPrepNP to_Prep (DemNP (UsePN (SymbPN (MkSymb s)))) ;
|
|
||||||
|
|
||||||
</PRE>
|
|
||||||
<P>
|
|
||||||
Then we can instantiate this to all languages for which
|
|
||||||
the <CODE>Multimodal</CODE> API has been implemented:
|
|
||||||
</P>
|
|
||||||
<PRE>
|
|
||||||
concrete TramEng of Tram = TramI with
|
|
||||||
(Multimodal = MultimodalEng) ;
|
|
||||||
|
|
||||||
concrete TramSwe of Tram = TramI with
|
|
||||||
(Multimodal = MultimodalSwe) ;
|
|
||||||
|
|
||||||
concrete TramFre of Tram = TramI with
|
|
||||||
(Multimodal = MultimodalFre) ;
|
|
||||||
</PRE>
|
|
||||||
<P></P>
|
|
||||||
<A NAME="toc20"></A>
|
|
||||||
<H3>The order problem</H3>
|
|
||||||
<P>
|
|
||||||
It was pointed out in the section on the multimodal conversion that
|
|
||||||
the concrete word order may be different from the abstract one,
|
|
||||||
and vary between different languages. For instance, Swedish
|
|
||||||
topicalization
|
|
||||||
</P>
|
|
||||||
<BLOCKQUOTE>
|
|
||||||
Det här tåget vill den här kunden inte ta.
|
|
||||||
</BLOCKQUOTE>
|
|
||||||
<P></P>
|
|
||||||
<P>
|
|
||||||
(``this train, this customer doesn't want to take'') may well have
|
|
||||||
an abstract syntax of a form in which the customer appears
|
|
||||||
before the train.
|
|
||||||
</P>
|
|
||||||
<P>
|
|
||||||
This is a problem for the implementor of the resource grammar.
|
|
||||||
It means that some parts of the resource must be written manually
|
|
||||||
and not as a functor.
|
|
||||||
However, the <I>user</I> of the resource can safely
|
|
||||||
ignore the word order problem, if it is correctly dealt with in
|
|
||||||
the resource.
|
|
||||||
</P>
|
|
||||||
<A NAME="toc21"></A>
|
|
||||||
<H3>A recipe for using the resource library</H3>
|
|
||||||
<P>
|
|
||||||
When starting to develop resource grammars, we believed they
|
|
||||||
would be all that
|
|
||||||
an application grammarian needs to write a concrete syntax.
|
|
||||||
However, experience has shown that it can be tough to start
|
|
||||||
grammar development in this way: selecting functions from
|
|
||||||
a resource API requires more abstract thinking than just
|
|
||||||
writing strings, and its take longer to reach testable
|
|
||||||
results. The most light-weight format is
|
|
||||||
maybe to start with context-free grammars (which notation is
|
|
||||||
also supported by GF). Context-free grammars that
|
|
||||||
give acceptable even though over-generating
|
|
||||||
results for languages like English are quick to produce.
|
|
||||||
</P>
|
|
||||||
<P>
|
|
||||||
The experience has led to the following
|
|
||||||
steps for grammar development. While giving the work
|
|
||||||
a quick start, this recipe
|
|
||||||
increases abstraction at a later level, when it is time to
|
|
||||||
to localize the grammar to different languages.
|
|
||||||
If context-free notation is used, steps 1 and 2 can
|
|
||||||
be merged.
|
|
||||||
</P>
|
|
||||||
<OL>
|
|
||||||
<LI>Encode domain ontology in and abstract syntax, <CODE>Domain</CODE>.
|
|
||||||
<LI>Write a rough concrete syntax in English, <CODE>DomainRough</CODE>.
|
|
||||||
This can be oversimplified and overgenerating.
|
|
||||||
<LI>Reimplement by using the resource library, and build a functor <CODE>DomainI</CODE>.
|
|
||||||
This can helped by <B>example-based grammar writing</B>, where
|
|
||||||
the examples are generated from <CODE>DomainRough</CODE>.
|
|
||||||
<LI>Instantiate the functor <CODE>DomainI</CODE> to different languages,
|
|
||||||
and test the results by generating linearizations.
|
|
||||||
<LI>If some rule doesn't satisfy in some language, use the resource in
|
|
||||||
a different way for that case (<B>compile-time transfer</B>).
|
|
||||||
</OL>
|
|
||||||
|
|
||||||
|
|
||||||
<!-- html code generated by txt2tags 2.3 (http://txt2tags.sf.net) -->
|
|
||||||
<!-- cmdline: txt2tags -\-toc multimodal.txt -->
|
|
||||||
</BODY></HTML>
|
|
||||||
@@ -1,728 +0,0 @@
|
|||||||
Demonstrative Expressions and Multimodal Grammars
|
|
||||||
Author: Aarne Ranta <aarne (at) cs.chalmers.se>
|
|
||||||
Last update: %%date(%c)
|
|
||||||
|
|
||||||
% NOTE: this is a txt2tags file.
|
|
||||||
% Create an html file from this file using:
|
|
||||||
% txt2tags --toc multimodal.txt
|
|
||||||
|
|
||||||
% Create a latex file from this file using:
|
|
||||||
% txt2tags -ttex multimodal.txt
|
|
||||||
|
|
||||||
%!target:html
|
|
||||||
|
|
||||||
|
|
||||||
==Abstract==
|
|
||||||
|
|
||||||
This document shows a method to write grammars
|
|
||||||
in which spoken utterances are accompanied by
|
|
||||||
pointing gestures. A computer application of such
|
|
||||||
grammars are **multimodal dialogue systems**, in
|
|
||||||
which the pointing gestures are performed by
|
|
||||||
mouse clicks and movements.
|
|
||||||
|
|
||||||
After an introduction to the notions of
|
|
||||||
**demonstratives** and **integrated multimodality**,
|
|
||||||
we will show by a concrete example
|
|
||||||
how multimodal grammars can be written in GF
|
|
||||||
and how they can be used in dialogue systems.
|
|
||||||
The explanation is given in three stages:
|
|
||||||
|
|
||||||
+ How to write a multimodal grammar by hand.
|
|
||||||
+ How to add multimodality to a unimodal grammar.
|
|
||||||
+ How to use a multimodal resource grammar.
|
|
||||||
|
|
||||||
|
|
||||||
==Multimodal grammars==
|
|
||||||
|
|
||||||
**Demonstrative expressions** are an old idea. Such
|
|
||||||
expressions get their meaning from the context.
|
|
||||||
|
|
||||||
//This train// is faster than //that airplane//.
|
|
||||||
|
|
||||||
I want to go from //this place// to //this place//.
|
|
||||||
|
|
||||||
In particular, as in these examples, the meaning
|
|
||||||
can be obtained from accompanying pointing gestures.
|
|
||||||
|
|
||||||
Thus the meaning-bearing unit is neither the words nor the
|
|
||||||
gestures alone, but their combination. Demonstratives
|
|
||||||
thus provide an example of **integrated multimodality**,
|
|
||||||
as opposed to parallel multimodality. In parallel
|
|
||||||
multimodality, speech and other modes of communication
|
|
||||||
are just alternative ways to convey the same information.
|
|
||||||
|
|
||||||
|
|
||||||
===Representing demonstratives in semantics and grammar===
|
|
||||||
|
|
||||||
When formalizing the semantics of demonstratives, we can combine syntax with coordinates:
|
|
||||||
|
|
||||||
I want to go from this place to this place
|
|
||||||
|
|
||||||
is interpreted as something like
|
|
||||||
```
|
|
||||||
want(I, go, this(place,(123,45)), this(place,(98,10)))
|
|
||||||
```
|
|
||||||
Now, the same semantic value can be given in many ways, by performing
|
|
||||||
the clicks at different points of time in relation to the speech:
|
|
||||||
|
|
||||||
I want to go from this place CLICK(123,45) to this place CLICK(98,10)
|
|
||||||
|
|
||||||
I want to go from this place to this place CLICK(123,45) CLICK(98,10)
|
|
||||||
|
|
||||||
CLICK(123,45) CLICK(98,10) I want to go from this place to this place
|
|
||||||
|
|
||||||
How do we build the value compositionally in parsing?
|
|
||||||
Traditional parsing is sequential: its input is a string of tokens.
|
|
||||||
It works for demonstratives only if the pointing is adjacent to
|
|
||||||
the spoken expression. In the actual input, the demonstrative word
|
|
||||||
can be separated from the accompanying click by other words. The two
|
|
||||||
can also be simultaneous.
|
|
||||||
|
|
||||||
|
|
||||||
===Asynchronous syntax in GF===
|
|
||||||
|
|
||||||
What we need is a notion of **asynchronous parsing**, as opposed to
|
|
||||||
sequential parsing (where demonstrative words and clicks must be
|
|
||||||
adjacent).
|
|
||||||
|
|
||||||
We can implement asynchronous parsin in GF by exploiting the generality
|
|
||||||
of **linearization types**. A linearization type is the type of
|
|
||||||
the **concrete syntax objects** assigned to semantic values.
|
|
||||||
What a GF grammar defines is a relation
|
|
||||||
```
|
|
||||||
abstract syntax trees <---> concrete syntax objects
|
|
||||||
```
|
|
||||||
When modelling context-free grammar in GF,
|
|
||||||
the concrete syntax objects are just strings.
|
|
||||||
But they can be more structured objects as well - in general, they are
|
|
||||||
**records** of different kinds of objects. For example,
|
|
||||||
a demonstrative expression can be linearized into a record of two strings.
|
|
||||||
```
|
|
||||||
{s = "this place" ;
|
|
||||||
this place (coord 123 45) <---> p = "(123,45)"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
The record
|
|
||||||
```
|
|
||||||
{s = "I want to go from this place to this place" ;
|
|
||||||
p = "(123,45) (98,10"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
represents any combination of the sentence and the clicks, as long
|
|
||||||
as the clicks appear in this order.
|
|
||||||
|
|
||||||
|
|
||||||
===Example multimodal grammar: abstract syntax===
|
|
||||||
|
|
||||||
A simple example of a multimodal GF grammar is the one called
|
|
||||||
the Tram Demo grammar. It was written by Björn Bringert within
|
|
||||||
the TALK project as a part of a dialogue system that
|
|
||||||
deals with queries about tram timetables. The system interprets
|
|
||||||
a speech input in combination with mouse clicks on a digital map.
|
|
||||||
|
|
||||||
The abstract syntax of (a minimal fragment of) the Tram Demo
|
|
||||||
grammar is
|
|
||||||
```
|
|
||||||
cat
|
|
||||||
Input, Dep, Dest, Click ;
|
|
||||||
fun
|
|
||||||
GoFromTo : Dep -> Dest -> Input ; -- "I want to go from x to y"
|
|
||||||
DepHere : Click -> Dep ; -- "from here" with click
|
|
||||||
DestHere : Click -> Dest ; -- "to here" with click
|
|
||||||
|
|
||||||
CCoord : Int -> Int -> Click ; -- click coordinates
|
|
||||||
```
|
|
||||||
An English concrete syntax of the grammar is
|
|
||||||
```
|
|
||||||
lincat
|
|
||||||
Input, Dep, Dest = {s : Str ; p : Str} ;
|
|
||||||
Click = {p : Str} ;
|
|
||||||
|
|
||||||
lin
|
|
||||||
GoFromTo x y = {s = ["I want to go"] ++ x.s ++ y.s ; p = x.p ++ y.p} ;
|
|
||||||
DepHere c = {s = ["from here"] ; p = c.p} ;
|
|
||||||
DestHere c = {s = ["to here"] ; p = c.p} ;
|
|
||||||
|
|
||||||
CCoord x y = {p = "(" ++ x.s ++ "," ++ y.s ++ ")"} ;
|
|
||||||
```
|
|
||||||
When the grammar is used in the actual system, standard parsing methods
|
|
||||||
are used for interpreting the integrated speech and click input.
|
|
||||||
Parsing appears on two levels: the speech input parsing
|
|
||||||
performed by the Nuance speech recognition program (without the clicks),
|
|
||||||
and the semantics-yielding parser sending input to the dialogue manager.
|
|
||||||
The latter parser just attaches the clicks to the speech input. The order
|
|
||||||
of the clicks is preserved, and the parser can hence associate each of
|
|
||||||
the clicks with proper demonstratives. Here is the grammar used in the
|
|
||||||
two parsing phases.
|
|
||||||
```
|
|
||||||
cat
|
|
||||||
Query, -- whole content
|
|
||||||
Speech ; -- speech only
|
|
||||||
fun
|
|
||||||
QueryInput : Input -> Query ; -- the whole content shown
|
|
||||||
SpeechInput : Input -> Speech ; -- only the speech shown
|
|
||||||
|
|
||||||
lincat
|
|
||||||
Query, Speech = {s : Str} ;
|
|
||||||
lin
|
|
||||||
QueryInput i = {s = i.s ++ ";" ++ i.p} ;
|
|
||||||
SpeechInput i = {s = i.s} ;
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
===Digression: discontinuous constituents===
|
|
||||||
|
|
||||||
The GF representation of integrated multimodality is
|
|
||||||
similar to the representation of **discontinous constituents**.
|
|
||||||
For instance, assume //has arrived// is a verb phrase in English,
|
|
||||||
which can be used both in declarative sentences and questions,
|
|
||||||
|
|
||||||
she //has arrived//
|
|
||||||
|
|
||||||
//has// she //arrived//
|
|
||||||
|
|
||||||
In the question, the two words are separated from each other. If
|
|
||||||
//has arrived// is a constituent of the question, it is thus discontinuous.
|
|
||||||
To represent such constituents in GF, records can be used:
|
|
||||||
we split verb phrases (``VP``) into a finite and infinitive part.
|
|
||||||
```
|
|
||||||
lincat VP = {fin, inf : Str} ;
|
|
||||||
|
|
||||||
lin Indic np vp = {s = np.s ++ vp.fin ++ vp.inf} ;
|
|
||||||
lin Quest np vp = {s = vp.fin ++ np.s ++ vp.inf} ;
|
|
||||||
```
|
|
||||||
|
|
||||||
===From grammars to dialogue systems===
|
|
||||||
|
|
||||||
The general recipe for using GF when building dialogue systems
|
|
||||||
is to write a grammar with the following components:
|
|
||||||
|
|
||||||
- The abstract syntax defines the semantics (the "ontology")
|
|
||||||
of the domain of the system.
|
|
||||||
- The concrete syntaxes define alternative modes of input and output.
|
|
||||||
|
|
||||||
|
|
||||||
The engineering advantages of this approach have to do partly with
|
|
||||||
the declarativity of the description, partly with the tools provided
|
|
||||||
by GF to derive different components of the system:
|
|
||||||
|
|
||||||
- The type checker guarantees that all the input and output
|
|
||||||
modes match with the ontology.
|
|
||||||
- The grammar compiler generates parsers for each input grammar
|
|
||||||
and generators for each output grammar.
|
|
||||||
- Translators between GF's abstract syntax and other ontology
|
|
||||||
description languages enable communication with different
|
|
||||||
kinds of dialogue managers and cover e.g. Prolog terms and XML objects.
|
|
||||||
- Translators from GF's concrete syntax to speech recognition formats
|
|
||||||
make it possible to generate e.g. Nuance grammars and ATK language
|
|
||||||
models.
|
|
||||||
|
|
||||||
|
|
||||||
An example of this process is Björn Bringert's TramDemo.
|
|
||||||
More recently, grammars have been integrated to the GoDiS dialogue
|
|
||||||
manager by Prolog representations of abstract syntax.
|
|
||||||
|
|
||||||
|
|
||||||
==Adding multimodality to a unimodal grammar==
|
|
||||||
|
|
||||||
This section gives a recipe for making any unimodal grammar
|
|
||||||
multimodal, by adding pointing gestures to chosen expressions. The recipe
|
|
||||||
guarantees that the resulting grammar remains semantically well-formed,
|
|
||||||
i.e. type correct.
|
|
||||||
|
|
||||||
|
|
||||||
===The multimodal conversion===
|
|
||||||
|
|
||||||
The **multimodal conversion** of a grammar consists of seven
|
|
||||||
steps, of which the first is always the same, the second
|
|
||||||
involves a decision, and the rest are derivative:
|
|
||||||
|
|
||||||
+ Add the category ```Point``` with a standard linearization type.
|
|
||||||
```
|
|
||||||
cat Point ;
|
|
||||||
lincat Point = {point : Str} ;
|
|
||||||
```
|
|
||||||
+ (Decision) Decide which constructors are demonstrative, i.e. take
|
|
||||||
a pointing gesture as an argument. Add a ``Point``` as their last argument.
|
|
||||||
The new type signatures for such constructors //d// have the form
|
|
||||||
```
|
|
||||||
fun d : ... -> Point -> D
|
|
||||||
```
|
|
||||||
+ (Derivative) Add a ``point`` field to the linearization type //L// of any
|
|
||||||
demonstrative category //D//, i.e. a category that has at least one demonstrative
|
|
||||||
constructor:
|
|
||||||
```
|
|
||||||
lincat D = L ** {point : Str} ;
|
|
||||||
```
|
|
||||||
+ (Derivative) If some other category //C// has a constructor //d// that takes
|
|
||||||
demonstratives as arguments, make it demonstrative by adding a //point// field
|
|
||||||
to its linearization type.
|
|
||||||
+ (Derivative) Store the ``point`` field in the linearization //t// of any
|
|
||||||
constructor //d// that has been made demonstrative:
|
|
||||||
```
|
|
||||||
lin d x1 ... xn p = t x1 ... xn ** {point = p.point} ;
|
|
||||||
```
|
|
||||||
+ (Derivative) For each constructor //f// that takes demonstratives //D_1,...,D_n//
|
|
||||||
as arguments, collect the //point// fields of the arguments in the //point//
|
|
||||||
field of the value:
|
|
||||||
```
|
|
||||||
lin f x_1 ... x_m =
|
|
||||||
t x_1 ... x_m ** {point = x_d1.point ++ ... ++ x_dn.point} ;
|
|
||||||
```
|
|
||||||
Make sure that the pointings ``x_d1.point ... x_dn.point`` are concatenated
|
|
||||||
in the same order as the arguments appear in the //linearization// //t//,
|
|
||||||
which is not necessarily the same as the abstract argument order.
|
|
||||||
+ (Derivative) To preserve type correctness, add an empty
|
|
||||||
``point`` field to the linearization //t// of any
|
|
||||||
constructor //c// of a demonstrative category:
|
|
||||||
```
|
|
||||||
lin c x1 ... xn = t x1 ... xn ** {point = []} ;
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
===An example of the conversion===
|
|
||||||
|
|
||||||
Start with a Tram Demo grammar with no demonstratives, but just
|
|
||||||
tram stop names and the indexical //here// (interpreted as e.g. the user's
|
|
||||||
standing place).
|
|
||||||
```
|
|
||||||
cat
|
|
||||||
Input, Dep, Dest, Name ;
|
|
||||||
fun
|
|
||||||
GoFromTo : Dep -> Dest -> Input ;
|
|
||||||
DepHere : Dep ;
|
|
||||||
DestHere : Dest ;
|
|
||||||
DepName : Name -> Dep ;
|
|
||||||
DestName : Name -> Dest ;
|
|
||||||
|
|
||||||
Almedal : Name ;
|
|
||||||
```
|
|
||||||
A unimodal English concrete syntax of the grammar is
|
|
||||||
```
|
|
||||||
lincat
|
|
||||||
Input, Dep, Dest, Name = {s : Str} ;
|
|
||||||
|
|
||||||
lin
|
|
||||||
GoFromTo x y = {s = ["I want to go"] ++ x.s ++ y.s} ;
|
|
||||||
DepHere = {s = ["from here"]} ;
|
|
||||||
DestHere = {s = ["to here"]} ;
|
|
||||||
DepName n = {s = ["from"] ++ n.s} ;
|
|
||||||
DestName n = {s = ["to"] ++ n.s} ;
|
|
||||||
|
|
||||||
Almedal = {s = "Almedal"} ;
|
|
||||||
```
|
|
||||||
Let us follow the steps of the recipe.
|
|
||||||
|
|
||||||
+ We add the category ``Point`` and its linearization type.
|
|
||||||
+ We decide that ``DepHere`` and ``DestHere`` involve a pointing gesture.
|
|
||||||
+ We add ``point`` to the linearization types of ``Dep`` and ``Dest``.
|
|
||||||
+ Therefore, also add ``point`` to ``Input``. (But ``Name`` remains unimodal.)
|
|
||||||
+ Add ``p.point`` to the linearizations of ``DepHere`` and ``DestHere``.
|
|
||||||
+ Concatenate the points of the arguments of ``GoFromTo``.
|
|
||||||
+ Add an empty ``point`` to ``DepName`` and ``DestName``.
|
|
||||||
|
|
||||||
|
|
||||||
In the resulting grammar, one category is added and
|
|
||||||
two functions are changed in the abstract syntax (annotated by the step numbers):
|
|
||||||
```
|
|
||||||
cat
|
|
||||||
Point ; -- 1
|
|
||||||
fun
|
|
||||||
DepHere : Point -> Dep ; -- 2
|
|
||||||
DestHere : Point -> Dest ; -- 2
|
|
||||||
|
|
||||||
```
|
|
||||||
The concrete syntax in its entirety looks as follows
|
|
||||||
```
|
|
||||||
lincat
|
|
||||||
Dep, Dest = {s : Str ; point : Str} ; -- 3
|
|
||||||
Input = {s : Str ; point : Str} ; -- 4
|
|
||||||
Name = {s : Str} ;
|
|
||||||
Point = {point : Str} ; -- 1
|
|
||||||
lin
|
|
||||||
GoFromTo x y = {s = ["I want to go"] ++ x.s ++ y.s ; -- 6
|
|
||||||
point = x.point ++ y.point
|
|
||||||
} ;
|
|
||||||
DepHere p = {s = ["from here"] ; -- 5
|
|
||||||
point = p.point
|
|
||||||
} ;
|
|
||||||
DestHere p = {s = ["to here"] : -- 5
|
|
||||||
point = p.point
|
|
||||||
} ;
|
|
||||||
DepName n = {s = ["from"] ++ n.s ; -- 7
|
|
||||||
point = []
|
|
||||||
} ;
|
|
||||||
DestName n = {s = ["to"] ++ n.s ; -- 7
|
|
||||||
point = []
|
|
||||||
} ;
|
|
||||||
Almedal = {s = "Almedal"} ;
|
|
||||||
```
|
|
||||||
What we need in addition, to use the grammar in applications, are
|
|
||||||
|
|
||||||
+ Constructors for ``Point``, e.g. coordinate pairs.
|
|
||||||
+ Top-level categories, like ``Query`` and ``Speech`` in the original.
|
|
||||||
|
|
||||||
|
|
||||||
But their proper place is probably in another grammar module, so that
|
|
||||||
the core Tram Demo grammar can be used in different systems e.g.
|
|
||||||
encoding clicks in different ways.
|
|
||||||
|
|
||||||
|
|
||||||
===Multimodal conversion combinators===
|
|
||||||
|
|
||||||
GF is a functional programming language, and we exploit this
|
|
||||||
by providing a set of combinators that makes the multimodal conversion easier
|
|
||||||
and clearer. We start with the type of sequences of pointing gestures.
|
|
||||||
```
|
|
||||||
Point : Type = {point : Str} ;
|
|
||||||
```
|
|
||||||
To make a record type multimodal is to extend it with ``Point``.
|
|
||||||
The record extension operator ``**`` is needed here.
|
|
||||||
```
|
|
||||||
Dem : Type -> Type = \t -> t ** Point ;
|
|
||||||
```
|
|
||||||
To construct, use, and concatenate pointings:
|
|
||||||
```
|
|
||||||
mkPoint : Str -> Point = \s -> {point = s} ;
|
|
||||||
|
|
||||||
noPoint : Point = mkPoint [] ;
|
|
||||||
|
|
||||||
point : Point -> Str = \p -> p.point ;
|
|
||||||
|
|
||||||
concatPoint : (x,y : Point) -> Point = \x,y ->
|
|
||||||
mkPoint (point x ++ point y) ;
|
|
||||||
```
|
|
||||||
Finally, to add pointing to a record, with the limiting case of no demonstrative needed.
|
|
||||||
```
|
|
||||||
mkDem : (t : Type) -> t -> Point -> Dem t = \_,x,s -> x ** s ;
|
|
||||||
|
|
||||||
nonDem : (t : Type) -> t -> Dem t = \t,x -> mkDem t x noPoint ;
|
|
||||||
```
|
|
||||||
Let us rewrite the Tram Demo grammar by using these combinators:
|
|
||||||
```
|
|
||||||
oper
|
|
||||||
SS : Type = {s : Str} ;
|
|
||||||
lincat
|
|
||||||
Input, Dep, Dest = Dem SS ;
|
|
||||||
Name = SS ;
|
|
||||||
|
|
||||||
lin
|
|
||||||
GoFromTo x y = {s = ["I want to go"] ++ x.s ++ y.s} **
|
|
||||||
concatPoint x y ;
|
|
||||||
DepHere = mkDem SS {s = ["from here"]} ;
|
|
||||||
DestHere = mkDem SS {s = ["to here"]} ;
|
|
||||||
DepName n = nonDem SS {s = ["from"] ++ n.s} ;
|
|
||||||
DestName n = nonDem SS {s = ["to"] ++ n.s} ;
|
|
||||||
|
|
||||||
Almedal = {s = "Almedal"} ;
|
|
||||||
```
|
|
||||||
The type synonym ``SS`` is introduced to make the combinator applications
|
|
||||||
concise. Notice the use of partial application in ``DepHere`` and
|
|
||||||
``DestHere``; an equivalent way to write is
|
|
||||||
```
|
|
||||||
DepHere p = mkDem SS {s = ["from here"]} p ;
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
==Multimodal resource grammars==
|
|
||||||
|
|
||||||
The main advantage of using GF when building dialogue systems is
|
|
||||||
that various components of the system
|
|
||||||
can be automatically generated from GF grammars.
|
|
||||||
Writing these grammars, however, can still be a considerable
|
|
||||||
task. A case in point are multilingual systems:
|
|
||||||
how to localize e.g. a system built in a car to
|
|
||||||
the languages of all those customers to whom the
|
|
||||||
car is sold? This problem has been the main focus of
|
|
||||||
GF for some years, and the solution on which most work has been
|
|
||||||
done is the development of **resource grammar libraries**.
|
|
||||||
These libraries work in the same way as program libraries
|
|
||||||
in software engineering, enabling a division of labour
|
|
||||||
between linguists and domain experts.
|
|
||||||
|
|
||||||
One of the goals in the resource grammars of different
|
|
||||||
languages has been to provide a **language-independent API**,
|
|
||||||
which makes the same resource grammar functions available for
|
|
||||||
different languages. For instance, the categories
|
|
||||||
``S``, ``NP``, and ``VP`` are available in all of the
|
|
||||||
10 languages currently supported, and so is the function
|
|
||||||
```
|
|
||||||
PredVP : NP -> VP -> S
|
|
||||||
```
|
|
||||||
which corresponds to the rule ``S -> NP VP`` in phrase
|
|
||||||
structure grammar. However, there are several levels of abstraction
|
|
||||||
between the function ``PredVP`` and the phrase structure rule,
|
|
||||||
because the rule is implemented in so different ways in different
|
|
||||||
languages. In particular, discontinuous constituents are needed in
|
|
||||||
various degrees to make the rule work in different languages.
|
|
||||||
|
|
||||||
Now, dealing with discontinuous constituents is one of the demanding
|
|
||||||
aspects of multilingual grammar writing that the resource grammar
|
|
||||||
API is designed to hide. But the proposed treatment of integrated
|
|
||||||
multimodality is heavily dependent on similar things. What can we
|
|
||||||
do to make multimodal grammars easier to write (for different languages)?
|
|
||||||
There are two orthogonal answers:
|
|
||||||
|
|
||||||
+ Use resource grammars to write a unimodal dialogue grammar and
|
|
||||||
then apply the multimodal
|
|
||||||
conversion to manually chosen parts.
|
|
||||||
+ Use **multimodal resource grammars** to derive multimodal
|
|
||||||
dialogue system grammars directly.
|
|
||||||
|
|
||||||
|
|
||||||
The multimodal resource grammar library has been obtained from
|
|
||||||
the unimodal one by applying the multimodal conversion manually.
|
|
||||||
In addition, the API has been simplified
|
|
||||||
by leaving out structures needed in written technical documents
|
|
||||||
(the original application area of GF) but not in spoken dialogue.
|
|
||||||
|
|
||||||
In the following subsections, we will show a part of the
|
|
||||||
multimodal resource grammar API, limited to a fragment that
|
|
||||||
is needed to get the main ideas and to reimplement the
|
|
||||||
Tram Demo grammar. The reimplementation shows one more advantage
|
|
||||||
of the resource grammar approach: dialogue systems can be
|
|
||||||
automatically instantiated to different languages.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
===Resource grammar API===
|
|
||||||
|
|
||||||
The resource grammar API has three main kinds of entries:
|
|
||||||
|
|
||||||
+ Language-independent linguistic structures (``linguistic ontology''), e.g.
|
|
||||||
```
|
|
||||||
PredVP : NP -> VP -> S ; -- "Mary helps him"
|
|
||||||
```
|
|
||||||
+ Language-specific syntax extensions, e.g. Swedish and German fronting
|
|
||||||
topicalization
|
|
||||||
```
|
|
||||||
TopicObj : NP -> VP -> S ; -- "honom hjälper Mary"
|
|
||||||
```
|
|
||||||
+ Language-specific lexical constructors, e.g. Germanic //Ablaut// patterns
|
|
||||||
```
|
|
||||||
irregV : (sing,sang,sung : Str) -> V ;
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
The first two kinds of entries are ``cat`` and ``fun`` definitions
|
|
||||||
in an abstract syntax. The multimodal, restricted API has
|
|
||||||
e.g. the following categories. Their names are obtained from
|
|
||||||
the corresponding unimodal categories by prefixing ``M``.
|
|
||||||
```
|
|
||||||
MS ; -- multimodal sentence or question
|
|
||||||
MQS ; -- multimodal wh question
|
|
||||||
MImp ; -- multimodal imperative
|
|
||||||
MVP ; -- multimodal verb phrase
|
|
||||||
MNP ; -- multimodal (demonstrative) noun phrase
|
|
||||||
MAdv ; -- multimodal (demonstrative) adverbial
|
|
||||||
|
|
||||||
Point ; -- pointing gesture
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
===Multimodal API: functions for building demonstratives===
|
|
||||||
|
|
||||||
Demonstrative pronouns can be used both as noun phrases and
|
|
||||||
as determiners.
|
|
||||||
```
|
|
||||||
this_MNP : Point -> MNP ; -- this
|
|
||||||
thisDet_MNP : CN -> Point -> MNP ; -- this car
|
|
||||||
```
|
|
||||||
There are also demonstrative adverbs, and prepositions give
|
|
||||||
a productive way to build more adverbs.
|
|
||||||
```
|
|
||||||
here_MAdv : Point -> MAdv ; -- here
|
|
||||||
here7from_MAdv : Point -> MAdv ; -- from here
|
|
||||||
|
|
||||||
MPrepNP : Prep -> MNP -> MAdv ; -- in this car
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
===Multimodal API: functions for building sentences and phrases===
|
|
||||||
|
|
||||||
A handful of predication rules construct sentences, questions, and imperatives.
|
|
||||||
```
|
|
||||||
MPredVP : MNP -> MVP -> MS ; -- this plane flies here
|
|
||||||
MQPredVP : MNP -> MVP -> MQS ; -- does this plane fly here
|
|
||||||
MQuestVP : IP -> MVP -> MQS ; -- who flies here
|
|
||||||
MImpVP : MVP -> MImp ; -- fly here!
|
|
||||||
```
|
|
||||||
Verb phrases are constructed from verbs (inherited as such from
|
|
||||||
the unimodal API) by providing their complements.
|
|
||||||
```
|
|
||||||
MUseV : V -> MVP ; -- flies
|
|
||||||
MComplV2 : V2 -> MNP -> MVP ; -- takes this
|
|
||||||
MComplVV : VV -> MVP -> MVP ; -- wants to take this
|
|
||||||
```
|
|
||||||
A multimodal adverb can be attached to a verb phrase.
|
|
||||||
```
|
|
||||||
MAdvVP : MVP -> MAdv -> MVP ; -- flies here
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
===Language-independent implementation: examples===
|
|
||||||
|
|
||||||
The implementation makes heavy use of the multimodal conversion
|
|
||||||
combinators. It adds a ``point`` field to whatever the implementation of the unimodal
|
|
||||||
category is in any language. Thus, for example
|
|
||||||
```
|
|
||||||
lincat
|
|
||||||
MVP = Dem VP ;
|
|
||||||
MNP = Dem NP ;
|
|
||||||
MAdv = Dem Adv ;
|
|
||||||
|
|
||||||
lin
|
|
||||||
this_MNP = mkDem NP this_NP ;
|
|
||||||
-- i.e. this_MNP p = this_NP ** {point = p.point} ;
|
|
||||||
|
|
||||||
MComplV2 verb obj = mkDem VP (ComplV2 verb obj) obj ;
|
|
||||||
|
|
||||||
MAdvVP vp adv = mkDem VP (AdvVP vp adv) (concatPoint vp adv) ;
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
===Multimodal API: interface to unimodal expressions===
|
|
||||||
|
|
||||||
Using nondemonstrative expressions as demonstratives:
|
|
||||||
```
|
|
||||||
DemNP : NP -> MNP ;
|
|
||||||
DemAdv : Adv -> MAdv ;
|
|
||||||
```
|
|
||||||
Building top-level phrases:
|
|
||||||
```
|
|
||||||
PhrMS : Pol -> MS -> Phr ;
|
|
||||||
PhrMS : Pol -> MS -> Phr ;
|
|
||||||
PhrMQS : Pol -> MQS -> Phr ;
|
|
||||||
PhrMImp : Pol -> MImp -> Phr ;
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
===Instantiating multimodality to different languages===
|
|
||||||
|
|
||||||
The implementation above has only used the resource grammar API,
|
|
||||||
not the concrete implementations. The library ``Demonstrative``
|
|
||||||
is a **parametrized module**, also called a **functor**, which
|
|
||||||
has the following structure
|
|
||||||
```
|
|
||||||
incomplete concrete DemonstrativeI of Demonstrative =
|
|
||||||
Cat, TenseX ** open Test, Structural in {
|
|
||||||
|
|
||||||
-- lincat and lin rules
|
|
||||||
|
|
||||||
}
|
|
||||||
```
|
|
||||||
It can be **instantiated** to different languages as follows.
|
|
||||||
```
|
|
||||||
concrete DemonstrativeEng of Demonstrative =
|
|
||||||
CatEng, TenseX ** DemonstrativeI with
|
|
||||||
(Test = TestEng),
|
|
||||||
(Structural = StructuralEng) ;
|
|
||||||
|
|
||||||
concrete DemonstrativeSwe of Demonstrative =
|
|
||||||
CatSwe, TenseX ** DemonstrativeI with
|
|
||||||
(Test = TestSwe),
|
|
||||||
(Structural = StructuralSwe) ;
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
===Language-independent reimplementation of TramDemo===
|
|
||||||
|
|
||||||
Again using the functor idea, we reimplement ``TramDemo``
|
|
||||||
as follows:
|
|
||||||
```
|
|
||||||
incomplete concrete TramI of Tram = open Multimodal in {
|
|
||||||
|
|
||||||
lincat
|
|
||||||
Query = Phr ; Input = MS ;
|
|
||||||
Dep, Dest = MAdv ; Click = Point ;
|
|
||||||
lin
|
|
||||||
QInput = PhrMS PPos ;
|
|
||||||
|
|
||||||
GoFromTo x y =
|
|
||||||
MPredVP (DemNP (UsePron i_Pron))
|
|
||||||
(MAdvVP (MAdvVP (MComplVV want_VV (MUseV go_V)) x) y) ;
|
|
||||||
|
|
||||||
DepHere = here7from_MAdv ;
|
|
||||||
DestHere = here7to_MAdv ;
|
|
||||||
DepName s = MPrepNP from_Prep (DemNP (UsePN (SymbPN (MkSymb s)))) ;
|
|
||||||
DestName s = MPrepNP to_Prep (DemNP (UsePN (SymbPN (MkSymb s)))) ;
|
|
||||||
|
|
||||||
```
|
|
||||||
Then we can instantiate this to all languages for which
|
|
||||||
the ``Multimodal`` API has been implemented:
|
|
||||||
```
|
|
||||||
concrete TramEng of Tram = TramI with
|
|
||||||
(Multimodal = MultimodalEng) ;
|
|
||||||
|
|
||||||
concrete TramSwe of Tram = TramI with
|
|
||||||
(Multimodal = MultimodalSwe) ;
|
|
||||||
|
|
||||||
concrete TramFre of Tram = TramI with
|
|
||||||
(Multimodal = MultimodalFre) ;
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
===The order problem===
|
|
||||||
|
|
||||||
It was pointed out in the section on the multimodal conversion that
|
|
||||||
the concrete word order may be different from the abstract one,
|
|
||||||
and vary between different languages. For instance, Swedish
|
|
||||||
topicalization
|
|
||||||
|
|
||||||
Det här tåget vill den här kunden inte ta.
|
|
||||||
|
|
||||||
(``this train, this customer doesn't want to take'') may well have
|
|
||||||
an abstract syntax of a form in which the customer appears
|
|
||||||
before the train.
|
|
||||||
|
|
||||||
This is a problem for the implementor of the resource grammar.
|
|
||||||
It means that some parts of the resource must be written manually
|
|
||||||
and not as a functor.
|
|
||||||
However, the //user// of the resource can safely
|
|
||||||
ignore the word order problem, if it is correctly dealt with in
|
|
||||||
the resource.
|
|
||||||
|
|
||||||
|
|
||||||
===A recipe for using the resource library===
|
|
||||||
|
|
||||||
When starting to develop resource grammars, we believed they
|
|
||||||
would be all that
|
|
||||||
an application grammarian needs to write a concrete syntax.
|
|
||||||
However, experience has shown that it can be tough to start
|
|
||||||
grammar development in this way: selecting functions from
|
|
||||||
a resource API requires more abstract thinking than just
|
|
||||||
writing strings, and its take longer to reach testable
|
|
||||||
results. The most light-weight format is
|
|
||||||
maybe to start with context-free grammars (which notation is
|
|
||||||
also supported by GF). Context-free grammars that
|
|
||||||
give acceptable even though over-generating
|
|
||||||
results for languages like English are quick to produce.
|
|
||||||
|
|
||||||
The experience has led to the following
|
|
||||||
steps for grammar development. While giving the work
|
|
||||||
a quick start, this recipe
|
|
||||||
increases abstraction at a later level, when it is time to
|
|
||||||
to localize the grammar to different languages.
|
|
||||||
If context-free notation is used, steps 1 and 2 can
|
|
||||||
be merged.
|
|
||||||
|
|
||||||
+ Encode domain ontology in and abstract syntax, ``Domain``.
|
|
||||||
+ Write a rough concrete syntax in English, ``DomainRough``.
|
|
||||||
This can be oversimplified and overgenerating.
|
|
||||||
+ Reimplement by using the resource library, and build a functor ``DomainI``.
|
|
||||||
This can helped by **example-based grammar writing**, where
|
|
||||||
the examples are generated from ``DomainRough``.
|
|
||||||
+ Instantiate the functor ``DomainI`` to different languages,
|
|
||||||
and test the results by generating linearizations.
|
|
||||||
+ If some rule doesn't satisfy in some language, use the resource in
|
|
||||||
a different way for that case (**compile-time transfer**).
|
|
||||||
|
|
||||||
|
|
||||||
Reference in New Issue
Block a user