Schlagwort-Archive: Reproduzierbarkeit

Die unbekannte Heldensage (Podcast-Version) #dehypo5

“Zwischen der Wissenschaft, wie sie die Öffenlichkeit erträumt oder die Medien feiern, und der Wissenschaft, wie sie die Forscher täglich praktizieren, besteht dieselbe Diskrepanz wie zwischen Heldensage und Reisetagebuch“ schreiben Sven Ortoli und Nicolas Witkowski in ihrer Sammlung wissenschaftlicher Legenden mit dem Titel “Die Badewanne des Archimedes”. Tatsächlich sind Durchbrüche in einer langen, entbehrungsreichen Wissenschaftskarriere doch eher spärlich gesät – und sollten sie doch eintreten, geht es meist um sehr spezifische Forschungsbereiche, die jenseits des einschlägigen Fachpublikums eher keine Begeisterungsstürme hervorzurufen vermögen. 

Berühmt geworden sind vor allem so illustre Legenden wie die Bestimmung der Dichte durch den badenden Archimedes oder Newtons Ableitung der Gravitation, induziert durch ein Nickerchen unterm Apfelbaum. Andere wissenschaftliche Erfolge sind der Öffentlichkeit weitgehend unbekannt geblieben, obwohl auch sie ohne Zweifel großartige Leistungen bedeuteten. Bei manchen mag es daran gelegen haben, dass sie Laien einfach nicht gut vermittelbar waren. Andere sind vielleicht einfach in Vergessenheit geraten, weil man sie zu gut versteckte oder sie wieder von der Bildfläche verschwanden, ehe jemand von ihnen Notiz nahm. Die unbekannte Heldensage (Podcast-Version) #dehypo5 weiterlesen

Experimente im Textlabor #dhiha6

Dieser Blogpost entstand in Vorbereitung auf den Studientag „dhiha6 – Experimente in den Digital Humanities“ und es dürfte nicht viele Mottos für Studientage geben, die besser zum Untertitel meines Blogs und dem von mir mit verantworteten System Tesla (Text Engineering Software Laboratory) passen – ist es doch konzipiert als virtuelles Labor, um Experimente auf Texten durchzuführen. Texte sind darüber hinaus u.a. Studienobjekte der Digital Humanties (manche würden wohl gar behaupten, Texte wären die Untersuchungsobjekte der DH schlechthin). Tatsächlich wurde Tesla als eines von vier virtuellen Laboren ausgewählt, die auf dem Studientag am 12.06.2015 in Paris vorgestellt werden dürfen.

Da ganze 90 Minuten für eine Präsentation und das Experimentieren und im Anschluss daran noch einmal die gleiche Zeit für die Klärung von Fragen zur Verfügung stehen, muss ich mir einiges an Programm einfallen lassen, was ich dort alles vorführen kann. Das hieß erst einmal Gedanken sortieren und eine Mindmap anlegen (was mir schon des Öfteren geholfen hat, Dinge zu planen). Experimente im Textlabor #dhiha6 weiterlesen

Reproduzierbar Wissen schaffen

Aktuell findet auf den Scilogs ein Bloggewitter statt, welches exakt das Thema aufgreift, das mich damals veranlasste, mit dem Bloggen anzufangen – die Frage nach der Bedeutung von Reproduzierbarkeit in der Wissenschaft. Ausgelöst wurde dieses Bloggewitter vom britischen Wissenschaftsautor Ed Yong, der in der aktuellen Ausgabe der Zeitschrift Spektrum der Wissenschaft in einem sehr lesenswerten Artikeldarlegt, dass eine der zentralen Forderungen der Wissenschaft – eben die Reproduzierbarkeit wissenschaftlicher Ergebnisse – zumindest für das von ihm betrachtete Gebiet der Psychologie eher die Ausnahme denn die Regel darstellt. Das führte zu einer ganzen Reihe von Reaktionen, die verschiedene Sichtweisen aus sehr unterschiedlichen – bisher zumeist naturwissenschaftlichen Bereichen – darlegen. Reproduzierbar Wissen schaffen weiterlesen

Ästhetik auf dem Weg oder lieber im Ziel?

Die letzte Woche habe ich fast ausschließlich damit zugebracht, ein Titelblatt für die Veröffentlichung meiner Dissertation zu entwerfen. Seit gestern bin ich einigermaßen zufrieden mit dem Ergebnis, eigentlich ging es die ganze Zeit nur darum, folgendes Bild zu erzeugen:

Cloud_120209
Es handelt sich um eine sogenannte WordCloud, welche die Häufigkeiten der Wörter eines Eingabetextes (in diesem Fall der Text meiner Dissertation selbst) in Relation zueinander abbildet. D.h. Je häufiger ein Wort im Text vorkommt, desto größer wird es dargestellt. Wer sich schon einmal mit Sprachstatistik beschäftigt hat, weiß natürlich, dass im Deutschen die Konjunktion „und“ sowie der bestimmte Artikel in seinen unterschiedlichen Formen (die, der, das) am häufigsten auftreten und sich dabei leidlich an die vom Zipfschen Gesetz vorgegebenen Verhältnisse halten.

Es erschien mir relativ witzlos, mein Titelblatt mit einer WordCloud zu verzieren, die auf den ersten Blick den Eindruck macht, sie wäre aus einem beliebigen deutschen Text erzeugt worden. Vielmehr sollte schon durch die Wolke der Leserin bzw. dem Leser ein Eindruck gegeben werden, was sie bzw. ihn im Text selbst erwartet. Dazu musste ich die WordCloud irgendwie dazu bringen, die Wörter, die häufig vorkommen, aber uninteressant sind, zu ignorieren und dafür die weniger häufig vorkommenden, aber immer noch frequenten Wörter meiner Dissertation darzustellen.

Einen solchen Filterprozess kann man durch unterschiedliche Verfahren realisieren. Wenn man ein ganzes Textkorpus hat, so ist die sauberste Methode das TF-IDF-Verfahren. Bei diesem wird die Auftrittshäufigkeit eines Wortes innerhalb eines Dokuments (Term Frequency, TF) in Relation gesetzt zur Vorkommenshäufigkeit des Wortes in allen Dokumenten des Korpus (Document Frequency, DF, für die Berechnung muss diese invertiert werden, deswegen IDF). Diese Methode funktioniert sehr gut und wird im Information Retrieval (vereinfacht Suchmaschinentechnologie) mit großem Erfolg angewendet.

Hat man kein Vergleichskorpus zur Hand, so muss man sich irgendwie anders behelfen. Ich habe z.B. festgestellt, dass eigentlich die Nomen in meinem Text die klarste Aussage darüber treffen, was darin behandelt wird. Nur wie kommt man an die Nomen? Dazu gibt es natürlich Tagger und schon sind wir bei einer Aufgabe, die man doch eigentlich auch mit Tesla erledigen kann, denn die Stuttgarter Computerlinguisten waren so nett, uns zu erlauben, Ihren TreeTagger in Tesla zu nutzen. Dazu habe ich dann noch eine Stoppwortliste geschaltet und zwei Filter, von denen einer die Nomen des Taggers und der andere die Nicht-Stoppwörter des Gazetteers durchlässt sowie einen Rewriter, der die beiden gefilterten Ströme kombiniert und voila – fertig ist das Tesla-Experiment:

cloud_experiment_120209

Leider war ich mit dem Ergebnis nicht vollständig zufrieden – offenbar werden mehr Wörter als Nomen ausgezeichnet, als ich das will (z.B. „kurz“, „führt“), außerdem gibt es im Text noch ein paar Latex-Überbleibsel, die mein Reader noch nicht richtig verarbeiten kann und die deswegen im Resultat landen (z.B. „hbt“, „L3cm“). Außerdem habe ich einen Stemmer vergessen, deswegen taucht z.B. „Komponente“ auch im Plural auf:

[Das Ergebnis kann man im Header dieses Blogs hier bestaunen]

Jetzt wäre es möglich, diese Dinge tatsächlich innerhalb von Tesla zu lösen – einen Stemmer haben wir da auch (den Snowball Stemmer), den ich allerdings noch konfigurieren müsste, da er auch Derivative auf ihre Grundform zurückführen will. In den LatexReader hab ich zwar schon viel Hirnrindenenergie investiert, verbesserbar ist der aber natürlich immer. Das mit den falsch positiven Nomen könnte ich unter Kontrolle bekommen, wenn ich noch eine Komponente erzeugen würde, die mir Kleingeschriebenes aussortiert (ein hoch auf die deutsche Großschreibung), usw. usf.

Ich habe mich letztlich entschieden, eine quick-and-dirty-Pipeline zu bauen, die zwar Tesla-Komponenten nutzt, aber nicht im Workflow-Editor zusammengebaut und auf dem Tesla-Server ausgeführt wird. Ja, werden jetzt vielleicht einige von euch sagen – da bauen die eine Riesensoftware und dann nutzen sie sie selbst nicht mal. Richtig, kann ich da nur sagen – Tesla kann zwar so gut wie alles (sogar selbst eine Cloud visualisieren), manche Anwendungen verlangen aber weniger eine exakte Reproduzierbarkeit als vielmehr möglichst flexible Eingriffe in den Prozess, der zum Endergebnis führt. Ich habe mich im oben beschriebenen Fall dazu entschieden, eine schnelle Lösung zu verfolgen, um die Ästhetik des Resultats zu optimieren. Hätte ich mein Titelblatt mit Tesla erzeugt, so hätte ich jetzt ein für die ganze Welt reproduzierbares Experiment, das mein Titelbild erzeugt. Ich denke, da gibt es wichtigere Experimente, die auf diese Weise durchgeführt werden sollten.

Mein Post ist schon wieder zu lang geworden, eigentlich wollte ich noch etwas über die Cloud-Software Cloudio meines Kollegen Stephan Schwiebert schreiben, die sowohl Teil von Tesla ist, aber auch standalone genutzt werden kann. Mit ihr wurden die beiden Clouds oben erzeugt – versucht sowas mal mit Wordle. Ich lass mich demnächst mal drüber aus (oder Stephan nen Gastbeitrag).

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?