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

starting German: nouns

Browse Source
This commit is contained in:
aarne
2006-01-04 13:01:05 +00:00
parent 958c754112
commit 5f1cd79b9b
29 changed files with 2437 additions and 168 deletions
Download Patch File Download Diff File Expand all files Collapse all files

180
lib/resource-1.0/doc/Resource-HOWTO.txt
View File

@@ -5,7 +5,7 @@ Last update: %%date(%c)
% NOTE: this is a txt2tags file.
% Create an html file from this file using:
% txt2tags Resource-HOWTO.txt
% txt2tags --toc -thtml Resource-HOWTO.txt
%!target:html
@@ -175,88 +175,112 @@ different languages.
Unless you are writing an instance of a parametrized implementation
(Romance or Scandinavian), which will be covered later, the most
simple way is to follow roughly the following procedure. Assume you
are building a grammar for the Dutch language. Here are the first steps.
are building a grammar for the German language. Here are the first steps,
which we actually followed ourselves when building the German implementation
of resource v. 1.0.
+ Create a sister directory for ``GF/lib/resource/english``, named
``dutch``.
```
``german``.
```
cd GF/lib/resource/
mkdir dutch
cd dutch
```
mkdir german
cd german
```
+ Check out the [ISO 639 3-letter language code http://www.w3.org/WAI/ER/IG/ert/iso639.htm]
for Dutch: it is ``Dut``.
+ Check out the [ISO 639 3-letter language code
http://www.w3.org/WAI/ER/IG/ert/iso639.htm]
for German: both ``Ger`` and ``Deu`` are given, and we pick ``Ger``.
+ Copy the ``*Eng.gf`` files from ``english`` ``dutch``,
+ Copy the ``*Eng.gf`` files from ``english`` ``german``,
and rename them:
```
```
cp ../english/*Eng.gf .
rename 's/Eng/Dut/' *Eng.gf
```
rename 's/Eng/Ger/' *Eng.gf
```
+ Change the ``Eng`` module references to ``Dut`` references
+ Change the ``Eng`` module references to ``Ger`` references
in all files:
``` sed -i 's/Eng/Dut/g' *Dut.gf
```
sed -i 's/English/German/g' *Ger.gf
sed -i 's/Eng/Ger/g' *Ger.gf
```
The first line prevents changing the word ``English``, which appears
here and there in comments, to ``Gerlish``.
+ This may of course change unwanted occurrences of the
string ``Eng`` - verify this by
``` grep Dut *.gf
```
grep Ger *.gf
```
But you will have to make lots of manual changes in all files anyway!
+ Comment out the contents of these files:
``` sed -i 's/^/--/' *Dut.gf
```
sed -i 's/^/--/' *Ger.gf
```
This will give you a set of templates out of which the grammar
will grow as you uncomment and modify the files rule by rule.
+ In the file ``TestDut.gf``, uncomment all lines except the list
of inherited modules. Now you can open the grammar in GF:
``` gf TestDut.gf
+ In all ``.gf`` files, uncomment the module headers and brackets,
leaving the module bodies commented. Unfortunately, there is no
simple way to do this automatically (or to avoid commenting these
lines in the previous step) - but you uncommenting the first
and the last lines will actually do the job for many of the files.
+ Now you will at all following steps have a valid, but incomplete
+ Now you can open the grammar ``TestGer`` in GF:
```
gf TestGer.gf
```
You will get lots of warnings on missing rules, but the grammar will compile.
+ At all following steps you will now have a valid, but incomplete
GF grammar. The GF command
``` pg -printer=missing
```
pg -printer=missing
```
tells you what exactly is missing.
===The develop-test cycle===
The real work starts now. The order in which the ``Phrase`` modules
were introduced above is a natural order to proceed, even though not the
only one. So you will find yourself iterating the following steps:
+ Select a phrase category module, e.g. ``NounDut``, and uncomment one
linearization rule (for instance, ``IndefSg``, which is
+ Select a phrase category module, e.g. ``NounGer``, and uncomment one
linearization rule (for instance, ``DefSg``, which is
not too complicated).
+ Write down some Dutch examples of this rule, in this case translations
of "a dog", "a house", "a big house", etc.
+ Write down some German examples of this rule, for instance translations
of "the dog", "the house", "the big house", etc. Write these in all their
different forms (two numbers and four cases).
+ Think about the categories involved (``CN, NP, N``) and the
variations they have. Encode this in the lincats of ``CatDut``.
You may have to define some new parameter types in ``ResDut``.
variations they have. Encode this in the lincats of ``CatGer``.
You may have to define some new parameter types in ``ResGer``.
+ To be able to test the construction,
define some words you need to instantiate it
in ``LexDut``. Again, it can be helpful to define some simple-minded
morphological paradigms in ``ResDut``, in particular worst-case
in ``LexGer``. Again, it can be helpful to define some simple-minded
morphological paradigms in ``ResGer``, in particular worst-case
constructors corresponding to e.g.
``ResEng.mkNoun``.
+ Doing this, you may want to test the resource independently. Do this by
```
i -retain ResDut
cc mkNoun "ei" "eieren" Neutr
```
```
i -retain ResGer
cc mkNoun "Brief" "Briefe" Masc
```
+ Uncomment ``NounDut`` and ``LexDut`` in ``TestDut``,
and compile ``TestDut`` in GF. Then test by parsing, linearization,
+ Uncomment ``NounGer`` and ``LexGer`` in ``TestGer``,
and compile ``TestGer`` 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:
```
```
gr -cat=NP -number=20 -tr | l -table
```
```
+ Spare some tree-linearization pairs for later regression testing.
You can do this way (!!to be completed)
@@ -278,8 +302,8 @@ very soon, keep you motivated, and reveal errors.
These modules will be written by you.
- ``ResDut``: parameter types and auxiliary operations
- ``MorphoDut``: complete inflection engine; not needed for ``Test``.
- ``ResGer``: parameter types and auxiliary operations
- ``MorphoGer``: complete inflection engine; not needed for ``Test``.
These modules are language-independent and provided by the existing resource
@@ -300,12 +324,12 @@ package.
When the implementation of ``Test`` is complete, it is time to
work out the lexicon files. The underlying machinery is provided in
``MorphoDut``, which is, in effect, your linguistic theory of
Dutch morphology. It can contain very sophisticated and complicated
``MorphoGer``, which is, in effect, your linguistic theory of
German morphology. It can contain very sophisticated and complicated
definitions, which are not necessarily suitable for actually building a
lexicon. For this purpose, you should write the module
- ``ParadigmsDut``: morphological paradigms for the lexicographer.
- ``ParadigmsGer``: morphological paradigms for the lexicographer.
This module provides high-level ways to define the linearization of
@@ -320,15 +344,15 @@ the functions
- ``mkN``, for worst-case construction of ``N``. Its type signature
has the form
```
```
mkN : Str -> ... -> Str -> P -> ... -> Q -> N
```
```
with as many string and parameter arguments as can ever be needed to
construct an ``N``.
- ``regN``, for the most common cases, with just one string argument:
```
```
regN : Str -> N
```
```
- A language-dependent (small) set of functions to handle mild irregularities
and common exceptions.
@@ -336,15 +360,15 @@ For the complement-taking variants, such as ``V2``, we provide
- ``mkV2``, which takes a ``V`` and all necessary arguments, such
as case and preposition:
```
```
mkV2 : V -> Case -> Str -> V2 ;
```
```
- A language-dependent (small) set of functions to handle common special cases,
such as direct transitive verbs:
```
```
dirV2 : V -> V2 ;
-- dirV2 v = mkV2 v accusative []
```
```
The golden rule for the design of paradigms is that
@@ -356,31 +380,31 @@ The golden rule for the design of paradigms is that
The discipline of data abstraction moreover requires that the user of the resource
is not given access to parameter constructors, but only to constants that denote
them. This gives the resource grammarian the freedom to change the underlying
data representation if needed. It means that the ``ParadigmsDut`` module has
data representation if needed. It means that the ``ParadigmsGer`` module has
to define constants for those parameter types and constructors that
the application grammarian may need to use, e.g.
```
oper
Case : Type ;
nominative, accusative, genitive : Case ;
nominative, accusative, genitive, dative : Case ;
```
These constants are defined in terms of parameter types and constructors
in ``ResDut`` and ``MorphoDut``, which modules are are not
in ``ResGer`` and ``MorphoGer``, which modules are are not
accessible to the application grammarian.
===Lock fields===
An important difference between ``MorphoDut`` and
``ParadigmsDut`` is that the former uses "raw" record types
An important difference between ``MorphoGer`` and
``ParadigmsGer`` is that the former uses "raw" record types
as lincats, whereas the latter used category symbols defined in
``CatDut``. When these category symbols are used to denote
record types in a resource modules, such as ``ParadigmsDut``,
``CatGer``. When these category symbols are used to denote
record types in a resource modules, such as ``ParadigmsGer``,
a **lock field** is added to the record, so that categories
with the same implementation are not confused with each other.
(This is inspired by the ``newtype`` discipline in Haskell.)
For instance, the lincats of adverbs and conjunctions may be the same
in ``CatDut``:
in ``CatGer``:
```
lincat Adv = {s : Str} ;
lincat Conj = {s : Str} ;
@@ -415,19 +439,19 @@ in her hidden definitions of constants in ``Paradigms``. For instance,
===Lexicon construction===
The lexicon belonging to ``LangDut`` consists of two modules:
The lexicon belonging to ``LangGer`` consists of two modules:
- ``StructuralDut``, structural words, built by directly using
``MorphoDut``.
- ``BasicDut``, content words, built by using ``ParadigmsDut``.
- ``StructuralGer``, structural words, built by directly using
``MorphoGer``.
- ``BasicGer``, content words, built by using ``ParadigmsGer``.
The reason why ``MorphoDut`` has to be used in ``StructuralDut``
is that ``ParadigmsDut`` does not contain constructors for closed
The reason why ``MorphoGer`` has to be used in ``StructuralGer``
is that ``ParadigmsGer`` does not contain constructors for closed
word classes such as pronouns and determiners. The reason why we
recommend ``ParadigmsDut`` for building ``BasicDut`` is that
recommend ``ParadigmsGer`` for building ``BasicGer`` is that
the coverage of the paradigms gets thereby tested and that the
use of the paradigms in ``BasicDut`` gives a good set of examples for
use of the paradigms in ``BasicGer`` gives a good set of examples for
those who want to build new lexica.
@@ -459,29 +483,25 @@ worst-case paradigms (``mkV`` etc).
You can often find resources such as lists of
irregular verbs on the internet. For instance, the
[Dutch for Travelers http://www.dutchtrav.com/gram/irrverbs.html]
[Irregular German Verbs http://www.iee.et.tu-dresden.de/~wernerr/grammar/verben_dt.html]
page gives a list of verbs in the
traditional tabular format, which begins as follows:
```
begrijpen begrijp begreep begrepen to understand
bijten bijt beet gebeten to bite
binden bind bond gebonden to tie
breken breek brak gebroken to break
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
```
All you have to do is to write a suitable verb paradigm
```
irregV : Str -> Str -> Str -> Str -> V ;
irregV : (x1,_,_,_,_,x6 : Str) -> V ;
```
and a Perl or Python or Haskell script that transforms
the table to
```
begrijpen_V = irregV "begrijpen" "begrijp" "begreep" "begrepen" ;
bijten_V = irregV "bijten" "bijt" "beet" "gebeten" ;
binden_V = irregV "binden" "bind" "bond" "gebonden" ;
backen_V = irregV "backen" "bäckt" "back" "backte" "backte" "gebacken" ;
befehlen_V = irregV "befehlen" "befiehlt" "befiehl" "befahl" "beföhle" "befohlen" ;
```
(You may want to use the English translation for some purpose, as well.)
When using ready-made word lists, you should think about
coyright issues. Ideally, all resource grammar material should
@@ -510,7 +530,7 @@ 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
the copy and paste method (from English to Dutch), that is, formally
the copy and paste method (from English to German), that is, formally
speaking, from scratch. A more elegant solution available for
families of languages such as Romance and Scandinavian is to
use parametrized modules. The advantages are