GitHub/gf-core
1
0
Fork 1
mirror of https://github.com/GrammaticalFramework/gf-core.git synced 2026-04-28 22:12:51 -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

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