Bearbeitung und Annotation historischer Texte mittels Graph-Datenbanken am Beispiel der Chronik des Matthias von Edessa

1. Effizientes Speichern und Bearbeiten von Manuskripten und Annotationen

Aufbauend auf den Erkenntnissen, die wir aus dem Stemmaweb-Projekt gewonnen haben, werden die Manuskripte in Form von Graphen gespeichert 1. Daher ist für uns der naheliegenste Schritt, die gesamte Arbeit des Benutzers im Graph zu repräsentieren. Als mögliche Darstellungsformen für den Benutzer kommen hierfür Online-Präsentationen oder ein Export, zum Beispiel nach TEI, in Betracht.

Während die Speicherung in Stemmaweb als Perl-Objekte in einer Relationalen-Datenbank (MySQL (Oracle Cooperation 2015)) erfolgt, haben wir uns für dieses Projekt dafür entschieden, Neo4J (Neo Technology Inc 2015), eine Graph-Datenbank zu verwenden. Zum einen kommt dies unserer intern verwendeten Datenstruktur entgegen, die auf einer Modellierung auf Graphen basiert. Damit verbunden hat dies auch den Vorteil, dass viele, für uns wichtige Funktionen (z. B. Depth First Search, Breadth First Search, etc.), nativ vom Datenbanksystem zur Verfügung gestellt werden und speziell benötigte Operationen, wie z. B. Plausibilitätsprüfungen, einfacher implementiert und effizienter ausgeführt werden können.

Des Weiteren migrieren wir derzeit große Teile, des aus Stemmaweb vorliegenden Quellcodes, von Perl nach Java. Gleichzeitig überarbeiten wir die API, mit dem Ziel, den Service auch über eine Web-API nutzen zu können. Die Hauptgründe hierfür sind, die bestehende Stemmaweb Backend-Engine zu modernisieren und effizienter zu gestalten. Dieser Schritt soll bis Ende 2015 abgeschlossen sein.

Parallel zu der Migration, haben wir bereits einen ersten Prototypen des Editions-Interfaces erstellt. Dieser Prototyp basiert bereits auf Neo4J und implementiert ein Textmodel das interoperabel mit Stemmaweb ist und wir zu Testzwecken bereits mit zusätzlichen Annotationen versehen haben.

In Abbildung 1 ist ein typischer Ausschnitt unserer Neo4J Datenbankstruktur zu sehen. Man erkennt, dass sich eine „TRADITION“ aus ein oder mehreren „SECTION“-Knoten zusammensetzt, die wiederum mittels gerichteter „NEXT“-Kanten miteinander verbunden sind und somit ihre Reihenfolge gewährleistet bleibt 2. Jeder „SECTION“-Knoten verweist wiederum auf eine Folge von untereinander mit „LEMMA_TEXT“ verbundenen „READING“-Knoten. Darüber hinaus existieren noch sogenannte „TRANSLATION“-Knoten, die die jeweilige Übersetzung in einer Sequenz aus READING-Knoten speichern. Hierbei bleibt es dem Bearbeiter freigestellt, die Granularität der Übersetzung festzulegen. So sind Einheiten, wie zum Beispiel Sigle-Wörter, Sätze oder ganze Paragraphen, etc. vorstellbar.

Figure 1. Abb. 1 : Beispiel für die derzeitige Datenbankstruktur in Neo4J. Gut zu Erkennen ist die Gliederung in Tradition (blau), Sections (orange), Readings (pink) und Translations (rosa).

2. Eine adäquate Wiedergabe der gespeicherten Informationen

Wie bereits erwähnt, liegt ein weiterer Schwerpunkt des Projektes auf einer angemessenen Wiedergabe der im System vorhandenen Informationen. Aus diesem Grund haben wir, parallel zu den Arbeiten am Backend, bereits damit begonnen, den Prototypen einer Webseite zur Darstellung der Informationen zu implementieren.

Dieser Prototyp stellt zur Zeit vier Abschnitte (Sections) aus der Chronik bereit, zwischen denen der Benutzer auswählen kann (Abbildung 2). Zu einem ausgewählten Abschnitt werden dessen Transkription, sowie (englische) Übersetzung angezeigt. Eine Karte, in Form einer eingebetteten Google-Map (Google Inc. 2012), zeigt zusätzlich alle im Abschnitt vorkommenden Örtlichkeiten an, sofern sie lokalisierbar sind. In der Transkription werden Textteile, zu denen Zusatzinformationen vorliegen, dem Benutzer farblich kodiert angezeigt (Ortsangaben (blau), Personenangaben (rot) und Zeitangaben (gelb)).

Figure 2. Abb. 2 : Screenshot der Webseite. Neben der Transkription (linke Spalte), befinden sich die englische Übersetzung (rechte Spalte), sowie ein Karte mit Positionsmarkierungen der im Text vorkommenden Ortsbeschreibungen.

Fährt nun der Benutzer mit dem Mauszeiger über einen solchen farblich hervorgehobenen Textteil, werden zu diesem in einem Popup-Fenster weitere Informationen oder Verlinkungen angezeigt. So ist zum Beispiel für Ortsangaben, wie in Abbildung 3 zu sehen, dies üblicherweise der Ortsname, sowie ein vergrößerter Ausschnitt der Karte mit einer Markierung der genauen Position, soweit diese bekannt ist.

Figure 3. Abb. 3: Beispiel für Zusatzinformationen bezüglich Constantinople (Faith).

Bei Personenangaben, siehe Abbildung 4, wird die Übersetzung des Namens, der volle Name und weitere Informationen, sowie Links, die zu Einträgen bezüglich der Person auf externen Seiten verweisen, hier Links zu Wikipedia (Wikimedia Foundation 2015) und Prosopography of the Byzantine World (Jeffreys et al. 2011), in einem Popup-Fenster angezeigt.

Figure 4.

Figure 4. Abb. 4 : Beispiel für Zusatzinformationen bezüglich Ioannes 1 (John I Tzimiskes).

Darüber hinaus arbeiten wir daran, sowohl individuelle Textzeugen als auch verschiedene Variationen eines Textes anzeigen zu können.

Hervorzuheben ist, wie oben bereits angedeutet, das die Plattform auch die Möglichkeit bietet, die Edition zu exportieren. Hierzu werden relevante Standards wie zum Beispiel TEI oder CIDOC-CRM (International Council of Museums 2014) angeboten.

3. Zusammenfassung und Ausblick

Wir haben einen kurzen Einblick in das Projekt The Chronicle of Matthew of Edessa Online gegeben. Dieses hat als Ziel eine digitale Plattform zur Verfügung zu stellen, welche das Untersuchen und Bearbeiten von Manuskripten aus philologischer, als auch historischer Sichtweise unterstützt. Hierzu haben wir einen Einblick in technische Aspekte und dem derzeitigen Stand der Implementierung gegeben. Zusammendfassend kann man sagen, dass wir schon eine gute Strecke zurückgelegt haben und dass das Projekt noch einige interessante Aufgaben für uns bereit hält 3.