Inhaltsverzeichnis

1  Einleitung  2

2  Ziele des Projekts  2

3  Evaluierung der nötigen externen Software  3

3.1  British National Corpus (BN)C  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 Textverarbeitungen zu finden ist ¹ . Das Projekt beschränkt sich auf Englisch, da dort einerseits die Grammatikregeln vergleichsweise 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älschlicherweise 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 Programmlogik (Backend) wird in Perl programmiert.

Das fertige Programm soll unter anderem mit Hilfe des British National Corpus getestet werden, um eine geringe 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 Rechtschreibkontrolle 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 werden, 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).

¹ Eine 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 Dokumentation, 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änkungen 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 Gegensatz 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: unterbringen). 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% Korrektheit 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 Datenmenge dauert allein das Starten des Taggers 1,5 Sekunden ² . 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 stilistische 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 exportiert. 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  

² Alle 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 Funktionalität möglichst vielen Programmen zugute kommen zu lassen, werden auch heute üblicherweise noch Bibliotheken 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 Grammatikprü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 verarbeiten, 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_.pl, Das Perl-Script, verteilt auf mehrere Dateien

Hauptprogramm des Backends ist das Perl-Skript languagechecker.pl. Zur Übersichtlichkeit ist es in mehrere Dateien aufgeteilt. Es wird mit dem Namen der zu prüfenden Datei und eventuell mit Optionen aufgerufen, die größtenteils denen im GUI entsprechen:

5

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 Ausgabe 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):

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 , rules_false_friends.xml und rules_words.xml mittels des Perl-Moduls XML::DOM::Parser eingelesen 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 natü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 Beschreibungssprache 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 strukturorientierte 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 Strings ³ . 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 Standard 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 ausgeben. 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.

³ Der Perl-Befehl grep() arbeitet mit regulären Ausdrücken auf Listen, er betrachtet aber jeweils nur ob ein Listenelement dem regulären Ausdruck 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 Suchanfrage ”sorry for my bad english” (inkl. Anführungszeichen) auf Google, was zu ca. 8000 Treffern führt ⁴ . 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öglicherweise 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, andernfalls 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 unberechtigterweise 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:

”as” JJ ”(like|than|then)” Comparison requires ’as’ + adj + ’as’. 0.028 2

This house is as big as mine. This house is as big like mine.

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:

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

⁴ Weitere Anfragen, die amüsanterweise ebenfalls zu Treffern führen: "sorry for my bat english", "sorry for my bed english"

8

Modal verbs like ’will’/’might’/... require base form of verb. 0.018 2

John will talk to her. John will go home. John will goes home. John will walked home.

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 auszugehen, 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 eine ”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 aufgehoben. 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 sensible 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:

9

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 gemeinte 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 gewechselt, 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 regionalen 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 Vokabulars 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:

⁵ Ein 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 Textverarbeitung. 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 Einheitlichkeit besteht nicht nur aus Sicht des Benutzers, sondern auch aus Sicht des Entwicklers. Ein Projekt in KDE zu integrieren 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 automatisch 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

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 mindestens 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) ⁶ . Da ein Zeiger auf die Daten übergeben 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

- 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:  

⁶ Sollte 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 Systemvoraussetzungen 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

Es sollte eine XML-Datei ausgegeben werden, in der mögliche Fehler des Originaltextes mit einem message-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:

(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=/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 Friends. 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

11.2 Die Regel-DTD (rules.dtd)

17

11.3 Die Ergebnis-DTD (result.dtd)

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 KLanguageTool 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 reserved.

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]

[Bosewitz, 1999]

[Breitkreuz, 1997]

[Brill, 1992]

[Brill, 1996]

[Burnard, 2001]

[Bustamente, 1996]

[Crysmann]

[Englisch-Deutsch, 1997] Englisch-Deutsch Deutsch-Englisch, Orbis Verlag, 1987

[English G, 1981] English G Grammatik, Cornelsen, 1981

[False Friends]

[Gößnitzer]

[Mason]

[Moore, 2001]

[Oliva, 1995]

[Park et al, 1997]

[Sakar]

[St-Onge, 1998]

[Temperly]

[Thurmair, 1990]

[Weidacher, 1992]