Mathias Bank

Arbeite gerade an einem Paper, in dem ich eine Übersicht über aktuell vorhandene OpenSource-Architekturen zur Behandlung von unstrukturierten Daten geben will. Folgende fallen mir da ein:

• UIMA: der einzige OASIS Standard
• Heart of Gold: für mich bisher interessant aus wissenschaftlicher Sicht, aber aus Anwendungssicht mach ich mir durch den exzessiven XML / XSLT-Gebrauch große Performanz-Sorgen. Für den Alltag halte ich das weniger für interessant. Vorteil ist, dass bereits eine recht große Anzahl an vorhandenen NLP-Tools integriert wurde.
• Weka: an sich eine nette DataMining-Architektur, bei größeren Datenmengen aber in meinen Tests nicht zu gebrauchen. Das System frisst einfach viel zu viel Speicher. Außerdem sind im Gegensatz zu den vorgenannten Systemen die Schnittstellen zwischen den Modulen nicht definiert, was eben auch eine wesentliche Aufgabe von UI Architekturen ist.
• GATE: Sicherlich eines der “Hauptkonkurrenten” zu UIMA mit einer sehr großen Funktionsvielfalt.

Jetzt gibt es natürlich noch andere Frameworks wie die AITools der Uni Weimar oder die Toolbox der Uni Leipzig, aber die sind eben nicht öffentlich verfügbar und werden zumindest derzeit auch nicht als OpenSource angeboten. Kommerzielle Systeme gibt es natürlich auch noch einige, aber die sind recht schwer zu evaluieren, weil man ja keinen direkten Zugriff darauf bekommt. Auch einfache Bibliotheken wie die openNLP Sammlung oder NLTK sind in dieser Liste nicht enthalten, weil es an sich keine Frameworks sind sondern eben Sammlungen von Bibliotheken.

Zu einem Framework gehört eben, dass sie eine Interaktionsschnittstelle zwischen unterschiedlichen Bibliotheken und Analyse-Methoden bilden und die Austauschbarkeit eben auch durch Standardisierung garantiert.

Hab ich welche vergessen? Her damit!

Ich spiele in den letzten Wochen immer wieder den Gedanken durch, ob ich nach dem sehr erfolgreichen Einsatz von UIMA mal ausprobieren sollte, ob man das ganze noch mit Hadoop kombinieren sollte. Ich verspreche mir dadurch die Möglichkeit, Performanz-Engpässe relativ einfach durch Hardware-Skalierung lösen zu können (à la Google). In den Mailinglisten hab ich jetzt eher viele Fragen als Antworten dazu gefunden. Hat jemand da schon Erfahrung?

Die letzten Wochen hatte ich zwar Urlaub, aber trotzdem die ganze Zeit geackert Hab ein Paper für ein Management-Journal geschrieben. Tja und wie das mal so ist, war das Format beliebig. Also Latex mit “article” Klasse rangezogen.

Jetzt hat mich an der Klasse aber extrem der Abstand von Bild und Caption gestört. Das gleiche gilt aber auch für Tabellen. Glücklicherweise kann man den Abstand aber sehr einfach korrigieren. Es gibt ein passendes Packet dafür:


\usepackage[justification=justified,singlelinecheck=false,labe lfont={bf,small,sf},font={small,sf},
aboveskip=0em,belowskip=0em]{caption}


Es ist halt so schön mit Latex: es gibt für alles eine App ein Packet.

Nachdem nun ein paar Blogger bereits auf das deutsche Blogcorpus verwiesen haben, möchte ich hier mal den aktuellen Zwischenstand veröffentlichen.

Aktuell haben sich 64 Blogs bereits beteiligt. Der älteste Blogger ist dabei 65, der jüngste 17. Die Altersverteilung sieht wie folgt aus:

Wie man schön erkennen kann, haben wir für die Jahrgänge 1970 - 1985 schon eine anschauliche Zahl an Blogs. Ich denke, dass man mit denen durchaus schon was anfangen könnte. Für die Jahrgänge davor und insbesondere danach sieht es aber deutlich schlechter aus. Da ist es bisher unmöglich, die Verfahren zu testen.

Ähnlich sieht es bei der Geschlechtsverteilung aus:

Wie man leider sehen kann, sind Bloggerinnen deutlich unter repräsentiert.

Also liebe Bloggerinnen und Blogger - tragt das Projekt bitte weiter. Schreibt darüber in euren Blogs und in Twitter, damit noch mehr Blogger sich im Corpus registrieren. Gerne auch kritisch. So kann ich auch evtl. darauf reagieren.

Im Rahmen meiner Doktorarbeit habe ich mir inzwischen eine Reihe unterschiedlichster Systeme zur Verarbeitung von Texten (NLP Tools) angeschaut. Hier gibt es inzwischen auch eine ganze Reihe freier Implementierungen, am bekanntesten sind sicherlich folgende:

• Natural Language Toolkit: eine Sammlung von python-Modulen
• Weka: An sich eher ein Data-Mining-System, das aber auch “einfache” Module für Text-Verarbeitung anbietet. Scheitert aber sehr schnell an der Datenmenge (wir haben allein im Vektorraum-Model schnell Dimensionen > 70.000)
• Open NLP: eine recht interessante Sammlung an NLP Bibliotheken

Sicher gibt es noch eine große Anzahl anderer “Insellösungen”. Das Problem ist nur, dass sie in der Praxis kaum zu verwenden sind. Hauptsächlich liegt es daran, dass den Systemen eine saubere Basisarchitektur für sehr große Datenmengen fehlt. Und hier kommt UIMA ins Spiel.

UIMA steht für “Unstructured Information Management Architecture” und wurde ursprünglich von IBM entwickelt. Wie der Name schon sagt ist es eigentlich kein System zur Text-Verarbeitung, sondern eine Architektur, mit der sich beliebige unstrukturierte Daten - also auch Bilder und Sound - verarbeiten lassen.

UIMA stellt dem Entwickler eine sehr einfaches System zur Verfügung, mit dem in einem linearen Prozess Daten aus einer beliebigen Datenquelle eingelesen, verarbeitet und wieder gespeichert werden können. Somit besteht eine UIMA-Architektur immer aus drei Hauptkomponenten:

• Reader: liest die Daten ein.
• Processor: verarbeitet die Daten. In der Regel werden mehrere Prozessoren - im UIMA-Jargon Annotatoren genannt - hintereinander geschaltet.
• Consumer: schreibt die Daten wieder raus.

Die Aufgabe des Programmierers ist nun, diese drei Komponenten mit Leben zu füllen. Dazu bietet UIMA schon sehr nützliche Basisklassen an, die einfach erweitert werden können. Der Gedanke dahinter ist: jede Klasse erfüllt genau eine Aufgabe. Sie muss nichts anderes als den Text, den es verarbeiten soll, wissen. Wir haben also praktisch ein Multiagentensystem vorliegen, das man am besten mit Fließbandarbeitern vergleichen kann. Eine Beispielanwendung könnte z.B. zur Füllung eines Lucene-Datenindexes so aussehen:

• CSV-Reader (Reader)
• Tokenizer (Annotator)
• Spelling-Correction (Annotator - benötigt die Informationen vom Tokenizer-Annotator)
• Lucene-Consumer

Natürlich ist man in der Lage, für die einzelnen Agenten wieder öffentliche Bibliotheken zu verwenden, man nutzt aber dabei bereits die - meiner Meinung nach - sehr ausgereifte und flexible Basisarchitektur. Die einzelnen Agenten können dabei sehr flexibel über eine XML-Datei konfiguriert und im Ablauf auch verändert werden. Damit sind die Methoden sehr gut wiederverwendbar. Gerade im Rahmen von Forschungsarbeiten sehr nützlich!

Wer also unstrukturierte Daten irgendwie verarbeiten will, sollte sich dieses Framework auf jeden Fall mal ansehen. Für mich war die Umstellung einer selbst entwickelten Architektur auf dieses System sehr lohnenswert.