forked from GitHub/gf-core
fixes in multimodal document, last section
This commit is contained in:
@@ -7,7 +7,7 @@
|
||||
<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: Sun Jan 8 21:50:32 2006
|
||||
Last update: Mon Jan 9 20:29:45 2006
|
||||
</FONT></CENTER>
|
||||
|
||||
<P></P>
|
||||
@@ -39,7 +39,7 @@ Last update: Sun Jan 8 21:50:32 2006
|
||||
<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 a resource library</A>
|
||||
<LI><A HREF="#toc21">A recipe for using the resource library</A>
|
||||
</UL>
|
||||
</UL>
|
||||
|
||||
@@ -820,27 +820,41 @@ ignore the word order problem, if it is correctly dealt with in
|
||||
the resource.
|
||||
</P>
|
||||
<A NAME="toc21"></A>
|
||||
<H3>A recipe for using a resource library</H3>
|
||||
<H3>A recipe for using the resource library</H3>
|
||||
<P>
|
||||
In the beginning, we believed resource grammars are all that
|
||||
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 heavy to start
|
||||
the grammar development in this way: selecting functions from
|
||||
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 things (maybe even in a context-free grammar notation,
|
||||
also supported by GF). This experience has led to the following
|
||||
steps for grammar development, which, while permitting
|
||||
a quick start of the work, towards the end increase abstraction
|
||||
to localize the grammar in different languages.
|
||||
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 resource, and build a functor <CODE>DomainI</CODE>.
|
||||
<LI>Instantiate this functor to different languages, and test.
|
||||
<LI>If a rule doesn't satisfy in a language, use its resource in
|
||||
a different way (<B>compile-time transfer</B>).
|
||||
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>
|
||||
|
||||
|
||||
|
||||
@@ -691,25 +691,38 @@ ignore the word order problem, if it is correctly dealt with in
|
||||
the resource.
|
||||
|
||||
|
||||
===A recipe for using a resource library===
|
||||
===A recipe for using the resource library===
|
||||
|
||||
In the beginning, we believed resource grammars are all that
|
||||
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 heavy to start
|
||||
the grammar development in this way: selecting functions from
|
||||
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 things (maybe even in a context-free grammar notation,
|
||||
also supported by GF). This experience has led to the following
|
||||
steps for grammar development, which, while permitting
|
||||
a quick start of the work, towards the end increase abstraction
|
||||
to localize the grammar in different languages.
|
||||
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 resource, and build a functor ``DomainI``.
|
||||
+ Instantiate this functor to different languages, and test.
|
||||
+ If a rule doesn't satisfy in a language, use its resource in
|
||||
a different way (**compile-time transfer**).
|
||||
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