10.2
 Entwicklung

10.2.1
 Tools

Nutzen von klassischen Software-Engineering-Tools 

Versionskontrolle: Z.B. CVS (www.nongnu.org/cvs) oder git

• Zentrales Archiv des Quellkodes; Entwickler arbeiten immer in privaten "<Sandkasten">, wo sie weiter entwickeln. Modifikationen werden ins Archiv zurückgespielt, wenn die Sandkastenversion zufriedenstellend funktioniert. git erlaubt verteilte Archive.
• Ermöglicht kontrollierte System-Entwicklung im Team : Entdeckung und Verwaltung von konkurrenzierenden Modifikationen. Einfache Übernahme von aktualisierten Dateien aus dem Archiv.
• Zuverlässiges Rekonstruieren von älteren Zuständen des Systems aus den verschiedenen Versionen der Dateien für Systemvergleiche.
• Erlaubt verschiedene Releases und verzweigende Entwicklungsäste über einen gemeinsamen Bestand von Quellkodes.
• Änderungen können wegen der Unterstützung durch das Revisionssystem leicht zurückverfolgt werden.

Nutzen von klassischen Software-Engineering-Tools 

Systemkompilation: Z.B. GNU make (www.gnu.org/software/make)

• In einem "<Makefile"> werden die Abhängigkeiten der Systemkomponenten beschrieben.
• Und festgehalten, wie neue Komponenten automatisch aus bestehenden generiert werden.
• Bei Änderungen werden nur die von der modifizierten Komponente/Datei abhängigen Komponenten neu erzeugt.
• Durch Analysieren aller Abhängigkeiten kann ein einziger make-Befehl zuverlässig und effizient das ganze System neu erzeugen.
• Unterschiedliche Varianten eines Systems lassen sich gut in Makefiles definieren und erzeugen.

Makefile-Beispiel 

make-Regel im Deutsch-Morphologieprojekt für Binärkompilation

Falls eine Komponente eine Datei mit der Endung .xfst.bin (sog. target) benötigt : Schaue, ob eine Datei ohne Endung .bin (sog. prerequisite) existiert. Überprüfe (rekursiv) die Abhängigkeiten der prerequisite und generiere sie allenfalls neu. Falls das target älter ist als die prerequisite, führe den entsprechenden UNIX-Shell-Befehl aus ($@ ist Make-Platzhalter für target und $< für prerequisite).

10.2.2
 Inhalt

Linguistische Analyse und Planung 

Formale linguistische Analyse

Ein Morphologiesystem benötigt eine möglichst gründliche vorangehende linguistische Analyse, welche die Klassen, Regeln und Ausnahmen möglichst detailliert zur Verfügung stellt.

Abstraktion und systematisches Wissen

“The ability to speak multiple languages, though admirable, doesn’t make one a formal linguist any more than having a heart makes one a cardiologist.”

[BEESLEY und KARTTUNEN 2003b, 283]

Unterspezifikation linguistischer Beschreibung

Bei der Implementation handgeschriebener Regelsysteme ergeben sich immer unvorhergesehene Überraschungen trotz aller Planung : Unsicherheiten, Ungenauigkeiten, Unvollständigkeiten. Dies ist auch bei handgeschriebenen wissenschaftlichen Grammatiken der Fall.

Linguistische Analyse 

Repräsentation der lexikalischen Seite

Die exakte Form der Lemmata ist eine Design-Entscheidung des Lexikographen.

• Systeme sollen sich möglichst an die bestehenden lexikographischen Konventionen einer bestimmten Sprache halten: Infinitiv als Grundform im Spanischen (“cantar”); aber in Latein z.B. die 1. Person Singular Indikativ Präsens (“canto”); abstrakte Stämme in Esperanto oder Sanskrit; Konsonantenwurzel in semitischen Sprachen
• Grund für diese konservative Einstellung: Bestehende lexikalische Ressourcen können so einfacher benutzt werden.
• Falls sich implementationstechnisch andere Grundformen eigentlich besser eignen, lassen sich die konventionellen oft auf der finalen lexikalischen Seite daraus erzeugen.
• Die Grundform flektierter Funktionswörter (“die”, “sie”) ist meist unklar.

Linguistische Analyse 

Repräsentation der lexikalischen Seite

Die Anzahl, Form und Abfolge von morphologischen Tags ist eine Design-Entscheidung des Lexikographen.

• Die lexikalische Grammatik , d.h. Kombinationen und Abfolgen der Tags muss fest definiert sein. Ansonsten ist die Generierung von Wortformen kaum möglich.
• Typischerweise folgen die Tags dem Lemma – sprachspezifische Ausnahmen von dieser Regel sind möglich (semitische Sprachen oder Sprachen, wo Präfigierung wichtiger ist als Suffigierung).
• Namen sind Schall und Rauch: Ein Tag lässt sich mittels Ersetzungsoperator jederzeit umbenennen.
• Umstellungen der Tag-Reihenfolge sind allerdings etwas umständlicher – Benutzung von Flag-Diacritics kann hier helfen.

Empfohlene Tags nach Xerox-Konvention  
Im Anhang G [BEESLEY und KARTTUNEN 2003a], welcher im gedruckten Buch keinen Platz mehr fand, sind diverse sprachübergreifende morphologische Tags mit ihrer linguistischen Bedeutung aufgeführt.

Die Laufzeit-Applikation lookup zur morphologischen Analyse behandelt Tags mit der +-Konvention defaultmässig effizient als Mehrzeichensymbole.

10.2.3
 Applikationen

Ein Kernsystem mit mehreren Runtime-Applikationen 

Gemeinsames Kernsystem

• Das Kernsystem sollte möglichst viele Anwendungen unterstützen:
• Dialektale und Standard-Varianten (brasilianisches vs. kontinentales Portugiesisch), verschiedene Standards von Rechtschreibung, Umschreibungen (ss für ß, oe für ö)
• Konsequenz: Das Kernsystem soll so differenziert wie möglich sein (z.B. Merkmale für Brasilianisch oder rechtschreibereformbetroffene Wörter)

Runtime-Anwendungen

• Mache das Kernsystem toleranter (z.B. KAPITALISIERUNG oder kleinschreibung erlauben), spezifischer (Spellchecker für brasilianisches Portugiesisch), erweitert (Zufügen von Spezialwörtern), …
• Erzeuge andere Ausgabe-Formate!

Runtime-Anwendungen 

Relaxierung von Kern-Systemen zur Laufzeit

Das lookup-Tool erlaubt morphologische Analysestrategien, welche fehlerorientiert relaxieren und zur Laufzeit die Komposition von Transduktoren simulieren:

• Falls eine Wortform nicht erkannt wird vom normalen System, erlaube deakzentuierten Input.
• Falls weiterhin keine Analyse vorliegt, erlaube Kapitalisierung.
• Falls weiterhin keine Analyse vorliegt, verwende einen heuristischen “Guesser”, welcher ohne Lexikon arbeitet.

Klein-/Grossschreibung 

lookup-Strategien mit “virtueller” Komposition  

Alternativ-Analysen, nur falls bisher keine gefunden

Analysen mit Relaxierung sollen nur dann gemacht werden, wenn keine “normale” Analyse möglich ist. [BEESLEY und KARTTUNEN 2003b, 433]

1. FST-Variablen :
   
   deaccent     allow-deaccentuation.fst
   normalize    allow-allcaps.fst
   analyser     deutsch.fst
2. Virtuelle Komposition : Schreibe die FST-Variablen hintereinander!
3. Strategien
   
   analyser                          # Versuche zuerst normale Analyse
   allcap analyser                   # Sonst entkapitalisiere zuerst
   deaccent allcap analyser          # Sonst deakzentiere vor Entkapitalisierung