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
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.
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.
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.
Der Gruppe um den bekannten Elektrochemiker Zylev* ist es nach Jahren nervenaufreibender und kostenintensiver Forschung endlich gelungen, mithilfe eines Palladium-Katalysators in lauwarmer Umgebung schwere Wasserstoffisotope zu Helium-Atomen zu verschmelzen und dabei eine Menge Energie zu gewinnen. Gemäß den Konventionen wissenschaftlicher Forschung werden der Versuchsaufbau und die Ergebnisse dieser “Lauwarmen Fusion” peinlich genau dokumentiert, in Prosa gegossen und per Pressemitteilung des Instituts sowie einer Veröffentlichung in einer rennomierten Zeitschrift verbreitet. Forschungsgruppen auf der ganzen Welt unter der Leitung der nicht minder berühmten Wissenschaftler Yslan, Xennux und Wenzelheim versuchen, das Ereignis der lauwarmen Fusion in ihren eigenen Laboratorien zu reproduzieren. Sie lesen dafür den Fachzeitungsartikel und bauen den beschriebenen Versuchsaufbau penibel nach. Trotz der großen Gewissenhaftigkeit, die sie dabei an den Tag legen, verändert sich die Zusammensetzung ihrer Ausgangsstoffe nicht – es entsteht kein Helium und schon gar kein Energieüberschuss.
Der bisher – im kryptoanalytischen Bereich – eher leidlich erfolgreiche Softwarearchitekt Vercout veröffentlicht auf seinem persönlichen Blog einen Beitrag, in dem er behauptet, den Klartext des ersten Blattes der mysteriösen Beale-Chiffre (Zahlenfolge siehe Abbildung unten, Quelle: Wikipedia) entziffert zu haben. Dazu müsse lediglich ein von ihm entwickelter Vertausch-Algorithmus auf die Zahlen der Chiffre angewendet werden, im Anschluss daran sind sie Stellvertreter für die letzten Buchstaben von Wörtern aus der englischen Genesis-Übersetzung, deren Position durch den Zahlwert bestimmt wird. Mit dem veröffentlichten Vertausch-Algorithmus starten mehrere Hobbyforscher einen Versuch, den Vercout’schen Klartext zu reproduzieren. Auch wenn die Implementation des Algorithmus relativ einfach gelingt, erhalten sie bei der Anwendung auf die Genesis nur sinnlose Aneinanderreihungen von Buchstaben.
Beale-Chiffre (Quelle: wikipedia.org)
Sind die beiden Fälle vergleichbar? Nein, es besteht ein gewichtiger Unterschied – und zwar keinesfalls der, dass die Forscher und die Veröffentlichungskanäle aus den beiden Beispielen mit sehr unterschiedlichem Renommee ausgestattet sind. Vielmehr liegt die Diskrepanz im Grad der Reproduzierbarkeit – sie ist nämlich im ersten Beispiel bloß prinzipiell, im zweiten aber generell leistbar.
Obwohl ich tatsächlich mal zwei Semester Chemie studiert habe, bin ich weit davon entfernt, zu wissen, was im Experiment aus Beispiel 1 so alles schiefgehen kann. Was man aber ohne Zweifel behaupten kann, ist, dass die Umgebung einen Einfluss auf das Geschehen in der Versuchsanordnung nehmen kann. Die genauen Randbedingungen, die beim gelungenen Versuch geherrscht haben, sind wahrscheinlich nie exakt dokumentierbar, schon gar nicht in einem Paper, das ja auch gelesen werden will. Ebensowenig ist es möglich, den Versuchsaufbau einfach an andere Laboratorien zu verschicken, da die Randbedingungen schwer mitverschickt werden können. Was bleibt, ist andere Forschergruppen zum Ursprungsort der lauwarmen Fusion zu geleiten, auf dass sie dort die Ergebnisse reproduzieren können. Entscheidende Randbedingungen könnten sich dennoch inzwischen geändert haben.
Ehe ich hier noch weiter auf einem Gebiet herumeiere, von dem ich nur einen sehr blassen Schimmer habe, kümmere ich mich lieber darum, woran es gelegen haben könnte, dass die Entschlüsselung der Beale-Chiffre in Beispiel 2 gescheitert ist. Erstens könnte Vercout ein Scharlatan sein, schließlich ist er wenn überhaupt nur lose mit dem entsprechenden Wissenschaftsbetrieb vernetzt. Es ist aber nicht zwingend notwendig, dass hier bewusst getäuscht wurde: Vielleicht wurde evtl. der Algorithmus einfach nicht in einer Form niedergeschrieben, dass er eindeutig nachprogrammiert werden könnte. Möglicherweise stimmt aber einfach die Version des Textes (die englische Genesis-Übersetzung) beim ursprünglichen Versuch nicht mit der der Reproduktionsversuche überein. Oder das Wortmodell, das Vercout nutzt, ist ein anderes als das seiner Überprüfer (Zählt man etwa don’t als zwei Wörter? Wo beginnt das zweite? Wird die Versnummerierung als Wort gezählt? Wie verhält es sich mit den Zahlen im Text?). Auch in diesem Fall haben wir es mit einer Menge an Randbedingungen zu tun, die Einfluss auf das Ergebnis des Experiments nehmen.
Im Unterschied zu Beispiel 1 sind diese Randbedingungen aber selbst reproduzierbar, da der Rahmen des Experiments virtualisierbar ist. Sowohl die Ausgangsmaterialien des Versuchs (die Zahlenkolonnen der Beale-Chiffre, die englische Genesis-Übersetzung) wie auch der Versuchsaufbau (der Vertausch-Algorithmus sowie der Tokenizer für den Bibeltext) sind prinzipiell eindeutig durch Algorithmen und Datenstrukturen abbildbar. Die moderne Informations-, Kommunikations- und Softwaretechnologie ermöglicht es uns, diese Algorithmen und Datenstrukturen auf eine zugängliche Weise zu verpacken und untereinander auszutauschen. Eine solche Verpackung für Experimente über textbasierte Daten ist das von uns entwickelte Tesla. Und da es hier jetzt schon ein wenig lang wird, werde ich die Eigenschaften dieser Verpackung (deren graphische Repräsentation man im Screenshot unten sieht) in einem eigenen Post thematisieren.
Screenshot eines Tesla-Experiments
* Bevor mich hier jemand verklagt: Die Namen der Wissenschaftler und ihre Forschungsergebnisse sind frei erfunden. Ähnlichkeiten mit lebenden oder verstorbenen Personen sind rein zufällig und nicht beabsichtigt.
