tesla – Planet Clio

Actualités / News, Artikel, dhiha6, komponentensystem, Programmierung, Reproduzierbarkeit, tesla

Experimente im Textlabor #dhiha6

3. Mai 2015 Keine Kommentare

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 dürften, 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 also 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). (...)

Quelle: http://texperimentales.hypotheses.org/1344

Artikel, Empirie, Experiment, tesla, validität, Wissenschaftstheorie

Scheitern als Chance – Testen durch Fehler

30. November 2012 Keine Kommentare

Momentan experimentiere ich mit Marcos Zampieri zu Eigenschaften von brasilianisch-portugiesischen Internettexten. Dabei geht es unter anderem darum, spezifisches Vokabular aus diesen zu extrahieren und anhand dieses Vokabulars die Texte wiederum nach ihrer Internetness zu klassifizieren. Die Studie erscheint demnächst als Paper, hier will ich deswegen nicht über die Ergebnisse schreiben, sondern nur eine (zumindest für uns) lehrreiche Begebenheit aus der Entwicklungsphase schildern.

Aus wissenschaftlichen Veröffentlichungen lässt sich nur in den seltensten Fällen herauslesen, welche Fehlschläge auf dem Weg zu den letztlich öffentlich gemachten Versuchsaufbauten und Ergebnissen die Autoren hinnehmen mussten. Um zu zeigen, dass solche Fehlschläge durchaus fruchtbar sein können, muss ich zunächst etwas weiter ausholen und bei den drei Gütekriterien empirischer Studien beginnen, die ja, wie allgemein bekannt, die folgenden sind:

Validität – Misst das gewählte Verfahren tatsächlich das, was es messen soll?
Reliabilität – Funktioniert die Messung zuverlässig, sind die Ergebnisse im Wiederholungsfall stabil?
Objektivität – Wurden die Ergebnisse unabhängig vom Prüfer erzielt?

Auch wenn man – wie wir – ein Labor gebaut hat, in dem alles, was man experimentell anstellt, protokolliert wird, so dass die Ergebnisse im Normalfall (d.h., wenn man die Ausgangsdaten und die Werkzeuge in den entsprechenden Versionen nicht verlegt) jederzeit reproduziert werden können, sind diese drei Kriterien natürlich nicht automatisch erfüllt.

Wir (Computer)Linguisten wollen z.B. Aussagen über Sprache treffen und analysieren dafür Sprachdaten. Diese Aussagen sind natürlich immer abhängig von der Auswahl der Sprachdaten, die wir getroffen haben. Natürliche Sprachen sind ja leider kein abgeschlossenes System (im Gegensatz z.B. zum Text aus dem Voynich Manuskript, jedenfalls solange dessen fehlende Seiten nicht irgendwo auftauchen). Die Auswahl betrifft vor allem die beiden letzten oben genannten Gütekriterien, die Reliabilität (bleiben die Aussagen gleich, wenn ich eine andere Auswahl treffe) und Objektivität (bleiben die Aussagen gleich, auch wenn jemand anders die Auswahl trifft).

Die Validität betrifft mehr die Werkzeuge, die im Analyseprozess verwendet werden – zunächst einmal müssen sie korrekt funktionieren (wer selbst einmal Algorithmen implementiert hat, weiß wahrscheinlich sehr gut, welche Fehler dabei auftreten können). Darüber hinaus muss aber auch irgendwie festgestellt werden, ob sich die Messungen der gewählten Werkzeuge wirklich dazu eignen, darauf die zu treffenden Aussagen zu gründen.

Im kombinierten Programmier/Experimentier-Prozess, in dem man sich befindet, wenn man neue Werkzeuge erstellt, die dann auch umgehend für empirische Studien eingesetzt werden, muss man sich überlegen, wie man die Validität denn am besten testen kann. Und um jetzt endlich zum Punkt dieses Artikels zu kommen: Ich möchte hier einen solchen Test beschreiben, der in der Form gar nicht geplant war und nur durch einen Fehler zustande kam.

Um, wie wir das vorhatten, die Internetness von Texten bzw. Dokumenten zu ermitteln, kann man sie z.B. mit einem Referenzkorpus vergleichen und schauen, inwieweit sich Spezifika in Abgrenzung zu diesem ermitteln lassen. Es gibt unterschiedliche Methoden, die Keywordness von einzelnen Termen (Wörtern) zu berechnen, im Bereich des Information Retrieval (also im Umfeld von Suchmaschinen) wird häufig der Quotient aus Termfrequenz und inverser Dokumentfrequenz (TF/IDF) hinzugezogen. Für den Vergleich von Korpora eignet sich unserer Meinung nach die Berechnung der Log-Likelihood-Ratio (LLR) für einzelne Termes besser. Um es ganz simpel zu erklären: Das Vorzeichen der LLR gibt für jeden Term an, ob er stärker mit dem Untersuchungskorpus oder mit dem Referenzkorpus assoziiert ist. Noch einfacher: In welchem Korpus er häufiger vorkommt. Allerdings zählen dabei nicht die absoluten Häufigkeitsunterschiede (welche die frequentesten Wörter, also {und, der, die, das} usw. aufweisen würden), die LLR relativiert diese stattdessen (wie sie das tut, passt gerade nicht hier rein). Summiert man nun die LLR-Werte der Token jedes Korpus-Dokumentes und teilt diese Summe durch die Länge des entsprechenden Dokuments, so erhält man vergleichbare Internetness-Werte für jedes Dokument.

Ein Experiment, das den im Text beschriebenen Workflow über einzelne Komponenten realisiert. Von oben nach unten: Korpora, Tokenizer, Frequenz-Zähler, LLR-Berechner, Ranker für Dokumente (die hier in Paragraphen repräsentiert sind) nach den LLR-Werten ihres Vokabulars.

Auf den ersten Blick war fatal, dass uns der Fehler unterlief, unsere Korpora mit Texten unterschiedlicher Encodings zu bestücken. Das ist für Tesla normalerweise kein Problem, wenn nicht gerade alle zusammen in einem Archiv hochgeladen werden, was wir aber getan haben. Das Resultat war, dass alle Wörter mit Umlauten im Internet-Korpus korrekt dargestellt wurden, diese aber im Referenz-Korpus nie auftauchten, weil dessen Encoding zerschossen war. Resultat war, dass não (portugiesisch für nein, falsch encodiert nÃ£o), offenbar in unserem Korpus das frequenteste Wort mit Sonderzeichen, den höchsten LLR-Wert erhielt. Texte, die lediglich aus não bestanden, bekamen deshalb den höchsten Wert für ihre Internetness.

Das Ergebnis entsprach natürlich keinesfalls dem, das wir erhalten wollten, dennoch hatte die Tatsache, dass wir einen so blöden Fehler gemacht hatten, auch einen gewichtigen Vorteil: Dadurch, dass wir ein so falsches, aber absolut nachvollziehbares Ergebnis erhielten, konnten wir Rückschlüsse bezüglich der Validität des Verfahrens bzw. die Richtigkeit der Algorithmen-Implementationen innerhalb der Komponenten ziehen: Wir hatten genau das gemessen, was aufgrund unseres Fehlers gemessen werden musste. Den Fehler konnten wir einfach korrigieren, die Ergebnisse veränderten sich dementsprechend – auch wenn sie weiterhin bemerkenswerte, durch die Korporaauswahl bedingte, Artefakte enthalten (da muss ich allerdings auf die wissenschaftliche Veröffentlichung vertrösten). Wir waren in einem ersten Versuch gescheitert, aber gerade dieses Scheitern hatte uns einen relativ starken Hinweis auf die Validität unseres Verfahrens gegeben. Und ich finde, das ist schon einen Blogpost wert, zumal solche produktiven Fehlschläge nur sehr selten Platz in wissenschaftlichen Veröffentlichungen finden.

Quelle: http://texperimentales.hypotheses.org/620

Artikel, Kryptoanalyse, Kryptographie, Kryptologie, tesla, Textprozessierung, Trithemius, v, Voynich Manuskript

Heldensage im Reisetagebuch

28. Juni 2012 Keine Kommentare

Vor ungefähr drei Jahren war ich mit meiner Promotion an einen Punkt gelangt, an dem ich die Entscheidung treffen musste, in welche Richtung sich meine Dissertation weiterentwickeln sollte. Wir hatten unser System Tesla schon zu einem guten Teil realisiert, die Darlegung zur Motivation der Entwicklung eines eigenen Komponentensystems – die Idee wirklich reproduzierbarer Experimente auf Textdaten beliebigen Formats – lag auch bereits in einer Rohform vor. Was fehlte, war ein Anwendungsfall, an dem ich die Funktionalität des Systems bestmöglich demonstrieren konnte. Und die Suche nach einem solchen geeigneten Untersuchungsobjekts hatte mich schon eine ganze Zeit beschäftigt. Eher zufällig stöberte ich dabei nochmal in einem Buch, dessen Lektüre bei mir schon etwas weiter zurücklag: Im wirklich empfehlenswerten Lexikon des Unwissens von Kathrin Passig und Aleks Scholz.1

Dabei fiel mir auf, dass das Voynich-Mauskript (VMS), dem im Lexikon ein Eintrag gewidmet ist, ein durchaus geeignetes Thema wäre, um die Anwendbarkeit von Tesla zu demonstrieren:

Das VMS enthält einen Text. Mit unbekannten Zeichen geschrieben, unbekannten Inhalts und unbekannter Herkunft. Aber einen Text. Und wir haben Tesla entwickelt, um sämtliche Texte analysieren zu können. Auch wenn der VMS-Text auf seine Art einzigartig ist, er sollte sich mit Tesla analysieren lassen.
Die Analysen zu VMS sind genauso zahlreich wie auch widersprüchlich. So gut wie alle denkbaren Theorien zur Herkunft oder Inhalt des Textes lassen sich irgendwo finden. Die glaubhaften Analysen einmal in einem System zu bündeln, in dem sie für die ganze Welt reproduzierbar sind, sollte nicht schaden.
Das VMS reizt natürlich auch durch seine geheimnisvolle Aura. Damals schon 97 Jahre zerbarsten daran die Theorien durchaus (bisweilen überaus) intelligenter Wissenschaftler und Nicht-Wissenschaftler, ohne dass jemand tatsächlich eine allgemein anerkannte Lösung zum Problem hatte liefern können.

Der Anspruch, den Text tatsächlich entschlüsseln zu können, wäre natürlich allzu vermessen gewesen. Das war auch von Anfang an nicht der Plan. Stattdessen wollte ich die Analysen, welche zu den seltsamen Eigenschaften des Manuskripttextes, die ich hier schon einmal thematisiert habe, in einer Umgebung zusammenführen, welche eine einfache Überprüfung der Analyse-Ergebnisse ermöglicht.

Eine aufgeschlagene Seite des Voynich Manuskripts - seltsame Zeichnungen, seltsamer Text. Quelle: en.wikipedia.org

Tatsächlich bin ich aber weiter gekommen, als ich anfangs annahm und wie es dazu kam, will ich hier kurz erzählen: Beim Studium der Literatur zum VMS – die nicht in allen Fällen wissenschaftlichen Ansprüchen genügt und wo sie dies tut, meist in Veröffentlichungen zu anderen Themen versteckt wurde – nahm ich als Grundtenor wahr, dass kein Chiffrierverfahren bekannt wäre, aus dessen Anwendung ein Text resultiert, der dem VMS-Text ähnlich wäre. Ebenso deuteten bestimmte statistische Eigenschaften darauf hin, dass es sich nicht um eine Transkription einer natürlichen Sprache handeln könne. Wenn es aber weder eine Chiffre noch eine unbekannte Transkription sein kann, so liegt die Vermutung nahe, der Text bestehe einfach aus einer sinnlosen Aneinanderreihung von Phantasiewörtern. Damit korrespondiert – semiotisch ausgedrückt – mit der Ausdrucksseite seiner Zeichen keine Inhaltsseite. Und weil ein Text ohne Inhalt auf gewisse Art ein Schwindel ist, wird die Hypothese, dass es sich beim VMS-Text um einen solchen handelt, auch Hoax-Hypothese genannt.

Irgendwie ist der Gedanke, das VMS sei nur ein Schwindel und es gäbe gar nichts zu entziffern, nicht besonders befriedigend. Mehr Charme hat da die Vermutung von William Friedman (einem der größten Kryptoanalytiker des 20. Jahrhunderts), der es für wahrscheinlich hielt, dass der VMS-Text ein früher Entwurf einer synthetischen Sprache a priori sei – ihm also eine Kunstsprache zugrundliege, die sich – im Gegensatz z.B. zum Esperanto – nicht an natürlichen Sprachen orientiert. Weil solche Sprachen aber scheinbar erst in der zweiten Hälfte 17. Jahrhundert entworfen wurden, das VMS aber relativ sicher schon Ende des 16. Jahrhunderts in Prag kursierte, ist diese These problematisch.

Mehr Charme ist jetzt nicht unbedingt ein wissenschaftliches Kriterium. Ich beschloss aber dennoch, Verschlüsselungsverfahren und Ansätze zu Universalsprachen im ausgehenden Mittelalter und der frühen Neuzeit zu recherchieren. Im Zuge dieser Recherchen zu stieß ich auf die Monographie von Gerhard Strasser2 zum Thema, in der dieser die Verbindung zwischen kryptographischen Verfahren und universell gedachten Sprachentwürfen beleuchtet. Ursprünglich wollte Strasser dabei auf die Universalsprachentwürfe des 17. Jahrhunderts eingehen, allgemein als die ersten ihrer Art angesehen. Er kann aber zeigen, dass schon viel früher – durch den Abt Johannes Trithemius (den ich u.a. schon hier für eine andere seiner Arbeiten gewürdigt habe) – eine Chiffre entworfen wurde, deren Anwendung etwas ergab, das wie das Resultat einer Kunstsprache aussieht, das aber ein verschlüsselter Text ist.

Konkret bezieht sich Strasser dabei auf die Teile III und IV der trithemischen Polygraphia. Die darin beschriebenen Verfahren funktionieren prinzipiell wie die aus den ersten beiden Teilen (die ich hier auch schon vorgestellt habe): Einzelne Buchstaben werden gemäß einer Ersetzungstabelle durch ganze Wörter ersetzt. Während aber die Ersetzungschiffren in den ersten beiden Teilen lateinische Wörter sind und die resultierenden Geheimtexte wie lateinische Gebete anmuten, sind sie in den darauffolgenden Büchern von Trithemius erdachte Phantasiewörter, der resultierende Text sieht demnach aus wie eine Phantasiesprache. Der sehr regelmäßige Aufbau der Phantasiewörter – an einen Wortstamm sind unterschiedliche Endungen angehangen – gemahnt Strasser an die Universalsprachentwürfe von Wilkins und Dalgano, die erst viel später, um 1660, entworfen wurden.

Je zwei Zeilen von Ersetzungschiffren aus der Polygraphia III und IV. In der Spalte ganz links finden sich die zu ersetzenden Buchstaben.

Die Tatsache, dass nun doch um 1500 schon eine Möglichkeit beschrieben wurde, wie ein Text erzeugt werden kann, der wie das Produkt einer Kunstsprache aussieht, fesselte mich natürlich und ich beschloss, die Trithemischen Werke im Original zu konsultieren. Die Recherche führte mich in ein Mikrofichekabüffchen und den Lesesaal der historischen Sammlungen der hiesigen Universitätsbibliothek genauso wie in die Erzbischöfliche Buchsammlung zu Köln (womöglich wäre ich noch im Stadtarchiv gelandet, das aber gerade der Erdboden verschluckte) – alles spannende Orte, zu denen man als Computerlinguist unter normalen Umständen gar nicht vorstößt.

Ich werde nie vergessen, wie ich im Holzverschlag zur Mikrofichebetrachtung über das Lesegerät gebeugt stand, fieberhaft und ungelenk die kleine Folie weiterschob über die Tabellen der trithemischen Polygraphia, bis ich endlich im dritten Teil angekommen, überprüfen konnte, ob das, was ich mir auf Grundlage von Strassers Schilderung vorstellte, tatsächlich auch im historischen Werk zu finden war. Und wirklich hatte Trithemius einzelne Spalten mit Stamm-Endungs-Kombinationen versehen, die wie Flexionsparadigmen aussahen (auch die “Wörter” des VMS weisen ähnliche Eigenschaften auf). Noch phantastischer war, dass die manuelle Strichliste, die ich nebenbei über die Wortlängenverteilung der Ersetzungstabellen führte, eine Binomialverteilung ergab (ebenso wie die VMS-”Wörter”, siehe auch hier). Dank Patrick Sahle hatte ich dann bald auch die Möglichkeit, die Polygraphia an meinem Schreibtisch zu studieren, der sich als die langweiligere, aber effektivere Arbeits-Location erwies.

Dort konnte ich mich dann weiteren Überlegungen zur Operationalisierung der von mir ja erst per Augenmaß festgestellten Ähnlichkeiten zwischen den beiden Texten widmen. Dabei hatte ich stets die Warnung von Kennedy und Churchill3 vor Augen, dass das VMS ein Spiegel sei, in dem jeder nur seine eigenen Vorurteile und Hypothesen bestätigt sieht. Insbesondere musste ich erst einmal Werkzeuge entwickeln, die mir erlaubten, den VMS-Text einzulesen und Polygraphia-III-Texte zu erzeugen, diese in Analyseeinheiten zu unterteilen und schließlich statistische Eigenschaften, die ich nicht einfach per manueller Zählung ermitteln konnte, auszuwerten. Ich befand mich erst am Anfang eines langen Prozesses, an dessen Ende die Fertigstellung und Veröffentlichung meiner Dissertation und die der duchgeführten Experimente stand.

Irgendwann später las ich das Bonmot von Ortoli und Witkowski: “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.” Da dachte ich, dass - zumindest bei mir im Kopf – genau diese Diskrepanz für einen kurzen Moment aufgehoben war.

1 Katrin Passig, Aleks Scholz: “Lexikon des Unwissens. Worauf es bisher keine Antwort gibt.” Rowohlt Berlin; Auflage: 7 (2007)

2 Gehard Strasser: “Lingua Universalis: Kryptologie und Theorie der Universalsprachen im 16. und 17. Jahrhundert” (Wolfenbütteler Forschungen 38) Harrassowitz, Wiesbaden (1988)

3 Gerry Kennedy und Rob Churchill: “Der Voynich-Code: Das Buch, das niemand lesen kann” Rogner & Bernhard bei Zweitausendeins (2005)

4 Sven Ortoli und Nicolas Witkowski: “Die Badewanne des Archimedes: Berühmte Legenden aus der Wissenschaft” Piper Taschenbuch (2007)

Anm: Drei der vier aufgeführten Bücher sind das, was gemeinhin und bisweilen abschätzig als populärwissenschaftliche Veröffentlichungen bezeichnet wird. Eine ganze Reihe meiner Links führen außerdem zur Wikipedia. Ich halte den Einbezug beider Arten von Quellen für durchaus legitim in einem Blog, der versucht, die eigene wissenschaftliche Tätigkeit etwas populärer zu machen. Dass manche das anders sehen, weiß ich inzwischen auch. Da kann man aber auch gerne mit mir diskutieren. Nebenbei: Untersuchungen zum Voynich Manuskript tragen im Wissenschaftsbetrieb nicht gerade zur Kredibilität bei, was wohl auch ein Grund dafür ist, dass sich so wenige wirkliche Spezialisten mit dem Thema beschäftigen oder aber ihre Ergebnisse in Unterkapiteln anderer Veröffentlichungen (z.B. in einer Einführung in die Programmiersprache BASIC, kein Witz) verstecken. Bei mir ist das ja auch irgendwie der Fall gewesen.

Quelle: http://texperimentales.hypotheses.org/278

Artikel, tesla, Visualisierung

Visualisierung von Ergebnissen

15. Mai 2012 Keine Kommentare

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]. 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.

Quelle: http://texperimentales.hypotheses.org/229

Artikel, news, tesla

Neuigkeiten 1204

27. April 2012 Keine Kommentare

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.

Quelle: http://texperimentales.hypotheses.org/205

analyse, Annotation, Artikel, tesla, text

“Und was kann man jetzt mit Tesla machen?”

28. März 2012 Keine Kommentare

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.

Quelle: http://texperimentales.hypotheses.org/125