mirror of
https://github.com/GrammaticalFramework/gf-core.git
synced 2026-04-12 06:19:33 -06:00
620 lines
24 KiB
HTML
620 lines
24 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="generator" CONTENT="http://txt2tags.sf.net">
|
|
<TITLE>Resource grammar writing HOWTO</TITLE>
|
|
</HEAD><BODY BGCOLOR="white" TEXT="black">
|
|
<P ALIGN="center"><CENTER><H1>Resource grammar writing HOWTO</H1>
|
|
<FONT SIZE="4">
|
|
<I>Author: Aarne Ranta <aarne (at) cs.chalmers.se></I><BR>
|
|
Last update: Thu Jan 5 23:19:40 2006
|
|
</FONT></CENTER>
|
|
|
|
<P></P>
|
|
<HR NOSHADE SIZE=1>
|
|
<P></P>
|
|
<UL>
|
|
<LI><A HREF="#toc1">The resource grammar API</A>
|
|
<UL>
|
|
<LI><A HREF="#toc2">Phrase category modules</A>
|
|
<LI><A HREF="#toc3">Infrastructure modules</A>
|
|
<LI><A HREF="#toc4">Lexical modules</A>
|
|
</UL>
|
|
<LI><A HREF="#toc5">Phases of the work</A>
|
|
<UL>
|
|
<LI><A HREF="#toc6">Putting up a directory</A>
|
|
<LI><A HREF="#toc7">The develop-test cycle</A>
|
|
<LI><A HREF="#toc8">Resource modules used</A>
|
|
<LI><A HREF="#toc9">Morphology and lexicon</A>
|
|
<LI><A HREF="#toc10">Lock fields</A>
|
|
<LI><A HREF="#toc11">Lexicon construction</A>
|
|
</UL>
|
|
<LI><A HREF="#toc12">Inside phrase category modules</A>
|
|
<UL>
|
|
<LI><A HREF="#toc13">Noun</A>
|
|
<LI><A HREF="#toc14">Verb</A>
|
|
<LI><A HREF="#toc15">Adjective</A>
|
|
</UL>
|
|
<LI><A HREF="#toc16">Lexicon extension</A>
|
|
<UL>
|
|
<LI><A HREF="#toc17">The irregularity lexicon</A>
|
|
<LI><A HREF="#toc18">Lexicon extraction from a word list</A>
|
|
<LI><A HREF="#toc19">Lexicon extraction from raw text data</A>
|
|
<LI><A HREF="#toc20">Extending the resource grammar API</A>
|
|
</UL>
|
|
<LI><A HREF="#toc21">Writing an instance of parametrized resource grammar implementation</A>
|
|
<LI><A HREF="#toc22">Parametrizing a resource grammar implementation</A>
|
|
</UL>
|
|
|
|
<P></P>
|
|
<HR NOSHADE SIZE=1>
|
|
<P></P>
|
|
<P>
|
|
The purpose of this document is to tell how to implement the GF
|
|
resource grammar API for a new language. We will <I>not</I> cover how
|
|
to use the resource grammar, nor how to change the API. But we
|
|
will give some hints how to extend the API.
|
|
</P>
|
|
<P>
|
|
<B>Notice</B>. This document concerns the API v. 1.0 which has not
|
|
yet been released. You can find the beginnings of it
|
|
in <A HREF=".."><CODE>GF/lib/resource-1.0/</CODE></A>. See the
|
|
<A HREF="../README"><CODE>resource-1.0/README</CODE></A> for
|
|
details on how this differs from previous versions.
|
|
</P>
|
|
<A NAME="toc1"></A>
|
|
<H2>The resource grammar API</H2>
|
|
<P>
|
|
The API is divided into a bunch of <CODE>abstract</CODE> modules.
|
|
The following figure gives the dependencies of these modules.
|
|
</P>
|
|
<P>
|
|
<IMG ALIGN="left" SRC="Lang.png" BORDER="0" ALT="">
|
|
</P>
|
|
<P>
|
|
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.
|
|
</P>
|
|
<P>
|
|
<IMG ALIGN="middle" SRC="Test.png" BORDER="0" ALT="">
|
|
</P>
|
|
<P>
|
|
The module structure is rather flat: almost every module is a direct
|
|
parent of the top module (<CODE>Lang</CODE> or <CODE>Test</CODE>). The idea
|
|
is that you can concentrate on one linguistic aspect at a time, or
|
|
also distribute the work among several authors.
|
|
</P>
|
|
<A NAME="toc2"></A>
|
|
<H3>Phrase category modules</H3>
|
|
<P>
|
|
The direct parents of the top could be called <B>phrase category modules</B>,
|
|
since each of them concentrates on a particular phrase category (nouns, verbs,
|
|
adjectives, sentences,...). A phrase category module tells
|
|
<I>how to construct phrases in that category</I>. You will find out that
|
|
all functions in any of these modules have the same value type (or maybe
|
|
one of a small number of different types). Thus we have
|
|
</P>
|
|
<UL>
|
|
<LI><CODE>Noun</CODE>: construction of nouns and noun phrases
|
|
<LI><CODE>Adjective</CODE>: construction of adjectival phrases
|
|
<LI><CODE>Verb</CODE>: construction of verb phrases
|
|
<LI><CODE>Adverb</CODE>: construction of adverbial phrases
|
|
<LI><CODE>Numeral</CODE>: construction of cardinal and ordinal numerals
|
|
<LI><CODE>Sentence</CODE>: construction of sentences and imperatives
|
|
<LI><CODE>Question</CODE>: construction of questions
|
|
<LI><CODE>Relative</CODE>: construction of relative clauses
|
|
<LI><CODE>Conjunction</CODE>: coordination of phrases
|
|
<LI><CODE>Phrase</CODE>: construction of the major units of text and speech
|
|
</UL>
|
|
|
|
<A NAME="toc3"></A>
|
|
<H3>Infrastructure modules</H3>
|
|
<P>
|
|
Expressions of each phrase category are constructed in the corresponding
|
|
phrase category module. But their <I>use</I> takes mostly place in other modules.
|
|
For instance, noun phrases, which are constructed in <CODE>Noun</CODE>, are
|
|
used as arguments of functions of almost all other phrase category modules.
|
|
How can we build all these modules independently of each other?
|
|
</P>
|
|
<P>
|
|
As usual in typeful programming, the <I>only</I> thing you need to know
|
|
about an object you use is its type. When writing a linearization rule
|
|
for a GF abstract syntax function, the only thing you need to know is
|
|
the linearization types of its value and argument categories. To achieve
|
|
the division of the resource grammar to several parallel phrase category modules,
|
|
what we need is an underlying definition of the linearization types. This
|
|
definition is given as the implementation of
|
|
</P>
|
|
<UL>
|
|
<LI><CODE>Cat</CODE>: syntactic categories of the resource grammar
|
|
</UL>
|
|
|
|
<P>
|
|
Any resource grammar implementation has first to agree on how to implement
|
|
<CODE>Cat</CODE>. Luckily enough, even this can be done incrementally: you
|
|
can skip the <CODE>lincat</CODE> definition of a category and use the default
|
|
<CODE>{s : Str}</CODE> until you need to change it to something else. In
|
|
English, for instance, most categories do have this linearization type!
|
|
</P>
|
|
<P>
|
|
As a slight asymmetry in the module diagrams, you find the following
|
|
modules:
|
|
</P>
|
|
<UL>
|
|
<LI><CODE>Tense</CODE>: defines the parameters of polarity, anteriority, and tense
|
|
<LI><CODE>Tensed</CODE>: defines how sentences use those parameters
|
|
<LI><CODE>Untensed</CODE>: makes sentences use the polarity parameter only
|
|
</UL>
|
|
|
|
<P>
|
|
The full resource API (<CODE>Lang</CODE>) uses <CODE>Tensed</CODE>, whereas the
|
|
restricted <CODE>Test</CODE> API uses <CODE>Untensed</CODE>.
|
|
</P>
|
|
<A NAME="toc4"></A>
|
|
<H3>Lexical modules</H3>
|
|
<P>
|
|
What is lexical and what is syntactic is not as clearcut in GF as in
|
|
some other grammar formalisms. Logically, however, lexical means
|
|
<CODE>fun</CODE> with no arguments. Linguistically, one may add to this
|
|
that the <CODE>lin</CODE> consists of only one token (or of a table whose values
|
|
are single tokens). Even in the restricted lexicon included in the resource
|
|
API, the latter rule is sometimes violated in some languages.
|
|
</P>
|
|
<P>
|
|
Another characterization of lexical is that lexical units can be added
|
|
almost <I>ad libitum</I>, 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:
|
|
</P>
|
|
<UL>
|
|
<LI><CODE>Structural</CODE>: structural words (determiners, conjunctions,...)
|
|
<LI><CODE>Basic</CODE>: basic everyday content words (nouns, verbs,...)
|
|
<LI><CODE>Lex</CODE>: a very small sample of both structural and content words
|
|
</UL>
|
|
|
|
<P>
|
|
The module <CODE>Structural</CODE> aims for completeness, and is likely to
|
|
be extended in future releases of the resource. The module <CODE>Basic</CODE>
|
|
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.
|
|
</P>
|
|
<P>
|
|
The module <CODE>Lex</CODE> is used in <CODE>Test</CODE> 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.
|
|
</P>
|
|
<P>
|
|
In the case of <CODE>Basic</CODE> 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
|
|
different languages.
|
|
</P>
|
|
<A NAME="toc5"></A>
|
|
<H2>Phases of the work</H2>
|
|
<A NAME="toc6"></A>
|
|
<H3>Putting up a directory</H3>
|
|
<P>
|
|
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 German language. Here are the first steps,
|
|
which we actually followed ourselves when building the German implementation
|
|
of resource v. 1.0.
|
|
</P>
|
|
<OL>
|
|
<LI>Create a sister directory for <CODE>GF/lib/resource/english</CODE>, named
|
|
<CODE>german</CODE>.
|
|
<PRE>
|
|
cd GF/lib/resource/
|
|
mkdir german
|
|
cd german
|
|
</PRE>
|
|
<P></P>
|
|
<LI>Check out the [ISO 639 3-letter language code
|
|
<A HREF="http://www.w3.org/WAI/ER/IG/ert/iso639.htm">http://www.w3.org/WAI/ER/IG/ert/iso639.htm</A>]
|
|
for German: both <CODE>Ger</CODE> and <CODE>Deu</CODE> are given, and we pick <CODE>Ger</CODE>.
|
|
<P></P>
|
|
<LI>Copy the <CODE>*Eng.gf</CODE> files from <CODE>english</CODE> <CODE>german</CODE>,
|
|
and rename them:
|
|
<PRE>
|
|
cp ../english/*Eng.gf .
|
|
rename 's/Eng/Ger/' *Eng.gf
|
|
</PRE>
|
|
<P></P>
|
|
<LI>Change the <CODE>Eng</CODE> module references to <CODE>Ger</CODE> references
|
|
in all files:
|
|
<PRE>
|
|
sed -i 's/English/German/g' *Ger.gf
|
|
sed -i 's/Eng/Ger/g' *Ger.gf
|
|
</PRE>
|
|
The first line prevents changing the word <CODE>English</CODE>, which appears
|
|
here and there in comments, to <CODE>Gerlish</CODE>.
|
|
<P></P>
|
|
<LI>This may of course change unwanted occurrences of the
|
|
string <CODE>Eng</CODE> - verify this by
|
|
<PRE>
|
|
grep Ger *.gf
|
|
</PRE>
|
|
But you will have to make lots of manual changes in all files anyway!
|
|
<P></P>
|
|
<LI>Comment out the contents of these files:
|
|
<PRE>
|
|
sed -i 's/^/--/' *Ger.gf
|
|
</PRE>
|
|
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.
|
|
<P></P>
|
|
<LI>In all <CODE>.gf</CODE> 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.
|
|
<P></P>
|
|
<LI>Now you can open the grammar <CODE>TestGer</CODE> in GF:
|
|
<PRE>
|
|
gf TestGer.gf
|
|
</PRE>
|
|
You will get lots of warnings on missing rules, but the grammar will compile.
|
|
<P></P>
|
|
<LI>At all following steps you will now have a valid, but incomplete
|
|
GF grammar. The GF command
|
|
<PRE>
|
|
pg -printer=missing
|
|
</PRE>
|
|
tells you what exactly is missing.
|
|
<P></P>
|
|
Here is the module structure of <CODE>TestGer</CODE>. It has been simplified by leaving out
|
|
the majority of the phrase category modules. Each of them has the same dependencies
|
|
as e.g. <CODE>VerbGer</CODE>.
|
|
<P></P>
|
|
<IMG ALIGN="middle" SRC="German.png" BORDER="0" ALT="">
|
|
</OL>
|
|
|
|
<A NAME="toc7"></A>
|
|
<H3>The develop-test cycle</H3>
|
|
<P>
|
|
The real work starts now. The order in which the <CODE>Phrase</CODE> 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:
|
|
</P>
|
|
<OL>
|
|
<LI>Select a phrase category module, e.g. <CODE>NounGer</CODE>, and uncomment one
|
|
linearization rule (for instance, <CODE>DefSg</CODE>, which is
|
|
not too complicated).
|
|
<P></P>
|
|
<LI>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).
|
|
<P></P>
|
|
<LI>Think about the categories involved (<CODE>CN, NP, N</CODE>) and the
|
|
variations they have. Encode this in the lincats of <CODE>CatGer</CODE>.
|
|
You may have to define some new parameter types in <CODE>ResGer</CODE>.
|
|
<P></P>
|
|
<LI>To be able to test the construction,
|
|
define some words you need to instantiate it
|
|
in <CODE>LexGer</CODE>. Again, it can be helpful to define some simple-minded
|
|
morphological paradigms in <CODE>ResGer</CODE>, in particular worst-case
|
|
constructors corresponding to e.g.
|
|
<CODE>ResEng.mkNoun</CODE>.
|
|
<P></P>
|
|
<LI>Doing this, you may want to test the resource independently. Do this by
|
|
<PRE>
|
|
i -retain ResGer
|
|
cc mkNoun "Brief" "Briefe" Masc
|
|
</PRE>
|
|
<P></P>
|
|
<LI>Uncomment <CODE>NounGer</CODE> and <CODE>LexGer</CODE> in <CODE>TestGer</CODE>,
|
|
and compile <CODE>TestGer</CODE> 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:
|
|
<PRE>
|
|
gr -cat=NP -number=20 -tr | l -table
|
|
</PRE>
|
|
<P></P>
|
|
<LI>Spare some tree-linearization pairs for later regression testing.
|
|
You can do this way (!!to be completed)
|
|
</OL>
|
|
|
|
<P>
|
|
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
|
|
<CODE>funs</CODE> in <CODE>Test</CODE> (at the moment).
|
|
</P>
|
|
<P>
|
|
Of course, you don't need to complete one phrase category module before starting
|
|
with the next one. Actually, a suitable subset of <CODE>Noun</CODE>,
|
|
<CODE>Verb</CODE>, and <CODE>Adjective</CODE> will lead to a reasonable coverage
|
|
very soon, keep you motivated, and reveal errors.
|
|
</P>
|
|
<P>
|
|
Here is a <A HREF="../german/log.txt">live log</A> 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!)
|
|
</P>
|
|
<A NAME="toc8"></A>
|
|
<H3>Resource modules used</H3>
|
|
<P>
|
|
These modules will be written by you.
|
|
</P>
|
|
<UL>
|
|
<LI><CODE>ResGer</CODE>: parameter types and auxiliary operations
|
|
<LI><CODE>MorphoGer</CODE>: complete inflection engine; not needed for <CODE>Test</CODE>.
|
|
</UL>
|
|
|
|
<P>
|
|
These modules are language-independent and provided by the existing resource
|
|
package.
|
|
</P>
|
|
<UL>
|
|
<LI><CODE>ParamX</CODE>: parameter types used in many languages
|
|
<LI><CODE>TenseX</CODE>: implementation of the logical tense, anteriority,
|
|
and polarity parameters
|
|
<LI><CODE>Coordination</CODE>: operations to deal with lists and coordination
|
|
<LI><CODE>Prelude</CODE>: general-purpose operations on strings, records,
|
|
truth values, etc.
|
|
<LI><CODE>Predefined</CODE>: general-purpose operations with hard-coded definitions
|
|
</UL>
|
|
|
|
<A NAME="toc9"></A>
|
|
<H3>Morphology and lexicon</H3>
|
|
<P>
|
|
When the implementation of <CODE>Test</CODE> is complete, it is time to
|
|
work out the lexicon files. The underlying machinery is provided in
|
|
<CODE>MorphoGer</CODE>, 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
|
|
</P>
|
|
<UL>
|
|
<LI><CODE>ParadigmsGer</CODE>: morphological paradigms for the lexicographer.
|
|
</UL>
|
|
|
|
<P>
|
|
This module provides high-level ways to define the linearization of
|
|
lexical items, of categories <CODE>N, A, V</CODE> and their complement-taking
|
|
variants.
|
|
</P>
|
|
<P>
|
|
For ease of use, the <CODE>Paradigms</CODE> modules follow a certain
|
|
naming convention. Thus they for each lexical category, such as <CODE>N</CODE>,
|
|
the functions
|
|
</P>
|
|
<UL>
|
|
<LI><CODE>mkN</CODE>, for worst-case construction of <CODE>N</CODE>. Its type signature
|
|
has the form
|
|
<PRE>
|
|
mkN : Str -> ... -> Str -> P -> ... -> Q -> N
|
|
</PRE>
|
|
with as many string and parameter arguments as can ever be needed to
|
|
construct an <CODE>N</CODE>.
|
|
<LI><CODE>regN</CODE>, for the most common cases, with just one string argument:
|
|
<PRE>
|
|
regN : Str -> N
|
|
</PRE>
|
|
<LI>A language-dependent (small) set of functions to handle mild irregularities
|
|
and common exceptions.
|
|
<P></P>
|
|
For the complement-taking variants, such as <CODE>V2</CODE>, we provide
|
|
<P></P>
|
|
<LI><CODE>mkV2</CODE>, which takes a <CODE>V</CODE> and all necessary arguments, such
|
|
as case and preposition:
|
|
<PRE>
|
|
mkV2 : V -> Case -> Str -> V2 ;
|
|
</PRE>
|
|
<LI>A language-dependent (small) set of functions to handle common special cases,
|
|
such as direct transitive verbs:
|
|
<PRE>
|
|
dirV2 : V -> V2 ;
|
|
-- dirV2 v = mkV2 v accusative []
|
|
</PRE>
|
|
</UL>
|
|
|
|
<P>
|
|
The golden rule for the design of paradigms is that
|
|
</P>
|
|
<UL>
|
|
<LI>The user will only need function applications with constants and strings,
|
|
never any records or tables.
|
|
</UL>
|
|
|
|
<P>
|
|
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 <CODE>ParadigmsGer</CODE> module has
|
|
to define constants for those parameter types and constructors that
|
|
the application grammarian may need to use, e.g.
|
|
</P>
|
|
<PRE>
|
|
oper
|
|
Case : Type ;
|
|
nominative, accusative, genitive, dative : Case ;
|
|
</PRE>
|
|
<P>
|
|
These constants are defined in terms of parameter types and constructors
|
|
in <CODE>ResGer</CODE> and <CODE>MorphoGer</CODE>, which modules are are not
|
|
accessible to the application grammarian.
|
|
</P>
|
|
<A NAME="toc10"></A>
|
|
<H3>Lock fields</H3>
|
|
<P>
|
|
An important difference between <CODE>MorphoGer</CODE> and
|
|
<CODE>ParadigmsGer</CODE> is that the former uses "raw" record types
|
|
as lincats, whereas the latter used category symbols defined in
|
|
<CODE>CatGer</CODE>. When these category symbols are used to denote
|
|
record types in a resource modules, such as <CODE>ParadigmsGer</CODE>,
|
|
a <B>lock field</B> is added to the record, so that categories
|
|
with the same implementation are not confused with each other.
|
|
(This is inspired by the <CODE>newtype</CODE> discipline in Haskell.)
|
|
For instance, the lincats of adverbs and conjunctions may be the same
|
|
in <CODE>CatGer</CODE>:
|
|
</P>
|
|
<PRE>
|
|
lincat Adv = {s : Str} ;
|
|
lincat Conj = {s : Str} ;
|
|
</PRE>
|
|
<P>
|
|
But when these category symbols are used to denote their linearization
|
|
types in resource module, these definitions are translated to
|
|
</P>
|
|
<PRE>
|
|
oper Adv : Type = {s : Str ; lock_Adv : {}} ;
|
|
oper Conj : Type = {s : Str} ; lock_Conj : {}} ;
|
|
</PRE>
|
|
<P>
|
|
In this way, the user of a resource grammar cannot confuse adverbs with
|
|
conjunctions. In other words, the lock fields force the type checker
|
|
to function as grammaticality checker.
|
|
</P>
|
|
<P>
|
|
When the resource grammar is <CODE>open</CODE>ed in an application grammar, the
|
|
lock fields are never seen (except possibly in type error messages),
|
|
and the application grammarian should never write them herself. If she
|
|
has to do this, it is a sign that the resource grammar is incomplete, and
|
|
the proper way to proceed is to fix the resource grammar.
|
|
</P>
|
|
<P>
|
|
The resource grammarian has to provide the dummy lock field values
|
|
in her hidden definitions of constants in <CODE>Paradigms</CODE>. For instance,
|
|
</P>
|
|
<PRE>
|
|
mkAdv : Str -> Adv ;
|
|
-- mkAdv s = {s = s ; lock_Adv = <>} ;
|
|
</PRE>
|
|
<P></P>
|
|
<A NAME="toc11"></A>
|
|
<H3>Lexicon construction</H3>
|
|
<P>
|
|
The lexicon belonging to <CODE>LangGer</CODE> consists of two modules:
|
|
</P>
|
|
<UL>
|
|
<LI><CODE>StructuralGer</CODE>, structural words, built by directly using
|
|
<CODE>MorphoGer</CODE>.
|
|
<LI><CODE>BasicGer</CODE>, content words, built by using <CODE>ParadigmsGer</CODE>.
|
|
</UL>
|
|
|
|
<P>
|
|
The reason why <CODE>MorphoGer</CODE> has to be used in <CODE>StructuralGer</CODE>
|
|
is that <CODE>ParadigmsGer</CODE> does not contain constructors for closed
|
|
word classes such as pronouns and determiners. The reason why we
|
|
recommend <CODE>ParadigmsGer</CODE> for building <CODE>BasicGer</CODE> is that
|
|
the coverage of the paradigms gets thereby tested and that the
|
|
use of the paradigms in <CODE>BasicGer</CODE> gives a good set of examples for
|
|
those who want to build new lexica.
|
|
</P>
|
|
<A NAME="toc12"></A>
|
|
<H2>Inside phrase category modules</H2>
|
|
<A NAME="toc13"></A>
|
|
<H3>Noun</H3>
|
|
<A NAME="toc14"></A>
|
|
<H3>Verb</H3>
|
|
<A NAME="toc15"></A>
|
|
<H3>Adjective</H3>
|
|
<A NAME="toc16"></A>
|
|
<H2>Lexicon extension</H2>
|
|
<A NAME="toc17"></A>
|
|
<H3>The irregularity lexicon</H3>
|
|
<P>
|
|
It may be handy to provide a separate module of irregular
|
|
verbs and other words which are difficult for a lexicographer
|
|
to handle. There are usually a limited number of such words - a
|
|
few hundred perhaps. Building such a lexicon separately also
|
|
makes it less important to cover <I>everything</I> by the
|
|
worst-case paradigms (<CODE>mkV</CODE> etc).
|
|
</P>
|
|
<A NAME="toc18"></A>
|
|
<H3>Lexicon extraction from a word list</H3>
|
|
<P>
|
|
You can often find resources such as lists of
|
|
irregular verbs on the internet. For instance, the
|
|
<A HREF="http://www.iee.et.tu-dresden.de/~wernerr/grammar/verben_dt.html">Irregular German Verbs</A>
|
|
page gives a list of verbs in the
|
|
traditional tabular format, which begins as follows:
|
|
</P>
|
|
<PRE>
|
|
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
|
|
</PRE>
|
|
<P>
|
|
All you have to do is to write a suitable verb paradigm
|
|
</P>
|
|
<PRE>
|
|
irregV : (x1,_,_,_,_,x6 : Str) -> V ;
|
|
</PRE>
|
|
<P>
|
|
and a Perl or Python or Haskell script that transforms
|
|
the table to
|
|
</P>
|
|
<PRE>
|
|
backen_V = irregV "backen" "bäckt" "back" "backte" "backte" "gebacken" ;
|
|
befehlen_V = irregV "befehlen" "befiehlt" "befiehl" "befahl" "beföhle" "befohlen" ;
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
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.
|
|
</P>
|
|
<A NAME="toc19"></A>
|
|
<H3>Lexicon extraction from raw text data</H3>
|
|
<P>
|
|
This is a cheap technique to build a lexicon of thousands
|
|
of words, if text data is available in digital format.
|
|
See the <A HREF="http://www.cs.chalmers.se/~markus/FM/">Functional Morphology</A>
|
|
homepage for details.
|
|
</P>
|
|
<A NAME="toc20"></A>
|
|
<H3>Extending the resource grammar API</H3>
|
|
<P>
|
|
Sooner or later it will happen that the resource grammar API
|
|
does not suffice for all applications. A common reason is
|
|
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.
|
|
</P>
|
|
<A NAME="toc21"></A>
|
|
<H2>Writing an instance of parametrized resource grammar implementation</H2>
|
|
<P>
|
|
Above we have looked at how a resource implementation is built by
|
|
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
|
|
</P>
|
|
<UL>
|
|
<LI>theoretical: linguistic generalizations and insights
|
|
<LI>practical: maintainability improves with fewer components
|
|
</UL>
|
|
|
|
<P>
|
|
In this chapter, we will look at an example: adding Portuguese to
|
|
the Romance family.
|
|
</P>
|
|
<A NAME="toc22"></A>
|
|
<H2>Parametrizing a resource grammar implementation</H2>
|
|
<P>
|
|
This is the most demanding form of resource grammar writing.
|
|
We do <I>not</I> recommend the method of parametrizing from the
|
|
beginning: it is easier to have one language first implemented
|
|
in the conventional way and then add another language of the
|
|
same family by aprametrization. This means that the copy and
|
|
paste method is still used, but at this time the differences
|
|
are put into an <CODE>interface</CODE> module.
|
|
</P>
|
|
<P>
|
|
This chapter will work out an example of how an Estonian grammar
|
|
is constructed from the Finnish grammar through parametrization.
|
|
</P>
|
|
|
|
<!-- html code generated by txt2tags 2.3 (http://txt2tags.sf.net) -->
|
|
<!-- cmdline: txt2tags -\-toc -thtml Resource-HOWTO.txt -->
|
|
</BODY></HTML>
|