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:
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:
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).
