Software-Werkzeuge im Deutschen Textarchiv

1. In Kürze

Für das Deutsche Textarchiv wurde eine Reihe von Software-Lösungen entwickelt, die während der Volltexterstellung oder für die linguistische Erschließung zum Einsatz kommen. Auf dieser Seite finden Sie einen kurzen Überblick über die für das DTA entwickelten oder angepassten Werkzeuge.

2. DTA Workflow-Datenbank (DTADB)

Die DTA-Workflow-Datenbank dient sowohl der Verwaltung der bibliographischen Metadaten aller für das DTA zu digitalisierenden Bücher als auch der Dokumentation des gesamten Arbeitsablaufs von der Digitalisierung der gedruckten Vorlage bis zur Publikation des Volltextes auf den Servern des DTA. Die Daten werden in einer MySQL-Datenbank verwaltet, ein mit PHP entwickeltes grafisches Web-Frontend ermöglicht die einfache Neuaufnahme und Bearbeitung der Datensätze. Als Schnittstelle für den Export der Daten wurde in der Programmiersprache Python ein Skript geschrieben, für das mittels einer einfachen Templatesprache verschiedene Exportformate entwickelt werden können. Derzeit existiert ein Exportfilter für die automatisierte Erstellung von TEI-Headern, Filter für weitere Metadatenformate (u.a. MODS und Dublin Core) sind in der Entwicklung.

Screenshot DTADB

3. Makrostrukturierung der Bilddigitalisate (ZOT)

Für die Vorbereitung der digtalen Faksimiles für die automatische Volltexterkennung wurde für das DTA das Programm ZOT (ZoningTool) entwickelt. ZOT wurde in der Programmiersprache C++ mit der Klassenbibliothek Qt4 geschrieben. Es stellt eine grafische Benutzer-Schnittstelle bereit, mit deren Hilfe auf jeder Seite verschiedene "Textzonen" definiert werden können

Screenshot ZOT

Nur die hier definierten Zonen werden später durch die OCR-Software erkannt. Damit können die bei einer automatischen Layout-Analyse häufig auftretenden Erkennungsfehler vermieden werden. Dadurch, dass die Zonen in ZOT auch inhaltlich klassifiziert werden (z.B. als "normaler Prosatext", "Kapitelüberschrift", "Seitenzahl", "Fußnote" usw.), ist es möglich, den Text automatisch mit Strukturinformationen zu versehen, nachdem er von der OCR-Software erkannt wurde.

Für diejenigen Texte, die nicht für eine Texterkennung per OCR-Software geeignet sind, sondern manuell erfasst werden, wird eine leicht abgewandelte Version des Programms eingesetzt, mit der die vorstrukturierten Seiten als Bilddateien exportiert werden. Die so vorbereiteten Bilddateien dienen als Vorlage für die manuelle Texterfassung. So kann bereits während der manuellen Erfassung der Text strukturiert werden, indem einfach die in der Bilddatei aufgetragenen Zonen-Marker (für z.B. Überschriften Anmerkungen, Vor- und Nachstücken und ähnlichem "Beiwerk") übernommen werden. Dieses Vorgehen entlastet den Erfasser von der Aufgabe, die oft nicht einfach zu durchschauende Makrostruktur selbst erkennen zu müssen.

4. Datenbank zur OCR Nachkorrektur (DON)

Für die Nachkorrektur der per OCR erkannten Volltexte wurde das Programm DON (DTA-OCR-Nachkorrektur) entwickelt, das eine mehrstufige, parallele Korrektur der Texte ermöglicht. Diese Nachkorrektur erwies sich als notwendig, weil die Ergebnisse der OCR in der Regel eine deutlich höhere Fehlerquote aufweisen (zum Teil unter 95% korrekt erkannte Zeichen) als die manuell per Double-Keying erfassten Texte ( mit 99,97% korrekt erkannten Zeichen). Jede einzelne Seite wurde unabhängig von zwei Bearbeitern anhand der Bildvorlage korrigiert und formatiert, um so eine möglichst hohe Textqualität zu erreichen. Zugrunde liegen eine MySQL-Datenbank und ein in C++ mit Qt4 programmiertes Frontend.

Screenshot DON

5. Variantenabgleich der OCR-Korrekturen (COP)

Durch die Korrektur der OCR-Ergebnisse in DON entstehen zwei Korrekturfassungen, die gegebenenfalls, sollte z.B. in einer Fassung ein Fehler übersehen worden sein, voneinander abweichen. Das Programm COP (COmPare) wurde entwickelt, um Abweichungen der beiden Korrekturversionen anzuzeigen und dem Benutzer eine interaktive Korrektur zu ermöglichen. Wie bereits in DON wird auch in diesem Korrekturschritt das Bilddigitalisat parallel zum Volltext zur Kontrolle angezeigt, die abweichenden Stellen werden im Text automatisch markiert. Der Nachbearbeiter hat so die Möglichkeit sich anhand des Bildes für die korrekte Version zu entscheiden. Im Anschluss werden die in DON und COP korrigierten Bücher aus dem dort verwendeten proprietären Format in ein TEI/P5-konformes XML-Format überführt.

Screenshot COP

6. Bild-Text-Alinierung

Für diejenigen Werke, die per OCR-Software in Volltext umgewandelt wurden, konnten die von der Software erkannten Bildkoordinaten verwendet werden, um bei den Suchergebnissen eine wortweise Verknüpfung zwischen Bild und Volltext zu ermöglichen. Um diese Verknüpfung auch für jene Texte zu ermöglichen, die manuell erfasst wurden, werden auch diese Texte nachträglich durch die OCR-Software erkannt. Die dabei entstandene (fehlerbehaftete) Textfassung wird mit der (korrekten) manuell erfassten Version abgeglichen und dabei die Bildkoordinaten in die manuell erfasste Textfassung übernommen. Das Ergebnis wird in ein internes XML-Format überführt, in zu jedem Zeichen die zugehörigen Bildkoordinaten gespeichert sind. Ein Beispiel für das 'alinierte' XML-Format sehen Sie hier:

<?xml version="1.0" encoding="UTF-8"?>
<TEI>
    <!-- . . . -->
    <c ulx="209" uly="1610" lrx="235" lry="1641" dta:guess="0" xml:id="c24298">U</c>
    <c ulx="237" uly="1618" lrx="254" lry="1640" dta:guess="0" xml:id="c24299">n</c>
    <c ulx="257" uly="1612" lrx="271" lry="1640" dta:guess="0" xml:id="c24300">d</c>
    <c xml:id="c24301"> </c>
    <c ulx="289" uly="1620" lrx="305" lry="1644" dta:guess="0" xml:id="c24302">n</c>
    <c ulx="309" uly="1622" lrx="326" lry="1644" dta:guess="0" xml:id="c24303">u</c>
    <c ulx="328" uly="1623" lrx="344" lry="1644" dta:guess="0" xml:id="c24304">n</c>
    <c xml:id="c24305"> </c>
    <c ulx="361" uly="1625" lrx="373" lry="1645" dta:guess="0" xml:id="c24306">e</c>
    <c ulx="376" uly="1624" lrx="387" lry="1647" dta:guess="0" xml:id="c24307">r</c>
    <c ulx="392" uly="1616" lrx="402" lry="1652" dta:guess="0" xml:id="c24308">f</c>
    <c ulx="403" uly="1619" lrx="419" lry="1649" dta:guess="0" xml:id="c24309">ü</c>
    <c ulx="423" uly="1620" lrx="431" lry="1647" dta:guess="0" xml:id="c24310">l</c>
    <c ulx="431" uly="1618" lrx="440" lry="1649" dta:guess="0" xml:id="c24311">l</c>
    <c ulx="442" uly="1626" lrx="453" lry="1648" dta:guess="0" xml:id="c24312">e</c>
    <c ulx="456" uly="1624" lrx="467" lry="1648" dta:guess="0" xml:id="c24313">t</c>
    <c xml:id="c24314"> </c>
    <c ulx="490" uly="1619" lrx="508" lry="1656" dta:guess="0" xml:id="c24315">ſ</c>
    <c ulx="490" uly="1619" lrx="508" lry="1656" dta:guess="0" xml:id="c24316">i</c>
    <c ulx="511" uly="1618" lrx="536" lry="1656" dta:guess="0" xml:id="c24317">c</c>
    <c ulx="511" uly="1618" lrx="536" lry="1656" dta:guess="0" xml:id="c24318">h</c>
    <c ulx="539" uly="1620" lrx="545" lry="1630" dta:guess="0" xml:id="c24319">’</c>
    <c ulx="548" uly="1622" lrx="561" lry="1648" dta:guess="0" xml:id="c24320">s</c>
    <c ulx="570" uly="1636" lrx="579" lry="1652" dta:guess="0" xml:id="c24321">,</c>
    <c xml:id="c24322"> </c>
    <c ulx="602" uly="1619" lrx="616" lry="1647" dta:guess="0" xml:id="c24323">d</c>
    <c ulx="619" uly="1624" lrx="634" lry="1645" dta:guess="0" xml:id="c24324">a</c>
    <c ulx="637" uly="1615" lrx="653" lry="1651" dta:guess="0" xml:id="c24325">ß</c>
    <c xml:id="c24326"> </c>
    <c ulx="676" uly="1621" lrx="691" lry="1642" dta:guess="0" xml:id="c24327">a</c>
    <c ulx="695" uly="1612" lrx="713" lry="1641" dta:guess="0" xml:id="c24328">l</c>
    <c ulx="695" uly="1612" lrx="713" lry="1641" dta:guess="0" xml:id="c24329">l</c>
    <c ulx="714" uly="1619" lrx="725" lry="1641" dta:guess="0" xml:id="c24330">e</c>
    <c xml:id="c24331"> </c>
    <c ulx="741" uly="1606" lrx="774" lry="1639" dta:guess="0" xml:id="c24332">N</c>
    <c ulx="777" uly="1617" lrx="789" lry="1639" dta:guess="0" xml:id="c24333">o</c>
    <c ulx="793" uly="1614" lrx="802" lry="1640" dta:guess="0" xml:id="c24334">t</c>
    <c ulx="805" uly="1607" lrx="822" lry="1647" dta:guess="0" xml:id="c24335">h</c>
    <!-- . . . -->
</TEI>

Vgl. Goethe, Johann Wolfgang von: Iphigenie auf Tauris. Leipzig: Göschen, 1787, S. 35.

Die Attribute 'ulx', 'uly', 'lrx', 'lry' dienen der Kodierung der Bildkoordinaten, sie sind stets bezogen auf die Masterkopie des Bilddigitalisats mit maximaler Auflösung. Das Attribut 'dta:guess' gibt an, ob die Buchstabenkoordinaten aus den Daten des rohen OCR-Textes extrahiert werden konnten, oder auf der Basis der benachbarten Buchstaben geschätzt sind.

7. Tokenizer für komplexe Texte (DTA-Tokwrap)

Die Tokenisierung, d.h. die automatische Erkennung von Wort- und Satzgrenzen, steht am Anfang jeder weiteren computerlinguistischen Verarbeitung und Analyse. Obwohl dieser Verarbeitungsschritt zunächst trivial klingt, sind gerade bei komplexen Texten verschiedene Probleme zu beachten. So sind beispielsweise getrennt geschriebene Worte (z.B. am Zeilen- oder Seitenumbruch) zusammenzuführen und Abkürzungen, die mit einem Punkt enden, sind zu unterscheiden von Satzenden, die ebenfalls durch einen Punkt markiert sein können. Weiterhin können Anmerkungen oder Marginalien den Textfluss durchbrechen und im XML-kodierten Volltext innerhalb eines Satzes auftreten. Das gleiche Problem ergibt sich auch bei Seitenzahlen, Kolumnentiteln, Bogensignaturen u.Ä., sofern diese im Volltext umgesetzt werden. Auch sie durchbrechen den eigentlichen Textfluss und müssen für die automatisierte Verarbeitung gesondert behandelt werden.

Im DTA kommt daher ein Tokenizer zum Einsatz, der speziell an die Bedürfnisse des Projekts angepasst wurde. Er zeichnet sich durch eine Vorverarbeitungskomponente aus, in der Fußnoten und ähnliche, für die Verarbeitung problematische Textbestandteile erkannt und gesondert analysiert werden, sowie durch eine Abkürzungserkennung, die speziell für historische Texte angepasst wurde. Damit kann die Fehlerrate bei der Erkennung von Satzenden minimiert werden.

Für die Weiterverarbeitung erzeugt der Tokenizer ein TEI-konformes XML-Format, in dem Wörter und Satzgrenzen ausgezeichnet und mit einer eindeutigen Indentifikationsnummer versehen sind. Nachfolgend ein Beispiel, in dem der vom Tokenizer erkannte Satz durch eine Bogensignatur und einen Kolumnentitel durchbrochen ist. Durch die Vergabe eindeutiger ID-Nummern sowohl für Sätze als auch für die einzelnen Worte können derartige "Einschübe" in den Haupttext in der weiteren Verarbeitung ignoriert bzw. separat verarbeitet werden.

<?xml version="1.0" encoding="UTF-8"?>
<TEI>
  <!-- . . . -->
	<s part="I" xml:id="s365">
	    <w xml:id="w4704">Und</w>
	    <w xml:id="w4705">nun</w>
	    <w xml:id="w4706">erfüllet</w>
	    <w xml:id="w4707">ſich’s</w>
	    <w xml:id="w4708">,</w>
	    <w xml:id="w4709">daß</w>
	    <w xml:id="w4710">alle</w>
	    <w xml:id="w4711">Noth</w>
	</s>
	<lb/>
	<fw place="bottom" type="sig">C 2</fw>
	<lb/>
	<pb facs="#f0045" n="36"/>
	<fw place="top" type="header">Iphigenie auf Tauris</fw>
	<lb/>
	<s part="F" n="#s365">
	    <w xml:id="w4712">Mit</w>
	    <w xml:id="w4713">meinem</w>
	    <w xml:id="w4714">Leben</w>
	    <w xml:id="w4715">völlig</w>
	    <w xml:id="w4716">enden</w>
	    <w xml:id="w4717">ſoll</w>
	    <w xml:id="w4718">.</w>
	</s>
    <!-- . . . -->
</TEI>

Vgl. Goethe, Johann Wolfgang von: Iphigenie auf Tauris. Leipzig: Göschen, 1787, S. 35f.

Ein weiterer Vorteil des tokenisierten XML-Formats ist, dass es durch die Vergabe eindeutiger ID-Nummern Annotationen im Standoff-Verfahren ermöglicht. Zusätzliche Informationen zum Text (beispielsweise linguistische Analysen, aber auch inhaltliche Anmerkungen o.Ä.) können in separaten Dateien an die Grunddatei 'angelagert' werden, ohne dass die Ausgangsdatei verändert wird. Es genügt lediglich ein Verweis auf die ID-Nummer des Wortes bzw. Satzes, zu dem die zusätzlichen Informationen gehören.

8. Werkzeuge zur linguistischen Analyse historischer Texte (CAB)

Um die Suche speziell für Texte aus dem 18. und 19. Jahrhundert anzupassen, wird mit CAB (Cascaded Analysis Broker) ein Programm zur fehlertoleranten linguistische Analyse historischer Texte entwickelt. CAB führt ein Wort in historischer Orthographie (z.B. "Theyl" für "Teil") zunächst auf seine phonetische Entsprechung zurück (Letter-To-Sound-Reduktion, LTS), um von dort aus alle möglichen Schreibweisen des Wortes zu rekonstruieren (z.B. auch "Thayl", "Teyl" usw.) und suchbar zu machen.

Eine weitere Analysemethode verwendet eine Kaskade gewichteter endlicher Transduktoren, die ein Wort durch einen im Rahmen des DTA entwickelten Regelsatz in linguistisch plausible orthografische Variationsmöglichkeiten überführt. Durch eine dynamische n-beste Pfadsuche in dieser Transformations-Kaskade können auch solche historische Formen identifiziert werden, die keine direkte phonetische Entsprechung im synchronen Wortschatz haben. Dadurch, dass die Ergebnisse mit Hilfe der TAGH-Morphologie, die auch aktive Komposita-Bildungen akzeptiert, überprüft werden, ist eine hohe Abdeckung des synchronen Wortschatzes gewährleistet. Die Ergebnisse der CAB-Analyse können als Ausgangspunkt für weitere computerlinguistische Bearbeitungen (z.B. morphologische Analyse) dienen.

Eine andere Funktion ist die Normalisierung des Unicode-Zeichensatzes auf das Zeicheninventar des Latin-1-Zeichensatzes. Dabei wird beispielsweise das in Frakturschriften verwendete 'lange' s ( ſ, Unicode-Zeichen U+017F) in ein 'kurzes' s umgewandelt. Dadurch können bei der Suche auch die typographischen Besonderheiten historischer Drucke berücksichtigt werden.

CAB steht projektintern als XML-RPC-basierter Webservice bereit, der bei der Indizierung der Texte durch die Suchmaschine mit angesprochen wird. Es ist vorgesehen, den Webservice auch für externe Benutzer zu öffnen. Eine webbasierte Demoversion, welche die Ergebnisse der CAB-Analysen demonstriert, finden Sie hier.

Literatur: Bryan Jurish (2008), "Finding canonical forms for historical German text". In Storrer, Geyken, Siebert, and Würzner (eds.) /Text Resources and Lexical Knowledge/, Proceedings KONVENS 2008, de Gruyter, pp. 27-37.

9. Indizierung und linguistische Suche (DDC)

Der tokenisierte Text ist das Ausgangsformat für die nachfolgende Indizierung durch die Suchmaschine DDC (Dialing/DWDS-Concordancer). DDC baut für jeden Text eine Index-Datei auf, die für jedes Wort Zusatzinformationen enthält, die bei der Anfrage berücksichtigt werden. Nachfolgend sehen Sie als Beispiel einen Ausschnitt aus einer von DDC erzeugten Index-Datei:

<s>
    <l>Und	Und	\?unt	209|1610|271|1640	44	-	|text|</l>
    <l>nun	nun	nun	289|1620|344|1644	44	-	|text|</l>
    <l>erfüllet	erfüllet	\?E6fYlet	361|1625|467|1648	44	-	|text|</l>
    <l>sich's	ſich’s	zIC	490|1619|561|1648	44	-	|text|</l>
    <l>,	,	-	570|1636|579|1652	44	-	|text|</l>
    <l>daß	daß	das	602|1619|653|1651	44	-	|text|</l>
    <l>alle	alle	\?ale	676|1621|725|1641	44	-	|text|</l>
    <l>Noth	Noth	not	741|1606|822|1647	44	-	|text|</l>
    <l>Mit	Mit	mit	374|342|441|376	45	-	|text|</l>
    <l>meinem	meinem	m[aI]nem	455|352|571|378	45	-	|text|</l>
    <l>Leben	Leben	leben	588|345|670|378	45	-	|text|</l>
    <l>völlig	völlig	f9lIC	686|354|767|385	45	-	|text|</l>
    <l>enden	enden	\?Enden	787|356|871|379	45	-	|text|</l>
    <l>soll	ſoll	zOl	888|348|933|378	45	-	|text|</l>
    <l>.	.	-	937|372|943|379	45	-	|text|</l>
</s> 

Die hier gezeigte Datei bietet in der ersten Spalte jeweils die LATIN-1-normalisierte Form, es folgen das Wort in der gefundenen Form, die phonetische Umschrift im SAMPA-Format, Hinweise zur Fundstelle (Bildkoordinaten und Digitalisat-Nummer) sowie Informationen zum typographischen und textstrukturellen Kontext.