Entwicklung einer Software zur

Stil- und Grammatikprüfung für englische Texte

Daniel Naber

2002-06-10

Projektarbeit, WS2001/2002 bis SS2002, Universität Bielefeld

Hinweis:

Die aktuelle Version dieser Arbeit ist zu finden unter:

http://www.danielnaber.de/languagetool/

---

Inhaltsverzeichnis

1

Einleitung

2

2

Ziele des Projekts

2

3

Evaluierung der nötigen externen Software

3

3.1

British National Corpus (BNC) .

3

3.2

Eric Brills Part-of-Speech-Tagger

.

3

4

Die Testfälle

4

5

Implementierung der Stil- und Grammatikprüfung

4

5.1

Übersicht .

4

5.2

Das Regelsystem und seine DTD .

7

5.3

Beispiel für die Entwicklung einer Regel .

8

5.4

Prüfung auf ′False Friends′ .

9

5.5

Prüfung auf unerwünschte Wörter .

10

5.6

Prüfungen außerhalb der Regeln .

10

5.7

Geschwindigkeitsoptimierungen .

11

6

Integration in KDE

11

6.1

Was ist KDE? .

11

6.2

Implementierung der grafischen Benutzeroberfläche .

11

7

Installation

12

7.1

Systemvoraussetzungen .

12

7.2

Schrittweises Vorgehen .

14

8

Ergebnisse der Evaluierung der Stil- und Grammatikprüfung

14

9

Bekannte Probleme und mögliche Erweiterungen

16

10 Fazit

16

11 Anhang

17

11.1 Penn Treebank Tagset .

17

11.2 Die Regel-DTD (rules.dtd) .

17

11.3 Die Ergebnis-DTD (result.dtd) .

18

11.4 Benutzer-Dokumentation .

18

11.4.1 Introduction .

18

11.4.2 Known Limitations .

19

11.4.3 Basic Configuration

.

19

11.4.4 Advanced Configuration .

19

11.4.5 Copyright and Licensing .

19

1

---

1

Einleitung

Im Projekt soll eine Stil- und Grammatikprüfung entwickelt werden, ähnlich wie sie heute in kommerziellen Text-

verarbeitungen zu finden ist1. Das Projekt beschränkt sich auf Englisch, da dort einerseits die Grammatikregeln ver-

gleichsweise einfach sind und es so andererseits möglichst viele potentielle Nutzer gibt.

Eine Grammatikprüfung ist einerseits sinnvoll, um Tippfehler zu erkennen, die von der Rechtschreibkontrolle nicht

erfasst werden (z.B.

now

vs.

no

), andererseits können damit fehlerhafte Grammatikkonstruktionen erkannt werden. Da

eine vollständige Prüfung eines Textes, z.B. durch komplettes Parsing, bis heute nicht zufriedenstellend möglich ist,

sollen zur Grammatikprüfung Regeln entwickelt werden, die vor allem typische Fehler finden. Ziel ist einerseits das

Finden vieler Fehler (

Erkennungsrate

), aber auch eine geringe

Fehlerrate

- d.h. korrekte Sätze sollen nicht fälsch-

licherweise als ungrammatisch erkannt werden. Fehlermeldungen und Warnungen sollen eine hilfreiche Erklärung

beinhalten.

Die geplante Stilprüfung umfasst formale Kriterien wie Satzlänge, das Erkennen von Kurzformen (

do not

vs.

don′t

)

aber auch eine semantische Prüfung von Wörtern für Benutzer, für die Englisch eine Fremdsprache ist. Dazu soll eine

Liste mit

False Friends

definiert werden, deren Warnungen einzeln ein- und ausgeschaltet werden können.

Zum Projekt gehört auch die Entwicklung einer einfachen Benutzeroberfläche, die in die Textverarbeitung KWord

integriert werden soll. Die Implementierung der grafischen Benutzeroberfläche (

GUI

) wird in C++ erfolgen, die Pro-

grammlogik (

Backend

) wird in Perl programmiert.

Das fertige Programm soll unter anderem mit Hilfe des British National Corpus getestet werden, um eine ge-

ringe Fehlerrate sicherzustellen. Andererseits werden Testfälle mit Grammatikfehlern entwickelt, so dass mit beiden

Verfahren zusammen genaue Aussagen über die Leistungsfähigkeit der Software möglich sind.

2

Ziele des Projekts

Ziel des Projekts ist eine Software, die kurze bis mittellange Texte auf bestimmte Grammatikfehler und mögliche

stilistische Probleme auf Wortebene prüft. Eine Grammatikprüfung kann zwei Arten von Grammatikfehlern erkennen:

1. Ungrammatische Konstruktionen, die dadurch entstehen, dass der Textproduzent eine Grammatikregel nicht

kennt oder falsch benutzt.

2. Tippfehler und Verwechslungen von Wörtern, die zu einer falschen Grammatik führen, aber von der Recht-

schreibkontrolle nicht erkannt werden. Dazu gehören z.B.

no

/

now

,

their

/

there

und

is

/

it

. Tippfehler, die schon

von einer Rechtschreibkontrolle als Fehler erkannt werden, spielen für die Grammatikprüfung keine Rolle, da

sie von einem Text ausgeht, der bereits mit der Rechtschreibkontrolle geprüft wurde.

Beide Arten von Fehlern können also zu ungrammatischen Sätzen führen. Eine klare Unterscheidung zwischen beiden

Fehlerarten ist nicht immer möglich. So ist z.B. bei der Benutzung von

there

statt

their

nicht klar, ob der Benutzer sich

vertippt hat, oder ob ihm der Bedeutungsunterschied nicht bewusst war.

Die Ziele der Implementierung sind Folgende:

1. Die Prüfung soll korrekte Sätze nicht als fehlerhaft kennzeichnen.

2. Fehlerhafte Sätze sollen als fehlerhaft erkannt werden.

3. Zu erkannten Fehlern soll eine hilfreiche Erklärung angezeigt werden. Der fehlerhafte Satz soll angezeigt wer-

den, mit dem fehlerhaften Wort in hervorgehobener Form. Der angezeigte Satz soll vom Benutzer korrigiert

werden können.

4. Zur Geschwindigkeit: Es soll ein flüssiges interaktives Prüfen von kurzen bis mittellangen Texten möglich sein.

Obwohl in begrenztem Umfang möglich, wird auf eine automatische Korrektur verzichtet. Die Fehlermeldungen und

Hinweise sollen für den Benutzer ausreichend sein, um die Probleme selber zu beheben.

Die Stilprüfung soll Teil der Grammatikprüfung sein, sich also aus Sicht des Benutzers im gleichen Programm

befinden. Sie soll Hinweise zur Lesbarkeit des Textes geben: zu lange Sätze, Benutzung von Kurzformen (

don′t

vs.

do
not

) in formellen Texten, Hinweise auf Wörter die in einem bestimmten Kontext unerwünscht sind (z.B. bei technischer

Dokumentation).

1Eine freie Software - dass heißt eine Software deren Quellcode frei zugänglich ist - zur Stil- und Grammatikprüfung konnte ich auch nach

intensiver Suche nicht finden. Auch wissenschaftliche Projekte wie FLAG [Crysmann] präsentieren lediglich die Ergebnisse in Form von Doku-

mentation, nicht jedoch die eigentliche Software.

2

---

Sowohl bei der Grammatik- als auch bei der Stilprüfung soll der Benutzer über die grafische Oberfläche auswählen

können, welche Prüfungen genau durchzuführen sind.

Bei der Planung des Projekts wurde folgendes Vorgehen festgelegt:

1. Evaluierung der nötigen Software

2. Die folgenden Schritte können z.T. parallel ablaufen:

Entwicklung des Backend, also der Stil- und Grammatikprüfung

Schreiben von Testfällen mit und ohne Stil- und Grammatikfehler bzw. Extraktion der Testfälle aus dem

BNC (British National Corpus). Anwendung der Testfälle zur iterativen Verbesserung des Backend

Integration in KDE, d.h. Entwicklung des Frontend

3. Abschließender Test an realen Texten aus dem BNC, um Aussagen über die Leistungsfähigkeit der Software zu

gewinnen

3

Evaluierung der nötigen externen Software

Zu Beginn des Projekts war nicht vollständig klar, welche andere Software bei der Verwirklichung der Ziele helfen

kann. So wäre z.B. auch ein stärker grammatikorientierter Ansatz denkbar gewesen (statt eines eher patternbasierten

Ansatzes). Als Ziel ist eine Integration in KDE vorgesehen, wodurch sich für die verwendete Software Einschrän-

kungen ergeben: Software, die in das Projekt integriert wird, muss unter einer Open-Source-Lizenz verfügbar sein, da

sonst eine Verbreitung mit KDE nicht möglich ist (mehr zu KDE unter 6.1).

3.1

British National Corpus (BNC)

Der BNC [Burnard, 2001] ist ein kommerzieller Korpus im Umfang von 100 Millionen Wörtern, der 1994 fertiggestellt

wurde. Er umfasst gesprochene und geschriebene Sprache, wobei die geschriebene Sprache den weitaus größeren

Teil einnimmt (etwa 90%). Wie der Name sagt, handelt es sich um britisches Englisch, andere Varianten sind nicht

berücksichtigt, insbesondere auch nicht die amerikanische. Alle Texte stammen von Englisch-Muttersprachlern. Aus

rechtlichen Gründen sind die meisten Texte im Korpus nicht komplett, vielmehr ist jeweils nur der Anfang, der Mittel-

oder der Endteil vorhanden. Es wurde auf eine thematisch und stilistisch große Bandbreite der Text geachtet, so sind

z.B. fiktionale Texte ebenso vorhanden wie wissenschaftliche Veröffentlichungen und technische Dokumentationen.

Sämtliche Texte des Korpus liegen in SGML-annotierter Form vor. Neben den üblichen Metadaten (Überschrift,

Autor, etc.) sind Absätze und Wortarten annotiert. Der BNC ist ein Client-Server-System, wobei der Server unter Unix

und der Client unter Windows läuft.

Relevant ist der BNC für das Projekt weil er eine große Menge von Texten zur Verfügung stellt, an der man die Stil-

und Grammatikprüfung während ihrer Entwicklung testen kann. Dabei sind nur die reinen Texte ohne Annotationen

interessant. Der BNC, also seine Texte und seine Software, sind nicht Teil des fertigen Programms, so dass seine

kommerzielle Lizenz zunächst keine Schwierigkeit darstellt. Eine Verbreitung der Texte zu Testzwecken, z.B. um die

Entwicklung neuer Stil- und Grammatikregeln zu fördern, ist allerdings nicht möglich.

3.2

Eric Brills Part-of-Speech-Tagger

Ein Part-of-Speech-Tagger (kurz: POS-Tagger oder Tagger) weist jedem Wort eines Textes seine Wortart zu. Im Ge-

gensatz zu einem Parser, der einem Satz eine oder mehrere Baumstrukturen zuzuweisen versucht, arbeitet ein Tagger

also ausschließlich auf Wortebene. Viele Wörter können zu mehr als einer Wortart gehören. Insbesondere lassen sich

im Englischen sehr viele Nomen auch als Verben benutzen (z.B.

house

als Nomen: Haus,

house

als Verb: unterbrin-

gen). Häufigere Wörter sind bezüglich ihrer Wortart eher ambig als seltene Wörter, und so kommt es, dass nur 11,5%

der

Wörter

des Brown Korpus, aber 40% des

Gesamttextes

ambig sind. Der Extremfall ist eine 7-fache Ambiguität

beim Wort

still

. Obwohl man allein durch die Auswahl der häufigsten Wortart für das jeweilige Wort schon 91% Kor-

rektheit erreicht, bringen es heutige Tagger üblicherweise nur auf 96-97% Korrektheit [Moore, 2001]. Damit werden

also von 100 Wörtern im Durchschnitt 3-4 falsch getaggt, was allerdings bei dem in diesem Projekt gewähltem Ansatz

von Grammatikprüfung nicht automatisch zu einer ebenso hohen Fehlerrate führt, da nicht auf jedes falsch getaggte

Wort ein Fehler-Pattern zutrifft.

Die Anzahl der erkannten Wortarten unterscheidet sich je nach benutztem Tagger. Eric Brills Tagger [Brill, 1996]

erkennt die 36 Wortarten des Penn Treebank Tagsets (siehe 11.1). Die Genauigkeit ist mit 95-97% angegeben [Brill, 1992].

Der Tagger arbeitet mit Regeln, die er aus einem mit Wortarten annotierten Text automatisch generiert.

3

---

Ähnlich wie bei statistischen Taggern (z.B. QTag [Mason]) erhält man bei Brills Tagger keinen Hinweis auf die

Qualität einer Annotation - eine solche Bewertung wäre z.B. in Form einer Prozentzahl denkbar. Es wird in jedem Fall

einem Wort nur eine einzige Wortart zugewiesen. Bei unbekannten Wörtern wird mit Heuristiken eine Wortart erraten.

Ebenfalls vergleichbar mit statistischen Taggern ist das Laufzeitverhalten: Wegen der großen zu ladenden Daten-

menge dauert allein das Starten des Taggers 1,5 Sekunden2. Die Annotation von 36 Bytes Text (1 Satz) dauert 1,5

Sekunden inklusive Startvorgang, die Annotation von 10.000 Bytes (ca. 80 Sätze) dauert 1,75 Sekunden inklusive

Startvorgang. Der Tagger ist also recht schnell, wenn er einmal gestartet ist.

Neben XTAG [Sakar] ist Brills Tagger offenbar der einzige Tagger, der unter einer freien Lizenz verfügbar ist.

Brills Tagger ist in C implementiert, was eine Integration in bestehende C- und C++-Programme einfach macht.

4

Die Testfälle

Testfälle sind in diesem Fall Texte, bei denen bekannt ist, ob und welche Fehler sie beinhalten. Die Benutzung von

Testfällen ermöglicht Aussagen über die Qualität und Leistungsfähigkeit der Software. Die natürliche Sprache zeichnet

sich durch eine enorme Menge an Wörtern und grammatischen Phänomen aus, was eine entsprechend große Menge

an Testfällen erforderlich macht. Wünschenwert wäre ein umfangreicher annotierter Fehler-Korpus für die englische

Sprache, der jedoch nicht zu existieren scheint. Daher wird nur ein Teil der Testfälle mit der Information versehen, um

welche Fehler es sich handelt.

Die Testfälle unterteilen sich in zwei Kategorien:

"Künstliche" Testfälle: Frei erfundene Sätze, die absichtlich eingebaute Fehler enthalten und der entsprechende

korrekte Satz. Die Sätze wurden passend zu den Fähigkeiten der Software entwickelt. Alle künstlichen Testfälle

enthalten entweder genau einen oder keinen Fehler. Dies und die Art des Fehlers ist zusammen mit den Testfällen

gespeichert. So ist ein systematisches und automatisches Testen aller implementierten Warnungen möglich.

Insbesondere lassen sich

Regresssion Tests

durchführen, die bei Änderungen an der Software sicherstellen, dass

die bisherige Funktionalität nicht beeinträchtigt wurde. Es existieren 49 dieser Testfälle.

"Natürliche" Testfälle fast ohne Fehler: Der BNC bietet ca. 4000 Texte mit zusammen 4 Millionen Sätzen, die

mit diversen Metainformationen annotiert sind. Die Texte stammen größtenteils aus Zeitschriften, Büchern und

sonstigen Veröffentlichungen. Es ist also davon auszugehen, dass die Texte nur wenige grammatische und stili-

stische Fehler beinhalten. Diese Testfälle lassen sich nutzen, um die Fehlerrate der Stil- und Grammatikprüfung

bei tatsächlichen Texten zu ermitteln. Bei einer zu hohen Fehlerrate müssen Regeln entsprechend abgeschwächt

werden.

Die natürlichen Testfälle wurden mit Hilfe eines Perl-Skripts aus dem SGML-Text des BNC in ASCII-Dateien expor-

tiert. Alle Testfälle stammen aus der geschriebenen Sprache. Sie wurden vor und während der Implementierung des

Programms entwickelt/extrahiert.

5

Implementierung der Stil- und Grammatikprüfung

5.1

Übersicht

Die Stil- und Grammatikprüfung besteht aus zwei weitgehend unabhängigen Teilen: dem Backend, das die eigentliche

Prüfung übernimmt, und dem Frontend, mit dem der Benutzer interaktiv arbeiten kann. Diese Trennung hat mehrere

Vorteile:

Die beiden Teile können in unterschiedlichen Programmiersprachen implementiert werden, wie es hier der Fall

ist.

Man kann auf einfache Weise neue Benutzerschnittstellen hinzufügen, z.B. eine, die sich über ein Formular in

einer Webseite bedienen lässt.

Man hat zwei kleine Programmteile statt eines großen, d.h. die Implementierung ist modularer.

Im Einzelnen soll das Backend folgendes leisten:

einen Dateinamen mit dem zu prüfenden Text entgegennehmen

2Alle Zeitmessungen haben auf einem Athlon 900 mit 256 MB RAM stattgefunden.

4

---

diverse Konfigurationseinstellungen entgegennehmen

die Satzgrenzen erkennen

den Text unter Zuhilfenahme externer Tools POS-taggen

die so getaggten Sätze auf Stil- und Grammatikfehler prüfen

das Ergebnis der Prüfung an das aufrufende Programm zurückgeben, und zwar auf eine Art und Weise, die eine

Kennzeichnung des fehlerhaften Wortes zulässt und die eine kurze Erklärung des Fehlers ermöglicht. Dazu wird

das Ergebnis in XML zurückgegeben (s.u.).

Die Aufgaben des Backend sind also von einer möglichen grafischen Benutzeroberfläche unabhängig. Um eine Funk-

tionalität möglichst vielen Programmen zugute kommen zu lassen, werden auch heute üblicherweise noch Biblio-

theken mit C-APIs benutzt. Wie ein solches API (

Application Programming Interface

) aussehen könnte, lässt sich

im Groben schon an den obigen Anforderungen ablesen. Einem einfachen C-API stehen allerdings diverse Probleme

entgegen:

Das Backend selbst ist in Perl implementiert (s.u.). Um auf ein Perl-Programm mittels C zugreifen zu können,

müsste man einen Wrapper in C schreiben.

Selbst wenn ein solcher Wrapper existiert, muss auf dem ausführenden System Perl vorhanden sein. Die mei-

sten Open-Source-Programme sind heute in C, C++ oder Java implementiert, und für sie würde die Forderung

nach Perl eine neue Abhängigkeit darstellen. D.h. alle Benutzer der C/C++/Java-Software müssten auch Perl

installiert haben. Auch wenn das zumindest auf Unix-Systemen kein Problem darstellen sollte, sollten derartige

neue Abhängigkeiten immer sehr kritisch gesehen und besser vermieden werden. Da eine Stil- und Grammatik-

prüfung, vom GUI abgesehen, in keiner Weise KDE-spezifisch ist, sollte auch hier keine solche Abhängigkeit

eingeführt werden.

Ein Ausweg wäre, die Software direkt in C oder C++ zu schreiben. Dies bedeutet jedoch einen erheblich höheren

Entwicklungsaufwand, der sich nur durch Einsatz entsprechend leistungsfähiger Libraries mindern lässt. Benutzt man

jedoch solche Libraries, wie z.B. Qt, ergibt sich wieder das Problem der Abhängigkeiten - Qt ist sehr umfangreich und

sein Einsatz nur wegen der regulären Ausdrücke und Container-Typen (Listen etc.) lässt sich nicht rechtfertigen. Wenn

man ohnehin schon Qt benutzt, wie es bei KDE der Fall ist, ist dies kein Problem, andernfalls macht eine Abhängigkeit

von Qt die Software für andere Entwickler weniger attraktiv.

Um den Implementierungsaufwand also in Grenzen zu halten, wurde das Backend in Perl 5.6 programmiert. Perl

ist eine untypisierte, interpretierte Sprache. Sie ist hauptsächlich prozedural, kann aber auch objektorientiert benutzt

werden. Als Container für Daten stehen Skalare, Arrays und Hashtables zur Verfügung. Perl bietet reguläre Ausdrücke,

und eignet sich damit sehr gut für die Verarbeitung von Strings. XML lässt sich über eines der vielen Module verar-

beiten, die man kostenlos im Internet bekommt. Auch Perl selbst ist freie Software. Durch die fehlende bzw. implizite

Typisierung, die vielen Module und die Tatsache, dass nach Änderungen keine Neukompilierung nötig ist, lassen sich

kleine bis mittelgroße Programme in Perl sehr schnell implementieren.

Das Backend besteht aus folgenden Dateien:

languagechecker_<mod>.pl,

Das Perl-Script, verteilt auf mehrere Dateien

Grammar/Rule.pm

Hilfsmodul für die Regeln

rules_grammar.xml

Pattern, die Grammatik-Fehler erkennen

rules_false_friends.xml

Pattern, die False Friends in verschiedenen Sprachen erkennen

rules_words.xml

Pattern, die unerwünschte Wörter erkennen

rules.dtd

Das Schema der Regel-Dateien

Verzeichnis tagger

Eric Brills Part-of-Speech-Tagger

Hauptprogramm des Backends ist das Perl-Skript languagechecker.pl. Zur Übersichtlichkeit ist es in meh-

rere Dateien aufgeteilt. Es wird mit dem Namen der zu prüfenden Datei und eventuell mit Optionen aufgerufen, die

größtenteils denen im GUI entsprechen:

-verbose

Während des Prüfens Hinweise auf den Fortschritt ausgeben

-errors-only

Bei der Ausgabe nur Sätze mit Fehlermeldungen anzeigen

-test

Automatische Tests durchführen

-grammar=s

IDs der zu benutzenden Grammatikregeln

5

---

-falsefriends=s

IDs der zu benutzenden False-Friend-Regeln

-words=s

IDs der zu benutzenden Wortregeln

-textlanguage=s

Kürzel für die Textsprache, z.B.

en

-mothertongue=s

Kürzel für die Muttersprache des Schreibers, z.B.

de

-max-sentence-length=n

Warnung bei längeren Sätzen ausgeben

Die IDs entsprechen den id-Attributen in den XML-Konfigurationsdateien, mehrere IDs sind durch Kommata

voneinander zu trennen.

Eric Brills Tagger erwartet den zu bearbeitenden Text in folgender Form:

Jeder Satz belegt genau eine Zeile.

Sonderzeichen sind durch mindestens einen Freiraum (Whitespace) von den umgebenden Zeichen getrennt.

Jedes durch Freiraum von den benachbarten Zeichen getrennte Zeichen nennt man in dieser Form

Token

. Ein- und Aus-

gabe sollen an einem Beispiel kurz gezeigt werden. Man beachte auch den teilweise vorhandenen Freiraum vor dem

abschließenden Punkt (die Zeilenumbrüche in der Ausgabe des Perl-Skripts wurden lediglich der Übersichtlichkeit

halber hinzugefügt):

Original-Satz

This is bigger then the other one.

Eingabe Perl-Skript

<Dateiname>

Eingabe Tagger

This is bigger then the other one .

Ausgabe des Taggers

This/DT is/VBZ bigger/RBR then/RB the/DT other/JJ one/CD ./.

Ausgabe Perl-Skript

<text><s>This is bigger

<message text="Comparison requires ′than′.">then</message>

the other one.</s></text>

Der durch einen Schrägstrich abgetrennte zweite Teil eines jeden Tokens der Ausgabe kennzeichnet eine von 36

Wortarten (siehe 3.2). Der Tagger überführt aufeinanderfolgende Freiräume in einen einzelnen Freiraum. Da dies eine

unerwünschte Änderung des Textes darstellt, werden in languagechecker.pl die gefundenen Fehler in dem

ursprünglichen Text annotiert.

languagechecker.pl geht im Einzelnen wie folgt vor: Der Aufruf erfolgt mit dem Namen einer zu testenden

Textdatei oder mit -test. Bei letzterem werden alle Beispiele in den Regeldateien als Testfälle interpretiert. Wird ein

korrekter Satz als falsch erkannt oder wird ein falscher Satz als korrekt erkannt, erfolgt eine entsprechende Warnung

(siehe auch 4).

Im Test- und Normalmodus werden als nächstes die Regeln aus den Dateien rules_grammar.xml , ru-

les_false_friends.xml und rules_words.xml mittels des Perl-Moduls XML::DOM::Parser eingele-

sen und in eine interne, objektorientierte Repräsentation überführt. Danach wird der zu testende Text geladen und in

eine Liste mit Tokens geteilt. Freiraum geht dabei nicht verloren, sondern bildet jeweils ein eigenes Token. In der Liste

der Tokens werden die Satzgrenzen gesucht, so dass sich eine geschachtelte Liste ergibt: Die äußere Liste beinhaltet

die Sätze, die innere die Tokens pro Satz.

Automatisch Satzgrenzen zu erkennen ist nur mit Hilfe von Heuristiken möglich. So wird ein Punkt als Satzende

aufgefasst, es sei denn, er ist von zwei Ziffern umgeben (z.B.

3.14

). Das Erkennen der Satzgrenzen ist also nur bedingt

automatisch möglich und stellt eine mögliche Fehlerquelle dar.

Aus der geschachtelten Liste wird ein String erzeugt, der in einer temporären Datei für den Tagger als Eingabe

benutzt wird. Die Eingabe genügt den Anforderungen des Taggers, so befindet sich zum Beispiel vor und nach Satz-

und Sonderzeichen ein Freiraum.

Für jeden Satz werden nun alle Regeln geprüft, indem jedes Wort und seine Wortart mit den Pattern aller Regeln

verglichen wird. Trifft eine Regel zu, wird das die Regeln und damit den Fehler auslösende Wort im Originaltext mit

einem message-Element umgeben. Das text-Attribut enthält dabei eine kurze Erklärung des Fehlers. Auch bei

Auftreten eines Fehlers werden alle weiteren Regeln geprüft, so dass auch mehrere Fehler in einem Satz gefunden

werden können. Mehrere Fehler für ein und dasselbe Wort werden allerdings nicht unterstützt. Auch wird pro Fehler

immer nur genau ein Wort als falsch gekennzeichnet.

Jeder Satz wird mit einem s-Element umschlossen, diese Elemente werden wiederrum mit einem text-Element

umschlossen und der gesamte XML-String stellt nun die Ausgabe von languagechecker.pl dar (siehe 11.3).

Entfernt man aus der Ausgabe alle Tags so erhält man wieder den Originaltext inklusive Freiraum. Dies ist wichtig,

da das GUI auch interaktive Korrekturen erlauben soll. Der Text soll dabei selbstverständlich bis auf die Korrektur

6

---

unverändert bleiben.

5.2

Das Regelsystem und seine DTD

Die Stil- und Grammatikprüfung ist ein System aus Regeln, die Fehler beschreiben. Die Software sucht im Text nach

Übereinstimmungen mit den Regeln und gibt in einem solchen Fall eine Warnung an den Benutzer aus. Das Pattern,

mit dem der Fehler beschrieben wird, kann sowohl konkrete Wörter als auch Wortformen und Kombinationen von

beidem enthalten. Ähnlich wie bei regulären Ausdrücken wird "|" als Symbol für

oder

benutzt, "^" als Symbol für

nicht

. Andere Merkmale regulärer Ausdrücke wie Wiederholungen werden jedoch nicht unterstützt, außerdem arbeitet

das System nur auf der Wortebene: Denkbare morphologische Analysen von Wörtern finden nicht statt - dies wird

jedoch zum Teil vom Part-of-Speech-Tagger übernommen, der z.B. verschiedene Verbformen unterscheiden kann.

Dieses System bietet also nur eine eingeschränkte Leistungsfähigkeit, insbesondere könnte man damit keine na-

türliche Sprache komplett beschreiben, weil dazu eine kontextfreie Grammatik nötig ist. Eine Sprache komplett zu

beschreiben, macht in diesem Fall jedoch auch keinen Sinn, denn es sollen ja

Fehler

dargestellt werden können, die

per Definition außerhalb der Grammatik der Sprache liegen. Es ist durchaus denkbar, eine stärkere Beschreibungs-

sprache zu benutzen, die eine Grammatik erweitert [Thurmair, 1990]. Dazu könnte man die Regeln der kontextfreien

Grammatik um Fehlerregeln erweitern. Lässt sich ein Satz nur unter Zuhilfenahme dieser Fehlerregeln parsen, ist

er nicht korrekt und eine zu der Fehlerregel passende Warnung kann angezeigt werden. Damit kann man Fehler in

Baumstrukturen beschreiben, statt nur auf Listen, wie bei diesem System. Allerdings hat das stärker strukturorientier-

te Vorgehen auch einige Nachteile:

Es ist weniger effizient als ein Pattern-Matching auf Listen.

Es ist zu klären: Wenn sich ein Satz selbst mit Hilfe der Fehler-Regeln nicht parsen lässt, ist er dann nicht

korrekt (z.B. reiner Wortsalat), oder ist doch die zugrundeliegende Grammatik nicht leistungsfähig genug? Bis

heute existieren für die englische Sprache keine formalen Grammatiken, die leistungsfähig genug sind, alle real

vorkommenden korrekten Sätze eindeutig zu parsen.

Im Fehlerfall stellt sich bei Ambiguitäten in der Struktur die Frage, welches der "richtige" Fehler ist, der dem

Benutzer anzuzeigen ist.

Bereits das POS-Tagging hat nur eine beschränkte Genauigkeit. Ein kompletter Satzbaum lässt sich als eine

weitere Struktur auf den POS-Tags auffassen, da sich in dem generierten Baum direkt überhalb der Wörter

POS-Tags befinden. Beim Parsen handelt es sich also um einen wesentlich komplexeren Prozess als beim POS-

Tagging, weshalb man von einer noch geringeren Korrektheit des Ergebnisses ausgehen muss.

Aufgrund dieser Schwierigkeiten wurde in diesem Projekt also ein patternbasierter Ansatz gewählt. Obwohl Perl - wie

inzwischen viele andere Sprachen - Unterstützung von regulären Ausdrücken bietet, konnte diese nicht benutzt werden,

denn sie arbeitet nur auf Strings3. Strings kann man zwar als Listen von Buchstaben sehen, doch hier kommt eine

weitere Anforderung ins Spiel: Das Pattern arbeitet, wie oben erwähnt, auf zwei Listen gleichzeitig: auf den Wörtern,

und auf ihren Wortarten. Also musste das eigentliche Pattern-Matching in diesem Projekt "von Hand" implementiert

werden, was aufgrund der beschränkten Leistungsfähigkeit nicht schwierig war.

Das hier benutzte Regelsystem erlaubt es, auf sehr ähnliche Weise Stil-, Grammatik- und False-Friends-Regeln zu

definieren. Um die Regeln einfach ergänzen zu können, und um eine mögliche Portierung des Systems auf eine andere

Programmiersprache zu erleichtern, wird XML als Dateiformat benutzt. Da DOM (Document Object Model) als Stan-

dard für den Zugriff auf XML-Daten von allen üblichen Programmiersprachen unterstützt wird, sollten zur Portierung

auf eine andere Programmiersprache als Perl einfache Syntaxänderungen ausreichen. Die nötigen Datenstrukturen der

drei Regelarten unterscheiden sich nur wenig, so dass sich zwar jede Art von Regeln in einer eigenen Datei befindet,

aber alle Dateien der gleichen DTD folgen. Die gemeinsame DTD hat auch den Vorteil, das Einlesen der Regeln im

Programm zu vereinfachen. Dazu wird ein DOM-Modul benutzt, mit dem alle aktiven Regeln bei Programmstart in

eine einheitliche interne Struktur überführt werden.

Das Regelsystem soll, und das ist unabhängig vom XML-Format, alle Warnungen in nur einem Durchlauf ausge-

ben. Hat ein Satz also zwei Fehler, sollen diese direkt hintereinander ausgegeben werden. Es soll nicht nötig sein, erst

einen Fehler zu korrigieren, um dann erst in einem zweiten Durchlauf den zweiten Fehler zu entdecken.

3Der Perl-Befehl grep() arbeitet mit regulären Ausdrücken auf Listen, er betrachtet aber jeweils nur ob

ein

Listenelement dem regulären Aus-

druck genügt.

7

---

5.3

Beispiel für die Entwicklung einer Regel

Der Prozess zur Entwicklung einer neuen Regel läuft beispielhaft folgendermaßen ab:

1. Man sucht Stil- und Grammatikfehler im World Wide Web oder in Mailing-Listen, z.B. mit Hilfe der Suchan-

frage

"sorry for my bad english"

(inkl. Anführungszeichen) auf Google, was zu ca. 8000 Treffern führt4. Dabei

ist davon auszugehen, dass ein Großteil der Fehler von Menschen stammt, für die Englisch eine Fremdsprache

ist. Man sollte sich vorwiegend auf häufige und damit typische Fehler beschränken, andernfalls wird möglicher-

weise die Fehlerregel zu komplex und die Chance auf fälschlich ausgelöste Warnungen steigt.

2. Man formuliert für den Fehler einige Regelverstöße, z.B. ausgehend vom ursprünglich falschen Satz. Zu jedem

fehlerhaften Satz entwickelt man das entsprechende korrekte Pendant.

3. Lassen sich die Fehler als Pattern ausdrücken? Wenn ja, ist eine Regel in der XML-Datei ausreichend, andern-

falls ist eine neue Funktion im Perl-Programm nötig (dies sollte die Ausnahme bleiben, z.B. für statistische

Kriterien wie die Satzlänge).

4. Man benutzt die in 2. ausgedachten Beispiele als Testfälle, indem man sie zusammen mit dem sie bschreibenden

Pattern der XML-Datei hinzufügt und das Programm im Testmodus aufruft:

./languagechecker.pl -test

Dabei werden alle Beispiele aus der XML-Datei geprüft. Die mit type="correct" gekennzeichneten dürfen

keine Warnung liefern, die mit type="incorrect" gekennzeichneten müssen eine Warnung liefern, und

zwar vom Typ der Regel, in der sie sich befinden. Alle Abweichungen davon zeigt der Testmodus an. Bei einem

korrekten System, das alle Fehlerbeispiele als Fehler des tatsächlichen Typs erkennt, und kein korrektes Beispiel

für fehlerhaft hält, lautet die Ausgabe dann "0 problems found in test mode".

5. Man prüft Sätze aus einer möglichst großen Teilmenge des BNC. Soweit möglich, ist bei allen angezeigten

Warnungen zu prüfen, ob es sich tatsächlich um einen Fehler im Text handelt, oder ob das Pattern unberech-

tigterweise auf einen korrekten Text zutrifft. Zum Prüfen sollte man ASCII-Dateien aus dem BNC extrahieren,

was z.B. mit folgendem Kommando möglich ist:

tool/bnc2txt.pl bnc/A3/* >ausgabe.txt

Damit werden alle Texte aus dem Verzeichnis A3 geladen, die Annotationen und Entitäten werden entfernt und

der Text nach ausgabe.txt umgeleitet. Diese Datei lässt sich dann prüfen:

./languagechecker.pl ausgabe.txt

Hier ein Beispiel für eine Fehler-Regel, wie sie in der XML-Datei rules_grammar.xml steht:

<rule id="AS_ADJ_AS">

<pattern lang="en">

"as" JJ "(like|than|then)

"</pattern>

<message>

Comparison requires ′as′ + adj + ′as′

.</message>

<error_rate>

0.028

</error_rate>

<marker>

2

</marker>

<example type="correct">

This house is as big

<em>

as

</em>

mine.

</example>

<example type="incorrect">

This house is as big

<em>

like

</em>

mine.

</example>

</rule>

Ausgegangen wird hier von der Regel, dass ein Vergleich bei Gleichheit immer in der Form

as

+ Adjektiv +

as

erfolgen muss.

Das Pattern beschreibt drei typische Fehler in dieser Situation, wobei Begriffe in doppelten Anführungszeichen

Wörter des Textes sind, alles andere sind die vom Tagger festgestellten Wortarten der Wörter im Text. Das Pattern

würde also bei

as big like

die Warnung ausgeben, die im message-Element abgelegt ist. Das Element error_rate

ist die Prozentzahl der Sätze, zu denen fälschlicherweise eine Warnung erscheint, obwohl sie korrekt sind (bezogen

auf die Gesamtheit aller zu prüfenden Sätze, ermittelt an den Texten des BNC).

Bei der folgenden Regel wird eine Ausnahme mit Hilfe der Negation implementiert: Das Pattern trifft zu auf

Modalverben, denen konjugierte Verben folgen, vor denen aber kein Determiner steht:

<rule id="WILL_MIGHT_BASE">

<pattern lang="en">

^(DT) MD (VBD|VBG|VBN|VBZ)

</pattern>

4Weitere Anfragen, die amüsanterweise ebenfalls zu Treffern führen:

"sorry for my bat english"

,

"sorry for my bed english"

8

---

<message>

Modal verbs like ′will′/′might′/... require base form of verb.

</message>

<error_rate>

0.018

</error_rate>

<marker>

2

</marker>

<example type="correct">

John will

<em>

talk

</em>

to her.

</example>

<example type="correct">

John will

<em>

go

</em>

home.

</example>

<example type="incorrect">

John will

<em>

goes

</em>

home.

</example>

<example type="incorrect">

John will

<em>

walked

</em>

home.

</example>

</rule>

5.4

Prüfung auf ′False Friends′

False Friends sind Wortpaare aus zwei Sprachen, die ähnlich gesprochen und/oder geschrieben werden, aber etwas

anderes bedeuten. Durch die scheinbare Vertrautheit mit dem Wort aus der Muttersprache wird man als Benutzer einer

Fremdsprache leicht dazu tendieren, das Wort in seiner falschen Bedeutung zu benutzen. Dies ist offensichtlich für

Lerner einer Sprache ein besonderes Problem. False Friends gibt es nicht nur zwischen Deutsch und Englisch, sondern

zwischen sehr vielen Sprachen. Aufgrund der gemeinsamen Wurzeln einiger Sprachen handelt es sich teilweise um

die gleichen Worte, z.B. ist

sensible

(englisch) für einen Deutsch-Muttersprachler (der

sensibel

kennt) auf genau die

gleiche Weise ein False Friend wie für den Französisch-Muttersprachler (der das französische

sensible

kennt). Das

Paar

sensibel

(deutsch) /

sensible

(franz.) ist dagegen kein False Friend, da die aus der Muttersprache nahegelegte

Bedeutung auch der tatsächlichen Bedeutung des Fremdwortes entspricht.

Lässt man Fachsprachen, z.B. Wirtschaftsenglisch[Weidacher, 1992], außer Acht, beträgt die Zahl der False-

Friend-Wortpaare zwischen Englisch und Deutsch ca. 100-200. Diese Zahl basiert auf den Quellen [Bosewitz, 1999,

False Friends, Breitkreuz, 1997]. Dabei gibt es naheliegende und weniger naheliegende Paare, so ist z.B. davon aus-

zugehen, dass ein Wortpaar eher verwechselt wird, wenn es in beiden Sprachen zur gleichen Wortart gehört. Die

Bedeutung von Wortpaaren ist nicht zwangläufig völlig verschieden oder völlig gleich, Wortpaare können auch ei-

ne "etwas andere" Bedeutung haben (in [Breitkreuz, 1997] als

partielle False Friends

bezeichnet). Dieser graduelle

Übergang ist in diesem Projekt nicht modelliert. Die für dieses Projekt zusammengestellte Liste von False Friends soll

nicht unbedingt vollständig, aber doch für den täglichen Einsatz nützlich sein.

Die Informationen über False Friends sind eigentlich am Besten in einem zweisprachigen Wörterbuch aufgeho-

ben. Dort ließen sich die entsprechenden Wörter mit einem "nicht zu verwechseln mit"-Link versehen, der von einer

Software ausgewertet werden könnte, die auf diese Weise aus dem Wörterbuch auf Wunsch eine Liste aller False

Friends extrahiert. Es ist aber völlig unrealistisch anzunehmen, dass für alle möglichen Sprachpaare ein kostenloses

Wörterbuch in elektronischer Form verfügbar ist, dessen Format sich auch noch um entsprechende Links erweitern

lässt.

Deshalb wurde hier ein anderer Ansatz gewählt: Es wurde eine XML-Datei entwickelt, die die False Friends

zwischen

beliebigen

Sprachen auf möglichst redundanzfreie und damit kompakte Weise beinhaltet - aber eben nur

False Friends, und keine anderen Wörter. Konkret befinden sich in der Datei ca. 80 deutsch-englische Wortpaare und

ein französisches Wort (nämlich das oben erwähnte

sensible

), um die Erweiterbarkeit bezüglich der Sprachen zu testen.

Die für False Friends entwickelte Struktur musste folgende Kriterien erfüllen:

Sie sollte beliebig viele Sprachen unterstützen.

Um praktikabel handhabbar und einfach erweiterbar zu sein, sollte sie sich in XML abbilden lassen.

Die Darstellung sollte möglichst redundanzfrei sein. Es muss insbesondere abgebildet werden, dass es sich

aufgrund der Ähnlichkeit als Kriterium um eine symmetrische Beziehung handelt. So ist das englische

sen-
sible

für einen Deutsch-Muttersprachler genauso irreführend wie das deutsche

sensibel

für einen Englisch-

Muttersprachler, der Deutsch lernt.

Die schließlich entwickelte Struktur soll an folgendem Beispiel erklärt werden:

<rulegroup id="SENSIBLE">

<rule level="0">

<pattern lang="en">

sensible

</pattern>

<translation lang="de">

vernünftig

</translation>

<translation lang="fr">

raisonnable

</translation>

</rule>

<rule level="0">

9

---

<pattern lang="de">

sensibel

</pattern>

<translation lang="en">

sensitive

</translation>

<!­ hier keine franz. Übersetzung, weil

sensibel (deutsch) ~ sensible (franz.) ­>

</rule>

<rule level="0">

<pattern lang="fr">

sensible

</pattern>

<translation lang="en">

sensitive

</translation>

<!­ hier keine deutsche Übersetzung, s.o. ­>

</rule>

</rulegroup>

Um diese Regel zu benutzen, muss dem System die Sprache des Textes und die Muttersprache des Schreibers über

Optionen mitgeteilt werden. Beim Programmstart wird obige XML-Datei geparst, wobei nur solche rule-Elemente

beachtet werden, die ein pattern-Element mit einem lang-Attribut haben, das der Sprache des zu prüfenden Textes

entspricht. Für diese Wörter wird eine Warnung erstellt, die später beim möglichen Eintreten der Regel dem Benutzer

angezeigt wird. Die Warnung lautet in etwa:

′EN1′ means ′DE1′. Did you perhaps mean ′EN2′, which means ′DE2′?

Dabei ist EN1 der im Text auftauchende Begriff, DE1 seine korrekte Übersetzung, EN2 der möglicherweise ge-

meinte Begriffe, und DE2 dessen korrekte Übersetzung. Die korrekte Übersetzung des im Text stehenden Begriffes

steht im gleichen rule-Element wie der Begriff selbst, ist also beim Auswerten der Datei leicht zugreifbar. Um den

möglichweise gemeinten Begriff zu erhalten, wird auf die rulegroup-Ebene des aktuellen rule-Element gewech-

selt, um alle dortigen Regeln zu durchsuchen. Relevant ist jetzt die, deren pattern-Element ein lang-Attribut hat,

das der Muttersprache des Schreibers entspricht. Die Übersetzung mit dem entsprechenden lang-Attribut ist der

möglicherweise gemeinte Begriff. Wie erwähnt findet dieser Vorgang nur einmal beim Parsen statt, programmintern

handelt es sich nach dieser Auswertung um eine ganz normale Regel, die beim Auftreten eines bestimmten Wortes

eine Warnung ausgibt.

Die DTD beinhaltet weiterhin ein level-Attribut, mit dem den Wortpaaren ein Schwierigkeitsgrad zugewiesen

werden kann. So können sich fortgeschrittene Benutzer einer Sprache nur nicht-triviale Warnungen anzeigen lassen. In

der vorliegenden Version ist der Level allerdings nicht belegt, bzw. immer auf 0 gesetzt. Das id-Attribut kennzeichnet

eine Regel eindeutig, so dass sie gezielt an- und ausschaltbar ist.

Als Spezialfall gibt es auch False Friends innerhalb einer Sprache [Bosewitz, 1999], die allerdings keine einfache

Übersetzung sondern eine etwas ausführlichere Erklärung erfordern. Deshalb sollten sie nicht bei den False-Friend-

Regeln, sondern bei den Wortregeln (s.u.) untergebracht werden.5

Eine interessante, wenn auch vielleicht nicht ganz so ernstzunehmende, Erweiterung wäre das Hinzufügen von re-

gionalen Sprachvarianten, die z.B. einem Österreicher bei Englisch als Zielsprache die gleichen Warnungen liefert wie

einem Deutschen, jedoch zusätzlich bei (Hoch-)Deutsch als Textsprache bei der Benutzung von

Eierspeise

(Rührei)

oder

Paradeiser

(Tomate) warnt. Weitere unterhaltsame österreichische Wörter finden sich unter [Gößnitzer].

5.5

Prüfung auf unerwünschte Wörter

Die Datei rules_words.xml enthält in der vorliegenden Version lediglich eine Regel zur Vermeidung von Kurz-

formen (z.B.

don′t

statt

do not

), sie kann aber vom Benutzer entsprechend seinen Ansprüchen erweitert werden.

Sinnvoll ist das z.B. beim Verfassen technischer Dokumentation, bei der die Benutzung eines einheitlichen Voka-

bulars erwünscht ist. Das unerwünschte Wort kann zusammen mit der erwünschten Alternative und einer Erklärung

angegeben werden. Das Dateiformat unterscheidet sich von rules_false_friends.xml nur dadurch, dass es

hier keine rulegroup-Elemente gibt, und man mit dem message-Element die Warnung für den Benutzer explizit

angeben kann.

5.6

Prüfungen außerhalb der Regeln

Es gibt wünschenswerte Prüfungen, die mit dem Regelsystem aufgrund seiner beschränkten Mächtigkeit nicht möglich

sind:

5Ein Fehler, bei dem ein Wort mit einem ähnlich klingendem verwechselt wird, nennt man auch Malapropismus. In [St-Onge, 1998] wird

beschrieben, wie man Malapropismen auf semantischer Ebene automatisch entdecken kann.

10

---

Das Erkennen langer Sätze: Dies wird im Perl-Skript von einer eigenen Funktion übernommen, die bei Sätzen,

welche die einstellbare Maximallänge überschreiten, eine Warnung ausgibt.

Eine Bewertung der Lesbarkeit mit Hilfe des Flesch-Reading-Ease-Index: Dies ist bereits Bestandteil von

KWord und damit nicht Teil dieses Projekts.

Kongruenz zwischen nicht benachbarten Konstituenten kann nicht allgemein sichergestellt werden. Beispiel: In

dem Satz "

Was

your car still

working

yesterday?" kann die nötige Kongruenz zwischen

was

und

working

nicht

mit einer allgemeingültigen Regel beschrieben werden, da die Nominalphrase

your car

theoretisch aus einem

bis beliebig vielen Wörtern bestehen kann. Man könnte diese Beschränkung aufheben, indem man in den Regeln

reguläre Ausdrücke statt nur einfache Pattern erlaubt.

5.7

Geschwindigkeitsoptimierungen

Tests mit Dateien von kurzer bis mittlerer Länge zeigen, dass die Geschwindigkeit der Stil- und Grammatikprüfung

für den täglichen Einsatz ausreichend ist: 1000 Sätze (107 kB Text) lassen sich in 12 Sekunden prüfen.

Um die Fehlerrate zu verringern, sollten allerdings neue Regeln mit möglichst vielen Sätzen getestet werden (siehe

4). Es zeigte sich, dass die Programmgeschwindigkeit bei Tests mit mehreren zehntausend Sätzen für die iterative

Entwicklung neuer Fehlerregeln deutlich zu langsam war. Dabei entfiel ca. ein Drittel der Laufzeit auf den POS-

Tagger, ein weiteres Drittel auf die Vor- und Nachbearbeitung der POS-Tagger-Ein- und Ausgabe und nur das letzte

Drittel auf die eigentliche Regelprüfung.

Um die Prüfung der sich nicht ändernden Texte des BNC zu beschleunigen, wurde ein Cache implementiert, der

das Ergebnis des POS-Taggers als ein Perl-Array im Binärformat abspeichert. Die Cache-Datei wird automatisch

angelegt bzw. erneuert, wenn die Originaldatei ein aktuelleres Datum als der Cache hat. Bei Benutzung des Cache

wird die Laufzeit fast nur noch durch die eigentliche Regelprüfung bestimmt, die oben erwähnten 1000 Sätze lassen

sich dann in 5 Sekunden prüfen.

6

Integration in KDE

6.1

Was ist KDE?

KDE (K Desktop Environment) ist eine freie Desktop-Umgebung für Unix. Neben dem Windowmanager und einem

Panel zum Starten von Programmen umfasst KDE viele Anwendungsprogramme, vom EMail-Client bis zur Textver-

arbeitung. KDE ist in C++ programmiert und benutzt als Klassenbibliothek Qt der Firma Trolltech, die alle Mittel zur

Verfügung stellt um komplexe grafische Benutzeroberflächen zu entwickeln. Außerdem bietet Qt Klassen für Unicode-

Strings, Dateizugriff, reguläre Ausdrücke, Zugriff auf XML-Dateien (mittels DOM und SaX) und einiges mehr.

KDE zeichnet sich durch eine gute Integration zwischen den Anwendungen aus. Die dadurch erreichte Einheit-

lichkeit besteht nicht nur aus Sicht des Benutzers, sondern auch aus Sicht des Entwicklers. Ein Projekt in KDE zu in-

tegrieren hat viele Vorteile gegenüber einer eigenständigen X11-Applikation: Als Programmierer profitiert man vom

umfangreichen KDE-Framework, das Internationalisierung, Dokumentation, Versionsmanagement und Bugtracking

erheblich erleichtert. Beispielsweise wird die Dokumentation im XML-Format nach DocBook-DTD verfasst und au-

tomatisch in die KDE-Hilfeseiten integriert (siehe 11.4). Um die Übersetzung des GUI in über 30 Sprachen muss

man sich als Programmierer ebenfalls keine weiteren Gedanken machen, sobald man alle zu übersetzenden Texte mit

einer bestimmten Funktion umgeben hat ("i18n()"). Die eigentliche Übersetzung vom Englischen in die jeweiligen

Sprachen übernehmen Teams von Freiwilligen.

Die grundlegenden KDE-Bibliotheken unterliegen der GNU Lesser Public License (LGPL), aller anderen Pakete

sowie Qt unterliegen der GNU Public License (GPL).

6.2

Implementierung der grafischen Benutzeroberfläche

Die grafische Benutzeroberfläche (GUI) existiert in zwei Varianten:

Ein sogenanntes KDataTool, das in vorhandene Programme eingebunden werden kann. Da KWord bereits auf

die Nutzung KDataTools vorbereitet ist, wird auch das neue KDataTool automatisch erkannt, ohne dass dazu

Änderungen am Quelltext von KWord nötig wären.

Ein Programm klanguage, das als Eingabe den Namen einer zu prüfenden Textdatei erwartet. Diese Variante

ist lediglich für Textzwecke vorgesehen. Mit ihr kann man die Funktionalität testen, ohne KWord starten zu

müssen. Der geänderte Text kann aber nicht wieder gespeichert werden kann.

11

---

Abbildung 1: Der Hauptdialog

Da klanguage lediglich als ein Wrapper um das KDataTool implementiert ist, gleichen sich bei beiden Varianten

sowohl Benutzeroberfläche als auch Funktionalität. Aus Benutzersicht besteht der einzige Unterschied im Aufruf: die

KDataTool-Variante wird über das Kontextmenü eines markierten Textes aufgerufen, die Programmvariante kann wie

jedes andere Programm über seinen Namen gestartet werden.

Technisch gesehen handelt es sich bei der KDataTool-Variante um eine Unterklasse von KDataTool, die min-

destens die Methode run() reimplementiert. Diese Methode bekommt als Argumente einen Kommando-String,

einen MIME-Typ-String, einen Zeiger auf die Daten und einen String, der den Typ der Daten angibt. Außer den

Daten sind bei diesem KDataTool alle Parameter festgelegt: Das Kommando muss language sein, der MIME-Typ

text/plain und der Datentyp QString (die String-Klasse der Qt-Bibliothek)6. Da ein Zeiger auf die Daten über-

geben wird, können sie direkt geändert und müssen nicht explizit an das aufrufende Programm zurückgegeben werden.

Nach der Kompilierung existiert ein KDataTool als eine Bibliothek, die vom aufrufenden Programm dynamisch

(d.h. zur Laufzeit und bei Bedarf) geladen wird.

Jedes KDataTool legt Informationen darüber, welche Daten es verarbeiten kann in einer *.desktop-Datei ab.

Das aufrufende Programm kennt den Inhalt dieser Datei und kann damit entscheiden, wann es sinnvoll ist, ein KData-

Tool zur Auswahl zu stellen. Das KDataTool zur Stil- und Grammatikprüfung kann also nur aufgerufen werden, wenn

Text markiert ist, nicht jedoch wenn eine Grafik angewählt ist.

Das GUI verfügt über zwei Textfelder und mehrere Buttons (siehe Abb. 1). Im oberen Textfeld wird ein fehlerhafter

Satz des Originaltextes angezeigt, wobei das fehlerhafte Wort durch Fettschrift hervorgehoben ist. Eine Korrektur

kann direkt in diesem Feld vorgenommen werden. Das zweite Textfeld zeigt die dazugehörige Fehlermeldung an.

Mit den

Next

- und

Previous

-Buttons gelangt man zu weiteren bzw. vorigen Fehlermeldungen.

Configure...

ruft den

Konfigurationsdialog auf (siehe Abb. 2).

Help

ruft die Online-Dokumentation auf (siehe Abb. 3). Mit

OK

wird der

korrigierte Text in das aufrufende Programm übernommen, mit

Cancel

werden mögliche Änderungen verworfen.

7

Installation

7.1

Systemvoraussetzungen

Backend:

­

C-Compiler (z.B. gcc) und die üblichen dazugehörigen Tools (z.B. make)

­

Perl 5.6 (Perl Version 5.00x wurde nicht getestet, sollte aber ebenfalls funktionieren)

­

Perl-Modul XML-DOM-1.35

GUI:

6Sollte das KDataTool aus irgendeinem Grund mit anderen Angaben aufgerufen werden, beendet es sich mit einem Fehler. Die Argumente

können für anderen KDataTools nützlich sein, die mehr als nur eine Funktionalität bieten.

12

---

Abbildung 2: Der Konfigurationsdialog

Abbildung 3: Die Online-Dokumentation

13

---

­

Das GUI wurde mit KDE 3.0 und einer Entwicklerversion von KOffice programmiert. Es sollte ohne

Änderungen auch mit der geplanten KOffice Version 1.2 funktionieren. Die genauen Systemvorausset-

zungen zum Kompilieren von KDE und KOffice, die auch für dieses GUI gelten, sind unter http:

//www.kde.org/install- source.html dokumentiert.

7.2

Schrittweises Vorgehen

1. Installation des Backend:

(a) Wechseln in das Verzeichnis tools im KOffice Paket:

cd koffice-1.2-beta1/tools

(b) Entpacken des Archivs:

tar xzf languagetool.tar.gz

cd language

(c) Kompilieren des Part-of-Speech-Taggers:

cd tagger

make (bei Problemen muss eventuell Makefile editiert werden)

(d) Testen des Backend:

cd ..

./languagechecker.pl <textdatei>

Es sollte eine XML-Datei ausgegeben werden, in der mögliche Fehler des Originaltextes mit einem mes-

sage-Element annotiert sind.

2. Installation des GUI:

(a) Für das GUI sollte zuerst geprüft werden, ob KOffice auf dem System kompiliert und gestartet werden

kann:

i. Installation:

tar xzf koffice-1.2-beta1.tar.gz

cd koffice-1.2-beta1

./configure

make install

ii. Test:

kword

(b) Anpassung von Makefile.am:

cd koffice-1.2-beta1/tools

language zu den vorhandenen Einträgen unter SUBDIRS in Makefile.am hinzufügen.

(c) Neue Makefiles generieren:

cd ..

./configure

make install

(d) Umgebungsvariable setzen:

export LANGUAGETOOL=<abs.Pfad>/koffice-1.2-beta1/tools/language/

(e) Testen des GUI: KWord starten, Text eingeben, einen Satz markieren und rechte Maustaste drücken, im

Kontextmenü

Language Tool

wählen. Der Hauptdialog erscheint und der markierte Satz wird geprüft.

8

Ergebnisse der Evaluierung der Stil- und Grammatikprüfung

Die Stil- und Grammatikprüfung besteht in ihrer jetzigen Form aus 15 Grammatikregeln und 82 Regeln für False Fri-

ends. Jede Grammatikregel wurde gegen 260.000 Sätze aus dem BNC getestet. Die Quote der Sätze, die als fehlerhaft

annotiert wurden liegt dabei zwischen 0,0004% (bei einer der Regeln zum Finden der

no

/

now

-Tippfehler) und 0,12%

(bei einer Regel zum Prüfen des Verbs beim Passiv mit

is

). Alle Grammatikregeln zusammen führten bei einem Test

mit 130.000 Sätzen zu einer Quote von 0,4% als fehlerhaft annotierter Sätze.

Trotz der geringen Quote ist die Gesamtzahl der für falsch befundenen Sätze zu groß, um eine genaue Analyse

der Fehlerursachen durchzuführen. Es wurde deshalb nur auf einer zufälligen Stichprobe von 38 angeblich falschen

14

---

Sätzen nach den Ursachen der Fehlermeldungen gesucht, wobei sich folgendes Bild ergibt: 22 der Fehlermeldungen

gehen auf falsch getaggte Wortarten zurück, der Fehler liegt also im Part-of-Speech-Tagger; 13 Fehler werden durch

Regeln ausgelöst, die nicht exakt genug sind, d.h. auch auf korrekte Sätze zutreffen; drei Fehler sind tatsächliche

Grammatikfehler im Text.

In dieser Stichprobe sind also nur ca. 8% der entdeckten Fehler tatsächliche Fehler, 92% der Fehlermeldungen

sind falscher Alarm. Dabei ist jedoch zu bedenken:

Bei den Texten des BNC handelt es sich zum Großteil um veröffentlichte Texte von professionellen Schreibern,

ausnahmslos alle Schreiber haben Englisch als Muttersprache. Auch kann man davon ausgehen, dass die Texte

vor ihrer Veröffentlichung mehrmals korrigiert worden sind. Die Zahl der wirklichen Fehler dürfte demnach

entsprechend gering sein.

Unter den falsch getaggten Wörtern gibt es auffällige Häufungen: So sind allein in der Stichprobe von 38 Sätzen

sechs Fehlermeldungen auf das falsche Erkennen von

said

in Phrasen wie

it is said that

zurückzuführen.

Said

wird als

past tense

erkannt, obwohl es hier als

past participle

benutzt wird. Das gleiche Problem bei

put

führt

zu drei weiteren Fehlermeldungen und bei

will

(wird als Nomen benutzt aber als Verb erkannt) nochmals zu

weiteren drei Fehlermeldungen. Baut man für solche Wörter entsprechende Ausnahmen in die Regeln ein, sollte

sich die Fehlerrate deutlich senken lassen.

Schließlich folgen noch drei Beispiele für vermeintliche Fehler, die die Stil- und Grammatikprüfung in den Texten des

BNC gefunden hat:

Mike Teague is doubtful but Will

Carling

, the captain, says he will be fit despite being concussed in

Harlequins′ win over London Irish.

Fehlermeldung: Modal verbs like ′will′/′might′/... require base form of verb.

Hier liegt ein Fehler des Part-of-Speech-Taggers vor:

Will

wird (trotz Großschreibung) nicht als Name sondern als

Modalverb erkannt,

Carling

wird als Gerundium (Form auf

-ing

) erkannt. Hier zeigt sich, dass es ein Problem ist, dass

der Tagger einem Wort im Zweifelsfall per Heuristik eine Wortart zuweist. Würde er stattdessen darüber informieren,

dass ihm das Wort nicht bekannt ist, so könnte man es einfach ignorieren und würde keinen vermeintlichen Fehler

finden.

Some schools offer a two-year course for students who have more experience, particularly those

from

overseas.

Fehlermeldung: Did you mean "form"?

In diesem Fall versucht die Regel mit Hilfe einer Heuristik den

from

/

form

-Tippfehler zu finden. Dabei wird der Fehler

ausgelöst, wenn

from

einem Determiner folgt. Da auch

those

vom Tagger korrekterweise als Determiner erkannt wird,

löst hier die Regel fälschlicherweise aus, sie ist also noch nicht restriktiv genug.

Applications will be accepted as long as they are made by 1st October 1991 but your council can

chose

to set a later date.

Fehlermeldung: Modal verbs like ′will′/′might′/... require base form of verb.

In diesem Satz wird der Fehler korrekt erkannt:

chose

ist eine Vergangenheitsform, die hier wegen des Hilfsverbs

can

nicht benutzt werden darf. Richtig wäre

choose

.

Es war geplant, die Texte des BNC vor allem einzusetzen, um die Fehlerrate der Regeln zu bestimmen. Um ein

realistischeres Bild von der Leistungsfähigkeit der Software zu bekommen, wurde ein zweiter Test durchgeführt.

Dazu wurden 223 private EMails in englischer Sprache geprüft, die alle von einer Person stammen, die kein Englisch-

Muttersprachler ist und auch sonst keine guten Englischkenntnisse hat. Aus den EMails wurde mit einem Perl-Skript

der Textinhalt (ohne zitierten Text) extrahiert und in die Stil- und Grammatikprüfung eingebenen. In den ca. 1200

Sätzen wurden 66 Fehler gefunden, davon waren 36 ein sich wiederholender Rechtschreibfehler (

can not

statt

cannot

).

Ignoriert man die 36 Rechtschreibfehler, zeigt sich bei der Analyse: 28 der Fehlermeldungen sind berechtigt und

zeigen tatsächliche Fehler an; eine Fehlermeldung erfolgt fälschlicherweise wegen unexakter Regeln; eine weitere

Fehlermeldung wird durch eine falsche Annotation des Taggers verursacht. Im Gegensatz zum Test mit dem BNC

zeigt sich hier also ein umgekehrtes Verhältnis: Die Fehlerrate beträgt nur noch 5%, 95% aller Fehlermeldungen

zeigen tatsächliche Fehler an.

Von den 28 gefundenen echten Fehlern sind 15 Konjugationsfehler im Zusammenhang mit Modalverben, neun

sind falsche Konjugationen bei der dritten Person Singular, vier sind falsche Verbformen in Zusammenhang mit dem

Passiv. Beispiele:

15

---

In this case the script will

contains

double categories.

Fehlermeldung: Modal verbs like ′will′/′might′/... require base form of verb.

The script will not tell him that he

pass

.

Fehlermeldung: Third person singular noun requires verb with ′-s′.

If the time is

finish

, the script will transfer all the students to a "thank you" page.

Fehlermeldung: Passive requires verb with ′-ed′.

Wie man sieht, kann das Programm für diese Fehler eine hilfreiche und korrekte Fehlermeldung ausgeben. Da in

1200 Sätzen jedoch nur 28 echte Fehler gefunden wurden, ist davon auszugehen, dass eine große Anzahl von Fehlern

übersehen wurde, da für sie noch keine entsprechenden Regeln existieren.

9

Bekannte Probleme und mögliche Erweiterungen

Derzeit kann die Stil- und Grammatikprüfung nur mit "plain text" umgehen. Mögliche Textformatierungen wie

Farben, Fettdruck und die Auszeichnung von Überschriften gehen bei der Korrektur von Fehlern verloren, wenn

der korrigierte Text wieder an die aufrufende Anwendung zurückgegeben wird. Um dieses Problem zu beheben,

müssten Änderungen an KWord vorgenommen werden, z.B. derart, dass der Text als XML an die Stil- und

Grammatikprüfung übergeben wird. Alle Formatierungen müssten innerhalb von Tags stehen, so dass diese

beim Prüfen ignoriert, aber später wieder mit dem Text zurückgeben werden könnten. Da diese Änderungen

auch den Kern von KWord (die internen Klassen zur Textstruktur) betreffen, gehen sie über das Projekt hinaus

und wurden nicht implementiert.

Es wäre sinnvoll, eine Rechtschreibprüfung in das System zu integrieren. Diese könnte automatisch vor der Stil-

und Grammatikprüfung durchgeführt werden. Das GUI muss dazu nur geringfügig geändert werden (vor allem

fehlt derzeit eine Auswahlliste möglicher Korrekturen).

Es wäre möglich, den Kontext von False Friends testen, um nur dann zu warnen, wenn

wahrscheinlich

eine

falsche Benutzung vorliegt. Zum Trainieren dieses Systems benötigte man jedoch einen annotierten Korpus mit

falsch benutzten False Friends.

Die Unterstützung von Unicode, die z.B. bei Erweiterung auf anderen Sprachen sinnvoll wäre, scheitert an den

mangelnden Unicode-Fähigkeiten von Perl 5.6. Die nächste Version (Perl 5.8) sollte Abhilfe bringen.

Wünschenswert wäre eine sogenannte "Online-Prüfung", bei der schon während des Tippens Fehler erkannt und

z.B. durch Unterstreichung angezeigt werden. Problem ist hier der Tagger, der wegen seiner langen Startzeit im

Sekundenbereich nicht für jeden Satz neu aufgerufen werden kann. Stattdessen müsste er als Server ständig im

Hintergrund laufen und dort einzelne Sätze entgegennehmen können.

Für bestimmte Fehler ist es denkbar, eine konkrete Korrektur vorzuschlagen, die der Benutzer interaktiv akzep-

tiert oder ablehnt.

10

Fazit

Im vorliegenden Projekt wurde eine Stil- und Grammatikprüfung für die englische Sprache implementiert. Sie kann

besonders für Benutzer hilfreich sein, deren Muttersprache nicht Englisch ist. Durch die grafische Benutzeroberfläche

und eine akzeptable Geschwindigkeit ist die Software für den täglichen Einsatz geeignet.

Ein Vergleich mit den Grammatikprüfungen in kommerziellen Textverarbeitungen ist nur begrenzt sinnvoll: Die

Leistung einer Grammatikprüfung basiert auf der Anzahl und Qualität ihrer Fehlerregeln, deren Erstellung mühsam

und zeitaufwendig ist und die in diesem Projekt nur zum Teil realisiert werden konnte. Allerdings ist hier durch die

Verwendung von XML-Konfigurationsdateien ist eine gute Erweiterbarkeit gegeben, die sich auch auf die Fehlerregeln

erstreckt. Aber auch ohne Änderung der XML-Dateien können alle Fehlerregeln über die grafische Benutzeroberfläche

einzeln ein- und ausgeschaltet werden.

Eine wirklich objektive Bewertung der Erkennungs- und Fehlerrate ist leider nicht möglich, da kein Korpus mit

annotierten Fehlern zur Verfügung steht. Dennoch zeigen die Ergebnisse unter 8, dass die Software für praktische

Anwendungen gute Ergebnisse erzielen kann.

16

---

11

Anhang

11.1

Penn Treebank Tagset

POS Tag

Description

Example

CC

coordinating conjunction

and

CD

cardinal number

1, third

DT

determiner

the

EX

existential there

there

is

FW

foreign word

d′hoevre

IN

preposition/subordinating conjunction

in, of, like

JJ

adjective

green

JJR

adjective, comparative greener

greener

JJS

adjective, superlative

greenest

LS

list marker

1)

MD

modal

could, will

NN

noun, singular or mass

table

NNS

noun plural

tables

NNP

proper noun, singular

John

NNPS

proper noun, plural

Vikings

PDT

predeterminer

both

the boys

POS

possessive ending

friend′

s

PRP

personal pronoun

I, he, it

PRP$

possessive pronoun

my, his

RB

adverb

however, usually, naturally, here, good

RBR

adverb, comparative

better

RBS

adverb, superlative

best

RP

particle

give

up

TO

to

to

go,

to

him

UH

interjection

uhhuhhuhh

VB

verb, base form

take

VBD

verb, past tense

took

VBG

verb, gerund/present participle

taking

VBN

verb, past participle

taken

VBP

verb, sing. present, non-3d

take

VBZ

verb, 3rd person sing. present

takes

WDT

wh-determiner

which

WP

wh-pronoun

who, what

WP$

possessive wh-pronoun

whose

WRB

wh-abverb

where, when

Quelle: http://www.mozart-oz.org/mogul/doc/lager/brill-tagger/penn.html

11.2

Die Regel-DTD (rules.dtd)

<!ENTITY % Languages "(en|de|fr)">

<!ELEMENT rules (rule|rulegroup)*>

<!ELEMENT rulegroup (rule+)>

<!ATTLIST rulegroup id ID #REQUIRED>

<!ELEMENT rule ( pattern, ((message,error_rate,marker,example,example+) |

(translation+,message?,example*)) )>

<!ATTLIST rule id ID #IMPLIED>

<!ATTLIST rule level (0|1|2|3|4|5|6|7|8|9|10) #IMPLIED>

<!ELEMENT pattern (#PCDATA)>

17

---

<!ATTLIST pattern lang %Languages; #REQUIRED>

<!ELEMENT translation (#PCDATA)>

<!ATTLIST translation lang %Languages; #REQUIRED>

<!-- message shown to the user if a rule matches: -->

<!ELEMENT message (#PCDATA|em)*>

<!-- percentage of sentences tagged as wrong in BNC: -->

<!ELEMENT error_rate (#PCDATA)>

<!-- number of (real or unreal) warnings when testing BNC sentences: -->

<!ATTLIST error_rate warnings CDATA #IMPLIED>

<!-- number of BNC sentences used to get ′warnings′ and thus ′error_rate′: -->

<!ATTLIST error_rate sentences CDATA #IMPLIED>

<!-- last filename of the BNC files that was tested: -->

<!ATTLIST error_rate last_5000_file CDATA #IMPLIED>

<!ELEMENT marker (#PCDATA)>

<!ELEMENT example (#PCDATA|em)*>

<!ATTLIST example type (correct|incorrect|triggers_error) #REQUIRED>

<!-- use to explain ′triggers_error′: -->

<!ATTLIST example reason CDATA #IMPLIED>

<!-- emphasis of the most significant part: -->

<!ELEMENT em (#PCDATA)>

11.3

Die Ergebnis-DTD (result.dtd)

<!ELEMENT text (s*)>

<!ELEMENT s (#PCDATA|message)*>

<!ELEMENT message (#PCDATA)>

<!ATTLIST message

text CDATA

#REQUIRED

type (warning|error) #IMPLIED

>

11.4

Benutzer-Dokumentation

KLanguageTool is a simple style checker for the English language. It recognizes a few errors and offers some help if

you are not a native speaker of English.

11.4.1

Introduction

KLanguageTool can check your English texts for some errors. The way it works is very simple: it searches the text for

certain patterns that

might

be errors. Each sentence with a possible error is displayed with an explanation of the error.

You can then fix the error by modifying the text, or you can ignore the warning if the sentence is actually correct.

Depending on the quality of your text you might receive much more false alarms than you might find real errors with

this tool.

Note:

KLanguageTool does only check a small part of the English grammar. Furthermore, it is no English teacher.

To use it, you should already know the English language so that you can decide if a warning can be safely ignored or

not.

KLanguageTool is not a standalone application, but it is integrated into programs like KWord. You can start KLan-

guageTool by marking text, pressing the right mouse button and selecting

Language Tool

.

18

---

11.4.2

Known Limitations

KLanguageTool will somtimes mark a sentence as incorrect even when it′s correct. Unlike a spell checker, which

can "learn" new words, you cannot teach KLanguageTool that this sentence is correct. All you can do is ignore

this warning by clicking

Next

or by clicking

Configure...

to turn it off.

KLanguageTool currently assumes that the text has no spelling errors. You should use a spell checker before

you use KLanguageTool.

KLanguageTool can currently only work on text without formats. If you correct errors in KLanguageTool and

click OK, the formatting of your text will be reset to plain text.

11.4.3

Basic Configuration

Click

Configure...

to set up KLanguageTool to your needs. There are three categories of possible errors: grammar

errors, false friends and word errors. Every category and every pattern which is used to find possible errors can be

turned on or off separately.

The

Spelling and Grammar

tab lists several rules that look for grammar errors and typos which cannot be found

by a spell checker (e.g. mixing up "then" and "than").

The

False Friends

tab lists words from different languages that sound similar but that have a different meaning.

Currently only English and German are supported, i.e. these rules are useful for native speakers of German who want

to write an English text and vice versa. KLanguageTool will warn you about every occurence of a false friend, it

cannot know if you are using a word in its correct meaning or not. If you′re not sure that you will remember the

correct meaning, click

Next

and the rule will stay active to warn you again if the word occurs again in your text. You

have to set the

Your mother tongue

and

Text language

fields to get useful warnings.

Text language

must be set to the

language of the text you are going to check. Setting both fields to the same value doesn′t make sense, i.e. you won′t

get any warnings.

The

Words

tab lists words that you want to be warned about for some reason. Initially this list only contains the

rule for contracted forms ("don′t" instead of "do not"). If you want to be warned in other cases you will have to add

words to an XML configuration file, as described in the Advanced Configuration section.

11.4.4

Advanced Configuration

KLanguageTool comes with three configuration files that correspond to the three tabs of the configuration dialog:

rules_grammar.xml

,

rules_false_friends.xml

, and

rules_word.xml

.

These are XML files whose format is defined and described in

rules.dtd

. You can make changes to these files with

a text editor. After that you should validate the files to make sure they are still in conformance with

rules.dtd

. For

example, you can use the following command to check

rules_grammar.xml

:

xmllint ­noout ­valid rules_grammar.xml

If you don′t see any output, the file is valid.

11.4.5

Copyright and Licensing

The code and data in the tagger sub directory is licensed under the terms of the following license:

Copyright 1993 by the Massachusetts Institute of Technology and the University of Pennsylvania. All rights reser-

ved.

THIS SOFTWARE IS PROVIDED "AS IS", AND M.I.T. MAKES NO REPRESENTATIONS OR WARRAN-

TIES, EXPRESS OR IMPLIED. By way of example, but not limitation, M.I.T. MAKES NO REPRESENTATIONS

OR WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE

USE OF THE LICENSED SOFTWARE OR DOCUMENTATION WILL NOT INFRINGE ANY THIRD PARTY PA-

TENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

The name of the Massachusetts Institute of Technology or M.I.T. may NOT be used in advertising or publicity

pertaining to distribution of the software. Title to copyright in this software and any associated documentation shall at

all times remain with M.I.T., and USER agrees to preserve same.

KLanguageTool and this documentation is copyrighted by Daniel Naber.

This documentation is licensed under the terms of the GNU Free Documentation License.

This program is licensed under the terms of the GNU General Public License.

19

---

Literatur

[Aston, 1998]

Aston, Guy; Burnard, Lou:

The BNC Handbook: Exploring the British National Corpus
with SARA

, Edinburgh Univ. Press, 1998

[Bosewitz, 1999]

Bosewitz, Rene:

Better your English. Wie man typisch deutsche Fehler vermeidet,

Rowohlt, 1999

[Breitkreuz, 1997]

Breitkreuz, Hartmut:

False Friends. Stolpersteine des deutsch-englischen Wortschatzes

,

Rowohlt, 1997

[Brill, 1992]

Brill, Eric:

A Simple Rule-Based Part Of Speech Tagger

, Proceedings of ANLP-92, 3rd

Conference on Applied Natural Language Processing, 1992

[Brill, 1996]

Brill, Eric:

Eric Brill′s Code Page

,

http://www.cs.jhu.edu/~brill/code.html, 1996-06-09

[Burnard, 2001]

Burnard, Lou:

Using SGML for Linguistic Analysis: the case of the BNC

in: Stephan Moser

et al: Maschinelle Verarbeitung Altdeutscher Texte V, Max Niemeyer Verlag, 2001

[Bustamente, 1996]

Bustamante, Flora Ramírez; León, Fernando Sánchez:

GramCheck: A Grammar and Style
Checker

, in: Proceedings of the 16th International Conference on Computational

Linguistics, Copenhagen, 1996

[Crysmann]

Crysmann, Berthold:

FLAG: Flexible Language and Grammar Checking

,

http://flag.dfki.de/, Stand: 2002-06-06

[Englisch-Deutsch, 1997]

Englisch-Deutsch Deutsch-Englisch

, Orbis Verlag, 1987

[English G, 1981]

English G Grammatik

, Cornelsen, 1981

[False Friends]

False Friends in German,

http://german.about.com/library/blfalsef.htm, Stand: 2002-06-06

[Gößnitzer]

Gößnitzer, Manuela:

Das deutsch-österreichische Lexikon

,

http://freunde.imperium.de/manuela/short/sprache.htm, Stand:

2002-06-06

[Mason]

Mason

,

Oliver:

Qtag ­ a portable POS tagger

,

http://www.english.bham.ac.uk/staff/oliver/software/tagger/,

Stand: 2001-12-25

[Moore, 2001]

Moore, Johanna:

Introduction to Computational Linguistics (2001)

,

http://www.cogsci.ed.ac.uk/~icl/, Stand: 2002-06-06

[Oliva, 1995]

Oliva, Karel:

Grammar-Based Grammar Checker

.

A feasible practical implementation of
high-level language technologies,

in: Proceedings 5. TaCoS, 1995

[Park et al, 1997]

Park, Jong C.; Palmer, Martha; Washburn, Gay:

An English Grammar Checker as a Writing
Aid for Students of English as a Second Language

, Conference on Applied Natural Langua-

ge Processing (ANLP), Descriptions of System Demonstrations and Videos, Washington,

D.C., USA, 1997

[Sakar]

Sarkar, Anoop:

The XTAG Project

, http://www.cis.upenn.edu/~xtag/, Stand:

2002-06-06

[St-Onge, 1998]

St-Onge, D.; Hirst, G.:

Detecting and Correcting Malapropisms with Lexical Chains

, in:

WordNet: an electronic lexical database, MIT Press, 1998

[Temperly]

Temperley, Davy; Sleator, Daniel; Lafferty, John:

Link Grammar

,

http://www.link.cs.cmu.edu/link/, Stand: 2002-06-06

[Thurmair, 1990]

Thurmair, Gregor:

Parsing for Grammar and Style Checking

, in: Proceedings of the 14th

International Conference on Computational Linguistics (COLING-90), p. 365-370, 1990

[Weidacher, 1992]

Weidacher, Josef:

Semantic pitfalls in business English: systematic translation exercises
English-German/German-English

, Service-Fachverlag, 1992

20

---