Parametrizing a resource grammar implementation
@@ -72,16 +73,8 @@ The following figure gives the dependencies of these modules.
-It is advisable to start with a simpler subset of the API, which
-leaves out certain complicated but not always necessary things:
-tenses and most part of the lexicon.
-
-
-
-
-
The module structure is rather flat: almost every module is a direct
-parent of the top module (Lang or Test). The idea
+parent of the top module Lang. The idea
is that you can concentrate on one linguistic aspect at a time, or
also distribute the work among several authors.
@@ -137,20 +130,6 @@ can skip the lincat definition of a category and use the default
{s : Str} until you need to change it to something else. In
English, for instance, most categories do have this linearization type!
-
-As a slight asymmetry in the module diagrams, you find the following
-modules:
-
-
-Tense: defines the parameters of polarity, anteriority, and tense
-Tensed: defines how sentences use those parameters
-Untensed: makes sentences use the polarity parameter only
-
-
-
-The full resource API (Lang) uses Tensed, whereas the
-restricted Test API uses Untensed.
-
Lexical modules
@@ -165,29 +144,22 @@ API, the latter rule is sometimes violated in some languages.
Another characterization of lexical is that lexical units can be added
almost ad libitum, and they cannot be defined in terms of already
given rules. The lexical modules of the resource API are thus more like
-samples than complete lists. There are three such modules:
+samples than complete lists. There are two such modules:
Structural: structural words (determiners, conjunctions,...)
-Basic: basic everyday content words (nouns, verbs,...)
-Lex: a very small sample of both structural and content words
+Lexicon: basic everyday content words (nouns, verbs,...)
The module Structural aims for completeness, and is likely to
-be extended in future releases of the resource. The module Basic
+be extended in future releases of the resource. The module Lexicon
gives a "random" list of words, which enable interesting testing of syntax,
and also a check list for morphology, since those words are likely to include
most morphological patterns of the language.
-The module Lex is used in Test instead of the two
-larger modules. Its purpose is to provide a quick way to test the
-syntactic structures of the phrase category modules without having to implement
-the larger lexica.
-
-
-In the case of Basic it may come out clearer than anywhere else
+In the case of Lexicon it may come out clearer than anywhere else
in the API that it is impossible to give exact translation equivalents in
different languages on the level of a resource grammar. In other words,
application grammars are likely to use the resource in different ways for
@@ -254,9 +226,9 @@ of resource v. 1.0.
lines in the previous step) - but you uncommenting the first
and the last lines will actually do the job for many of the files.
-Uncomment NounGer and LexiconGer in LangGer,
+ and compile LangGer in GF. Then test by parsing, linearization,
and random generation. In particular, linearization to a table should
be used so that you see all forms produced:
@@ -321,8 +293,9 @@ only one. So you will find yourself iterating the following steps:
You are likely to run this cycle a few times for each linearization rule
-you implement, and some hundreds of times altogether. There are 159
-funs in Test (at the moment).
+you implement, and some hundreds of times altogether. There are 66 cats and
+458 funs in Lang at the moment; 149 of the funs are outside the two
+lexicon modules).
Of course, you don't need to complete one phrase category module before starting
@@ -335,7 +308,8 @@ Here is a live log of the actual process of
building the German implementation of resource API v. 1.0.
It is the basis of the more detailed explanations, which will
follow soon. (You will found out that these explanations involve
-a rational reconstruction of the live process!)
+a rational reconstruction of the live process! Among other things, the
+API was changed during the actual process to make it more intuitive.)
Resource modules used
@@ -343,8 +317,9 @@ a rational reconstruction of the live process!)
These modules will be written by you.
-ResGer: parameter types and auxiliary operations
-MorphoGer: complete inflection engine; not needed for Test.
+ParamGer: parameter types
+ResGer: auxiliary operations (a resource for the resource grammar!)
+MorphoGer: complete inflection engine
@@ -439,7 +414,7 @@ the application grammarian may need to use, e.g.
These constants are defined in terms of parameter types and constructors
in ResGer and MorphoGer, which modules are are not
-accessible to the application grammarian.
+visible to the application grammarian.
Lock fields
@@ -509,16 +484,54 @@ use of the paradigms in BasicGer gives a good set of examples for
those who want to build new lexica.
-Inside phrase category modules
+Inside grammar modules
+
+So far we just give links to the implementations of each API.
+More explanation iś to follow - but many detail implementation tricks
+are only found in the cooments of the modules.
+
-Noun
+The category system
+
+
-Verb
+Phrase category modules
+
+- Tense, TenseGer
+
- Noun, NounGer
+
- Adjective, AdjectiveGer
+
- Verb, VerbGer
+
- Adverb, AdverbGer
+
- Numeral, NumeralGer
+
- Sentence, SentenceGer
+
- Question, QuestionGer
+
- Relative, RelativeGer
+
- Conjunction, ConjunctionGer
+
- Phrase, PhraseGer
+
- Lang, LangGer
+
+
-Adjective
+Resource modules
+
+
-Lexicon extension
+Lexicon
+
+
+Lexicon extension
+
The irregularity lexicon
It may be handy to provide a separate module of irregular
@@ -528,7 +541,7 @@ few hundred perhaps. Building such a lexicon separately also
makes it less important to cover everything by the
worst-case paradigms (mkV etc).
-
+
Lexicon extraction from a word list
You can often find resources such as lists of
@@ -538,10 +551,10 @@ page gives a list of verbs in the
traditional tabular format, which begins as follows:
- backen (du bäckst, er bäckt) backte [buk] gebacken
+ backen (du bäckst, er bäckt) backte [buk] gebacken
befehlen (du befiehlst, er befiehlt; befiehl!) befahl (beföhle; befähle) befohlen
- beginnen begann (begönne; begänne) begonnen
- beißen biß gebissen
+ beginnen begann (begönne; begänne) begonnen
+ beißen biß gebissen
All you have to do is to write a suitable verb paradigm
@@ -563,7 +576,7 @@ When using ready-made word lists, you should think about
coyright issues. Ideally, all resource grammar material should
be provided under GNU General Public License.
-
+
Lexicon extraction from raw text data
This is a cheap technique to build a lexicon of thousands
@@ -571,7 +584,7 @@ of words, if text data is available in digital format.
See the Functional Morphology
homepage for details.
-
+
Extending the resource grammar API
Sooner or later it will happen that the resource grammar API
@@ -580,7 +593,7 @@ that it does not include idiomatic expressions in a given language.
The solution then is in the first place to build language-specific
extension modules. This chapter will deal with this issue.
-
+
Writing an instance of parametrized resource grammar implementation
Above we have looked at how a resource implementation is built by
@@ -595,10 +608,10 @@ use parametrized modules. The advantages are
-In this chapter, we will look at an example: adding Portuguese to
+In this chapter, we will look at an example: adding Italian to
the Romance family.
-
+
Parametrizing a resource grammar implementation
This is the most demanding form of resource grammar writing.
@@ -614,6 +627,6 @@ This chapter will work out an example of how an Estonian grammar
is constructed from the Finnish grammar through parametrization.
-
+