📄 Maltilex: A Computational Lexicon for Maltese

Summary

Maltese was in everyday use in 1998 but had almost no NLP infrastructure. It is also hard to model because it mixes a Semitic (Maghrebi Arabic) base with heavy Romance and lighter English layers, all in a Latin script. The authors avoided both an application-first and a theory-first start. Instead they began building a machine-tractable lexicon, which serves both goals.

The first step is deliberately modest: a consistent, machine-readable list of basic lexical entries, with spell-checking as the first application. Entries are typed in by hand through a web form, using the "major" (capitalised) headwords of Aquilina's 1987 Maltese-English dictionary. Inflected forms are left to a separate morphology component. In parallel, the team is collecting a growing corpus of newspapers, books and radio news. They also define their own text encoding to cope with the chaotic local font standards.

The paper reports no evaluation numbers. Its value is as a blueprint for bootstrapping lexical resources for an under-resourced, morphologically rich mixed language.

Key points

• Maltese morphology is root-and-pattern, for example the root h-d-m yields forms for "work", "worker" and "be worked". Broken plurals are applied even to loanwords, such as pizza → pizez and the English-derived ċippa → ċipep. Some words allow free variation with suffix-based sound plurals.

• Loan verbs such as spjega ("explain") and ixxutja ("kick a ball") are fully absorbed into the Semitic conjugation. Verbs can also stack many affixes, as in bagħat-t-hie-lu-x ("I didn't send her to him").

• Each entry form has these fields:

  • headword, homonym number and polyseme number, with the numbering taken from the printed dictionary's order;
  • root (for Semitic words) or stem (for non-Semitic words);
  • spelling variants, such as farfett/ferfett;
  • plural information;
  • lexicographer comments.

  Entry content points back to Aquilina's dictionary rather than copying it.

• Corpus sources are Maltese newspapers, book excerpts from publishers, and national radio news speech with parallel transcripts.

• Characters are encoded with ISO8859-3 (Latin-3) fonts ("Tornado", "FTIMAL") and an internal format, SMTR. SMTR is human-editable, Unix-friendly and converted to other encodings with Xerox xfst. Planned next steps are finite-state extraction from corpora, an HPSG-based grammar, and computational morphology of plurals.

Interesting ideas

• I1. The lexicon stores only base lexemes, and inflected surface forms are produced by a separate rule-based morphological mapping; this keeps the word list small and makes inflection systematic rather than enumerated.
• I2. Entries are keyed by headword plus two separate integers, one for homonyms and one for polysemes, which cleanly separates "different words that look alike" from "one word with several senses".
• I3. Corpus and lexicon grow in a loop: the corpus adds entries to the lexicon, the lexicon is used to annotate the corpus, and the annotated corpus trains taggers.
• I4. Instead of trusting messy external encodings, the project defines one internal canonical text format that is readable, editable and reversibly converted by simple finite-state transducers.
• I5. The project codifies the uncontentious core first and defers disputed linguistic questions until data exists to settle them.

For Mova

How these ideas could serve Mova, our small open language model — its files, stages and tests:

• I1 (tokens): Keep the lemma lexicon in crate en minimal and push all inflection into explicit, inspectable morphology rules, so every surface form can be traced back to a lemma plus a rule.
• I2 (world): Use the same two-level key for ontology and WordNet-linked entries, so that frame and entity linking can say explicitly whether an ambiguity is homonymy or polysemy.
• I3 (learn): Frame silver-data rounds as this explicit loop, where each lexicon update re-tags the corpus and the retagged corpus is checked before it feeds the next training pass.
• I4 (tokens): Normalize all input (quotes, dashes, odd Unicode) into one documented canonical form via reversible, explainable transforms, so tokenizer behaviour never depends on the source encoding.
• I5 (tree): When converting UD dialects or treebanks, convert the clearly agreed constructions first and log contested ones separately rather than forcing a premature decision.