fixes in multimodal document, last section

doc/multimodal.html

@@ -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
+However, experience has shown that it can be tough to start
-the grammar development in this way: selecting functions from
+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,
+writing strings, and its take longer to reach testable
-also supported by GF). This experience has led to the following
+results. The most light-weight format is
-steps for grammar development, which, while permitting
+maybe to start with context-free grammars (which notation is
-a quick start of the work, towards the end increase abstraction
+also supported by GF). Context-free grammars that
-to localize the grammar in different languages.
+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.
+  This can be oversimplified and overgenerating. 
-<LI>Reimplement by resource, and build a functor <CODE>DomainI</CODE>.
+<LI>Reimplement by using the resource library, and build a functor <CODE>DomainI</CODE>.
-<LI>Instantiate this functor to different languages, and test.
+  This can helped by <B>example-based grammar writing</B>, where
-<LI>If a rule doesn't satisfy in a language, use its resource in
+  the examples are generated from <CODE>DomainRough</CODE>.
-  a different way (<B>compile-time transfer</B>).
+<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>
 
 

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
+However, experience has shown that it can be tough to start
-the grammar development in this way: selecting functions from
+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,
+writing strings, and its take longer to reach testable
-also supported by GF). This experience has led to the following
+results. The most light-weight format is
-steps for grammar development, which, while permitting
+maybe to start with context-free grammars (which notation is
-a quick start of the work, towards the end increase abstraction
+also supported by GF). Context-free grammars that
-to localize the grammar in different languages.
+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.
+  This can be oversimplified and overgenerating. 
-+ Reimplement by resource, and build a functor ``DomainI``.
++ Reimplement by using the resource library, and build a functor ``DomainI``.
-+ Instantiate this functor to different languages, and test.
+  This can helped by **example-based grammar writing**, where
-+ If a rule doesn't satisfy in a language, use its resource in
+  the examples are generated from ``DomainRough``.
-  a different way (**compile-time transfer**).
++ 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**).