Entwicklung

[ Weiter ] [ Zurück ] [ Zurück (Seitenende) ] [ Seitenende ] [ Überkapitel ] [ Bitte Skript-Fehler melden ]

12.2. Entwicklung

12.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. Modiﬁkationen 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 Modiﬁkationen. 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 "<Makeﬁle"> werden die Abhängigkeiten der Systemkomponenten beschrieben.
Und festgehalten, wie neue Komponenten automatisch aus bestehenden generiert werden.
Bei Änderungen werden nur die von der modiﬁzierten Komponente/Datei abhängigen Komponenten neu erzeugt.
Durch Analysieren aller Abhängigkeiten kann ein einziger make-Befehl zuverlässig und eﬃzient das ganze System neu erzeugen.
Unterschiedliche Varianten eines Systems lassen sich gut in Makeﬁles deﬁnieren und erzeugen.

Makeﬁle-Beispiel

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

%.xfst.bin: %.xfst
xfst -e ’source $<;’ -e ’save defined $@’ -stop

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

Beispiel 12.2.1 (Aufruf von make).
$ make adj.xfst.bin löst den Befehl aus:
xfst -e ’source adj.xfst’ -e ’save defined adj.xfst.bin’ -stop

12.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]

Unterspeziﬁkation 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: Inﬁnitiv 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 ﬁnalen lexikalischen Seite daraus erzeugen.
Die Grundform ﬂektierter 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 deﬁniert sein. Ansonsten ist die Generierung von Wortformen kaum möglich.
Typischerweise folgen die Tags dem Lemma – sprachspeziﬁsche Ausnahmen von dieser Regel sind möglich (semitische Sprachen oder Sprachen, wo Präﬁgierung wichtiger ist als Suﬃgierung).
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.

Beispiel 12.2.2 (Xerox-Mehrzeichensymbol-Tags im +-Format).

+Noun    ! noun(house)
+Prop    ! proper noun(John)
+Art     ! article (like English the and a)
+Det     ! determiner (like this,that,those)
+Dig     ! digit-based word
+Aug     ! augmentative
+Dim     ! diminutive
...

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

12.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 diﬀerenziert wie möglich sein (z.B. Merkmale für Brasilianisch oder rechtschreibereformbetroﬀene Wörter)

Runtime-Anwendungen

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

Runtime-Anwendungen

Beispiel 12.2.3 (Modiﬁkation von Kern-System durch Ersetzungsregeln).

read regex StrictGermanCoreNetwork
.o. [ü (->) u e ] .o. [ö (->) o e ]
.o. [ä (->) a e ] .o. [ß (->) s s ];

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

Beispiel 12.2.4 (Grossschreibung).
Wie kann man Grossschreibung von normalerweise kleingeschriebenen Wörtern erlauben?

Beispiel 12.2.5 (Kapitalisierung).
Wie kann man durchgängige Grossschreibung erlauben wie in “Dieses Verhalten ist KRANK!!!”?

lookup-Strategien mit “virtueller” Komposition [BEESLEY und KARTTUNEN 2003b, 433]

Scheiternsabhängige Alternativ-Analysen

Analysen mit Relaxierung sollen nur dann gemacht werden, wenn keine “normale” Analyse möglich ist.

FST-Variablen: deaccent allow-deaccentuation.fst normalize allow-allcaps.fst analyser deutsch.fst
Virtuelle Komposition: Hintereinanderschreiben der FST-Variablennamen
Strategien
analyser # Versuche zuerst normale Analyse
allcap analyser # Sonst entkapitalisiere zuerst
deaccent allcap analyser # Sonst normalisiere Spezialzeichen vor Entkapitalisierung

[ Weiter ] [ Zurück ] [ Zurück (Seitenende) ] [ Seitenbeginn ] [ Überkapitel ] [ Bitte Skript-Fehler melden ]