A computational grammar and lexicon for Maltese

include the derived form number and root radicals where relevant. Thus rikeb (‘he rode’)
becomes rikeb_RKB_1_9451_V.
2. A function is defined in the abstract syntax module for this identifier, with a category to
match its POS.
3. A linearisation for this function is defined in the concrete syntax module, which uses a
smart paradigm for the particular POS and supplying (minimally) a lemma form. In the
case of Maltese verbs, the root is also supplied since this information is available in the
lexicon.
At the end of this process one has a pair of modules which together constitute a monolingual
dictionary in GF. As with the rest of a resource grammar, such modules are typically not used
directly but imported in other application grammars as required.
Quality
It is common to require some post-editing of the generated dictionary grammars since invariably
in some cases the wrong paradigm will be chosen. As dictionaries are often quite large
however, this might turn into a somewhat time-consuming task.
While GF smart paradigms are generally designed to work with minimal information, all
relevant data that exists in the source word list can and should be be used in order to improve
the accuracy of the smart paradigm. Specifically, valency information would help in order to
choose between the correct forms of each lexical category, such as V, V2 etc. Unfortunately only
minimal amounts of valency information is available in the given sources and thus can only be
made use of to a small extent.
3.3.2 Dictionary modules
A monolingual dictionary in GF has function identifiers which are not shared with other languages.
For this reason, the dictionary must consist of both an abstract and concrete module.
The following is an example from each:
abstract DictMltAbs = Cat ** {
...
fun rikeb_RKB_1_9451_V : V ;
...
}
concrete DictMlt of DictMltAbs = CatMlt ** open ParadigmsMlt in {
...
lin rikeb_RKB_1_9451_V = mkV "rikeb" (mkRoot "r-k-b") ;
...
}
57