[Dieser Text ist das Abstract zu unserem Vortrag auf der TaCoS 2012 (für Kurzentschlossene: Anmeldeschluss heute!) und bietet einen knappen Einstieg in die Ideen, die Tesla zugrundeliegen, weswegen ich ihn hier nochmal (ungeachtet der daraus resultierenden Redundanzmehrung) veröffentliche.]
Das Text Engineering Software Laboratory (Tesla) ist eine Software, die einen virtuellen Laborarbeitsplatz simuliert, an dem Computerlinguisten und andere Wissenschaftler, die sich mit Texten auseinandersetzen, experimentell arbeiten können.
Laboratorien sind bislang eher aus der naturwissenschaftlichen oder medizinischen Forschung bekannt. Sie werden genutzt, um Rohmaterialien zu lagern, Versuchsaufbauten zusammenzustellen und Experimente durchzuführen. Analog sollte ein computerlinguistisches Labor Zugriff auf Rohmaterialien (hier: Texte) anbieten und die Möglichkeit eröffnen, diese Daten in selbst zusammengestellten Versuchsanordnungen (in Form annotierender und analysierender Werkzeuge) zu prozessieren, um im Anschluss die Ergebnisse dieser Prozessierung (d.h. annotierte und analysierte Daten) auswerten zu können.
Tesla realisiert ein solches computerlinguistisches Labor durch ein Client-Server-System, bei dem Clients die Interaktion mit Anwendern übernehmen und die genannten Funktionalitäten anbieten, während der Server für die u.U. ressourcenintensive Prozessierung und die Datenhaltung zuständig ist.
Der Client basiert auf Basis der Plattform Eclipse und bietet zwei verschiedene Perspektiven, die zwei unterschiedliche Anwenderkreise anspricht:
In der Entwickler-Perspektive können neue Werkzeuge (Komponenten) für die Prozessierung von Texten entwickelt werden.
In der Linguisten-Perspektive können diese Werkzeuge über einen graphischen Workflow-Editor (siehe Abbildung) zu Versuchsanordnungen (Experimenten) kombiniert und konfiguriert werden. Die Experimente werden vollständig dokumentiert; die gewonnenen Erkenntnisse sind dadurch jederzeit reproduzierbar.
Ein Tesla-Experiment (zur Ansicht bitte groß klicken)
Tesla steht unter der Eclipse Public Licence (Open-Source) und kann unter http://tesla.spinfo.uni-koeln.de heruntergeladen werden. Dort finden sich auch weitere Informationen (Tutorials, Dokumentation, Veröffentlichungen) zum System.
Anlässlich mehrerer Tagungen, auf denen wir Tesla präsentieren dürfen, haben wir ein wenig an der Visualisierung von Experiment-Ergebnissen gearbeitet, v.a hat Stephan die neueste Version seines WordCloud-Erzeugers Cloudio in den Client von Tesla integriert. Damit können jetzt Wortwolken, wie die oben im Titelbild meines Blogs, innerhalb von Tesla erzeugt werden.
Ich möchte die Gelegenheit nutzen, die bisher implementierten Tesla-Visualisierer hier im Blog vorzustellen, bevor wir heute das nachmittag ab 15:15 Uhr live im TextGrid-Café tun. Visualisierung wird vor allem da benötigt, wo die automatische Evaluation von Ergebnissen zu kurz greift und die Forscherin/der Forscher, der experimentell arbeitet, ihre/seine Ergebnisse mittels ihres/seines Intellektes überprüfen will. Wie es das Thema verlangt, werden hier mehr Screenshots denn Texte im Vordergrund stehen.
Alle folgenden Visualisierungen basieren auf den Ergebnissen eines einzigen Experiments, [das irgendwann im Laufe der Woche von Alena bei der Plattform MyExperiment geshart wird, ich binde den Link dann ein inzwischen dank Alena auch bei MyExperiment heruntergeladen werden kann]. Dabei geht es eigentlich nur um eine Studie zu einer Methode, temporale Ausdrücke aus Texten zu extrahieren. Der zugehörige Workflow sieht im Editor wie folgt aus:
Oben im Workflow finden sich Wikipedia-Texte, deren temporale Ausdrücke vorausgezeichnet wurden. Auf der linken Seite befindet sich die Komponenten, deren Zusammenspiel diese temporalen Ausdrücke (ohne die Kenntnis der Vorauszeichnungen) ermitteln soll. Auf der rechten Seite steht, relativ allein, die Evaluationskomponente, welche die Menge der vorausgezeichneten Ausdrücke mit der Menge der experimentell ermittelten vergleicht.
Nach der Ausführung des Experiments steht zunächst eine Ergebnis-Übersicht zur Verfügung, in der Informationen zu den einzelnen Komponenten abrufbar sind, hier schreibt z.B. die Evaluationskomponente ihre ermittelten Werte zur Precision, Recall und F1-Wert hinein:
Möglicherweise ist am aber nicht nur an den Evaluationsmaßen interessiert, sondern auch daran, welche der vorausgezeichneten Ausdrücke denn nun gefunden wurden und welche nicht. Dabei möchte man vielleicht auch direkt den Kontext sehen, in dem sich die (nicht) gefundenen Ausdrücke befinden. Hierfür bietet sich z.B. ein farblich unterlegter Text an:
In dieser Visualisierung sind die vorausgezeichneten (rot) und die ermittelten (gelb) temporalen Ausdrücke markiert. Überlappen sich beide, so werden sie mit der Mischfarbe (orange) markiert. Hier sieht man, dass der Versuchsaufbau für Datums-Angaben verschiedenen Formats recht gut funktioniert und noch Verbesserungen hinsichtlich von zeitbezogenen Wörtern eingebracht werden könnten (etwa durch Erweiterung der Gazetteer-Listen).
Vielleicht möchte man aber auch eine Aufstellung allerermittelten temporalen Ausdrücke haben. Dafür hat Tesla eine Tabellen-Visualisierung (Tabellen können auch direkt in ein csv-Format exporiert werden, um sie woanders weiter zu verarbeiten):
Außerdem verfügt Tesla noch über eine Visualisierung in Klammerstruktur (um etwa Dominanzbeziehungen zwischen Elementen im Text auszudrücken, den Sceenshot spare ich mir ausnahmsweise mal) und eben über die WordCloud, die zumindest visuell momentan der Höhepunkt jeder Tesla-Präsentation ist, auch wenn es nicht für jedes Datum Sinn macht, es in einer Cloud darzustellen. In der folgenden Abbildung sind etwa alle temporalen Ausdrücke nach ihrer Häufigkeit aufgetragen. Kann man nicht unbedingt für Interpretationszwecke nutzen, schön aussehen tut es dennoch:
Soweit meine kurzen Ausführungen zu den bereits in Tesla integrierten Visualisieren. Wir wissen selbst, dass es noch eine Menge von Möglichkeiten gibt, die zu integrieren sich wirklich lohnen würde, etwa einen Datenplotter und Darstellungsmöglichkeiten für statistische Auswertungen. Auch die allen Visualisierungen zugrundeliegende Datenstruktur ist historisch gewachsen und inzwischen überarbeitungsbedüftig. Ist auf der Liste der nice-to-haves. Ob wir wirklich noch mehr realisieren können hängt aber vor allem von potentiellen Geldgebern ab (sonst haben wir soviel anderes zu tun). Wir hoffen mal das Beste.
Nach einem abermaligen kurzen Ausflug in die historische Kryptographie komme ich nun wieder zum Kerngeschäft dieses Blogs zurück und berichte über die aktuellen Entwicklungen rund um Tesla, unserem Labor für Textwissenschaftler.
Momentan wird ein Großteil unserer Zeit davon beansprucht, abzuwägen, welche Weiterentwicklungen von Tesla wünschenswert und gleichzeitig förderungswürdig sind. Relativ sicher sind wir uns da hinsichtlich der Integration von Tesla in die Software, die innerhalb des Projekts TextGrid entstanden ist. Die ersten Gespräche haben dazu schon (mit sehr netten Leuten übrigens) stattgefunden, und wie es aussieht, sind beide Seiten der Meinung, dass die Systeme bisher relativ komplementäre Funktionalität bieten und dass eine Integration der beiden großen Gewinn für die geisteswissenschaftliche Community böte, auf die sowohl TextGrid wie auch Tesla ausgerichtet sind. Ich bin sehr gespannt, wie die weiteren Schritte diesbezüglich ausfallen, wenn wir uns im Rahmen des TextGrid Summit 2012 nochmal zusammensetzen.
Jenseits der TextGrid-Tesla-Integration gibt es aber auch noch eine Reihe weiterer Verbesserungen unseres Systems, die wir gerne in Angriff nehmen würden. Ich hatte ja bereits über die Möglichkeit gebloggt, Tesla-Experimente über das wissenschaftliche Social Network MyExperiment auszutauschen. Mit ein wenig Zeit könnte man die entsprechende Schnittstelle in einer Art ausbauen, dass der Upload aller relevanten Daten (Komponenten, Texte, Screenshot etc.) mit einem einzelnen Mausklick erfolgt. Weiterhin könnte beispielsweise die Unterstützung von Werkzeug-Entwicklern etwas komfortabler gestaltet werden, zur Zeit muss man noch viel zu Fuß erledigen, was eigentlich automatisierbar wäre. Unsere Überlegungen gehen auch dahin, Tesla Cloud-Computing-fähig zu machen, so dass wirklich komplexe Berechnungen auf wirklich großen Datenmengen in akzeptabler Zeit ermöglich werden. Stephan testet zur Zeit das Clustering von Vektoren auf Grafikkarten und erreicht damit eine schon jetzt beeindruckende Performance-Gewinne. Wenn man sich jetzt vorstellt, dass man nicht nur eine, sondern eine ganze Reihe von Grafikkarten nutzt (z.B. die unserer Computerpools zu Zeiten, in denen diese nicht öffentlich genutzt werden), so könnte man in ganz neue Sphären von Experiment-Setups in der Textprozessierung vorstoßen.
Abgesehen von dieser Zukunftsmusik (die wahrscheinlich auch nur gespielt wird, wenn wir Gutachter davon überzeugen können, dass es sich um wirklich förderungswürdige Vorhaben handelt) entwickeln wir Tesla gegenwärtig natürlich auch schon weiter. Zentral ist dabei momentan die vollständige Umstellung des Build-Prozesses auf Maven sowie der Umzug des Source-Codes auf GitHub. Im Rahmen einer Bachelorarbeit bei uns am Institut entstand vor kurzem auch ein Reader für TEI-codierte Dramen. Außerdem sind in letzter Zeit eine Reihe von Leuten auf uns zugekommen, die ihre Projekte mit Tesla bearbeiten wollen und die wir dabei gerne unterstützen. Daran, dass diese Anfragen aus sehr unterschiedlichen Fachbereichen kommen – Linguisten aus verschiedenen Philologien (Anglisten, Romanisten und Skandinavisten), Sprachtechnologen und sogar Geographen – kann man auch ersehen, dass Tesla keinesfalls nur auf Computerlinguisten ausgerichtet ist.
Wir stellen Tesla übrigens im nächsten Monat gleich zweimal vor, zuerst auf dem schon oben erwähnten TextGrid-Summit (Systemdemo/Postersession 15.5. an der TU Darmstadt), danach auf der TaCoS (Vortag 1.6. an der Uni Trier). Auf diesem Weg noch einmal herzlichen Dank für die beiden sehr netten Einladungen! Vielleicht sieht man sich ja.
Eine der am häufigsten gestellten Fragen an uns ist ohne Zweifel die nach den Verwendungsmöglichkeiten für Tesla. Die Frage kam bereits in den Kommentaren dieses Blogs auf, sie wird uns auf den Konferenzen gestellt, auf denen wir Tesla vorstellen, sie war sowohl Teil meiner Disputation, als auch der meines Kollegen Stephan Schwiebert.
Die Antwort auf die Frage ist relativ einfach: Mit Tesla kann man eigentlich alles machen, was auf maschinellen Annotationen oder einer automatischen Analyse von Texten beruht. Wie das mit einfachen Antworten so ist, ergibt sich aus ihnen meist eine ganze Reihe weiterer Fragen. So auch hier:
Was fällt denn alles unter den Begriff Texte?
Was kann man sich konkret unter maschinellen Annotationen vorstellen?
Und was unter automatischen Analysen?
Was bedeutet man kann eigentlich alles machen?
Gibt es denn Dinge, für die sich Tesla nicht eignet?
Aber es gibt doch auch das System XYZ, kann das nicht genau das Gleiche?
Versuche ich mal, diese Fragen zu beantworten, ohne dass allzu viele Folgefragen aufgeworfen werden (weswegen ich auch versuche, möglichst ohne sprachwissenschaftliche und informatische Fachbegriffe auszukommen):
(1) Wir verwenden den Begriff Text relativ weit gefasst. Texte sind für uns einfach alle Daten, die sich in einer linearen, eindimensionalen Abfolge von Zeichen aus einem definierten Alphabet repräsentieren lassen. Das gilt zunächst einmal für alle Daten, die sich irgendwie in einem herkömmlichen Computer speichern und verarbeiten lassen, letztlich arbeitet dieser ja mit Sequenzen von Nullen und Einsen. Wir meinen hier aber vor allem diejenigen Daten, die sich durch ihre eindimensionale Struktur auszeichnen. Darunter fallen vor allem natürlichsprachliche Texte, aber auch Text-Repräsentationen von DNA, RNA, Proteinen und auch von Musikstücken. Die Entscheidung, möglichst viele unterschiedliche Daten in Tesla verarbeiten zu können, wurde bewusst getroffen. Auf diese Weise können unterschiedliche Verfahren für spezifische Daten entwickelt werden, die dann gegebenenfalls auf andere Daten übertragen werden können. Tesla stellt außerdem keinerlei Anforderungen an das Format der Texte.
(2) Sprache ist zwar letztlich (spätestens beim Verlassen unseres Sprechorgans bzw. als Buchstabenfolge eines Textes) eindimensional organisiert: Mündliche Sprachmitteilungen bestehen etwa aus einer Folge von Lauten, schriftliche Texte aus einer Folge von Buchstaben. Über diesen mehr oder weniger grundlegenden Einheiten sprachlicher Kommunikation existieren jedoch weitere Organisationseinheiten wie Wörter oder Sätze, dabei gibt es unterschiedliche Wortklassen (z.B. Substantive, Verben) und Funktionen (z.B. Objekt, Prädikat). Alle diese Einheiten, Klassen und Funktionen sind implizit im Sprachsignal enthalten, um sie auswerten zu können, müssen die Sprachdaten explizit mit ihnen ausgezeichnet (annotiert) werden. Das kann man entweder manuell machen (was gewisse Vor-, aber auch Nachteile hat) oder bestimmte dafür programmierte Werkzeuge machen lassen. Dazu gehören z.B. Tokenizer, die Wortgrenzen bestimmen, Tagger, die Wörter Wortklassen zuordnen und Parser, welche die Funktion von Wörtern oder Wortgruppen erkennen. Tesla besitzt eine ganze Reihe solcher Werkzeuge, mit denen sich Daten maschinell annotieren lassen.
(3) Annotationen wie in (2) beschrieben, sind meist eine Vorstufe zur Daten-Analyse, die man auch innerhalb von Tesla betreiben kann. Aus der unüberschaubaren Menge möglicher Analysen wähle ich hier ein Beispiel aus dem Bereich Informationsextraktion (IE). IE ist eine Art Oberbegriff für Verfahren, die aus unstrukturierten Daten (z.B. Texten) strukturierte Daten (z.B. Tabellen in einer Datenbank) ableiten. Ein Anwendungsfall für IE-Verfahren ist die sogenannte Sentiment Analysis (zu deutsch etwa “Stimmungserkennung”), wo Texte z.B. nach positiven und negativen Einstellungen hinsichtlich eines Untersuchungsgegenstandes (Mobiltelefon, Hotel, Fluggesellschaft oder was auch immer) klassifiziert werden. Soll eine solche Klassifikation automatisch erfolgen, so benötigt man einerseits annotierte Texte, um Wörter und Wortgruppen ausfindig zu machen, von denen die Wertung des Textes abhängt, so wie spezielle Adjektive, Gradpartikel, Negationen etc. Man spricht davon, dass bestimmte Merkmale in Texten ausfindig gemacht werden. Mit diesen Merkmalen wird dann ein Klassifikationsmechanismus gefüttert, welcher auf dieser Basis die Texte in Klassen einteilt (also z.B. in gute und schlechte Bewertungen). Die beschriebene Sentiment-Analyse ist nur ein mögliches Verfahren, das in Tesla realisiert werden kann. Inzwischen haben wir eine ganze Bandbreite verschiedener Verfahren in Tesla realisiert, ich etwa habe das Voynich Manuskript damit analysiert, meine Kollegen arbeiten zu den Themen Extraktion syntaktischer Strukturen und Bedeutungskonstitution in natürlichsprachlichen Daten. Innerhalb eines Projekts wurden außerdem Vorarbeiten zur beschriebenen Sentiment-Analyse und der Extraktion temporaler Ausdrücke sowie von Gen-Bezeichnungen durchgeführt.
(4) Tesla ist ein Framework, in dem Werkzeuge zur Annotation und Analyse von Texten sowohl programmiert wie auch genutzt werden können. Was genau zu einem bestimmten Zeitpunkt in Tesla umgesetzt werden kann, hängt von der Ausstattung des Systems zu diesem Zeitpunkt ab. Zur Zeit umfasst das Inventar etwas mehr als 60 verschiedene Komponenten, manche Funktionalität ist gleich durch mehrere Werkzeuge abgedeckt (so gibt es z.B. zwei Tokenizer – einen, der sehr einfach zu bedienen ist, einer der sehr umfassend konfiguriert werden kann). Eine Übersicht zu den vorhandenen Komponenten findet sich auf der Tesla-Entwicklerseite. Prinzipiell (also eigentlich) kann man mit Tesla also alles machen, was in den Bereich der automatischen Prozessierung von Texten fällt. De facto beschränkt aber die aktuelle Ausstattung die momentan mögliche Anwendung – wobei man jederzeit die fehlende Funktionalität selbst implementieren kann.
(5) Man kann in Tesla nicht alles mit Texten machen, man kann nur alles machen, was sich automatisieren lässt. Alles, was mit manueller Auszeichnung zu tun hat, muss damit außerhalb von Tesla erfolgen – das bedeutet z.B., dass man nicht einfach in einem Editor die automatisch erzeugten Ergebnisse korrigieren kann. Hinter dieser Einschränkung steht die Überlegung, dass wir ein System haben wollten, in dem Analysen durchgeführt werden können, die absolut nachvollziehbar sind. Solange man lediglich Software-Algorithmen (die deterministisch sind, also keinen nicht reproduzierbaren Zufalls-Effekt enthalten) arbeiten lässt, hat man die Möglichkeit – so denn die geeigneten Vorkehrungen getroffen wurden – die Analysen jederzeit zu wiederholen und weiterzugeben, auf dass sie woanders reproduziert werden können. Ließe man manuelle Eingriffe in diesem Prozess zu, verlöre man diese Möglichkeit. Ich habe schon mehrere Posts zu diesem Thema geschrieben, etwa diese Parabel, so dass ich es jetzt hier mal dabei belasse. Nebenbei – Tesla ist kein absolut fertiges System (wir haben es mehr oder weniger zu zweit gebaut), so ist etwa die Umsetzung von Maschinellen Lernverfahren, für die Trainingsphasen durchgeführt werden müssen, noch verbesserungsfähig.
(6) Ja, es gibt eine Reihe von Systemen, die ähnlich wie Tesla angelegt sind und auf manchen Gebieten tatsächlich mit unserem System konkurrieren. Dazu zählen Gate, Apache UIMA und TextGrid. Zu den Unterschieden komm ich aber mal ein andermal. Ungeduldigen sei diese Monographie empfohlen.
Ich hoffe, dass ich mit diesem Post ein wenig aufklären konnte, was Tesla tatsächlich ist. Was man damit so alles machen kann, konnte nur bruchstückhaft dargestellt werden (auf Visualisierungen, wie z.B. das Titelbild oben, bin ich noch gar nicht eingegangen). Dafür brauche ich wohl ein paar mehr Posts. Damit man sich aber schonmal ein Bild machen kann, wie Tesla aussieht, habe ich unten noch einmal einen Screenshot der Tesla-Benutzeroberfläche angehangen.
Ansicht der Benutzeroberfläche von Tesla für Anwender. Groß im Bild der graphische Editor, in dem man seine Analysen zusammenstellt.
In meiner Arbeit habe ich unser System Tesla ja eher aus der Anwenderperspektive beschrieben und bin vor allem auf die Motivation eingegangen, die uns dazu bewegt hat, ein eigenes Komponentensystem zur Prozessierung von Texten zu entwickeln. Jetzt ist (endlich) auch Stephans Arbeit online, die mehr auf die technischen Grundlagen von Tesla eingeht (v.a. im Kapitel 4). Dabei setzt Stephan sich auch mit verwandten Systemen (vor allem GATE, UIMA und TextGrid) auseinander und zeigt auf, weshalb die Entwicklung eines Systems wie Tesla trotz dieser (von sehr viel größeren Einrichtungen getragenen) Konkurrenz unbedingt notwendig war.
Das Anwendungsgebiet, das Stephan beackert hat – kontrastive Evaluierung unterschiedlicher Verfahren zur automatischen Extraktion syntaktischer Strukturen – liest sich auf den ersten Blick etwas dröger als meine Analysen zum inhärent spektakulären Voynich-Manuskript. Es bietet aber die Möglichkeit aufzuzeigen, welch immens komplexe Versuchsaufbauten in Tesla möglich sind. Diese sind notwendig, da verschiedene Verfahren gegeneinander evaluiert werden. Die Ergebnisse der einzelnen Verfahren und ihrer Evaluierung sind dabei – durch die Arbeit mit Tesla garantiert – direkt reproduzierbar. Und alles natürlich – wie man es von uns gewohnt ist – Open Access. Also dann: Viel Spaß beim Lesen und der Reproduktion der Experimente!
