Graphdatenbanken für Historiker. Netzwerke in den Registern der Regesten Kaiser Friedrichs III. mit neo4j und Gephi

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

Kuczera Mai 2015 Abb1

Abbildung 1: Registereinträge, die in Regest Nr. 189 vorkommen, aus: Regesten Kaiser Friedrichs III. (1440-1493). Nach Archiven und Bibliotheken geordnet. H. 19: Die Urkunden und Briefe aus Archiven und Bibliotheken der Stadt Nürnberg. Teil 2: 1450-1455Rübsamen, Dieter [Bearb.]. – Wien [u.a.] (2004) , S. 106, 287, 296 und 297.

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.

Kuczera Mai 2015 Abb2

Abbildung 2: Graph zu den Registereinträgen zu Regest Nr. 189

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.

Kuczera Mai 2015 Abb3

Abbildung 3: Ausschnitt des kumulierten XML-Registers der Regesten Kaiser Friedrichs III. zum Eintrag der Nürnberger Familie Volckamer

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.

Kuczera Mai 2015 Abb4

Abbildung 4: Ausschnitt des Registereintrages der Familie Volckamer im XML-Quelltext

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.

Kuczera Mai 2015 Abb5

Abbildung 5: Liste aller Registereinträge im CSV-Format

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

Kuczera Mai 2015 Abb6

Abbildung 6: Ausschnitt der Nodes-Datei zum Registereintrag der Familie Volckamer

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

Abbildung 7: Auszug aus der Regestenliste

Abbildung 7: Auszug aus der 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

Abbildung 8: Ausschnitt aus der Edgesdatei

Abbildung 8: Ausschnitt aus der Edgesdatei

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

Abbildung 9: Ausschnitt aus der Datei ist_empfaenger

Abbildung 9: Ausschnitt aus der Datei 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

Abbildung 10: Blick in die CSV-Datei IS_MOTHER_OF

Abbildung 10: Blick in die CSV-Datei IS_MOTHER_OF

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.

Abbildung 11: Webfrontend von Neo4j

Abbildung 11: 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.

Abbildung 12: Einige Lemmata aus dem Register in Neo4j

Abbildung 12: Einige Lemmata aus dem Register in Neo4j

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.

Abbildung 13: Der Registereintrag der Familie Volckamer in Neo4j

Abbildung 13: Der Registereintrag der Familie Volckamer in Neo4j

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.

Abbildung 14: Anzeige der Eigenschaften einer Node

Abbildung 14: Anzeige der Eigenschaften einer Node

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.

Abbildung 15: Das Hauptlemma der Nürnberger Familie Muffel mit allen Unterlemmata und den genannten Regesten

Abbildung 15: Das Hauptlemma der Nürnberger Familie Muffel mit allen Unterlemmata und den genannten Regesten

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.

Abbildung 16: Liste der importieren Nodes im Data Laboratory von Gephi

Abbildung 16: Liste der importieren Nodes im Data Laboratory von Gephi

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.

Abbildung 17: Liste der Edges im Data Laboratory von Gephi

Abbildung 17: Liste der Edges im Data Laboratory von Gephi

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

Abbildung 18: Gephi zeigt die erste Visualisierung der Daten als Würfel an.

Abbildung 18: Gephi zeigt die erste Visualisierung der Daten als 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.

Abbildung 19: Nach Anwendung des Layouts ForceAtlas2

Abbildung 19: Nach Anwendung des Layouts ForceAtlas2

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.

Abbildung 20: Zuweisung unterschiedlicher Farben für Regesten und Lemmata

Abbildung 20: Zuweisung unterschiedlicher Farben für Regesten und Lemmata

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.

Kuczera Mai 2015 Abb21

Abbildung 21: Gesamtbild des Graphen

Kuczera Mai 2015 Abb22

Abbildung 22: Nach Anwendung des Degree-Filters

 

 

 

 

 

 

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.

Abbildung 23: Nodes mit eingeblendeter Beschriftung

Abbildung 23: Nodes mit eingeblendeter Beschriftung

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

Abbildung 24: Blick ins Datenlabor. Hier werden nur noch jene Nodes angezeigt, die vorher in der Auwahl sichtbar waren.

Abbildung 24: Blick ins Datenlabor. Hier werden nur noch jene Nodes angezeigt, die vorher in der Auwahl 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.

Abbildung 25: Gephi mit aktivierter Timeline. Hier werden nur die Verknüpfungen des Jahres 1443 angezeigt.

Abbildung 25: Gephi mit aktivierter Timeline. Hier werden nur die Verknüpfungen des Jahres 1443 angezeigt.

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

Andreas Kuczera

1993-1998 Studium der Physik und Geschichte an der Justus-Liebig-Universität Gießen (Staatsexamen für das Lehramt an Gymnasien), 2001 Promotion »Grangie und Grundherrschaft«. Zur Wirtschaftsverfassung des Klosters Arnsburg als Stipendiat der hessischen Graduiertenförderung. 2001-2006 Mitarbeiter im DFG-Projekt Regesta Imperii Online . Von 2007-2012 leitend in der Projektverwaltung der Akademie Mainz und der Digitalen Akademie tätig. Sachverständiger der IT-Kommission der Akademie Mainz. Seit 2013 wissenschaftliche Mitarbeiter im Projekt Regesten Kaiser Friedrich III., Arbeitsstelle Gießen. Forschungsschwerpunkte: Regesta Imperii Digitale Geisteswissenschaften -- Digital Humanities Zisterzienser im hessischen Raum

More Posts - Website

Das könnte Dich auch interessieren...

5 Antworten

  1. Lisa Bolz sagt:

    Guten Tag!
    Diesen sehr schönen Artikel haben wir in die Slideshow von de.hypotheses.org aufgenommen, um ihn der Community besser präsentieren zu können.
    Herzliche Grüße
    Lisa Bolz

  2. Jan Keupp sagt:

    Ich bedauere, dass Sie meinen Kommentar als Angriff auf Ihre Arbeit, die ich sehr schätze, missverstanden haben. Gerade das Medium Blog fasse ich als Möglichkeit auf, in kollegial-freundlicher, in diesem Fall ein wenig satirischer Form grundsätzliche Fragen offen und unverkrampft zu diskutieren. Ich sehe darin – in Analogie zur Fachtagung – eine „digitale Kaffeepause“, in der ein lockeres und ggf. ein wenig kritischeres Gespräch seinen Platz hat. Bitte verzeihen Sie, wenn ich mit dieser Auffassung eine Grenze überschritten haben sollte.

    Mein Perspektivwechsel hat seinen Grund in genau jenen Resentiments, die den digital humanities immer noch entgegenschlagen. Man könnte sie als Murren weniger „Zurückgebliebener“ abtun aber ich fände es wichtig, sich offensiv mit möglichen Kritikpunkten auseinanderzusetzen.

    Den Kern- und Angelpunkt bildet dabei die Frage: Was genau ist der Nutzen? Sie verstummt in dieser ärgerlichen Pauschalität regelmäßig dann, wenn die abstrakte Ebene verlassen wird und konkrete Anwendungsfälle und ihre Erträge vorgestellt werden. Gerade aus Ihren Forschungsgebieten, etwa der zisterziensischen Güterwirtschaft, sollten sich doch eigentlich hervorragende Anschauungsbeispiele ergeben. Damit ließen sich dann umso leichter andere überzeugen, sich das notwenige Wissen anzueignen und gleichfalls neue Erkenntniswege zu beschreiten.

  3. Jan Keupp sagt:

    Ich könnte hier nun den konservativen Historiker heraushängen lassen und wie folgt argumentieren: „Dem Fetisch Digitalisierung lässt sich offenbar unbegrenzt huldigen, um die reichlich fließenden Geldmittel zu perpetuieren. Was uns hier dargestellt wird ist in erster Linie ein Neuarrangement von Daten, dessen Mehrwert für die Forschung in keiner konkreten Studie erwiesen ist. Hier wird offenbar der zweite Schritt (die Aufbereitung) vor den ersten (die Fragestellung) gesetzt. Zudem werden von HistorikerInnen Spezialkompetenzen verlangt, die letztlich auf Kosten der Kernkompetenzen unseres Faches gehen. Schon deshalb wäre der Nutzen der vorgestellten Technologie sorgfältig zu prüfen“.

    Nein, ich bin kein radikaler Gegner von Graphdatenbanken oder der digitalen Erschließung von Quellen insgesamt. Schon bei meiner Dissertation wäre ich dankbar gewesen, nicht alle Namen abtippen und Verbindungen recherchieren zu müssen. Der Mehrwert der damals verfügbaren Itinerar- und Urkundenkartierungen lag auf der Hand und neue visuellen Darstellungsformen können sich als mindestens ebenso nützlich erweisen. Dennoch teile ich die Kritik meines konservativen Popanz in dem einen Punkt: Digitale Erschließung und praktische Anwendung sollten Hand in Hand gehen. Eine Datenaufbereitung muss immer im Hinblick auf konkrete Anwendungen geschehen – so habe ich es im Informatikseminar gelernt. Ich würde mich also freuen, neben den technischen Möglichkeit auch die Erkenntnispotentiale genauer vorgestellt zu bekommen.

    • Andreas Kuczera sagt:

      Sehr geehrter Herr Keup,
      zu den „reichlich fließenden Geldmitteln“ muss ich leider erwidern, dass für meine Versuche mit Graphdatenbanken keinerlei Forschungsmittel geflossen sind. In einem zweiten Schritt habe ich meine Erkenntnisse in dem Artikel zusammengefasst um Kollegen daran teilhaben zu lassen — auch ohne finanzielle Förderung. Für Hinweise auf Förderlinien in diesem Bereich bin ich immer dankbar.

      In Ihrem zweiten Punkt stellen Sie korrekterweise klar, dass es sich um ein Neuarrangement von Daten handelt. In dem Beitrag wurde aber auch an keiner Stelle behauptet, dass es mehr sein soll. Im Gegenteil, auch die Schwächen der Methode wurden explizit herausgestellt.

      Mit Ihrem dritten Punkt, dass von den Historikern Spezialkompetenzen gefordert werden, liegen sie natürlich richtig. Aber der Beitrag richtet sich gerade an experimentierfreudige Kollegen, die nach neuen Ansätzen Ausschau halten.

      Im zweiten Teil Ihrem Kommentars wechseln Sie die Perspektive, was die Einschätzung Ihres tatsächlichen Standpunktes nicht erleichtert. Von daher fällt es mir auch schwer, Ihrer letzten Forderung nachzukommen, nämlich „die Erkenntnispotentiale genauer vorgestellt zu bekommen“, da sich nicht nur die Fragestellungen an das Material natürlich individuell unterscheiden und damit eine Beantwortung Ihrer Frage den Rahmen des Artikels sprengen würde sondern auch die Anwendung von Graphdatenbanken an sich keine „Erkenntnis-Maschine“ darstellt.

      Vielmehr würde ich gerne abschließend auf Ihren Begriff „Neuarrangement“ der Daten zurückkommen. Gerade hier sehe ich Chancen, dem Historiker neue Sichtweisen auf sein Material zu ermöglichen. Wenn er dann neue Zusammenhänge erkannt hat, muss er anschließend nach bewährter historischer Methode die Quellen untersuchen und kann dann ggf. zu neuen Schlussfolgerungen kommen.

      Es gibt Menschen die suchen Gründe und es gibt Menschen die suchen Wege. In dem Beitrag versuche ich neue Wege zu beschreiten und würde mich freuen, wenn Sie dabei wären.

  1. 12. Juli 2015

    […] Kuczera: Graphdatenbanken für Historiker. Netzwerke in den Registern der Regesten Kaiser Friedrichs III. mi…in: Mittelalter. Interdisziplinäre Forschung und Rezeptionsgeschichte, 5. Mai […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.