GitHub/gf-core
1
0
Fork 1
mirror of https://github.com/GrammaticalFramework/gf-core.git synced 2026-04-09 04:59:31 -06:00
Code Issues Packages Projects Releases Wiki Activity

fixes in multimodal document, last section

Browse Source
This commit is contained in:
aarne
2006-01-09 19:30:27 +00:00
parent cd4e08bf7e
commit d2dc0e82e8
2 changed files with 57 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
doc/multimodal.html
View File

@@ -7,7 +7,7 @@
<P ALIGN="center"><CENTER><H1>Demonstrative Expressions and Multimodal Grammars</H1>
<FONT SIZE="4">
<I>Author: Aarne Ranta &lt;aarne (at) cs.chalmers.se&gt;</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>

41
doc/multimodal.txt
View File

@@ -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**).