From 59c4536d5e946518b4c2fb1595f89fbc6601dcec Mon Sep 17 00:00:00 2001 From: aarne Date: Mon, 9 Jan 2006 19:30:27 +0000 Subject: [PATCH] fixes in multimodal document, last section --- doc/multimodal.html | 46 +++++++++++++++++++++++++++++---------------- doc/multimodal.txt | 41 ++++++++++++++++++++++++++-------------- 2 files changed, 57 insertions(+), 30 deletions(-) diff --git a/doc/multimodal.html b/doc/multimodal.html index b1f202a9d..9f2b43902 100644 --- a/doc/multimodal.html +++ b/doc/multimodal.html @@ -7,7 +7,7 @@

Demonstrative Expressions and Multimodal Grammars

Author: Aarne Ranta <aarne (at) cs.chalmers.se>
-Last update: Sun Jan 8 21:50:32 2006 +Last update: Mon Jan 9 20:29:45 2006

@@ -39,7 +39,7 @@ Last update: Sun Jan 8 21:50:32 2006
  • Instantiating multimodality to different languages
  • Language-independent reimplementation of TramDemo
  • The order problem -
  • A recipe for using a resource library +
  • A recipe for using the resource library @@ -820,27 +820,41 @@ 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.

    1. Encode domain ontology in and abstract syntax, Domain.
    2. Write a rough concrete syntax in English, DomainRough. - This can be oversimplified and overgenerating. -
    3. Reimplement by resource, and build a functor DomainI. -
    4. Instantiate this functor to different languages, and test. -
    5. 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. +
    6. 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. +
    7. Instantiate the functor DomainI to different languages, + and test the results by generating linearizations. +
    8. If some rule doesn't satisfy in some language, use the resource in + a different way for that case (compile-time transfer).
    diff --git a/doc/multimodal.txt b/doc/multimodal.txt index cf8036651..8f41ab22e 100644 --- a/doc/multimodal.txt +++ b/doc/multimodal.txt @@ -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**).