11.2.  Entwicklung

11.2.1.  Tools

Nutzen von klassischen Software-Engineering-Tools

Versionskontrolle: Z.B. CVS (http://www.cvshome.org)

• 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.
• 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 in mOLIFde 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 folgenden UNIX-Shell-Befehl aus ($@ ist Platzhalter für target und $< für prerequisite):

xfst -e ’source $<;’ -e ’save defined $@’ -stop

11.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 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.

11.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.
• Fall weiterhin keine Analyse vorliegt, erlaube Kapitalisierung.