Berliner Gespräche zur Digitalen Kunstgeschichte

Am 30. November 2012 finden die ersten Berliner Gespräche zur Digitalen Kunstgeschichte am Institut für Kunst- und Bildgeschichte (IKB) der Humboldt-Universität zu Berlin statt.

Thema wird Bildannotation sein, es werden diverse bekannte und unbekanntere Tools vorgestellt werden.

Da nur noch wenige Plätze frei sind, wird um eine kurze Anmeldung bei Georg Schelbert gebeten.

Termin: 30.11.2012, 10:00-16:30 Uhr
Ort: Institut für Kunst- und Bildgeschichte (IKB) der Humboldt-Universität zu Berlin
Raum 0.12
Georgenstraße 47
D-10117 Berlin

Quelle: http://dhd-blog.org/?p=1096

Weiterlesen

“Und was kann man jetzt mit Tesla machen?”

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:

  1. Was fällt denn alles unter den Begriff Texte?
  2. Was kann man sich konkret unter maschinellen Annotationen vorstellen?
  3. Und was unter automatischen Analysen?
  4. Was bedeutet man kann eigentlich alles machen?
  5. Gibt es denn Dinge, für die sich Tesla nicht eignet?
  6. 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

Weiterlesen

Bericht vom Interedition Symposium März 2012, oder: was Aquarien, Ozeane, Archäologen und Taucher mit digitalen Editionen zu tun haben

Vom 19.-20. März 2012 fand in Den Haag das Abschluss-Symposium von Interedition zum Thema “Scholarly Digital Editions, Tools and Infrastructure” statt. In dem vielfältigen Programm des Symposiums wurden aktuelle und teils brandneue Entwicklungen im Bereich der Technologien rund um digitale Edition vorgestellt: von hoch flexibel interagierenden microservices über wohldefinierte Tools bis hin zu Infrastrukturprojekten mit Bezug zur digitalen Edition und zur Aufbereitung und Analyse konkreter Textsammlungen.

Im Bereich der microservices wurden beispielsweise mehrere Ergebnisse der Interedition Bootcamps vorgestellt: so unter anderem im Bereich der Kollationierung der flexible Verbund von CollateX mit einem Variant Graph Modul und einem Regularisierungsinterface (Tara Andrews, Troy Griffit, Joris van Zundert); mehrere micoservices im Bereich von Open Annotation und Linked Data (Grant Dickie, Moritz Wissenbach, Marco Petris); ergänzt wurden diese Beiträge durch Reflexionen darüber, wie Kollationierungstools wie Juxta oder CollateX mit oft sehr unterschiedlich kodierten TEI-Texten zurechtkommen können (Gregor Middell).

Im Bereich der eigenständigen Tools standen etablierte Projekte im Vordergrund: beispielsweise die Versioning Machine, die seit 1993 stetig weiterentwickelt wird und deren Bedeutung nicht zuletzt darin liegt, dass sie DH-Neulingen eindrücklich veranschaulicht, welche Möglichkeiten das digitale Medium mit sich bringt (Susan Schreibman); oder das Kollationierungstool Juxta, das mit einer schicken Desktop-Version, zahlreichen Funktionen und (ganz aktuell) mit der verstärkten Expansion in Richtung Webservice und API beeindruckte (Nick Laiacona).

Im Bereich der Infrastrukturen war einerseits Textgrid als Virtuelle Forschungsumgebung vertreten, wobei der Vortrag deutlich machte, wie die Weiterentwicklung dieser Umgebung stetig voranschreitet, unter anderem durch die Integration weiterer Tools, wie bspw. MEISE, der Editor für MEI-Dateien (Celia Krause, Philip Vanscheidt). Und auch DARIAH wurde vorgestellt, wobei der Fokus auf den konkreten DARIAH-Services lag, die DARIAH Entwicklern und Herausgebern von digitalen Editionen anbieten kann, vom Developer Portal über die Bit Preservation bis zu Referenzdaten-Services (Christiane Fritze, Christof Schöch).

Ebenfalls zum Thema Infrastrukturen, aber aus einer etwas anderen Perspektive, gab es zwei weitere Beiträge: ein knackiges Plädoyer dafür, dass doch lieber alle dazu beitragen sollten, einen gemeinsamen Daten- und Tool-Ozean zu managen, anstatt dass jeder ein kleines, privates Aquarium baut (Martin Wynne); und einen Beitrag mit dem schönen Titel “Smaller is Smarter”, der dazu provozierte, die positiven Erfahrungen mit “agile development” und “programming sprints” in den Interedition Bootcamps auch in großen Infrastrukturprojekten wie DARIAH zu nutzen (Doug Reside), wobei letztlich deutlich wurde, dass beide Ansätze sicherlich vor allem in ihrer Komplementarität am nützlichsten sein werden.

An Beiträgen, die weniger aus der Perspektive der Tools auf die Forschung, denn aus der Perspektive eines konkreten Forschungsprojektes auf die Durchführung und technische Umsetzung blickte, mangelte es aber auch nicht. Unter anderem wurde das Womens Writers in History-Projekt vorgestellt, in dem es zentral darum geht, die Rezeptionsgeschichte der Werke weiblicher Autoren in einer Datenbank zu modellieren (Suzan van Dijk, Gertjan Filarski), oder das Ancient Greek Dependency Treebank Projekt, in dem das altgriechische Korpus des Perseus Projects mit morphologischen, syntaktischen und pragmatischen Annotationen angereichtert wird (Marie-Claire Beaulieu, Mathew Harrington, Francesco Mambrini).

Den Abschluss des Symposiums bildete der Vortrag von Joris van Zundert, der Leiter von Interedition, der auf die Erfahrungen aus dem vierjährigen Projekt zurückblickte. Deutlich wurde dabei, dass eine Vision (ein lockeres Netzwerk interoperabler microservices), eine flexible und innovative Arbeitsweise (Bootcamps) und vor allem, motivierte und kompetente Menschen (Programmierer und Editionswissenschaftler) sowie genügend Reisemittel (in diesem Fall COST Action-Mittel) zusammenkommen müssen, damit all die faszinierenden und hochaktuellen Tools entstehen können, die Interedition jetzt vorweisen kann. Auch wenn die Veranstaltung eigentlich das Abschluss-Symposium war, ist kaum vorstellbar, dass es nicht irgendwie weitergeht! Und was ist mit den Archäologen und Tauchern? Zu dieser Geschichte muss jeder Joris van Zundert selbst fragen.

Quelle: http://dhd-blog.org/?p=356

Weiterlesen