Inhaltsverzeichnis
1 Einleitung
2 Ziele des Projekts
3 Evaluierung der nötigen externen Software
3.1 British National Corpus (BNC)
3.2 Eric Brills Part-of-Speech-Tagger
4 Die Testfälle
5 Implementierung der Stil- und Grammatikprüfung
5.1 Übersicht
5.2 Das Regelsystem und seine DTD
5.3 Beispiel für die Entwicklung einer Regel
5.4 Prüfung auf ’False Friends’
5.5 Prüfung auf unerwünschte Wörter
5.6 Prüfungen außerhalb der Regeln
5.7 Geschwindigkeitsoptimierungen
6 Integration in KDE
6.1 Was ist KDE?
6.2 Implementierung der grafischen Benutzeroberfläche
7 Installation
7.1 Systemvoraussetzungen
7.2 Schrittweises Vorgehen
8 Ergebnisse der Evaluierung der Stil- und Grammatikprüfung
9 Bekannte Probleme und mögliche Erweiterungen
10 Fazit
11 Anhang
11.1 Penn Treebank Tagset
11.2 Die Regel-DTD (rules.dtd)
11.3 Die Ergebnis-DTD (result.dtd)
11.4 Benutzer-Dokumentation
11.4.1 Introduction
11.4.2 Known Limitations
11.4.3 Basic Configuration
11.4.4 Advanced Configuration
11.4.5 Copyright and Licensing
1 Einleitung
Im Projekt soll eine Stil- und Grammatikprüfung entwickelt werden, ähnlich wie sie heute in kommerziellen Textverarbeitungen zu finden ist1. 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).
Sowohl bei der Grammatikals 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 Mitteloder 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.
Ä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 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 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
- 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 meisten 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 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:
Abbildung in dieser Leseprobe nicht enthalten
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:
Abbildung in dieser Leseprobe nicht enthalten
[...]
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 Dokumentation, nicht jedoch die eigentliche Software.
Häufig gestellte Fragen
Worum geht es in dem Stil- und Grammatikprüfungs-Projekt?
Das Projekt zielt darauf ab, eine Stil- und Grammatikprüfung für die englische Sprache zu entwickeln, ähnlich wie sie in kommerziellen Textverarbeitungsprogrammen zu finden ist. Es konzentriert sich auf die Erkennung von Grammatikfehlern, Tippfehlern, stilistischen Problemen und die Bereitstellung hilfreicher Erklärungen für Benutzer.
Was sind die Hauptziele des Projekts?
Die Hauptziele sind:
- Korrekte Sätze nicht als fehlerhaft zu kennzeichnen.
- Fehlerhafte Sätze als fehlerhaft zu erkennen.
- Hilfreiche Erklärungen zu erkannten Fehlern anzuzeigen, einschließlich der Hervorhebung des fehlerhaften Wortes.
- Ein flüssiges interaktives Prüfen von kurzen bis mittellangen Texten zu ermöglichen.
Welche Arten von Fehlern werden erkannt?
Die Software soll zwei Arten von Fehlern erkennen:
- Ungrammatische Konstruktionen aufgrund von Fehlern in der Anwendung von Grammatikregeln.
- Tippfehler und Wortverwechslungen, die zu falscher Grammatik führen, aber von der Rechtschreibkontrolle nicht erkannt werden.
Was beinhaltet die Stilprüfung?
Die Stilprüfung umfasst formale Kriterien wie Satzlänge, das Erkennen von Kurzformen (don’t vs. do not) in formellen Texten und eine semantische Prüfung von Wörtern (False Friends). Benutzer können auswählen, welche Prüfungen durchgeführt werden sollen.
Welche Software wird für das Projekt verwendet?
Das Projekt nutzt das British National Corpus (BNC) für Testzwecke und Eric Brills Part-of-Speech-Tagger zur Wortartenbestimmung. Die Implementierung erfolgt in Perl (Backend) und C++ (Frontend).
Was ist das British National Corpus (BNC)?
Der BNC ist ein kommerzieller Korpus mit 100 Millionen Wörtern britischen Englisch, der für das Testen der Stil- und Grammatikprüfung während der Entwicklung verwendet wird.
Was ist ein Part-of-Speech-Tagger?
Ein Part-of-Speech-Tagger (POS-Tagger) weist jedem Wort eines Textes seine Wortart zu. Eric Brills Tagger wird verwendet, um die 36 Wortarten des Penn Treebank Tagsets zu erkennen.
Wie werden Testfälle verwendet?
Testfälle sind Texte, bei denen bekannt ist, ob und welche Fehler sie enthalten. Es werden "künstliche" Testfälle (mit absichtlich eingebauten Fehlern) und "natürliche" Testfälle (aus dem BNC extrahiert) verwendet, um die Qualität und Leistungsfähigkeit der Software zu bewerten und Regressionstests durchzuführen.
Wie ist die Software aufgebaut?
Die Software besteht aus zwei Teilen: einem Backend (in Perl), das die eigentliche Prüfung übernimmt, und einem Frontend (in C++), mit dem der Benutzer interaktiv arbeiten kann. Diese Trennung ermöglicht Modularität und Flexibilität bei der Implementierung.
Wie funktioniert das Backend?
Das Backend nimmt einen Dateinamen entgegen, erkennt Satzgrenzen, POS-taggt den Text und prüft ihn auf Stil- und Grammatikfehler. Das Ergebnis wird in XML zurückgegeben, um das fehlerhafte Wort zu kennzeichnen und eine kurze Erklärung des Fehlers zu ermöglichen.
Warum wurde Perl für das Backend gewählt?
Perl wurde aufgrund seiner Eignung für die Verarbeitung von Strings, seiner Unterstützung für reguläre Ausdrücke und XML-Verarbeitung sowie seiner schnellen Implementierungsgeschwindigkeit gewählt.
Wie erfolgt die Integration in KDE?
Die grafische Benutzeroberfläche (GUI) wird in C++ implementiert und in die Textverarbeitung KWord integriert. Dies ermöglicht eine nahtlose Nutzung der Stil- und Grammatikprüfung innerhalb der KDE-Umgebung.
- Citar trabajo
- Daniel Naber (Autor), 2002, Entwicklung einer Software zur Stil- und Grammatikprüfung für englische Texte, Múnich, GRIN Verlag, https://www.grin.com/document/107031
