Ich lass die Katze raus

Jetzt kann ich endlich all die guten Vorsätze umsetzen, die ich letztes Jahr niedergeschrieben habe. Der Support von MyExperiment war so nett, Tesla als Workflow-Tool aufzunehmen, so dass man jetzt Tesla-Experimente über MyExperiment sharen kann. Zwar werden die Metadaten von Tesla-Experimenten noch nicht automatisch ausgewertet, so dass man sie manuell eingeben muss, das wird sich aber vielleicht demnächst ändern – insofern irgendeine Förderungseinrichtung mal erkennen sollte, welches Potential unser System hat (dazu wann anders mal mehr).

Das sollte aber kein allzu großes Hindernis darstellen – der Upload-Dialog ist relativ übersichtlich und schnell erledigt. Ich habe jetzt die ersten drei thematisch zusammenhängenden Experimente meiner Diss hochgeladen und außerdem mit den benötigten Rohmaterialien – den Texten – zu einem sogenannten Pack verschnürt, dass sich jetzt einfach aus MyExperiment herunterladen lässt.

Mit der Veröffentlichung der Experimente lasse ich auch eine Katze aus dem Sack, die da nun schon relativ lange drin geschmort hat. Ich habe zwar in meiner Dissertation (Titel: „Textprozessierung – Design und Applikation“) vor allem über die Motivation für Tesla und seine grundlegende Architektur geschrieben, seine Anwendbarkeit musste ich aber natürlich auch an einem Anwendungsfall demonstrieren. Nach langer Suche nach einem geeigneten Thema bin ich dann auf das Voynich-Manuskript gestoßen, das mir direkt als das prototypische Szenario für die Prozessierung von Texten ins Herz schoss, denn es ist ein Text, der

  1. in einer kanonischen Fassung vorliegt (dem Voynich Interlinear Archive File, in dem eine ganze Reihe verschiedener Transkriptionen aligniert sind),
  2. Grund für unzählige Analysen unterschiedlicher Dokumentationsgüte war, die nie in einer nachvollziehbaren Form zusammengebracht wurden,
  3. ein Geheimnis trägt, dem trotz aller Bemühungen bisher noch niemand auf die Spur gekommen ist.

Aktueller Stand der Forschung ist der, dass kein Chiffrierverfahren bekannt ist, dessen Anwendung einen Text erzeugt, der die Eigenarten des Voynich-Manuskripts aufweist. Ohne jetzt zu sehr ins Detail zu gehen – ich habe eine Chiffre gefunden, die meiner Meinung nach genau dies leisten kann. Sie wurde vom deutschen Abt Johannes Trithemius im dritten Teil seiner Polygraphia beschrieben. Als Beleg für die Ähnlichkeit führe ich die oben referenzierten Experimente an. In den nächsten Tagen werde ich dann meine Wege zur Entschlüsselung des VM-Textes online stellen. Um es vorwegzunehmen – es braucht niemand Angst zu haben, dass ich im Besitz des Klartextes bin (sofern es überhaupt einen solchen geben sollte). Möglicherweise kann ich aber Wege zu dessen Rekonstruktion aufzeigen.

Nachvollziehbar experimentieren mit Tesla (jetzt wirklich)

Heute komme ich endlich mal dazu, den Aufbau, die Konfiguration und die Durchführung von Tesla-Experimenten zu demonstrieren. Tesla-Experimente sind immer Experimente über textuelle Daten (allerdings lässt sich alles, was als Sequenz diskreter Einheiten dargestellt werden kann, als Text auffassen). Auf diesen Daten arbeiten Komponenten, d.h. Software-Einheiten, die spezifische Ein- und Ausgabe- sowie Konfigurationsschnittstellen haben. Texte und Komponenten lassen sich in Tesla importieren und stehen dann für Experimente zur Verfügung. Die importierten Texte und Komponenten sind in eigenen Views aufgeführt (auf dem Screenshot unten die beiden Fenster auf der linken Seite) und lassen sich per Drag&Drop dem graphischen Experiment-Workflow-Editor (großes Fenster auf der rechten Seite) hinzufügen.

Tesla-Client mit graphischem Workflow-Editor
Tesla-Client mit graphischem Workflow-Editor

Der Workflow wird konstituiert, indem man die einzelnen Elemente – das Text-Element am oberen Rand, die drei ausgewählten Prozessierungs-Komponenten darunter – miteinander durch gerichtete Kanten (vom Output einer Komponente zum Input einer anderen) verbindet. Dabei können diese Anschlüsse nicht beliebig gewählt werden, vielmehr müssen die Schnittstellen, die miteinander verbunden werden, kompatibel sein.

So verlangt bspw. der Präprozessor SPre als Eingabe textuelle Daten, die durch das Text-Element (genauer: Durch den Reader, der auf dem Text-Element sitzt) zur Verfügung gestellt werden. SPre erkennt Wort- und Satzgrenzen und produziert als Ergebnis Wörter und Sätze, indem er diese Elemente im Ausgangstext verankert. Beides ist – in einer verallgemeinerten Form, nämlich als Anchored Element – Eingabe für die nächsten beiden Komponenten. Die eine der Komponenten (N-Gram Tree Generator) erzeugt aus dem Input einen generalisierten N-Gramm-Baum, in dem alle N-Gramme bis zu einer definierten Länge aufgetragen sind. Die andere Komponente (Pattern Detector) wertet den erzeugten Baum aus und sucht nach Mustern (d.h. Wortwiederholungen), die besonders häufig vorkommen oder die besonders viele Elemente umfassen, um diese am Ausgangstext zu markieren.

Das Experiment dient also der Mustersuche in Texten, konkret wurde hier der Text des Voynich-Manuskripts gewählt, dessen Analyse mich auch innerhalb meiner Dissertation beschäftigt hat (dazu vielleicht hier demnächst auch mal bahnbrechende Neuigkeiten :-). Ich will gar nicht allzu tief in die Materie einsteigen, hier geht es schließlich nur darum, wie sich ein Experiment in Tesla realisieren lässt. Bisher haben wir lediglich kompatible Komponenten miteinander verbunden und damit quasi das Rohgerüst für unser Experiment erstellt. Diese Komponenten können jetzt noch einzeln konfiguriert werden, so kann etwa das Wort- oder Satzmodell im Präprozessor SPre auf das Wort/Paragraph-Modell der verwendeten Transkription des Voynich-Manuskripts angepasst werden. Im Tree-Generator kann die maximale Tiefe der erzeugten N-Gramme angegeben werden, und im Pattern Detector kann die Mindestlänge und Mindesthäufigkeit der zu markierenen Muster festgelegt werden. Letzteres ist dargestellt im nächsten Screenshot, in dem rechts oben statt dem graphischen Editor der Abbildung oben der Konfiguriations-Editor dargestellt ist.

Tesla-Client mit Konfigurations-Editor
Tesla-Client mit Konfigurations-Editor

In diesem Editor können links oben einzelne Komponenten ausgewählt werden (in diesem Fall der Pattern Detector), deren Konfigurations-Attribute links unten aufgeführt werden. Durch Auswahl der einzelnen Attribute können diese (rechts oben) auf die gewünschten Werte gesetzt werden. Hier wurde z.B. festgelegt, dass die zu markierenden Muster mindestens fünfmal vorkommen und mindestens zwei Wörter umspannen müssen (auf Reusable Results gehe ich ein andermal ein).

Die Ausführung des Experiments ist so einfach, wie ein Musikstück auf seinem MP3-Player abzuspielen und durch das gleiche Symbol gekennzeichnet – dem kleinen Play-Button oben in der Menüleiste. Mit der Ausführung wird der gesamte Versuchsaufbau – Referenzen auf verwendete Texte und Komponenten, Verbindungen zwischen den Komponenten, Konfigurationseinstellungen – in einer XML-Datei gespeichert, die zum Server geschickt wird. Dieser führt das spezifizierte Experiment aus und stellt die Ergebnisse zur Verfügung, die wiederum im Client visualisiert werden können. Im nächsten Screenshot sieht man den Ausgangstext, in dem die spezifizierten Muster markiert wurden:

Tesla-Client mit Inline-Visualisierung
Tesla-Client mit Inline-Visualisierung

Soweit zur Beschreibung des Aufbaus, der Konfiguration und der Ausführung von Tesla-Experimenten. Ich hoffe, dass aufgefallen ist, dass das Experiment vor seiner Ausführung in ein Format gebracht wurde, das einerseits zur Ausführung an den Server geschickt wird, das sich andererseits aber auch als Weitergabeformat zum Zweck der Reproduktion von Ergebnissen anderswo eignet. Ich habe die XML-Repräsentation dieses Formats hier bewusst ausgespart, um niemanden zu verschrecken. Es ist aber auch überhaupt nicht nötig, sich mit diesem Format auseinanderzusetzen, wenn man eine eigene Instanz von Tesla hat, in die man es importieren kann. Zugegebenermaßen benötigt man zur Reproduktion der Ergebnisse also Tesla sowie die einsetzten Texte und Komponenten. Das sollte aber kein allzu großes Hindernis darstellen, oder?

 

Nachvollziehbar experimentieren mit Tesla (I)

Hier bin ich am Ende darauf gekommen, welche vier Elemente von textprozessierenden Experimenten dokumentiert werden müssen, um ihren Aufbau zu definieren. Zur Erinnerung: Es handelte sich um

  • die Rohdaten (Texte)
  • den Code der prozessierenden Software-Einheiten (Komponenten)
  • die Feinabstimmung der Komponenten (Konfiguration)
  • das Zusammenspiel von Rohdaten und Komponenten (Interaktion)

Wie so vieles in der Datenwelt ist auch ein Tesla-Experiment letztlich eine XML-Datei. XML ist zwar grundsätzlich durch Menschen interpretierbar, allzu viel Spaß hat man damit aber nicht. Deshalb besitzt Tesla auch graphische Editoren, welche die Erstellung und Wartung von Experimenten weniger fehleranfällig und einfacher nutzbar machen. Die Editoren sind zusammengefasst im Client von Tesla, der als Plugin für die Plattform eclipse realisiert wurde. Der Client bietet verschiedene Funktionalitäten, eine Übersicht bietet z.B. dieses Tutorial. Eine dieser Funktionen ist die Zusammenstellung eines Experiments, das an den Server geschickt werden kann, damit dieser es ausführt und die Ergebnisse wiederum dem Client zur Verfügung stellt. Auch diese Ergebnisse haben eine XML-Repräsentation, die von unterschiedlichen Visualisieren des Clients interpretiert werden können. Die Kommunikation kann im Groben so dargestellt werden (links der Client, rechts der Server):

Austausch zwischen Tesla-Client und Tesla-Server
Austausch zwischen Tesla-Client und Tesla-Server

Es wäre nun möglich, alle vier oben erwähnten Elemente irgendwie in die XML-Repräsentation des Experiments zu packen. Dieser Zustand ist allerdings nicht gerade wünschenswert, da hierdurch eine extreme Redundanz bei der Datenspeicherung aufträte: Eine Kopie von Texten und Komponenten würde innerhalb jedes Experiments, das sie benutzt, gespeichert. Der Code der Komponenten (inkl. aller Bibliotheken, von denen er abhängt) müsste darüber hinaus jedesmal in XML serialisiert werden (um ihn vor der Ausführung wieder zu deserialisieren). Deshalb sollte es genügen, Texte und Komponentencode einmalig vorzuhalten und aus dem Experiment heraus eindeutig zu referenzieren. Nur die veränderlichen Elemente eines Experiments müssen komplett in seine XML-Repräsentation aufgenommen werden. Darunter fallen die Konfiguration im Großen (Interaktion der Komponenten) und die Konfiguration im Kleinen (Feineinstellung der einzelnen Komponenten). Den vier Elementen werde ich wohl jeweils einen eigenen Post gönnen müssen.

Labor? Wieso Labor?

In diesem Post ist es wohl einmal an der Zeit, das Akronym Tesla aufzulösen. Tesla ist erstens ein schöner Name, weil der geniale Erfinder und Gegenspieler Edisons diesen Namen trug, zweitens ist es aber auch eine Abkürzung für Text Engineering Software Laboratory, womit dieses System auch sehr passend umschrieben ist: Tesla ist als ein Software-Framework angelegt, mit dem beliebige technische Verfahren auf beliebigen textuellen Daten angewendet werden können. Anders ausgedrückt: Tesla bietet einen Arbeitsplatz für diejenigen Anwender, die Texte auf alle erdenklichen Arten prozessieren. Naturwissenschaftler nennen den Arbeitsplatz, an dem sie ihre Experimente umsetzen, Labor. Tesla ist dementsprechend ein Labor für Textprozessierer. Wer alles zu dieser Gilde der Textprozessierer gehört, werde ich mal in einem anderen Post ausführen, dahin gehören dann auch unsere Vorstellungen, was so alles als Text aufgefasst werden kann.

Im Labor werden also Versuchsanordnungen aufgebaut und Experimente durchgeführt. In einem Chemie-Labor benötigt man dafür Ausgangsstoffe (Chemikalien), Laborgeräte und Werkzeuge wie z.B. Erlenmeyerkolben, Verbindungsrohre, Bunsenbrenner, Messgeräte wie Thermometer, außerdem eine Infrastruktur wie  Wasser- und Gasanschlüsse, idealerweise einen Abfluss oder Auffangbehälter usw. Die durchgeführten Experimente müssen penibel in einem Laborbuch/-heft dokumentiert werden, wo für jeden durchgeführten Versuch Ausgangsmaterialien, Versuchsaufbau und Ergebnisse festgehalten werden (was doch alles aus einem abgebrochenen Chemiestudium hängenbleiben kann…).

In einem Software-Labor für die Textprozessierung benötigt man fast das gleiche – Ausgangsstoffe (Texte, die prozessiert werden sollen), Werkzeuge (Software, die prozessiert), Messgeräte (Software, die prozessierte Daten auswertet) und ein Laborbuch (Dokumentation der Prozessierungsabläufe). Was genau das Laborbuch aufzeichnen soll, entspricht genau den vier Punkten, die ich am Ende des letzten Posts aufgeführt habe. Im nächsten werde ich zeigen, wie diese Aufzeichnung in Tesla umgesetzt wird.

 

 

Empirismus, Vertrauen und Management

Sicherlich ist Tesla nicht das einzige Softwaretool, das es ermöglicht, komplexe Experimente zusammenzustellen, zu konfigurieren, auszuführen und am Ende weiterzugeben, auf dass sie auf identische oder evtl. sogar modifizierte Weise ausgeführt werden können. Vielmehr sind vor allem in jüngerer Zeit eine Reihe von Tools entworfen worden, die genau dies ermöglichen sollen. Im Rahmen der britischen MyGrid-Initiative ist sogar eine Social-Network-Plattform entstanden (myExperiment), auf deren Basis Experimente, die innerhalb verschiedener Arbeitsumgebungen entworfen wurden, auf einfache Weise veröffentlicht und weitergegeben werden können. Für die nahe Zukunft streben wir auch an, dass Tesla als eine dieser Arbeitsumgebungen aufgenommen wird.

Dass wir mit der Entwicklung von Tesla (mit dessen konkreter Implementation wir irgendwann 2006 begonnen haben) auf dem richtigen Weg sind, wurde mir aber vor allem durch einen Beitrag von Ted Pederson in der Computational Linguistics (September 2008) klar. Da die Zeitschrift dankenswerterweise inzwischen den Open-Access-Pfad eingeschlagen hat, kann man den Artikel hier legal einsehen. Der Artikel ist betitelt mit „Empiricism Is Not a Matter of Faith“ und führt auf sehr unterhaltsame Weise – durch die Parabel vom Zigglebottom-Tagger, einem Software-Werkzeug, das in einem Journalartikel gepriesen wird, in der Wirklichkeit aber nicht auf die angegebene Weise funktioniert – vor, dass Vertrauen in veröffentlichte Forschungsergebnisse zwar gut ist, Kontrolle aber besser wäre. Kontrolle von Software ist schlecht möglich, wenn man als Basis lediglich einen Journalartikel in Prosaform vorliegen hat. Notwendig ist vielmehr, dass die Software, über die geschrieben wurde, selbst in einer Form veröffentlicht wird, die ihre Benutzung durch die wissenschaftliche Community ermöglicht. Diese Form muss gewissen Ansprüchen genügen, so sollte die Funktionsweise und die Handhabung in einer Weise dokumentiert sein, mit der Außenstehende (also nicht-Mitentwickler) in die Lage versetzt werden, die Software zu überprüfen. Soweit Pedersen.

Soll nicht nur die Software, sondern auch die durch sie erlangten Ergebnisse kontrolliert werden, so ist außerdem eine Weitergabe der durch die Software prozessierten Ausgangsdaten notwendig. Besteht die Software nicht aus einem monolithischen Block, sondern aus mehreren, miteinander interagierenden autonomen Einheiten, dann müssen selbstverständlich alle Einheiten, als auch die Spezifikation ihrer Interaktion weitergegeben werden. Das führt uns wieder an den Schlussabsatz des letzten Posts, in dem von einer Verpackung für Experimente die Rede war. Eine solche Verpackung ist eigentlich nichts anderes, als eine eingefrorene Version des experimentellen Aufbaus, bestehend aus

  • den Rohdaten
  • dem Code der prozessierenden Software-Einheiten
  • der Konfiguration der Software-Einheiten
  • der Konfiguration ihrer Interaktion

Der Aufbau selbst wird auch als Workflow bezeichnet, insofern bedarf es einem Workflow-Management-Systems (WMS) zur Erzeugung und Verwaltung und Ausführung solcher Einheiten. Und – ihr werdet es erraten haben – Tesla enthält ein solches WMS, mit dem Experimente über textprozessierende Daten verwaltet werden können. Mehr dazu in Kürze.