Universität zu KölnInstitut für Linguistik

Sprachliche Informationsverarbeitung

Bachelorarbeitim Fach Informationsverarbeitung

Thema: Strukturierte Texte als Input eines Komponenten-Systems

Vorgelegt von:Mandy Neumann

Matrikelnummer: 4839250Waldecker Str. 42

51065 Köln

Inhaltsverzeichnis

1. Einleitung 21.1. Hinweise zur beiliegenden CD . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Von semistrukturierten zu strukturierten Texten - Dokument-Markup 52.1. Markup-Sprachen und XML . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2. Annotationsrichtlinien der Text Encoding Initiative . . . . . . . . . . . . . 7

2.2.1. Metadaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2. Auszeichnung von Dramentexten . . . . . . . . . . . . . . . . . . . 11

3. Ein Komponenten-System zur Textprozessierung: Tesla 133.1. Tesla-Reader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4. Praxis: Entwicklung einer Reader-Komponente zum Einlesen TEI-kodierterDramentexte für Tesla 184.1. Verarbeitung von XML-Dokumenten: Zugriff auf die Daten . . . . . . . . 184.2. Entwickung des Tesla-Readers . . . . . . . . . . . . . . . . . . . . . . . . . 22

5. Schlussbemerkungen und Ausblick 24

A. Beispiel eines nach TEI annotierten Dramas 26

B. Anleitung zur Verwendung des TEI-Drama-Readers 27

Literatur 29

1. Einleitung

Elektronische Textressourcen bilden eine Grundlage für zahlreiche Forschungsrichtungenwie etwa Korpuslinguistik und Sprachverarbeitung. Während der Textbegriff in denSprachwissenschaften nach wie vor nicht klar definiert und Gegenstand zahlreicher De-batten über Textualitätskriterien – vornehmlich inhaltlicher Art – ist, spielt eine aufinhaltlichen Kriterien basierende Definition von Texten für die elektronische Textprozes-sierung überhaupt keine Rolle. Im Gegenteil – ein vollkommen generischer Textbegriff,der Texte als bloße Folge von Zeichen betrachtet, ist hier meist völlig ausreichend. Eineandere Eigenschaft natürlichsprachlicher Texte spielt dagegen eine bedeutende Rolle fürderen Verarbeitung: Sie sind Instanzen semistrukturierter Daten. Dies bedeutet, dassTexte nicht nur eine sequentielle Aneinanderreihung von Zeichen darstellen, sonderndiese Sequenz eine gewisse inhärente Struktur aufweist – beispielsweise durch Leerzeilen,die Absätze markieren, oder Überschriften, die Abschnitten einen Namen geben. Dieseimplizite Struktur lässt sich durch manuell oder automatisch erstellte Markierungen (sog.Markup oder Annotationen) explizieren – die so gewonnenen strukturierten Texte stelleneine wertvolle Ressource für textprozessierende Systeme dar.

Vertreter besonders stark implizit strukturierter Texte sind die Texte der literarischenGattung Drama. Hier lassen sich zum einen die einzelnen Abschnitte wie Akte und Szenen(welche zudem in einer besonderen Beziehung zueinander stehen, als dass mehrere Szeneneinen Akt bilden), zum anderen auch die einzelnen Sprechakte mit ihren verschiedenenSprechern unterscheiden. Wird diese Struktur durch spezielles Markup expliziert, kanndiese Information in folgenden Analyseprozessen ausgeschöpft werden. Denkbar sind eherliteraturwissenschaftlich ausgerichtete Untersuchungen beispielsweise über die Wortwahlverschiedener Sprecher ebenso wie linguistische Analysen bestimmter grammatischerKonstrukte.

Zur Durchführung von Analysen auf Texten besteht ein breites Angebot dedizierter Soft-ware. Das in der Abteilung für Sprachliche Informationsverarbeitung an der Universitätzu Köln entwickelte Komponentensystem Tesla ist ein solches System. Die Besonderheitan Tesla ist u.a. der dahinterstehende Laborgedanke: Die Untersuchung von Texten solldabei ähnlich ablaufen können wie Untersuchungen in naturwissenschaftlichen Laboren,wobei Gegebenheiten und Ablauf von Experimenten genau dokumentierbar und dieErgebnisse dadurch exakt reproduzierbar sind. Daher werden Analysen in Tesla ebenfallsals Experimente bezeichnet und können durch das Zusammenschalten und Konfigurierenmehrerer Analysewerkzeuge (Komponenten) aufgebaut werden, die auf den Inputtex-

2

ten operieren. Dabei wird eine möglichst große Bandbreite von Input-Formaten vomSystem zugelassen, deren Inhalte für die weitere Verwendung im System von speziali-sierten Komponenten, den sogenannten Readern, eingelesen und wenn möglich bereitspräprozessierend ausgewertet werden.

Zum Markup der inhärenten Struktur von Texten kann das Vokabular der Text EncodingInitiative (TEI) verwendet werden. Um der stetig wachsenden Popularität von TEI in dene-Humanities gerecht zu werden, ist es nur ein logischer Schritt, nach TEI annotierte Texteebenfalls als Input für Tesla zuzulassen. Obwohl es sich bei TEI um ein XML-Formathandelt und Tesla bereits über einen XML-Reader verfügt, erschien es sinnvoll, einendesignierten Reader speziell für TEI-Dokumente (im Rahmen dieser Arbeit beschränktauf TEI-annotierte Dramen) zu entwerfen. Der XML-Reader ist für diese Aufgabe zugenerisch - da er sämtliche XML-Dokumente annimmt, vermag er ihr Markup nicht zuinterpretieren und beschränkt sich daher auf das Entfernen der Tags, um den reinenTextinhalt zu gewinnen. Da TEI als XML-Dialekt dagegen eine spezifische Grammatikund durch Richtlinien spezifizierte Semantik aufweist, kann die Markup-Informationunmittelbar genutzt werden - damit wird der Text nicht nur „maschinenlesbar“, sondernebenso (zumindest in Teilen) „maschinenverstehbar“.

Im Rahmen dieser Arbeit wurde ein solcher Reader für Tesla entwickelt, der in derLage ist, nach TEI annotierte Dramentexte einzulesen und ihre Struktur in Tesla-interneAnnotationen zu überführen. Damit bleibt wesentliche Strukturinformation wie dieEinteilung in Akte und Szenen wie auch die Zuordnung von Diskurstexten zu den Figurenim Stück erhalten und kann in nachfolgenden Schritten in der Analyse unmittelbarverwendet werden.

Die Arbeit ist folgendermaßen gegliedert: Zunächst wird der hier zugrundeliegendeTextbegriff definiert und die Erstellung explizit strukturierter Texte über Dokument-Markup erläutert. Dabei wird insbesondere auf die Annotationsrichtlinien der TEIeingegangen (Kapitel 2). In Kapitel 3 wird das textprozessierende KomponentensystemTesla vorgestellt, wobei der Fokus auf Erläuterung der Eigenschaften des speziellenKomponententyps Tesla Reader liegt. Schließlich wird im Praxisteil (Kapitel 4) nach einerkurzen Einführung in verschiedene Techniken der XML-Verarbeitung die Entwicklung desTEI-Drama-Readers skizziert. Für die Erläuterung einzelner Implementierungsdetails seian dieser Stelle auf die Quelltext-Dokumentation, für Hintergründe zu Architekturdetailsvon Tesla auf die offizielle Online-Dokumentation1 und die Arbeiten von Hermes (2012)und Schwiebert (2012) verwiesen.

1 http://tesla.spinfo.uni-koeln.de/ [11.04.2012].

3

1.1. Hinweise zur beiliegenden CD

Auf der dieser Arbeit beiliegenden CD befindet sich neben der schreibgeschützten elektro-nischen Fassung dieses Dokuments auch der Quelltext des beschriebenen Tesla-Readers.Der Reader ist zudem bereits in den aktuellen Nightly Build des Tesla Client integriert,welcher (in der 32-bit-Version für Windows) ebenfalls auf der CD mitgeliefert wird2. DerClient wird dabei durch Entpacken des dem Betriebssystem entsprechenden Archivs inein beliebiges Verzeichnis installiert und über die ausführbare Datei „Tesla“ gestartet.Eine kurze Anleitung, wie der Reader in Tesla genutzt werden kann findet sich in AnhangB. Auf der CD befinden sich einige Testdateien (TEI-annotierte Dramentexte aus demvon TextGrid zur Verfügung gestellten Bestand der Digitalen Bibliothek), die hierfürverwendet werden können.

2 Nightly Builds stehen derzeit nur für Windows und Linux zur Verfügung – 32- und 64-bit-Versionen sindzu beziehen unter http://tesla.spinfo.uni-koeln.de/nightlies/ [11.04.2012].

4

2. Von semistrukturierten zu strukturierten Texten -Dokument-Markup

Spricht man von Texten, muss zunächst verdeutlicht werden, ob dieser Begriff im lin-guistischen oder informationswissenschaftlichen Sinne gebraucht wird. In der Linguistik(insbesondere der Textlinguistik) spielen Texte insofern eine besondere Rolle, als dass bisheute keine allgemein anerkannte Begriffsdefinition besteht. Grundlage der Definitionbildet dabei der Begriff der Textualität, der bspw. von de Beaugrande und Dressler überdie Aufstellung von sieben kommunikationsbezogenen Kriterien bestimmt wird. Unterdiesen gibt es die beiden textuelle Merkmale der Kohäsion und Kohärenz, die besondersausschlaggebende Kriterien darstellen und sich u.a. auf grammatische Zusammenhängeund semantische Kontinuität im Text beziehen. Weiterhin bestehen Kriterien wie Inten-tionalität, Informativität oder Intertextualität, die Bezug nehmen auf den Verwender desTextes. (vgl. Hermes, 2012:21, Storrer, 2004)

In denjenigen Disziplinen, in denen Texte hauptsächlich zu Analysezwecken verwendetwerden, wie etwa in der Korpuslinguistik, der Sprachverarbeitung oder allgemein in dene-Humanities, spielen derartige inhaltliche Kriterien natürlich keine Rolle. Zentral isthier dagegen die Form der Daten. Nach dem dokumentzentrierten Modellierungspara-digma (vgl. Mehler und Lobin, 2004:4) lassen sich Texte als eine Ordered Hierarchy ofContent Objects (OHCO) begreifen – also als eine Struktur aus Inhaltsobjekten, die inihrer Gesamtheit eine Hierarchie bilden (d.h. ineinander geschachtelt sind, ohne sich zuüberlappen) und auf einer Hierarchieebene jeweils linear geordnet sind.3 Das Konzeptdes „Inhaltsobjekts“ beschreiben DeRose u. a. (1990, S. 5) folgendermaßen:

The essential parts of any document form what we call „content objects,“ [sic!] and areof many types, such as paragraphs, quotations, emphatic phrases, and attributions.Each type of content object usually has its own appearance when a document isprinted or displayed, but that appearance is superficial and transient rather thanessential - it is the content elements themselves, along with their content, which formthe essence of a document.

Der Textbegriff wird also hier nicht inhaltlich, sondern formal-logisch definiert - fürAnalysewerkzeuge stellen Texte damit lediglich eine besondere Form der Daten dar: „AusSicht der Informatik sind Texte semistrukturierte Daten, da sie einen Teil der Informationnur implizit tragen (bspw. Gliederung durch unterschiedliche Formatierungen).“ (Hermes,

3 Diese strikte Form des OHCO-Theorems wurde von den Autoren einige Jahre später revidiert und etwasweniger streng neu formuliert (vgl. Renear, Mylonas und Durand, 1993).

5

2012:21) Diese inhärente Information ist für den Menschen erkennbar, für Computerpro-gramme dagegen nicht – sie können aus dem Vorhandensein von Leerzeilen nicht ableiten,dass der Text in diverse Absätze unterteilt ist. Um also für weitere Analyseschrittedie implizite Struktur unmittelbar nutzbar zu machen, muss sie zuvor durch spezielleAuszeichnung expliziert werden: „Unter Textauszeichnung wird die Einfügung von Mar-kierungen in einen Text verstanden, aufgrund derer die auf diese Weise ausgezeichnetenTextteile in spezieller Weise verarbeitet werden können“ (Lobin, 2004:51). DerartigeMarkierungen bezeichnet man als Annotationen oder Markup4.

Es gibt verschiedene Möglichkeiten, Annotation von Texten durchzuführen. Die Annota-tionen können in einer separaten Datei notiert werden, wobei der Bezug zum Originaltextbeispielsweise über Positionsangaben hergestellt werden kann (sog. Standoff-Annotation).Die Alternative ist das direkte Einfügen der Markierungen in Form von Tags in den Text.Hierfür kommen im Allgemeinen spezielle Markup-Sprachen zum Einsatz.

2.1. Markup-Sprachen und XML

Bereits in den Anfängen der Computertechnologie hat man begonnen, Texte hinsicht-lich ihrer Struktur auszuzeichnen – die Auszeichnungen waren dabei hauptsächlich fürLayoutprogramme gedacht und waren daher proprietärer Natur (vgl. ebd.:52). Mit Ver-abschiedung des ISO-Standards der Standard Generalized Markup Language (SGML) imJahre 1986 wurde eine Loslösung der Dokumentauszeichnung von konkreten Systemenmöglich: Bei SGML handelt es sich um eine Metasprache, mit der sich verschiedeneMarkup-Sprachen für jeden beliebigen Anwendungszweck definieren lassen. Die besondereNeuerung im Bereich der Textauszeichnung, die durch SGML eingeführt wurde, war es,„die durch Tags annotierten Textteile in einen hierarchischen Zusammenhang zu bringen“(ebd.:52). Damit wurde mit SGML die ideale Markup-Sprache geschaffen, um die OHCOvon Textdokumenten explizit auszudrücken: „SGML defines a document in terms of itsOHCO structure“ (DeRose u. a., 1990:12).

Inzwischen wurde SGML durch die 1998 vom World Wide Web Consortium (W3C) zurEmpfehlung5 erklärten Extensible Markup Language (XML) weitgehend ersetzt. „[XML]is currently the most widely-used markup language for digital resources of all kinds“

4 Streng genommen handelt es sich bei Markup um eine bloße Markierung des Layouts und der Typographievon Texten, während Annotation stärker auf die Einfügung analytischer und interpretativer Informationabzielt (vgl. Adolphs, 2006:22f.). Oftmals wird aber auch ganz allgemein von Annotation als einem Textnachträglich hinzugefügte Information jeglicher Art gesprochen.

5 Die aktuelle Version der Empfehlung findet sich unter http://www.w3.org/TR/xml/ [07.04.2012].

6

(Burnard und Bauman, 2011:xxiii). XML ist im Grunde genommen eine Erweiterungvon SGML, die gleichzeitig in einigen Punkten gegenüber SGML vereinfacht wurde.Mittels XML lassen sich also wie mit SGML Markup-Sprachen zur Textauszeichnungdefinieren. Grundsätzlich sind die Namen der Tags (und Attribute) frei wählbar – umdie Mindestanforderung der Wohlgeformtheit an XML-Dokumente zu erfüllen, müssennur minimale Kriterien erfüllt werden. Sollen die Dokumente jedoch valide sein, mussdie XML-Struktur zusätzlich den Regeln einer Grammatik gehorchen, die alle zulässigenTags und Attribute sowie die Beziehungen unter ihnen definiert. Die Definition einersolchen Grammatik trägt zur Vereinheitlichung des Markups bei und vereinfacht Aus-tausch und Weiterverarbeitung der so standardisierten XML-Dokumente. Gerade für dietextprozessierenden Wissenschaften wäre es von Vorteil, wenn eine solche Grammatikfür sämtliche Szenarien der Textauszeichnung bestünde. Bisher konnte sich kein solcherStandard etablieren - die Arbeiten der Text Encoding Initiative (TEI) können jedochheute in den e-Humanities als de-facto-Standard betrachtet werden.6

2.2. Annotationsrichtlinien der Text Encoding Initiative

Die TEI entstand im Jahre 1988 aus einer Konferenz heraus, auf der sich Vertreter ausTextarchiven, Forschungsprojekten und wissenschaftlichen Vereinigungen trafen, um dieEntwicklung eines standardisierten Kodierungsschemas für die Auszeichnung digitalerTexte zu beschließen:

Die Text Encoding Initiative (Text-Kodierungs-Initiative, TEI) hat sich zum Zielgesetzt, einen Standard für die Kodierung von Texten jeglicher Art zu schaffen, umsie für die Verarbeitung mit Computern besser zugänglich zu machen. (Ule undHinrichs, 2004:228)

Um dieses Ziel zu erreichen,definiert die TEI eine Reihe von Richtlinien (Guidelines),die für Benutzer als Referenz dienen sollen. Sie spezifizieren sowohl das Vokabular alsauch das Kodierungsschema, d.h. die Regeln, nach denen das Markup in den jeweiligenAnwendungskontexten verwendet werden sollte. Die Guidelines werden regelmäßig aktua-lisiert und liegen derzeit in der Version P5 vor7. Dabei haben sie stets nur den Status

6 Eine umfangreiche Liste derjenigen Projekte, die TEI einsetzen, findet sich unter http://www.tei-c.org/Activities/Projects/ [11.04.2012].

7 Die aktuelle wie auch ältere Versionen der Guidelines sind online zugänglich unter http://www.tei-c.org/Guidelines/ [08.04.2012] und können dort sowohl heruntergeladen als auch unmittelbar online imHTML-Format durchsucht werden.

7

eines informellen Standards8:

The conclusions and the work of the TEI community are formulated as guidelines,rules, and recommendations rather than standards, because it is acknowledged thateach scholar must have the freedom of expressing his or her own theory of the text byencoding the features he or she thinks important in the text. (Vanhoutte, 2004:11)

Die Guidelines können somit als Referenzhandbuch für mögliche Vorgehensweisen bei derAuszeichnung bestimmter Textmerkmale betrachtet werden.

Grundsätzlich soll mit Hilfe von TEI9 jede beliebige Textsorte ausgezeichnet werdenkönnen: „These Guidelines apply to texts in any natural language, of any date, in anyliterary genre or text type, without restriction on form or content.“ (Burnard und Bauman,2011:xxiii) Um dieses Ziel zu erreichen, ist TEI von Anfang an modular konzipiert – dasgesamte Vokabular möglicher Tags ist in verschiedene Module aufgeteilt, die möglichst alleAnwendungsszenarien abdecken sollen. Dabei haben die Module unterschiedliche Status –eine Kernmenge an Tags, die in jedem TEI-Dokument benötigt werden finden sich inden vier Hauptmodulen tei, core, header und textstructure, welche folglich Bestandteiljedes TEI-Schemas sein sollten. Diese Module definieren u.a. die Klassen, Makros undDatenstrukturen, die von allen Elementen verwendet werden, den Aufbau des Headers(s.u. Abschnitt 2.2.1) und eine Grundtextstruktur mit Elementen, die vermutlich in jederTextauszeichnung Verwendung finden. Ein jedes TEI-Dokument besteht aus dem Wurzel-element <TEI> sowie mindestens den Elementen <teiHeader>, welches die Metadatenenthält, sowie <text> mit dem eigentlichen Textinhalt. Damit sieht die minimale Strukturaus wie in Listing 1 dargestellt10.

8 Dies drückt sich auch darin aus, dass die einzelnen Versionen der Guidelines stets mit einem vorangestellten„P“ (für proposal) bezeichnet werden.

9 Im Folgenden wird von TEI als Auszeichnungsformat gesprochen.10 Das Beispiel wurde übernommen aus Burnard und Bauman (2011):138.

8

� �<TEI>

<teiHeader><!-- .... --></teiHeader><text>

<front><!-- front matter of copy text, if any, goes here -->

</front><body>

<!-- body of copy text goes here --></body><back>

<!-- back matter of copy text, if any, goes here --></back>

</text></TEI>� �

Listing 1: Minimale Struktur eines TEI-Dokuments

Zur Auszeichnung weiterer, bspw. gattungsspezifischer Textmerkmale stehen zusätzlicheModule zur Verfügung – so etwa dictionaries zur Auszeichnung von Wörterbüchern, spokenfür transkribierte gesprochene Sprache oder drama zur Annotation von Dramentexten(s.u. Abschnitt 2.2.2). Einzelne Module können dabei beliebig kombiniert werden, da sielediglich eine Organisationsform für die insgesamt etwa 500 Elemente in TEI darstellen unddie Elemente jedes Moduls immer in Bezug auf ihre Zugehörigkeit zu den im Kernmodultei vordefinierten Klassen definiert sind. Die Kombination (und Manipulation) vonModulen erfolgt im speziellen ODD-Format („One Document Does it all“) – aus einemODD-Dokument lässt sich dann das gewünschte Schema in einer gängigen Schemasprache(DTD, XML Schema oder Relax NG) erzeugen, das schließlich als Grammatik für dieAnnotation eines Dokumentes fungiert. Ebenso besteht die Möglichkeit, Module manuellanzupassen, um etwa bestimmte Tags hinzuzufügen, zu entfernen oder umzubenennen.

2.2.1. Metadaten

Über einen Text kann man neben seinem eigentlichen Inhalt weitere Informationensammeln, sogenannte Metadaten. Dabei handelt es sich um „Daten, die eine Informati-onsressource beschreiben. Sie können sich dabei auf verschiedene Aspekte der Informati-onsressource wie Inhalt, Kontext oder Struktur beziehen.“ (Schmidt, 2004:145) Damit

9

Metadaten möglichst homogen sind und zwischen Anwendungen ausgetauscht werdenkönnen bzw. maschinenverstehbar sind, werden feste Regeln zur Definition einzelner Me-tadatenelemente benötigt. Ein standardisiertes und weit verbreitetes Metadaten-Schemabildet das Dublin Core Metadata Element Set (auch kurz Dublin Core (DC)) der Du-blin Core Metadata Initiative (DCMI)11, welches 15 Felder, darunter creator, title,source oder language, zur Beschreibung von Ressourcen definiert. Diese Kernmengevon Metadatenelementen ist dabei sehr allgemein gehalten, um für eine große Bandbreiteelektronischer Ressourcen nutzbar zu sein, was gleichzeitig Vor- und Nachteile hat:

Aufgrund dieser Allgemeinheit kann das Dublin Core Metadata Element Set alsSchnittstelle zwischen den verschiedenen fachspezifischen Metadaten-Schemata dienen.[. . . ] Dieser allgemeine Ansatz hat jedoch auch den Nachteil, dass aufgrund seinerAllgemeinheit nicht klar spezifiziert ist, wie die einzelnen Kategorien zu füllen sind.(Schmidt, 2004:155)

Ein weitaus fachspezifischeres Metadaten-Schema findet sich in der TEI. Das Modulheader gehört zu den Kernmodulen, weswegen seine Einbindung unbedingt erforderlichist, um die TEI-Konformität eines Dokuments zu wahren. Das zugehörige Tag, in dessenKindelementen die Metadaten deklariert werden, heißt <teiHeader>. Der TEI-Headerlässt sich damit als eine Art elektronischer Titelseite verstehen, die dem eigentlichen Textvorangestellt ist (vgl. Burnard und Bauman, 2011:17). Er enthält vier Hauptbereichezur Beschreibung der Datei selbst, der Beziehung des elektronischen Texts zu seinerQuelle, kontextueller Information und einer möglichen Revisionsgeschichte. Minimalerforderlich ist dabei lediglich die Dateibeschreibung unter <fileDesc>, die wiederummindestens eine Titel-, eine Quellen- und eine Veröffentlichungserklärung beinhaltenmuss. Der kleinstmögliche valide TEI-Header hat damit folgende in Listing 2 dargestellteStruktur12:

11 http://dublincore.org/ [09.04.2012].12 Das Beispiel wurde übernommen aus Burnard und Bauman (2011, S. 18).

10

� �<teiHeader>

<fileDesc><titleStmt>

<title><!-- title of the resource ... --></title>

</titleStmt><publicationStmt>

<p>(Information about distribution of the resource)</p></publicationStmt><sourceDesc>

<p>(Information about source from which the resourcederives)</p>

</sourceDesc></fileDesc>

</teiHeader>� �Listing 2: Struktur des kleinstmöglichen validen TEI-Headers

Die Ausführlichkeit des Headers kann von der Größe dieses Minimalbeispiels bis zu einemsehr großen und komplexen Objekt reichen, je nachdem, wie viele Informationen erfasstwerden sollen. Auch hier bestehen keine standardisierten Ansatzregeln, wie die jeweiligenTags zu verwenden sind, sondern lediglich Empfehlungen.

2.2.2. Auszeichnung von Dramentexten

Für die Auszeichnung von Dramentexten stehen bereits in der Kernmenge der TEI einigeallgemeine Tags zur Verfügung. Das Modul textstructure definiert die Elemente <div>

für ungeordnete bzw. <div1> und <div2> für geordnete Textabschnitte, die sich für dieEinteilung in Akte und Szenen eignen. Vorgeschlagen wird hierfür die Anwendung des@type-Attributs, das etwa mit den Werten "act" und "scene" gefüllt werden könnte.Für Redeakte stehen weiterhin die Elemente <sp> (speech) und <speaker>, für Bühnen-anweisungen <stage> zur Verfügung. Der gesprochene Text kann wie regulärer Text alsAbsatz (<p>), Zeile ( <l>) o.ä. annotiert werden. Listing A (s. Anhang A) zeigt einenAusschnitt einer Dramenannotation13.

13 Dieses Beispiel wurde aus den von TextGrid zur Verfügung gestellten TEI-annotierten Beständen derDigitalen Bibliothek (s. auch Abschnitt 4.1) übernommen und zu Anschauungszwecken manuell gekürzt.

11

Die Nutzung des Moduls drama14 ermöglicht eine gezieltere Auszeichung dramenspezi-fischer Merkmale durch die Einführung von speziellen Elementen für Besetzungslisten,Aufführungsdetails, Rollenbeschreibungen oder detailreichere Bühnenanweisungen. Dieeigentliche Textstruktur bleibt allerdings im Wesentlichen gleich und wie oben beschrie-ben.

Liegt ein in dieser Form ausgezeichneter Dramentext vor, so sind Informationen expliziterschlossen, die für eine weitere Textanalyse wertvoll sein können. „If the whole dramatext consists of nothing but the total sum of speeches, then it becomes rather importantwhat information one can gather from a single speech.“ (Ilsemann, 1995:11) In Ilsemann(ebd.) wird das Computerprogramm DRAMALYS vorgestellt, welches bis dato entwickeltemathematische Modelle und statistische Methoden zur Analyse eines Dramas heranzieht.Das Programm erzeugt als Output eine Liste aller Figuren zusammen mit einer Kon-figurationsstruktur des Stücks, in der Auftritte und Abgänge von Figuren sowie dereneinzelne Sprechakte in einer Matrix dargestellt und eine Reihe von Statistiken über dieseKonfigurationen ausgegeben werden. Dabei wird gezeigt, wie sich diese Darstellung unddie Statistik nutzen lässt, um beispielsweise das Verhältnis zwischen und die Prominenzeinzelner Figuren im Stück zu interpretieren.

Wie dieses Beispiel zeigt, kann die Analyse von Dramen Bestandteil der Textprozessie-rung sein. Wünschenswert wäre dabei, dass hierfür keine starre Software benötigt wird,sondern auf bestehende Teillösungen aufgesetzt werden kann – Dramenanalyse kannTeil eines textprozessierenden Systems sein, bei dem die Analyse als Experiment durchZusammenschalten mehrerer Komponenten, die konfigurierbar und austauschbar sind,durchgeführt wird. Für Anwendungsfälle wie dieser wurde das TextprozessierungssystemTesla entwickelt.

14 Modul 7: Performance Texts (Burnard und Bauman, 2011:197ff.).

12

3. Ein Komponenten-System zur Textprozessierung: Tesla

Das System Tesla wird seit 2005 an der Sprachlichen Informationsverarbeitung (Institutfür Linguistik, Universität zu Köln) entwickelt. Es handelt sich um eine Software15, dieunter zwei Perspektiven betrachtet werden kann. Aus Entwicklersicht bietet sie eineintegrierte Entwicklungsumgebung (IDE) zur Entwicklung textprozessierender Werk-zeuge (Komponenten). Aus Anwendersicht handelt es sich um eine Software, die zurTextprozessierung mit Hilfe ebendieser Werkzeuge genutzt werden kann.16

Tesla steht für Text Engineering Software Laboratory – gleichzeitig referiert dieses Akro-nym indirekt auf Nikola Tesla, einen berühmten Erfinder und Physiker aus dem 19.Jahrhundert. Somit stecken sowohl im vollen Namen als auch im Akronym Andeutungenan den Laborgedanken, der dieser Textprozessierungssoftware zugrunde liegt. Hinter-grund der Entwicklung war der Gedanke, dass Analysen auf textuellen Daten analogzur Durchführung von Experimenten über Rohdaten in naturwissenschaftlichen Laborenmöglich sein sollten. Dafür war es nötig eine Infrastruktur zu schaffen, die Rohdaten (alsotextuelle Daten) jeglichen Formats verarbeiten kann; die weiterhin einen Versuchsauf-bau durch Konfiguration und Verknüpfung textprozessierender Werkzeuge ermöglicht;und die schließlich den Austausch und die Reproduktion der Experimente durch ande-re Wissenschaftler durch die Persistenz von Konfigurationen vereinfacht. (vgl. Hermes,2012)

Um diesen Anforderungen auf technischer Seite gerecht zu werden, ist Tesla als Kom-ponentensystem realisiert. Wie auch in anderen Industriezweigen Waren häufig durchZusammensetzung einzelner Komponenten gefertigt werden, können auch Softwaresyste-me aus einzelnen Softwarekomponenten zusammengesetzt werden. Szyperski (2002, S. 41)definiert eine Softwarekomponente folgendermaßen:

A software component is a unit of composition with contractually specified interfacesand explicit context dependencies only. A software component can be deployedindepently and is subject to composition by third parties.

Komponenten sind also in sich geschlossene „Teil-Software“ mit gekapselter Implementie-rung. Die Kommunikation zwischen Komponenten und dem System bzw. den Komponen-

15 Downloadmöglichkeiten finden sich unter http://tesla.spinfo.uni-koeln.de/download.html[01.04.2012].

16 Für ausführliche Erläuterungen des Systems Tesla, seiner zugrundeliegenden Konzepte, Implementati-onsdetails und Anwendungsszenarien vgl. Hermes (2012) und Schwiebert (2012) – wobei erstere Arbeitstärker auf den Anwendungsaspekt fokussiert, letztere eher technisch orientiert ist.

13

ten untereinander erfolgt über klar definierte Schnittstellen. Innerhalb von Tesla dienenKomponenten zur Textprozessierung und erfüllen in diesem Rahmen spezifische Teilauf-gaben wie Tokenisierung, Lemmatisierung, Clustering oder das Ausführen statistischerAnalysen.

Tesla liegt der Gedanke zugrunde, dass stark speicherplatz- und ressourcenbedürftigeProzesse, wie sie bei der Textprozessierung anfallen, auf leistungsfähigere Hardwareausgelagert werden sollten, wie schon McEnery und Wilson (2003, S. 195) visionierten:

Imagine how much more work we will be able to do when, with the minimum ofeffort, corpus texts can be tagged, parsed and lemmatised on machines much morepowerful than our desktop PCs, while appearing never to move from them.

Daher ist Tesla als Client-Server-System realisiert, bei dem der Client für den Anwenderzur Verwaltung der Inputressourcen, zum Aufbau des Experiments und zum Begutachtender Ergebnisse dient, die eigentliche Experimentdurchführung jedoch auf dem Serverstattfindet (vgl. Hermes, 2012:38). Diese Architektur ermöglicht die Ausführung derExperimente völlig unabhängig von den hard- und softwaretechnischen Voraussetzungendes eigenen Rechners.

Arbeitet man mit Tesla aus der Anwenderperspektive (d.h. in der Linguist Perspective),ist der erste Schritt vor dem Ausführen jeglicher Experimente das Bereitstellen einesTextkorpus17. Teslas Corpus Manager übernimmt dabei serverseitig die Verwaltung dieserInputdaten und stellt seine Funktionalitäten dem Client im CorpusManagerView zurVerfügung. Der Corpus Manager repräsentiert alle Dokumente intern als Objekte vomTyp TeslaDocument in einem Byte-Format (s.u.) und importiert sie in die Tesla-eigenenDatenbanken. (vgl. ebd.:40ff.) Im Zuge dessen wird der für das jeweilige Inputformatpassende Reader ausgewählt – dabei handelt es sich um eine spezielle Komponente,die Rohdaten interpretiert und in ein einheitliches internes Format überführt. Readerstehen damit auch „zwangsläufig am Anfang des in einem Experiment definierten Ver-suchsaufbaus, da sie für die Extraktion der zu untersuchenden Daten verantwortlichsind.“ (Schwiebert, 2012:91) Im Folgenden soll das Konzept des Tesla-Readers nähererläutert werden, bevor im praktischen Teil die Entwicklung eines neuen Readers fürTEI-annotierte Dramen dokumentiert wird.

17 Ein Korpus wird in diesem Zusammenhang im Sinne des Wortes ganz allgemein als „Textkörper“, alsoals eine Sammlung aus mehreren Textdokumenten betrachtet.

14

3.1. Tesla-Reader

Tesla stellt keinerlei formale Anforderungen an die Natur des möglichen Inputs. EinzigeVoraussetzung ist, dass dieser textueller Natur ist – dabei muss es sich nicht einmalum natürlichsprachliche Texte handeln. Der Tesla zugrundeliegende Textbegriff ist weitgenerischer als bisher in dieser Arbeit gebraucht. So definiert Hermes (2012) den Begrifffolgendermaßen: „Ein Text ist eine konkrete Instanz einer Sequenz diskreter Einheitenaus einem endlichen Alphabet.“ (ebd.:22) Damit sind neben natürlichsprachlichen Textenauch MIDI-Sequenzen oder genomische Daten, die in der Bioinformatik ebenfalls alstextuelle Daten betrachtet werden, als Input für Tesla denkbar. Technisch realisiert wirddiese Flexibilität zum einen dadurch, dass die eingelesenen Daten intern als Byte-Arraygespeichert werden. Zum anderen wird die Interpretation dieser Rohdaten in Tesla durchspezielle Komponenten, sogenannte Reader, durchgeführt, wobei bereits eine Reihe Readerimplementiert wurde, die für die unterschiedlichsten Input-Formate spezialisiert sind.(vgl. ebd.:43)

Reader greifen über einen java.io.InputStream auf die Bytefolgen eines Dokuments zuund überführen sie in ein Format, das vom System auf generische Art verwendet werdenkann - „im Falle von Text-Dateien in eine Darstellung als UTF-8-kodierte Zeichenketten“(Schwiebert, 2012:91). Letztere standen bei der bisherigen Entwicklung im Vordergrund,sodass die derzeit vorhandenen Reader allesamt vom Typ String sind. Die einzelnenReader sind dabei unterschiedlich spezifisch, sodass man verschiedene Grade der Spezifitätunterscheiden kann.

Der generellste von ihnen ist der TextReader, der einfach sämtliche Bytes desTeslaDocuments auf einen String schreibt – für den TextReader ist also das gesamteRohdatum Content. Da er sämtliche String-basierten Formate behandeln kann, istder TextReader der Default- Reader für derartige Daten. (Hermes, 2012:44)

Etwas spezifischere Reader können den eigentlichen Textinhalt von etwaigen Auszeichnun-gen trennen, so wie etwa der XMLReader sämtliche Tags entfernt und den reinen Contentliefert. Am höchsten spezialisiert sind diejenigen Reader, die derartige Auszeichnungenauch interpretieren können und sie in Annotationen18 überführen, die zusätzlich zumText in der Datenbank persistiert werden.

18 Im Kontext von Tesla handelt es sich bei Annotationen um die Assoziation eines (Teil-)Signals mitInformationen über dieses Signal in Form eines Datenobjekts. Von Komponenten produzierte Annotationenwerden in einem Annotationsgraphen abgelegt, der als Austauschstruktur zwischen Komponenten dient(vgl. Hermes, 2012, Schwiebert, 2012).

15

Der TeslaCorpusManager kommuniziert mit den Readern über zwei in ihnen definierteSchnittstellen. Beim Import von Textdokumenten befragt er alle verfügbaren Reader-Klassen über deren supportsContent()-Methode (absteigend nach ihrem Spezialisie-rungsgrad), um herauszufinden, welcher Reader für den jeweiligen Input geeignet ist –der erste Reader, der hier true zurückliefert, wird ausgewählt. Die Auswahl kann vomNutzer im Upload-Dialog bei Bedarf manuell angepasst werden. Über getPreview()

wird weiterhin eine Vorschau auf den Text geliefert, wie er vom ausgewählten Readergeliefert wird. Hierfür wird letztlich der Input ebenso verarbeitet wie durch die eigentlicheprozessierende Methode – mit der Abweichung, dass für die Vorschau keine Annotationenerzeugt werden. Die folgende Abbildung zeigt das Vorschaufenster:

Abbildung 1: Vorschau auf den Text des Dokuments, wie er vom ausgewählten Readergeliefert wird

Zur Ausführung gelangen Reader schließlich bei der Ausführung von Experimenten. Einemit @Run annotierte Methode muss dabei wie bei allen Komponenten vorhanden sein –über diese „stellt das Tesla-Laufzeitsystem sicher, dass die entsprechenden Experiment-

16

Konfigurationen sowie die Input- und Output-Adapter des Readers gesetzt sind.“ (Hermes,2012:46) Über den Input-Adapter erhält der Reader dabei Zugriff auf den zugrundelie-genden Byte-Stream, über den Output-Adapter stellt er den gelesenen und prozessiertenContent und die produzierten Annotationen zur Verfügung. Die Adapter sind dabeimit Datenobjekten typisiert, die die Ergebnisse der Komponente darstellen. Sie könnenObjekte beliebiger Java-Klassen sein, solange sie von DataObject abgeleitet sind.

17

4. Praxis: Entwicklung einer Reader-Komponente zum EinlesenTEI-kodierter Dramentexte für Tesla

4.1. Verarbeitung von XML-Dokumenten: Zugriff auf die Daten

Da es sich bei nach TEI annotierten Dokumenten um Instanzen von XML-Dokumentenhandelt, können zu ihrer Verarbeitung gängige XML-Verarbeitungsmechanismen an-gewendet werden, für die verschiedene APIs und (z.T. auch bereits standardisierte)Referenzimplementationen bestehen.

Grundsätzlich unterscheidet man baumbasierte von ereignisbasierten XML-APIs. Beibaumbasierten APIs wird das gesamte Dokument vom Parser als Baumstruktur in denSpeicher geladen, auf die die Anwendung wahlfreien Zugriff erhält. Diese Baumstrukturwird durch das Document Object Model19 (DOM) definiert. Für die (abstrakt gehaltene,da sprachunabhängige) DOM-API existieren Bindungen für diverse Programmierspra-chen, um Schnittstellen für den Zugriff auf diese Baumstruktur in diesen Sprachenbereitzustellen.20 (vgl. Hégaret, 2002)

Ereignisbasierte APIs behandeln das XML-Dokument als eine Folge von Ereignissen –der Parser liest das Dokument sequentiell ein und informiert die Anwendung über dasAuftreten bestimmter Ereignisse (etwa Element- oder Zeichenkettenereignisse), damitdiese darauf reagieren kann. Der bekannteste Vertreter dieser Variante ist die SimpleAPI for XML (SAX). Im Gegensatz zur DOM-API ist SAX kein W3C-Standard – dieAPI entstand aus einer Diskussion auf der Mailingliste XML-dev heraus und wurdezunächst für Java entwickelt, steht aber inzwischen für eine Reihe Programmiersprachenzur Verfügung.21

Beide Ansätze haben Vor- und Nachteile. Die Navigation über den DOM-Baum erlaubtwahlfreien Zugriff auf das gesamte XML-Dokument. Dieser Ansatz ist allerdings insbe-sondere bei sehr großen XML-Dokumenten ungeeignet, da er sehr speicherintensiv ist– es muss stets das gesamte Dokument in den Speicher geladen werden, was ab einerbestimmten Größe nicht mehr praktikabel ist. Ereignisorientierte Ansätze kennen diesesProblem nicht - hier werden Teile des Dokumentes bei Bedarf einfach nachgeladen, wasdie Verarbeitung besonders von großen Dokumenten deutlich beschleunigt. Mit diesem

19 DOM ist ein W3C-Standard: http://www.w3.org/DOM/ [09.04.2012].20 Da die DOM-API abstrakt gehalten ist, kann sie keine sprachspezifischen Lösungen bei der Bereitstellung

von Funktionalitäten nutzen. Für Java gibt es deshalb neben der W3C-Referenzimplementation weitereDOM-APIs wie JDOM oder dom4j, die einen Java-spezifischeren Zugriff auf die Baumstruktur erlauben.

21 Siehe auch die offizielle Webseite: http://www.saxproject.org/ [09.04.2012].

18

Vorteil büßt man allerdings den wahlfreien Zugriff ein: An jedem Ereignis hat der Parserim besten Fall Informationen über das davor gesehene sowie evtl. einen Vorausschaume-chanismus auf das nächste Element. Weitere Kontextinformationen wie das Einsehenaller Kindelemente eines aktuellen Knotens sind hier nicht möglich, da das Baumkonzepthier völlig fehlt.

Aufgrund dieser Eigenschaften wurde für die Implementation des TEI-Drama-Readersdie ereignisbasierte Variante gewählt. Dramentexte sind meist relativ lang, und zusam-men mit den entsprechend detailreichen Annotationen kann ein solches XML-Dokumentdurchaus eine Größe von mehreren tausend Zeilen Inhalt erreichen. Obwohl die Prozes-sierung letztlich vom Tesla Server übernommen wird, sollte nicht verschwenderisch mitden Ressourcen umgegangen werden. Des Weiteren eignet sich der DOM-Ansatz vorallem dann, wenn die genaue Struktur des XML-Dokuments bekannt ist, was hier nichtvorausgesetzt werden konnte, da TEI relativ freie und modifizierbare Richtlinien vorgibt.Statt allerdings auf SAX zu setzen, wurde eine Alternative gewählt: die Streaming APIfor XML (StAX).

Innerhalb des ereignisorientierten Parsings lässt sich weiter unterscheiden zwischen Push-und Pull-Parsing. Beim Push-Parsing liegt die Kontrolle des Parsing-Vorgangs beimParser selbst, der das Auftreten der einzelnen Ereignisse der aufrufenden Anwendung überCallback-Methoden meldet. Dieser Weg wird mit SAX beschritten. Beim Pull-Parsinghingegen behält die Anwendung die Kontrolle - der Parser wird iterativ durch das An-wendungsprogramm aufgerufen. Dies erlaubt insbesondere das Filtern und Überspringenvon bestimmten Ereignissen, also insgesamt einen etwas flexibleren Umgang mit demParser. Eine Referenzimplementation von StAX ist inzwischen Teil des JDK.22

Der TEI-Drama-Parser wurde zunächst unabhängig von Tesla als eigenständige Applika-tion entwickelt und während der Entwicklung an einer Handvoll Testdaten evaluiert. DieTestdaten stammen dabei aus der Digitalen Bibliothek von TextGrid, die unter der Crea-tive Commons Lizenz „by“ Version 3.0 zur Verfügung gestellt werden.23 Darin befindensich literarische Werke, die nach Schriftsteller zusammengefasst in XML-Dateien TEI-annotiert gespeichert sind. Da ein Schriftsteller für gewöhnlich mehrere Werke produziert,sind die Texte nicht als einzelne TEI-Dokumente, sondern als TEI-Korpora ausgezeichnet- das bedeutet, dass das Wurzelelement jeweils <teiCorpus> ist. Ein Korpus kann ausmehreren TEI-Dokumenten zusammengesetzt sein und außerdem wiederum Korporaenthalten, wobei jedes Korpus ebenso wie die TEI-Dokumente einen eigenen Header für

22 http://stax.codehaus.org/ [10.04.2012].23 http://www.textgrid.de/digitale-bibliothek.html [10.04.2012].

19

die Metadaten besitzt. Damit sieht die Grundstruktur eines TEI-Korpus wie in Listing 3dargestellt aus:� �<teiCorpus>

<teiHeader><!-- .... -->

</teiHeader><TEI>

<!-- .... --></TEI><TEI>

<!-- .... --></TEI><teiCorpus>

<!-- .... --></teiCorpus>

</teiCorpus>� �Listing 3: Schematische Struktur eines TEI-Korpus

Da Tesla als Input einzelne Texte vorsieht, die lediglich vom Corpus Manager zu Korporaaggregiert werden, konnten derartig ausgezeichnete Dokumente nicht per se verwendetwerden. Einzelne Dramen wurden daher manuell aus den Korpusdateien extrahiert.Eine Alternative ist die Entwicklung einer kleinen Applikation, die ein Splitten einesTEI-Korpus in mehrere TEI-Dokumente automatisch übernimmt.24

Wie bereits erwähnt wurde zum Parsen der ereignisbasierte Ansatz mit StAX gewählt.Ziel war es, folgende Einheiten zu identifizieren und in Tesla-Annotationen zu überführen:Akte, Szenen, Sprechakte, Sprecher und Bühnenanweisungen. Da für alle diese Elementebereits im Kern der TEI entsprechende Tags definiert sind, kann ihr Vorhandenseingrundsätzlich für jedes TEI-Dokument vorausgesetzt werden. Auf die Nutzung eines vali-dierenden Parsers wurde daher verzichtet.25 Mit Hilfe der Iterator-API von StAX konntedas effektive Suchen und Filtern nach den gewünschten Elementen umgesetzt werden.Dabei läuft der Iterator des javax.xml.stream.XMLEventReader so lange über alle auf-tretenden Ereignisse, bis eines davon die gewünschten Bedingungen erfüllt, die v.a. überbestimmte Elementnamen und Attribute definiert werden. Dabei sind alle interessanten

24 In der Tat existiert im TEI-Wiki (http://wiki.tei-c.org/index.php/Split-teiCorpus [10.04.2012])ein Eintrag, in dem ein XSL-T Sytlesheet vorgestellt wird, das für diese Aufgabe verwendet werdenkönnte. Dessen Funktion konnte im Rahmen dieser Arbeit nicht mehr getestet werden.

25 Im ungünstigsten Fall – wenn also beispielsweise ein nach TEI annotierter Prosatext als Input geliefertwird, werden daher einfach keine Annotationen geschrieben.

20

Elementnamen als QName (Qualified Name) in der statischen Klasse TEIDramaElements

definiert, um den TEI-Namespace dabei zu berücksichten. Eine dieser Bedingungenist beispielsweise der Beginn eines Aktes, der durch das Startelement <div>, dessenAttribut @type den Wert "act" trägt, markiert wird. An diesem Punkt wird der Readeran eine Methode weitergereicht, die die Verarbeitung des Aktes bis zum schließenden</div>-Element übernimmt. In gleicher Weise wird innerhalb dieser Methode auf denBeginn einer Szene (@type des <div>-Elements trägt den Wert "scene") reagiert usw.Listing 4 zeigt beispielhaft den Einstiegspunkt in den Parsingvorgang mit derjenigenSchleife, die das Startelement <text> abpasst (und somit den Header ignoriert), andieser Stelle die entsprechende Handler-Methode aufruft und das Parsen letzlich beiAuftreten des Endelements </TEI> beendet. Der eigentliche Content des Dokuments, unddamit letztlich der Dramentext, wird dabei stets beim Auftreten von Character-Eventsausgelesen.� �XMLInputFactory factory = XMLInputFactory.newInstance();XMLEventReader reader = factory.createXMLEventReader(inputStream);

while (reader.hasNext()) {XMLEvent event = reader.nextEvent();if (event.isStartElement()) {

QName startEventName = event.asStartElement().getName();if (TEIDramaElements.TEXT.equals(startEventName)) {

parseTEIText(reader);}

}else if (event.isEndElement()) {

if (TEIDramaElements.TEI.equals(event.asEndElement().getName())){

break;}

}}� �

Listing 4: Umgang mit der Iterator-API zum Filtern spezifischer Ereignisse

Zusätzlich zum textuellen Inhalt der Dramen sollten auch die Metadaten aus dem Headerextrahiert werden. Dabei sollten diejenigen Metadaten behandelt werden, die den Felderndes Dublin Core entsprechen, da DC der in Tesla genutzte Metadaten-Standard ist. DasProblem dabei ist, dass die Ansatzregeln der Metadaten in TEI ebensowenig normiert

21

sind wie in DC und in beiden Schemata lediglich Empfehlungen bestehen. Es kanndaher nicht garantiert werden, dass jedes DC-Feld mit einem Eintrag gefüllt werdenkann. Nichtsdestotrotz lassen sich im TEI-Header diejenigen Elemente ausmachen, dieetwa äquivalent zu DC-Feldern sind. Dabei kommen teilweise auch mehrere Elemente imTEI-Header als mögliche Äquivalente eines DC-Feldes in Frage.

Das Auslesen der Metadaten aus dem TEI-Header wurde unabhängig von StAX mit Hilfevon XPath26 gelöst. Dies war möglich durch die sehr viel striktere Struktur im Header unddem dadurch gegebenen Wissen, an welcher Stelle nach entsprechenden Informationen zusuchen ist – die entsprechenden Pfadangaben werden einem XPath-Prozessor gegeben,der unmittelbar zu dieser Position navigiert und den Inhalt ausliest.27

4.2. Entwickung des Tesla-Readers

Teslas Komponenten sind einfache Java-Klassen, die im Sinne des Komponentenprinzipsspezifische Schnittstellen und Methoden bereitstellen. Tesla Reader sind dabei lediglichspezielle Komponenten, die statt einer @Component- eine @Reader-Annotation tragensowie die oben erläuterten Methoden zur Verfügung stellen müssen. Des Weiteren müssensie direkt oder indirekt von TeslaReaderComponent abgeleitet sein. Da der hier entwi-ckelte Reader auf natürlichsprachlichen Texten operiert, wurde er als Erweiterung desTextReaders implementiert.

Um der Anforderung zu begegnen, Akte, Szenen, Sprechakte, Sprecher und Bühnenan-weisungen wie auch Metadaten zu annotieren, wurden insgesamt sechs OutputAdapter

als Schnittstellen definiert, die mit den jeweiligen von DataObject abgeleiteten Klassentypisiert sind. Als AccessAdapter wurde dafür für die Metadaten auf die bereits beste-hende Implementation des DublinCoreMetaDataAccessAdapter zurückgegriffen, für dieübrigen Annotationen wurde der einheitliche DramaAccessAdapter definiert.

Um zu definieren, welche Art von Input vom Reader akzeptiert wird, wird innerhalbvon supportsContent() der Input-Stream rudimentär auf den Inhalt seiner erstenZeilen überprüft. Die Wohlgeformtheit des XML-Dokuments wird über das Vorhan-

26 Xpath ist die XML Path Language und dient zur Referenzierung einzelner Knoten im XML-Baum überPfadangaben. XPath ist W3C-Standard – seine Spezifikation findet sich unter http://www.w3.org/TR/xpath/ [11.04.2012].

27 Wenn man in diesem Fall von „navigieren“ spricht wird deutlich, dass XPath auf einer zugrundeliegendenBaumstruktur operiert. Dadurch rücken wieder die Nachteile von DOM in den Fokus, die bereitsbesprochen wurden. Im Hinblick auf Performanz wäre zu überlegen, diesen Ansatz wieder aufzugebenund auch die Metadaten über StAX auszulesen. Dies ginge zu Lasten der Komplexität des Codes.

22

densein der Processing Instruction <?xml> mit Versionsangabe am Dateianfang über-prüft. Einzig weitere Voraussetzung für die Akzeptanz des Inputs ist es, dass alsnächstes das Wurzelelement <TEI> zusammen mit der Definition des TEI-Namespaces(xmlns="http://www.tei-c.org/ns/1.0") auftritt. Der Einsatz einer Validierung in-nerhalb von supportsContent() war nicht sinnvoll einsetzbar, weil es das System zustark ausgebremst hätte, da diese Methode bei jedem neu hinzugefügten Dokument vomCorpus Manager aufgerufen wird und außerdem aufgrund der Flexibilität von TEI keineallgemeingültigen Validitätskriterien ausgemacht werden können.

Die beiden Methoden getPreview() und processText() arbeiten beide gleich - genaugenommen wird innerhalb von getPreview() die Methode processText() aufgerufen,wobei der boolsche Parameter writeAnnotations mit dem Wert false belegt übergebenwird, um keine Annotationen zu produzieren. Die Prozessierung erfolgt über den obenbeschriebenen Weg mit Hilfe von StAX, wobei Positionsangaben während des Vorgangsam Anfang eines zu behandelnden Abschnitts (wie etwa Akt) gespeichert und an dessenEnde zusammen mit der Endposition in die Annotation eingetragen werden (Standoff-Annotation). Wenn möglich werden den einzelnen Datenobjekten weiterhin spezielleLabels zugewiesen (bspw. erhält ein Akt als Label seine Bezeichnung wie „1. Akt“oder ein Sprecher seinen Namen). Jeglicher Zeicheninhalt (und damit der Content desDokuments) wird schließlich unmittelbar auf den Output-Stream geschrieben und kanndaher im Vorschaufenster eingesehen werden. Metadaten werden wie oben beschriebenseparat mittels XPath aus dem TEI-Header ausgelesen und am Ende des Parsingvorgangsin eine separate Annotation geschrieben.

23

5. Schlussbemerkungen und Ausblick

Der TEI-Drama-Reader wurde im Rahmen dieser Arbeit vollständig implementiertund ist lauffähig. Werden TEI-Dokumente in einem Experiment als Korpus eingesetztund während der Ausführung vom TEI-Drama-Reader vorprozessiert, erhält man alsErgebnis die Annotation aller vorhandenen Akte, Szenen, Sprechakte, Sprecher undBühnenanweisungen, sofern vorhanden. Des Weiteren werden Metadaten aus dem TEI-Header gesammelt, die Feldern des Dublin Core entsprechen. Insgesamt ist die Qualitätder Annotationen noch von bestimmten Voraussetzungen abhängig, die an die TEI-Dokumente gestellt werden. Akte und Szenen können nur dann erkannt werden, wennsie entsprechend in <div>-Container eingebettet sind, die exakt die Werte "act" und"scene" in ihren @type-Attributen gesetzt haben. Daher werden beispielsweise zu demauf CD mitgelieferten Dramentext „Der wundertätige Magus“ von Calderón de la Barcagar keine Annotationen für Szenen geschrieben, da sie im TEI-Text mit <div>s annotiertsind, deren @type-Attribut den Wert "text" trägt. Als Konsequenz werden ebensowenigAnnotationen für Sprechakte und Bühnenanweisungen innerhalb von Szenen produziert.Für die Zukunft ist daher zu überlegen, die Komponente weiter zu modifizieren, um dieseKontextabhängigkeiten soweit wie möglich zu eliminieren.

Derzeit sind natürlich noch keine Komponenten vorhanden, die die produzierten Anno-tationen auswerten können – daher wird sich der praktische Nutzen des Readers erstin Zukunft zeigen. Möglicherweise werden dann noch kleine Veränderungen notwendig.Insgesamt wird Tesla durch die Unterstützung des TEI-Standards weiter für das gesamteGebiet der e-Humanities interessant.

24

Erklärung

Hiermit versichere ich, dass ich diese Bachelorarbeit selbstständig verfasst und keineanderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Die Stellen meinerArbeit, die dem Wortlaut oder dem Sinn nach anderen Werken und Quellen, einschließlichder Quellen aus dem Internet, entnommen sind, habe ich in jedem Fall unter Angabe derQuelle als Entlehnung kenntlich gemacht. Dasselbe gilt sinngemäß für Tabellen, Kartenund Abbildungen. Diese Arbeit habe ich in gleicher oder ähnlicher Form oder auszugs-weise nicht im Rahmen einer anderen Prüfung eingereicht. Ich versichere zudem, dass dieeingereichte elektronische Fassung den beiden gebundenen Fassungen komplett entspricht.

Köln, den 12. April 2012 Unterschrift:

25

A. Beispiel eines nach TEI annotierten Dramas� �<TEI xmlns="http://www.tei-c.org/ns/1.0">

<teiHeader><fileDesc>

<titleStmt><title>Die Räuber</title>

</titleStmt><publicationStmt><!-- .... --></publicationStmt><sourceDesc><!-- .... --></sourceDesc>

</fileDesc></teiHeader><text>

<body><!-- .... --><div type="act">

<div><desc><title>5. Akt</title></desc>

</div><div type="scene">

<div><desc><title>1. Szene</title></desc>

</div><div type="text">

<!-- .... --><sp><speaker>DANIEL</speaker>

<stage><hi rend="italic">ängstlich.</hi></stage><p> Hilf, heilige Mutter Gottes! Seid Ihrs,

gestrenger Herre, der so gräßlich durch dieGewölbe schreit, daß alle Schläfer

auffahren?</p></sp>

</div></div>

</div></body>

</text></TEI>� �

Listing 5: Ausschnitt aus dem TEI-annotierten Drama „Die Räuber“

26

B. Anleitung zur Verwendung des TEI-Drama-Readers

Der im Rahmen dieser Arbeit entwickelte Reader-Komponente für Tesla wurde über dasVersionierungssystem Subversion (SVN) bereits fest in Tesla integriert, sodass sie in deraktuellen Nightly-Version von Tesla bereits zur Verfügung steht. Im Folgenden soll kurzerläutert werden, wie sie verwendet werden kann, um ihre Funktion zu testen.

Nach Download und Start des Clients startet man zunächst den Tesla Server verbindetsich mit ihm. Die Linguist Perspective (s. Abbildung 2) dient als virtueller Arbeitsplatzzur Textprozessierung und wird daher zum Erstellen und Ausführen von Experimentengeöffnet. Im Corpus Manager View lassen sich neue Dokumente über das Kontextmenühinzufügen – im sich öffnenden Upload Dialog werden die Dokumente aus dem Datei-system (bspw. von der beiliegenden CD) ausgewählt. Daraufhin ermittelt der CorpusManager den zuständigen Reader, wobei an dieser Stelle bei gültigen TEI-Dokumentender TEIDRamaReader automatisch ausgewählt werden sollte. Im Vorschaufenster wirddann bereits der Textinhalt so, wie er vom Reader ausgegeben wird, angezeigt.

Nach dem Hinzufügen neuer Dokumente kann man deren Metadaten im PropertiesView betrachten. Vollständig ausgeführt wird die Reader-Komponente allerdings erstbei der Ausführung eines Experiments, da sie für die prozessierenden Komponentenden Content und Annotationen zur Verfügung stellt. Da bisher keine Komponentenimplementiert sind, die die Annotationen verwenden, kann man zur Demonstration derArbeit des Readers zunächst auf eine einfache Komponente wie den Simple Tokenizerzurückgreifen, der den Inputtext tokenisiert. Dazu erstellt man ein neues Experiment, fügtdie zuvor hochgeladenen Dokumente als Korpus sowie den Tokenizer (oder eine andereKomponente, die als Input einen Text erwartet) hinzu und führt das Experiment aus.Nach der Ausführung kann man die produzierten Annotationen über das Kontextmenü„Analyze. . . “ beispielsweise in Form farblich hervorgehobener Textstellen betrachten (s.Abbildung 3).

Für genauere Anleitungen zur Nutzung der beschriebenen Funktionen in Tesla kann auchdie Online-Dokumentation unter http://tesla.spinfo.uni-koeln.de/tutorials.html

konsultiert werden.

27

Abbildung 2: Die Tesla Linguist Perspective mit dem Corpus Manager View (links oben),dem Properties View (links unten) und dem grafischen Editor für dieExperimentverwaltung

Abbildung 3: Der Highlighted Text View zeigt die produzierten Annotationen verschie-denfarbig hinterlegt an.

28

Literatur

Adolphs, Svenja (2006). Introducing Electronic Text Analysis. New York: Routledge.

Burnard, Lou und Syd Bauman (2011). TEI P5: Guidelines for Electronic Text Encodingand Interchange. Techn. Ber. TEI Consortium.

DeRose, Steven J. u. a. (1990). „What is Text, Really?“ In: Journal of Computing inHigher Education 1.2, S. 3–26.

Hermes, Jürgen (2012). „Textprozessierung - Design und Applikation“. Diss. Köln:Universität zu Köln.

Hégaret, Philippe Le (2002). The W3C Document Object Model (DOM). url: http:

//www.w3.org/2002/07/26-dom-article.

Ilsemann, Hartmut (1995). „Computerized Drama Analysis“. In: Literary and LinguisticComputing 10.1, S. 11–21.

Lobin, Henning (2004). „Textauszeichnung und Dokumentgrammatiken“. In: Texttech-nologie: Perspektiven und Anwendungen. Hrsg. von Henning Lobin und LotharLemnitzer. 2. Aufl. Tübingen: Stauffenburg Verlag. Kap. 2, S. 51–82.

Lobin, Henning und Lothar Lemnitzer, Hrsg. (2004). Texttechnologie: Perspektiven undAnwendungen. Stauffenburg Verlag.

McEnery, Tony und Andrew Wilson (2003). Corpus Linguistics. 2. Aufl. EdinburghTextbooks in Empirical Linguistics. Edinburgh: Edinburgh University Press.

Mehler, Alexander und Henning Lobin (2004). „Aspekte der texttechnologischen Modellie-rung“. In: Automatische Textanalyse. Hrsg. von Henning Lobin. 1. Aufl. Wiesbaden:Verlag für Sozialwissenschaften. Kap. 1, S. 1–22.

Renear, Allen, Elli Mylonas und David Durand (1993). Refining our Notion of WhatText Really Is: The Problem of Overlapping Hierarchies. url: http://www.stg.

brown.edu/resources/stg/monographs/ohco.html.

Schmidt, Ingrid (2004). „Modellierung von Metadaten“. In: Texttechnologie: Perspektivenund Anwendungen. Hrsg. von Henning Lobin und Lothar Lemnitzer. 2. Aufl.Tübingen: Stauffenburg Verlag. Kap. 5, S. 143–164.

Schwiebert, Stephan (2012). „Tesla - Ein virtuelles Labor für experimentelle Computer-und Korpuslinguistik“. Diss. Köln: Universität zu Köln.

29

Storrer, Angelika (2004). „Text und Hypertext“. In: Texttechnologie: Perspektiven undAnwendungen. Hrsg. von Henning Lobin und Lothar Lemnitzer. 2. Aufl. Tübingen:Stauffenburg Verlag. Kap. 1, S. 13–50.

Szyperski, Clemens (2002). Component Software. Beyond Object-Oriented Programming.2. Aufl. Component Software Series. New York: ACM Press.

Ule, Tylman und Erhard Hinrichs (2004). „Linguistische Annotation“. In: Texttechnologie:Perspektiven und Anwendungen. Hrsg. von Henning Lobin und Lothar Lemnitzer.2. Aufl. Tübingen: Stauffenburg Verlag. Kap. 8, S. 217–244.

Vanhoutte, Edward (2004). „An Introduction to the TEI and the TEI Consortium“. In:Literary and Linguistic Computing 19.1, S. 9–16.

30