Inhaltsverzeichnis

1 Einleitung

Zu Beginn der Digitalisierung von historischen Quellen stand die Imagedigitalisierung im Vordergrund. Sie hatte den Vorteil, dass sie unter den gegebenen technischen Rahmenbedingungen bezahlbar und mit vertretbarem Zeitaufwand durchzuführen war. Neben dem Image, also dem Bild der Quelle, wurden noch die sog. Metadaten erfasst, in denen z.B. Eigenschaften und Hinweise zur inhaltlichen Erschließung des Dokuments computerlesbar abgelegt sind.1

Die nächste Stufe der Digitalsierung stellte die Volltextdigitalisierung da. Exemplarisch kann hier auf die Digitalisierung der Regesta Imperii seit 2001 verwiesen werden.2 Neben den Imagedigitalisaten aller bis 2001 gedruckt vorliegenden Bände sind die Volltexte aller Regesten über die Internetseite www.regest-imperii.de recherchierbar.

Im Verlauf der letzten 10 Jahre hat die Menge an digital verfügbaren Volltexten stark zugenommen. Damit einher geht auch eine Veränderung sowohl der Nutzungsformen digitaler Quellen als auch der Möglichkeiten der historischen Arbeitsweise. Bestand um die Jahrtausendwende noch enger Kontakt zwischen Historiker und Quelle, nimmt dies mit zunehmender Digitalisierung perspektivisch ab. Hat der Forscher früher die für seine Forschungsfragen relevanten Quellen in der Regel alle mindestens einmal gelesen, scheint dies bei den heute recherchierbaren Mengen an digitalen Quellen kaum noch möglich. Ein Hauptproblem ergibt sich hier aus der Schnittstelle zwischen Forscher und den im Netz erreichbaren Quellendatenbanken. Die Suchinterfaces der Datenbanken sind oft für die Nutzung durch Experten des jeweiligen Materials optimiert.3 Dies ist auf der einen Seite zu begrüßen, da sie den Experten damit besten Zugriff auf das Material gewähren. Daneben sollten aber weitere Zugriffsmöglichkeiten für übergreifende Text-Mining- oder Big-Data-Recherchen bereitgestellt werden, mit denen verschiedene Quellenkorpora parallel im Hinblick auf übergreifende Fragestellungen untersucht werden können.

Momentan werden digitale Quellen meist in XML oder in SQL-Datenbanken abgelegt. XML hat sich als Standard bewährt und findet in vielen Editionsprojekten als Datenformat Verwendung während Websites meist auf SQL-Datenbanken als Daten-Repositories zurückgreifen. XML-Dateien sind meist noch verständlich lesbar, bei SQL-Datenbanken ist die Lesbarkeit ohne Kenntnis der zu Grunde liegenden Datenstrukturen in der Regel nicht mehr gegeben. Hier könnte die Verwendung von Graphdatenbanken ein neuer Ansatz für die Speicherung von erschließendem Wissen sein.

2 Graphdatenbanken für Historiker

In SQL-Datenbanken sind die Informationen in Tabellen abgelegt, die untereinander verknüpft sind. Graphdatenbanken folgen hier einem völlig anderen Ansatz. In einem Graph gibt es Knoten und Kanten. Vergleicht man die Knoten mit einem Eintrag in einer Tabelle einer SQL-Datenbank, wäre eine Kante eine Verknüfung zwischen zwei Tabelleneinträgen. Im Unterschied zu SQL-Datenbanken können Knoten und Kanten jeweils Eigenschaften haben.

Beispielhaft werden hier die Informationen des kumulierten Registers der Regesten Kaiser Friedrichs III. aufbereitet.4

Das folgende Beispiel demonstriert an Hand der mit Regest Nr. 189 aus Heft 19 der Regesten Kaiser Friedrichs III. verknüpften Registereinträge einen Graph mit neun Knoten (künftig als Nodes bezeichnet) und zehn Kanten (künftig als Edges bezeichnet).

In dem Graphen werden die Registereinträge und das Regest als Nodes dargestellt und die Verknüpfungen als Edges. Vergleicht man diese Datenstrukturen mit jenen einer SQL-Datenbank, fällt vor allem auf, dass sowohl Nodes als auch Edges Eigenschaften (sog. Properties) haben können. In der folgenden Abbildung werden also drei verschiedene Typen von Nodes (Registereintrag, Regest und Ort) und zwei verschiedene Typen von Edges (GENANNT_IN, IST_BUERGERMEISTER_ZU und IST_SOHN_VON) dargestellt und symbolisieren die verschiedenen Verknüpfungen zwischen den Knoten.

Neben den offensichtlich aus dem Register übernommenen Verknüpfungen, die sich direkt aus der Hierarchie und den Angaben unter den jeweiligen Registereinträgen ergeben (wie z.B. GENANNT_IN) können auch weitere Verknüpfungen, wie z.B. die Amtszuweisung IST_BUERGERMEISTER_ZU oder das Verwandschaftsverhältnis IST_SOHN_VON dargestellt und computerlesbar abgespeichert werden. Damit bieten Graphdatenbanken sehr flexible Möglichkeiten, z.B. Erschließungsinformationen zu historischen Quellen computerimplementiert zu erfassen. Gleichzeitig bieten Graphdatenbanken durch die dem menschlichen Denken eng verwandte beziehungszentrierte Ablage von Wissen verbunden mit entsprechenden Visualisierungsmöglichkeiten optimale Unterstützung bei der historischen Forschung an digitalen Quellenbeständen.

Im folgenden wird exemplarisch der Import des kumulierten Registers der Regesten Kaiser Friedrichs III. in die Graphdatenbank Neo4j durchgespielt und anschließend einige Anwendungsbeispiele dargestellt.

3 Das kumulierte Register der Regesten Kaiser Friedrichs III. als Graphdatenbank

Ausgangspunkt der Arbeiten für diesen Text war die Aufbereitung des kumulierten Registers der Regesten Kaiser Friedrichs III. für die Bereitstellung im Internet. Ein Register bietet auf der einen Seite Registereinträge (Personen und Orte) und auf der anderen Seite Regestennummern, die den jeweiligen Registereinträgen zugeordnet sind. Zunächst gingen die Überlegungen dahin, durch die gemeinsame Nennung von zwei Personen in einem Regest eine direkte Verbindung zu postulieren, der man dann als Eigenschaften noch die jeweiligen Angaben des Regests zuweisen kann.5 Im Laufe der Arbeiten erwies es sich aber als praktikabler, die Regesten selbst als Knoten mit in die Datenbank aufzunehmen. Im folgenden werden die verschiedenen Schritte zur Datenaufbereitung, zum Einspielen und zum Auswerten des Registers dargestellt.

3.1 Dateneingabe

3.1.1 Datenaufbereitung

In der folgenden Abbildung wird ein Ausschnitt des kumulierten XML-Registers der Regesten Kaiser Friedrichs III. zum Eintrag der Nürnberger Familie Volckamer dargestellt. Zur Bearbeitung wurde der XML-Editor Oxygen mit einer für die Bearbeitung des Registers angepassten Oberfläche verwendet.

Um die Informationen aus dem Register in die Graphdatenbank neo4j einspielen zu können, müssen sie zunächst in einzelne CSV-Dateien (Comma-Seperated-Values) transformiert werden. Das Ziel sind einzelne CSV-Dateien, die jeweils Wertepaare enthalten.

Wie in der Abbildung zum XML-Quelltext zu sehen, besitzt jeder Eintrag eine eindeutige ID sowie eine Angabe zur Stufe des Registereintrages, zum Inhalt und den zugehörigen Regestennummern. Die Stufe gibt an, ob es sich um einen Untereintrag oder um ein Hauptlemma handelt.

3.1.2 Die Lemmaliste

In einem ersten Schritt werden alle einzelnen Registereinträge exportiert und mit einer zusätzlichen ID versehen. Da das Register hierarchisch aufgebaut ist, müssen zum Verständnis der einzelnen Registereinträge auch die ggf. vorhandenen übergeordneten Einträge hinzugenommen werden. Würde man in unserem o.a. Beispiel das erste Unterlemma unter dem Hauptlemma Volckamer, nämlich Agnes, Frau des Hans ohne weitere Informationen in die Liste übernehmen, wäre es schwierig die Person zu identifizieren. Daher werden die Informationen bei der Transformation in drei Spalten aufgeteilt. In der Spalte name1 steht das Lemma, in der Spalte name2 werden ggf. vorhandene Zusatzinformationen, die nach dem eigentlichen Lemma in Klammern angegeben sind, vermerkt. Dabei kann es sich z.B. um Schreibvarianten oder Lokalisierungen von Ortsnamen handeln. Schließlich werden in der Spalte name3 alle Angaben des Lemmata selbst und der übergeordneten Lemmata, jeweils durch zwei Schrägstriche (//)getrennt, aufgelistet. In der Spalte name3 sind also alle für ein Lemma relevanten Informationen zusammengefasst.

In der ersten Spalte erhält jedes Lemma eine eindeutige ID, auf die dann später die Edges verweisen. Spalte2 enthält die jeweilige XML-ID aus dem XML-Register. Hiermit können später wieder Verknüpfungen ins XML-Register erstellt werden. In Spalte 4 ist die ID des jeweiligen Muttereintrages im Register vermerkt. Über diese Angaben lässt sich das Register später auch wieder in seiner hierarchischen Struktur rekonstruieren. Anschließend folgen die Spalten zu den Namensangaben und schließlich noch eine Spalte mit dem Typ des Eintrages, hier also immer lemma.

Die nächste Abbildung zeigt als direkten Vergleich den Ausschnitt zum Registereintrag der Familie Volckamer aus der Nodes-Datei.

Zu beachten ist, dass in die Nodes-Datei keinerlei Informationen zu den zum Registereintrag gehörigen Regestennummern übernommen werden, sondern nur die Registereinträge.

3.1.3 Die Regestenliste

In einer zweiten Datei werden nun alle im Register vorkommenden Regestennummern angelegt. Da es sich bei dem Register um das kumulierte Register aller Bände der Regesten Kaiser Friedrichs III. handelt, kann hierfür ein Auszug aus der Regestendatenbank mit allen Regesten zu Friedrich III. genutzt werden. Im Register setzten sich die Verweisnummern auf die Regesten aus zwei Bestandteilen zusammen: #13-189 – Das Doppelkreuz (#) markiert die Angabe zum jeweiligen Band und die mit dem Minus anschließende Nummer gibt die Regestennummer an. Analog werden die Regesten in der Regestenliste aufgelistet.

In der Abbildung sehen Sie einen Auszug aus der Regestenliste. In der ersten Spalte wird jedem Regest eine ID gegeben, die später für die Verknüpfung zu den Registereinträgen genutzt wird. Die zweite Spalte enthält die Regestennummer mit Heftangabe, die dritte Spalte das Datum des Regests und die vierte Spalte schließlich den Typ des Eintrages. Hierzu aber später mehr.

3.1.4 Die Liste der Edges

Abschließend wird noch eine Liste mit den Verknüpfungen zwischen Registereinträgen (Nodes) und Regesten (auch Nodes) erstellt. Diese Verknüpfungen nennt man Kanten oder Edges. Quelle und Ziel der Verknüpfungen sind die in den vorherigen Listen erstellen IDs aus der ersten Spalte. Die erste Spalte der Abbildung nennt die ID des Registereintrages. Die zweite Spalte enthält die Regestennummer mit Heftangabe. In der dritten Spalte wird angegeben, ob der Registereintrag Empfänger der im Regest beschriebenen Urkunde ist, hierzu aber mehr im nächsten Abschnitt. Spalte vier enthält die ID des Regests aus der Regestenliste und Spalte 5 das Datum des jeweiligen Regests.

3.1.5 ist_empfaenger

Dem Ausschnitt des Registers zur Familie Volckamer ist zu entnehmen, dass einige der Regestennummern fett gedruckt sind. Dies bedeutet, das der Registereintrag der Empfänger jener im Regest zusammengefassten Urkunde ist. Auch diese Informationen sollen in die Graphdatenbank übernommen werden. In der Abbildung ist eine Zeile markiert, deren Werte hier erläutert werden. Die erste Spalte enthält die ID des Registereintrages. In der zweiten Spalte wird die Regestennummer des Regests angegeben, dessen zugrunde liegende Urkunde die im Registereintrag genannte Person empfangen hat. Spalte 4 nennt die ID des Regests und in Spalte 5 wird das Datum des Regests bzw. der Urkunde angegeben.

3.1.6 is_mother_off

Die letzte CSV-Datei mit der Bezeichnung is_mother_of.csv enthält Informationen zur Hierarchie des Registers. Die zweispaltige Tabelle enthält in der ersten Spalte die ID eines Eintrages und in der zweiten Spalte die ID des jeweiligen übergeordneten Eintrages im Register. Mit diesen Informationen lässt sich die Hierarchie des Registers auch in der Graphdatenbank wieder aufbauen.6

3.1.7 Dateneingabe

Für den Datenimport in neo4j werden in diesem Beispiel csv-Dateien verwendet. Damit stehen uns nach den ganzen, eben beschriebenen Umwandlungen fünf csv-Dateien zur Verfügung: nodes.csv, regestenliste.csv, edges.csv, ist_empfaenger.csv und is_son_of.

Die Installation von neo4j wird auf den Internetseiten des Anbieters beschrieben.7 Es stehen Installationspakete für Windows, Linux und MacOSX zur Verfügung.

Nach der Installation rufen wir die neo4j-shell auf, die Kommandozeile von neo4j.8

Zum Import der ersten Datei werden folgende Befehle eingegeben (oder in die neo4j-shell kopiert):
// Lemmata
USING PERIODIC COMMIT 1000
LOAD CSV WITH HEADERS FROM “file:////home/neo4j/RegisterFIII/nodes.csv”
AS line FIELDTERMINATOR ‘|’
// WITH line LIMIT 500
CREATE (:Lemma {id:line.nodeID, xmlid:line.xmlID, name1:line.name1, name2:line.name2, name3:line.name3, type:line.type})
RETURN line.nodeID, line.name1;

Die erste Zeile erzwingt einen commit nach jeweils 1000 eingelesenen Zeilen. Die zweite Zeile enthält das Kommando für das Einlesen der CSV-Datei, wobei als Feldtrenner das Pipesymbol „|“ gewählt wird. Die Befehlssequenz WITH HEADERS verweist darauf, dass die erste Zeile der CSV-Datei die Spaltenüberschriften enthält. In der dritten Zeile des Befehlsbeispiels wird angegeben, dass für jede eingelesene Zeile der CSV-Datei ein node-Eintrag in der Datenbank erzeugt wird. Dabei werden die einzelnen Angaben für die Erstellung der Nodes mit Hilfe der Spaltenüberschrift in der CSV-Datei den einzelnen Werten zugeordnet. Im Folgenden werden die einzelen Sequenzen des CREATE-Befehls nochmal erläutert:

Befehl	Erläuterung
CREATE	Mit dem CREATE-Befehl wird eine Node in neo4j angelegt.
:Lemma	Die angelegte Node respräsentiert ein Lemma des Registers
id:line.nodeID	Die Lemma-Node soll die ID line.nodeID haben.
name1:line.name1	Import des Feldes name1 (vgl. Abschnitt die Lemmaliste).
name2:line.name2	Import des Feldes name2 (vgl. Abschnitt die Lemmaliste).
name3:line.name3	Import des Feldes name3 (vgl. Abschnitt die Lemmaliste).
type:line.type	Ist eine Node vom Typ Lemma.

Dass es sich bei der angelegten Node um eine Node vom Typ Lemma handelt, wird zweimal berücksichtigt. Einmal als Node vom Typ Lemma und nochmals als Eigenschaft der Node. Diese Doppelung wird für den späteren Export nach Gephi und für die dortige Visualisierung benötigt.

Die Zeile // WITH line LIMIT 5 ist mit zwei Schrägstrichen auskommentiert. Entfernt man den Kommentar, werden nur die ersten fünf Zeilen der CSV-Datei eingelesen. Damit lässt sich die Fehlerfreiheit des Skripts leichter und schneller testen, da ein schneller Rechner für die Abarbeitung des gestammten Materials mehrere Stunden benötigt.

Alle weiteren Befehle für die neo4j-shell sind ähnlich aufgebaut.

// Regesten
LOAD CSV WITH HEADERS FROM “file:////home/neo4j/RegisterFIII/regesten.csv”
AS line FIELDTERMINATOR ‘|’
// WITH line LIMIT 5
CREATE (:Regest {id:line.regID, nummer:line.regestennummer, date:line.datum, type:line.type})
RETURN line.regID;

// Edges
USING PERIODIC COMMIT 1000
LOAD CSV WITH HEADERS FROM “file:////home/neo4j/RegisterFIII/edges.csv”
AS line FIELDTERMINATOR ‘|’
// WITH line LIMIT 5
MATCH (from {id:line.nodeID}), (to {id:line.regID}) create from-[r:GENANNT_IN{datum:line.datum}]->to
RETURN r;

// Empfänger-Edges
USING PERIODIC COMMIT 1000
LOAD CSV WITH HEADERS FROM “file:////home/neo4j/RegisterFIII/empfaenger.csv”
AS line FIELDTERMINATOR ‘|’
// WITH line LIMIT 5
MATCH (from {id:line.nodeID}), (to {id:line.regID}) create from-[r:EMPFAENGER_IN{datum:line.datum}]->to
RETURN line.nodeID,r,line.regestennummer;

// is-son-of
USING PERIODIC COMMIT 1000
LOAD CSV WITH HEADERS FROM “file:///home/neo4j/RegisterFIII/is-son-of.csv”
AS line FIELDTERMINATOR ‘|’
// WITH line LIMIT 5
MATCH (from {id:line.son}), (to {id:line.mother}) create from-[:SON_OF]->to
RETURN *;

Es können auch alle Befehle auf einmal in die Shell kopiert werden. Dann dauert der Einspielprozess einige Stunden. Anschließend können erste Versuche mit dem Material unternommen werden.

3.2 Datenausgabe

Nach dem Ende des Einspielprozesses sind alle Informationen in der Graphdatenbank vorhanden. Im nächsten Schritt werfen wir einen Blick auf das Webfrontend von neo4j.

3.2.1 Neo4j-Webfrontend

Für die Anzeige des Webfrontends von Neo4j benötigt man einen aktuellen Browser (Firefox, Safari oder Chrome). Dort gibt man in die Adresszeile ein:

http://localhost:7474

Anschließend erscheint das Webfrontend von Neo4j.

Zunächst wenden wir uns den Symbolen am linken Rand des Browserfensters zu, zum einen den drei verschieden großen Kreisen und zum anderen dem Stern-Symbol.

Nach Auswahl des Symbols mit den drei verschieden großen Kreisen blendet Neo4j eine weitere Anzeigespalte ein, welche die in der Datenbank verfügbaren Nodes und Edges auflistet.

Wählt man unter Node labels die Schaltfläche Lemma aus, werden einige Lemmata aus dem Register angezeigt.

Nach Belieben können nun andere Ansichten des Registers über die Auswahl der weiteren Schaltflächen angezeigt werden. Unter Relationship types sind die verschiedenen Typen von Verknüpfungen, also Edges, aufgelistet. Schließlich werden unter Property keys noch alle vorhandenen Eigenschaften von Lemmata, Regesten und Verknüpfungen aufgelistet.

3.2.2 Die Abfragesprache cypher

Im vorherigen Abschnitt haben wir zur Ansicht des Materials nur die bereits angebotenen Abfragen genutzt. In diesem Abschnitt sollen erste eigene Schritte unternommen werden. Neo4j bringt eine eigene Abfragesprache mit. Sie nennt sich cypher. Da hier nur erste Schritte erläutert werden können, sei an dieser Stelle auf die Dokumentation von cypher im Neo4j-Handbuch verwiesen.9

Als ersten Beispiel rufen wir die oben bereits angesprochene Familie Volckamer auf und nutzen hierfür die XML-ID des Eintrages im Register.

Der entsprechende cypher-Befehl lautet:
MATCH (n)––(x) WHERE n.xmlid = 'V00000774' RETURN n,x;
und ergibt die in der Abbildung zu sehende Ausgabe. Einen solchen Teil der gesamten Graphdatenbank bezeichnet man als Subgraph. Der Befehl MATCH liefert als Treffer alle Nodes x zurück, die in irgendeiner Beziehung zur Node n mit der xmlid V00000774 stehen. Im XML-Register hat das Hauptlemma der Familie Volckamer genau diese XML-ID, und rundherum werden alle Untereinträge angezeigt, die mit dem Hauptlemma über Edges mit dem Typ SON_OF verknüpft sind.

3.2.3 Visualisierungsoptionen im neo4j-Webfrontend

Klickt man auf eine Node, werden in einem separaten Fenster die Eigenschaften angezeigt.

Das Fenster ist in zwei Tabs aufgeteilt. Im ersten Tab Properties werden die Werte der Node oder der Edge aufgelistet. Im zweiten Tab mit dem symbolisierten Auge können Eigenschaften der Anzeige wie Größe und Farbe der Nodes oder der Edges geändert werden sowie die jeweils angezeigte Property eingestellt werden. Damit kann die Anzeige etwas übersichtlicher gestaltet werden.

In einem zweiten Beispiel soll der Subgraph zum Nürnberger Bürger Niklas Muffel und den anderen mit ihm über Regesten verknüpften Registereinträgen dargestellt werden. Die Befehlszeile sieht folgendermaßen aus:
MATCH (n)-[r1]-(m)-[r2]-(x) WHERE n.xmlid="M00002942" RETURN n,m,x,r1,r2 LIMIT 500;
Hier wird zunächst die Node (n) gesucht, welche, gesteuert über die Angabe
WHERE n.xmlid="M00002942"
auf den Registereintrag von Niklas Muffel weist. Ausgehend von diesem Startpunkt werden alle mit diesem Lemma verknüpften Einträge aufgelistet. Die Verküpfung wird repräsentiert durch
-[r1]-
und die verküpften Einträge durch die Variable (m).

Dann werden ausgehend von jedem einzelnen Treffer (m) alle mit diesem verküpften Einträge (x) aufgelistet, jeweils verbunden über die Verknüpfung
-[r2]-
Das abschließende Statement
RETURN n,m,x,r1,r2 LIMIT 500
gibt neo4j die Anweisung, die Werte n,m,x,r1,r2 bis zu einer Gesamttreffermenge von 500 zurück zu liefern und anzuzeigen.

In diesem Beispiel wurden alle Regestennodes in gelber Farbe, die Lemmata in grauer Farbe, die SON_OF-Edges in roter Farbe und die GENANNT_IN-Edges in blauer Farbe dargestellt. Dies verbessert zwar die Erkennbarkeit der Strukturen, jedoch ist das Anzeigefenster zu klein, um alle Treffer in lesbarer Art und Weise sichtbar zu machen.

Um diesen Subgraphen weiter auswerten zu können, kann man einerseits versuchen, die Ergebnismenge einzuschränken. Andererseits könnten aber auch Fragestellungen auftreten, bei denen weit größere Ergebnismengen vorliegen als im oben dargestellten Beispiel. Für diese Fälle gibt es die Möglichkeit, den Subgraphen zu exportieren und in einem anderen Programm weiter zu analysieren und zu bearbeiten.

3.2.4 Export von Subgraphen zur Weiterbearbeitung

Für den Export von Daten aus Neo4j ist die Installation der neo4j-shell-tools notwendig. Das Paket wird unter https://github.com/jexp/neo4j-shell-tools (abgerufen am 13.03.2015) im Internet angeboten. Dort wird auch die Installation des Pakets beschrieben. Mit der Installation stehen nun in der neo4j-shell zusätzliche Befehle zur Verfügung, darunter auch der Befehl export-graphml.

Nach Aufruf der Shell können Sie nun folgenden Befehl eingeben:
export-graphml -t -o /home/neo4j/RegisterFIII/subgraph.graphml MATCH (n)-[r1:GENANNT_IN]-(m)-[r2:GENANNT_IN]-(z) WHERE n.xmlid="M00002942" RETURN n,m,z,r1,r2 LIMIT 500
Der Befehl liefert bei Erfolg folgendes Ergebnis zurück:

Wrote to GraphML-file /home/neo4j/RegisterFIII/subgraph.graphml 0. 100%: nodes = 192 rels = 559 properties = 1593 time 1849 ms total 1849 ms

Der Parameter -t führt zu einer speziell für die Weiterbearbeitung in Gephi notwendigen Formatierung der graphml-Datei. Der Parameter -o gibt den Pfad zur Datei an. Hier ist besonders auf die Schreibberechtigung von neo4j zu achten, da es ansonsten zu Fehlern kommt. Zum Schluss wird der cypher-Befehl zur Erstellung des Subgraphen angegeben. Zu beachten ist, dass die Reihenfolge der Kommandozeilenparameter nicht beliebig ist, sondern genau in der oben angegebenen Weise erfolgen muss, sonst funktioniert der Export nicht. Zum Schluss haben wir eine Datei subgraph.graphml, die wir mit Gephi öffnen können.

4 Visualisierung von Netzwerken in Gephi10

4.1 Das Programm Gephi

Gephi ist Open-Source-Software und kann auf der Seite www.gephi.org heruntergeladen werden.11 Nach der Installation können die exportieren Daten importieren werden.

4.2 Import und Aufbereitung der Daten

Nach dem Öffnen von Gephi erstellt man ein neues Projekt und kann anschließend die GraphML-Datei öffnen. Die vorgeschlagenen Importparameter können so übernommen werden. Im oberen Bereich des Programmfensters finden sich die drei Reiter Overview, Data Laboratory und Preview. Falls im Bereich Overview kein Graph angezeigt wird, kann man die Anzeige über das Menü Fenster – Graph erzwingen. Das gleiche gilt für den Fall, dass im Bereich Data Laboratory nichts angezeigt wird. Auch hier kann über das Menü Fenster – Data Table die Anzeige erzwungen werden.

Zunächst sehen wir uns im Bereich Overview die verschiedenen Visualisierungsmöglichkeiten näher an.

4.3 Visualisierungsmöglichkeiten

Wählt man im oberen Bereich des Programmfensters den Reiter Data Laboratory aus, erscheinen die der Netzwerkvisualisierung zu Grunde liegenden Daten. Unter Nodes erkennen wir unsere Personen aus dem Register wieder. Der Eintrag mit der ID n15957 ist z.B. unser Niklas Muffel III.

Unter dem Reiter Edges werden die Verknüpfungdaten (Edges) angezeigt. Die markierte Edge verweist auf eine gemeinsame Nennung von Bamberg in Bayern (mit der ID n1096) im Regest 463 aus Heft 14 mit dem Datum 1449-04-29. Im Datenlabor hat man also direkten Zugriff auf alle der Visualisierung zu Grunde liegenden Daten.

Wechselt man in den Bereich Overview, zeigt Gephi zunächst die entsprechenden Nodes und Edges in einem Würfel an.

4.4 Auswahl des Layout: ForceAtlas2

Auf der linken Seite des Programmfensters können im Fenster Layout verschiedene Layouts für die weitere Bearbeitung der Daten ausgewählt werden. In unserem Beispiel wenden wir nun das Layout ForceAtlas2 an. Nach kurzer Zeit hat sich unser Würfel auseinandergezogen und es werden verschiedene Zentren bzw. Gruppen von Nodes sichtbar.

In den folgenden Abschnitten werden noch weitere Funktionen erläutert, mit denen charakteristische Merkmale der Daten sichtbar gemacht werden können.

4.5 Lemmata und Regesten farbig darstellen

Für den besseren Überblick lassen sich Regesten und Lemmata verschiedene Farben zuordnen. Hierfür benötigt Gephi aber Informationen zum Typ der jeweiligen Nodes. Daher wurde in vorher in Neo4j den Nodes jeweils die Angabe hinzugefügt, ob es sich um Regesten oder Lemmata handelt.

Diese Angaben können jetzt für die unterschiedliche Farbzuweisung verwendet werden.

Hierfür wird oben links im Bereich Partition „Nodes“ ausgewählt. Anschließend werden über den grünen Aktualisierungsknopf die verfügbaren Eigenschaften aktualisiert. Dann werden bei der Auswahl unter type für lemma und regest verschiedene Farben angeboten. Mit Apply werden die angebotenen Farben den Nodes zugeordnet.

4.6 Degree Range

Unter dem Reiter Filters am rechten Bildrand gibt es noch weitere Analysemöglichkeiten. Unter dem Punkt Topology befindet sich der Unterpunkt Degree Range. Mit diesem kann man auswählen, wieviele Verknüpfungen eine Node haben muss, damit sie noch angezeigt wird. Für unser Beispiel haben wir die alle Nodes ausgeblendet, die 42 oder weniger Verknüpfungen haben.

 

 

 

 

 

 

In der linken Abbildung wird das gesamte Netzwerk abgebildet, im rechten Bild nur noch jene Nodes, die 10 oder mehr Verknüpfungen haben. Zu diesen „wichtigen“ Nodes lassen sich auch die Namen einblenden.

Wechselt man von dieser Ansicht ins Datenlabor, werden dort nur noch jene Nodes angezeigt, die in der Auswahl vorher sichtbar waren.

4.7 Timeline

Abschließend soll noch die Verwendung der Timeline in Gephi erläutert werden. Die Datengrundlage unserer Visualisierung bilden zum einen die aus dem Register extrahierten Registereinträge und Regesten (Nodes) und die aus den Regestenangaben im Register gewonnenen Verküpfungen (Edges). Jede Verküpfung zwischen den Registereinträgen geht auf die gemeinsame Zuordnung zu einem Regest zurück. Das Regest selbst hat ein Datum und dieses kann man den Verknüpfungen zuordnen, so dass sie zeitlich eingeordnet werden können. Hier soll nur auf die zeitliche Einordnung eingegangen werden.

Momentan erstellt Gephi aus importieren Datumsangaben nicht automatisch eine Timeline, auch wenn die Daten in der normierten Form YYYY-MM-DD vorliegen. Es gibt aber einen Workaround, mit dem man Gephi überzeugen kann, doch die importierten Datumsangaben für die Visualiserung mit einer Timeline zu verwenden. Hierfür wechselt man ins Datenlabor in den Bereich Edges. Im unteren Bereich des Programmfensters wählt man nun merge columns aus. Im sich nun öffnenden Dialogfenster wählt man unter available columns die Spalte datum und bringt sie mit dem Pfeilsymbol in den Bereich columns to merge. Im sich nun öffnenden neuen Fenster wählt man time interval creation options. Hier muss man nun parse dates auswählen und das Format zu yyyy-mm-dd anpassen. Nach dem OK-Click erscheint die Timeline.

Aktiviert man am unteren Ende des Programmfensters in Gephi die Timeline, kann ein bestimmter Zeitintervall für die Anzeige ausgewählt werden.

Unser Beispiel enthält Daten über einen Zeitraum von 1442 bis 1454. Zunächst sind alle Jahre ausgewählt, so dass alles angezeigt wird. Schränkt man die Auswahl mit Hilfe des Zeitbalkens am unteren Fensterrand jedoch ein, werden nur noch jene Edges angezeigt, deren Datumsangaben innerhalb des ausgewählten Intervalls liegen.

Je nach Fragestellungen lassen sich hier also Netzwerkstrukturen für bestimmte Zeiträume visualisieren. Es ist auch möglich, ein ausgewähltes Zeitintervall über den gesamten Zeitraum quasi filmartig ablaufen zu lassen, jedoch lässt sich dieses Feature hier nicht darstellen.

Abschließend noch der Verweis auf die von mir verwendete Neo4-Datenbank:

Graphdatenbank des kumulierten Registers der Regesten Kaiser Friedrichs III. (Stand Anfang 2014):12 https://www.dropbox.com/s/ciq6wc4qzf3wer1/data-FIII.tar.gz?dl=0

5 Zusammenfassung

Die zunehmende Menge an Volltexten in den Geschichtswissenschaften bietet neue Chancen für die Forschung, erfordert aber auch neue Methoden und Sichtweisen. In diesem Artikel wurde der Import des kumulierten Registers der Regesten Kaiser Friedrichs III. in die Graphdatenbank Neo4j vorgestellt. Anschließend konnte ein Teil des Registers, ein sog. Subgraph, exportiert und in Gephi weiterbearbeitet werden. Graphdatenbanken können sich für Historiker zu einer Möglichkeit für die transparente Speicherung von Beziehungs- und Interpretationsstrukturen entwickeln.

Aktuelle Visualisierungswerkzeuge wie Gephi (www.gephi.org) können auch für die Visualisierung von Netzwerkstrukturen in historischen Quellenbeständen, Regesten- und Editionswerken genutzt werden.

Zu beachten ist die Qualität der Verknüpfungsdaten. Bei Registern lassen gemeinsame Nennungen von Personen in Urkunden oder Regesten nur sehr begrenzte Schlüsse auf ihre tatsächlichen Beziehungen zu.

---

DOWNLOAD (PDF/A-Version)

---

Zitationsvorschlag: Andreas Kuczera: Graphdatenbanken für Historiker. Netzwerke in den Registern der Regesten Kaiser Friedrichs III. mit neo4j und Gephi, in: Mittelalter. Interdisziplinäre Forschung und Rezeptionsgeschichte, 5. Mai 2015, http://mittelalter.hypotheses.org/5995 (ISSN 2197-6120).

1. Die Imagedigitalisierung einer Edition findet man z.B. bei den dmgh (www.dmgh.de). Neben den üblichen Matedaten werden bei den dmgh sogar die Koordinaten der einzelnen Worte und Buchstaben auf den Seiten mit erfasst und mit dem ebenso erstellten Volltext verknüpft. Einen Überblick zu Publikationen zu den dmgh bietet die Seite http://www.mgh.de/dmgh/pub/ (abgerufen am 4.2.1015). [↩]
2. Zur Digitalsierung der RI vgl. Dieter Rübsamen, Andreas Kuczera: Verborgen, vergessen, verloren? Perspektiven der Quellenerschließung durch die digitalen Regesta Imperii. In: Rainer Hering, Jürgen Sarnowsky, Christoph Schäfer und Udo Schäfer [Hrsg.]: Forschung in der digitalen Welt. Sicherung, Erschließung und Aufbereitung von Wissensbeständen. Tagung des Staatsarchivs Hamburg und des Zentrums ‚Geisteswissenschaften in der digitalen Welt‘ an der Universität Hamburg am 10. und 11. April 2006. Hamburg 2006, S. 109–123 (=Veröffentlichungen aus dem Staatsarchiv der Freien und Hansestadt Hamburg, Bd. 20). (http://hup.sub.uni-hamburg.de/opus/volltexte/2008/77/pdf/HamburgUP_HeringEtAl._Forschung.pdf PDF; 13,1 MB abgerufen am 4.2.2015). [↩]
3. Die Problematik wird in diesem Beitrag näher untersucht: Andreas Kuczera: Digitale Perspektiven mediävistischer Quellenrecherche, in: Mittelalter. Interdisziplinäre Forschung und Rezeptionsgeschichte, 18. April 2014, http://mittelalter.hypotheses.org/3492 (ISSN 2197-6120) (abgerufen am 4.2.2015). [↩]
4. Das kumulierte Register der Regesten Kaiser Friedrichs III. finden sie unter http://www.regesta-imperii.de/regesten/register.html (abgerufen am 4.2.2015). [↩]
5. Die Entstehung der Idee zur Visualisierung von Registernetzwerken beschreibt auch der Artikel Andreas Kuczera: Digitale Farbenspiele oder nützliches Werkzeug – Visualisierung von Netzwerken aus den Registern von Editions- und Regestenwerken, in: Mittelalter. Interdisziplinäre Forschung und Rezeptionsgeschichte, 8. Januar 2015, http://mittelalter.hypotheses.org/5089 (ISSN 2197-6120) (abgerufen am 5.2.2015). [↩]
6. In einer neueren Version der Datenbank wurde die Angabe is_son_of durch die Bezeichnung OBERLEMMA ersetzt, da die Gefahr für Verwechselungen mit Verwandschaftsbeziehungen verringert. [↩]
7. Vgl. http://neo4j.com/download/ (abgerufen am 12.03.2015). [↩]
8. Weitere Informationen zur neo4j-shell finden sich im neo4j-Nutzerhandbuch: http://neo4j.com/docs/stable/shell.html (abgerufen am 12.03.2015). [↩]
9. http://neo4j.com/docs/stable/cypher-query-lang.html abgerufen am 13.03.2015. [↩]
10. Das Kapitel ist teilidentisch mit Andreas Kuczera: Digitale Farbenspiele oder nützliches Werkzeug – Visualisierung von Netzwerken aus den Registern von Editions- und Regestenwerken, in: Mittelalter. Interdisziplinäre Forschung und Rezeptionsgeschichte, 8. Januar 2015, http://mittelalter.hypotheses.org/5089 (ISSN 2197-6120). [↩]
11. Auf der Seite www.gephi.org findet man unter dem Reiter Download die Softwarepakete für verschiedene Betriebssysteme. Installationsanleitungen für die einzelnen Betriebssystemumgebungen finden sich unter https://gephi.github.io/users/install/ (abgerufen am 30.3.2015). [↩]
12. Es handelt sich um eine komprimierte-Datei (im tar.gz-Format) mit der gesamten Neo4j-Datenbank. Nach der erstmaligen Installation von Neo4j müssen Sie im neo4j-Verzeichnis den Ordner data löschen und durch den entsprechenden Ordner in der komprimierten Datei ersetzen. [↩]

---

---