DH³

Die Welt ist ein Graph.

Michael Hunger

Am 27.02. fand an der SUB der erste vom Referat für Digitale Forschungsdienste veranstaltete Workshop statt, der ergänzend zum Vortrag zu Graphentheorien und -technologien im Januar (hier der Bericht) die Gelegenheit bieten sollte, unter Anleitung selbst tätig zu werden und am Beispiel der Korrespondenzdaten des Projekts Dehmel Digital erste Praxiserfahrung mit Neo4J zu sammeln. Hamburg zeigte sich zu diesem Anlass von seiner schönsten Seite und die Teilnehmer:innen konnten die Aussicht und Dachterrasse des Bücherturms bei bester Wintersonne genießen.

Nachdem alle Teilnehmer:innen den Weg in den Seminarraum gefunden und sich mit Kaffee, Tee und Keksen eingedeckt hatten, begann die Veranstaltung mit einer kurzen Vorstellungsrunde. Hierbei wurde deutlich, wie unterschiedlich die Hintergründe der Teilnehmer:innen waren: Aus Bibliotheken, Universitäten und Forschungsanstalten kamen Interessierte angereist, unter anderem aus Hamburg, Berlin und sogar aus Zürich.

Danach eröffnete Franziska Klemstein den eigentlichen Workshop mit dem schon eingangs genannten Zitat von Michael Hunger: “Die Welt ist ein Graph”, um zu demonstrieren, wie allgegenwärtig Relationen und Beziehungen sind. Entsprechend wurden die Teilnehmer:innen gebeten, sich ihre eigenen Projekte, oder auch nur den Raum zu vergegenwärtigen und auf Papier die Skizze eines Graphen zu erstellen, der in Knoten und Kanten Beziehungen darstellt und eine oder mehrere spezifische Fragestellungen beantworten sollte.

Nach einer Viertelstunde angeregter Arbeit wurden dann die Ergebnisse präsentiert. In einem Fall wurde danach gefragt, welche Personen im Raum mit welcher Hardware welche Betriebssysteme nutzen würden. Andere Teilnehmer:innen fragten nach der Genese eines Artikels vom Entstehen zur Publikation, oder auch nach der Verknüpfung von Forschungsprojekten zu Infrastruktur und Institutionen. Mein eigener Graph sollte das Datenmodell für das Kairener Brief- und Salon-Netzwerk um May Ziyadeh abbilden:

Mein erster Entwurf hatte noch einen Knoten für “Rolle”, was aber über die zeitliche Entwicklung schwer darstellbar ist. Dieses Problem hatten mehrere Teilnehmer:innen und mit ein wenig mehr Zeit wäre das sicherlich ein spannender Punkt zur weiteren Diskussion gewesen. Vielleicht Material für einen künftigen Workshop? Zentrale Erkenntnis dieser Übung war sowohl die Allgegenwart von Relationen, aber auch ganz konkret, wie wichtig es ist, sich im Vorfeld Gedanken über Sinn und Zweck des Graphen zu machen und zu klären, welche Fragestellungen der Graph am Ende beantworten soll. Auch die Richtung der Kanten und korrekte Bezeichnungen sind essenziell. Franziska betonte hier auch noch, dass im Verlauf der Arbeit an Graphen immer wieder geprüft werden muss, ob der Graph die Ansprüche noch immer gut bedienen kann, oder ob er entsprechend angepasst werden muss.

Nach einer recht ausführlichen Diskussion über die Herausforderungen, mit denen man sich in der Übung konfrontiert sah, folgte dann die wohlverdiente Pause, in der sich die Teilnehmer:innen mit Kaffee und Tee ausgestattet auf der Dachterrasse im Sonnenschein über das gerade Gelernte austauschen, oder einfach nur die Aussicht genießen konnten.

In der zweiten Hälfte des Workshops ging es dann los mit der Arbeit an Neo4J selbst. Zunächst gab es eine kurze Einführung zu den grundlegenden Eigenschaften und Anwendungsszenarien von Neo4J: Knoten und Kanten haben immer eine interne ID und können verschiedene Eigenschaften besitzen. In den Konventionen werden Knoten immer im CamelCase geschrieben: (:EinKnoten), Kanten werden groß und mit Unterstrich bezeichnet: [:EINE_KANTE], wobei hier auch alles klein geschrieben werden kann. In Abfragen lassen sich Kanten und Knoten über Variablen ansteuern, die jeweils aber nur für die Abfrage gültig sind: (e:EinKnoten) oder [k:EINE_KANTE]. Auf Umlaute sollte verzichtet werden, interessanterweise funktioniert aber die Nutzung von arabischer Schrift, was mich persönlich natürlich sehr gefreut hat:

// Arabisch funktioniert:
CREATE (ب:شخص {اسم: 'محمد'})
RETURN ب;

Es besteht übrigens von Haus aus nicht die Möglichkeit, den Graph gegen vorher festgelegte Schemata oder Onthologien zu prüfen, was eine gewisse Disziplin voraussetzt, arbeitet man in Teams. Zwar gibt es Workarounds, XML-Verwöhnte werden sich hier aber umgewöhnen müssen. Neo4J Desktop bietet aber etwa die Möglichkeit, bereits getätigte Abfragen als Favoriten zu speichern, so kann man sich bei komplexeren Abfragen lästiges Nachschauen oder Copy’n’Paste sparen.

Nachdem grundlegende Befehle und Abfragen in der Neo4J-eigenen Abfragesprache Cypher gelernt und geübt wurden, sollten die Teilnehmer:innen sich zunächst überlegen, ob die vorher erstellten Graph-Modelle so wohl in Neo4J umsetzbar wären und was daran noch geändert werden müsse oder welche potenziellen Fehlerquellen es geben könnte.

Eine kurze Diskussion später konnten die Teilnehmer:innen dann endlich statt mit ausgedachten Platzhaltern konkret mit Inhalten aus der Praxis arbeiten, nämlich mit einem Beispieldatensatz aus Korrespondenzdaten der Briefedition Dehmel Digital. Im Vorfeld wurden die Korrespondenzdaten und Personendaten aus dem Projekt aufbereitet und durch Franziska in einem Git zur Verfügung gestellt. Nach einer kurzen Aufklärung über die notwendigen Aufbereitungsschritte (so kann Neo4J etwa nicht mit leeren Feldern umgehen, Arrays in Feldern müssen reduziert werden), wurden die Teilnehmer:innen zunächst eingeführt in den Neo4J-eigenen CSV-Import, der tatsächlich sowohl für lokale, als auch für Daten von remote ziemlich einfach ist:

// CSV importieren, bei lokal ist URL = 'file:///'
LOAD CSV FROM 'URL' AS row
fieldterminator ';'
CREATE (p:Person {name: row[0], gnd: row[1]})

// CSV importieren und Briefe und Relationen erstellen:
LOAD CSV FROM 'URL' AS row
fieldterminator ';'
MATCH (n1:Person {GND: row[2]}), (n2:Person {GND: row[4]})
CREATE (n1)-[:verfasste]->(b:Brief {ID: row[0], Autor_in: row[1], Empfaenger_in: row[3]})-[:empfing]->(n2)

Die Desktop-Version von Neo4J bietet außerdem einen komfortablen CSV-Import über die GUI.

Mit den importierten Daten hatte man nun einen ansehnlichen Graphen, der die Korrespondenz über die Beispielmetadaten gut darstellte. Die Teilnehmer:innen diskutierten nun über Anwendungsfälle und stellten erste Abfragen zu den Korrespondenzen. Leider gab der Zeitrahmen komplexere Abfragen nicht her, wie etwa die Errechnung eines Clusterkoeffizienten oder die Erstellung eines Triangle Count. Letzterer hätte im Beispieldatensatz aber ohnehin nicht funktioniert, da keine Person-Person-Beziehungen enthalten waren. Franziska erörterte das Vorgehen in der Theorie, die entsprechenden Folien finden sich ebenfalls im verlinkten Git.

Da einige Teilnehmer:innen pünktlich ihre Züge erreichen mussten, endete der Workshop also annähernd planmäßig. Ein Vormittag reich an neuen Eindrücken und gelerntem Wissen ging zuende und ich kann da nur für mich reden, aber ich denke, dass das Thema Graphen für mich erst begonnen hat. Im Laufe des Workshops stellten sich immer wieder Probleme dar, die nicht einfach beantwortet oder gelöst werden konnten, etwa die Ebene der Zeitlichkeit oder auch die Frage, wie man die Neo4J-Graphen dann gut in die eigenen Interfaces integriert (Spoiler: Für Kartendarstellungen gibt es eine Neo4J-eigene App). Vielen Dank auf jeden Fall an Franziska Klemstein für die gute Einführung in Neo4J, vielen Dank an alle Teilnehmer:innen, ich hoffe ihr hattet so eine gute Zeit wie ich und natürlich auch vielen Dank an Yuki und David beim Organisieren.

Für Interessierte gibt es neben der DHd-AG Graphen und Netzwerke noch regelmäßige Events von Neo4J, weiterhin findet in diesem Jahr auch wieder die GraphHNR 2023 statt, die passenderweise Temporalität zum Thema hat. Und ich bin mir auch recht sicher, dass das Thema Graphen auch an der SUB noch nicht abgeschlossen ist. 🙂

Neo4J ist kostenlos nutzbar als Desktop-Anwendung oder zum Ausprobieren in einer Online-Sandbox. Für kommerzielle oder große Anwendungsfälle bietet Neo4J kostenpflichtige Angebote. In der GraphAcademy gibt es für Selbstlerner:innen eine große Menge an Materialien und ergänzend dazu eine gute Dokumentation.

Zu guter Letzt hier noch die wichtigsten Cypher-Snippets:

// Knoten erstellen
// Person = Label
// name, GND = Eigenschaft
CREATE (n:Person {name: 'Ida Dehmel', GND: 'https://...'})
	RETURN n;
				   
// Knoten löschen - Option A
MATCH (n:Person {name: 'Ida Dehmel'})
	DELETE n;

// Knoten löschen - Option B
MATCH (n:Person)
	WHERE ID(n) = 0
	DELETE n;

// Alles anzeigen
MATCH (n)
	RETURN n;

// Eigenschaften und Bezeichnungen ändern
MATCH (n:Person {name: 'Ida Dehmel'})
	SET n.biographical_data = '1870-1942'
	RETURN n;
	  
// Kante erstellen
MATCH (n:Person), (b:Brief)
	WHERE n.name = 'Richard Dehmel'
    AND b.ID = 'HANSb29366'
CREATE (n)-[:verfasste]->(b)

// Kante mit Eigenschaft versehen
MATCH (n:Person {name: 'Richard Dehmel'}), (b:Brief)
	CREATE (n)-[:verfasste {Datum: '09.05.1907'}]->(b)
					
// Knoten mit Kanten löschen
MATCH (n:Brief)
	WHERE ID(n) = 0
	DETACH DELETE n

Ein kurzer Einblick in Graphtechnologien und die Graphentheorie.

Am Dienstag, den 31. Januar 2023 eröffnete Dr. Franziska Klemstein die Veranstaltungsreihe “Digital Humanities – Wie geht das?”, die vom Referat für Digitale Forschungsdienste der Staats- und Universitätsbibliothek Hamburg veranstaltet wird. In einem spannenden Vortrag führte sie in das Thema Graphen ein, welche in den letzten Jahren im Bereich der Digital Humanities zunehmend an Bedeutung gewinnen.

Im ersten Teil des Vortrags ging es um die Theorie, die hinter Graphen steckt. Dabei wurde und wird zwischen den Begriffen Graph und Netzwerk gerade in der geisteswissenschaftlichen Nutzung nicht immer klar unterschieden, beziehen sich doch beide oft beschreibend auf das gleiche oder zumindest wesensähnliche Phänomen: Die semantische Modellierung und Visualisierung von Entitäten und den Beziehungen dieser Entitäten zueinander.

Der Ursprung der Graphentheorie liegt in der Mathematik. Als Beispiel nennt Franziska hier die Eulerkreis- und Traveling Salesman-Probleme. Das Eulerkreis-Problem beschreibt die Frage, wie alle Kanten eines Graphen in einem Zyklus enthalten sein können. Anschaulich wird dies etwa im “Königsberger Brückenproblem”, das fragt, wie alle Brücken in Kaliningrad genau einmal überquert werden können und on man am Ende wieder am Ausgangspunkt ankommt, ohne dass ein Weg zweimal begangen werden muss. Ein anderes Beispiel ist das “Haus vom Nikolaus”. Das Traveling Salesman-Problem beschreibt eine ähnliche Situation: Kaufleute müssen auf ihrer Reise mehrere Orte besuchen. Wie müssten sie reisen, um die kürzeste Route zu befahren, jeden Ort – außer dem Ausgangspunnkt – nur einmal zu besuchen, und am Ende wieder am Ausgangspunkt anzukommen?

Graphentheorie setzt sich also mit Kanten und Knoten auseinander und nimmt diese als Analysemuster für die Beantwortung theoretischer Fragestellungen. Analog dazu werden Graphen in den Digital Humanities genutzt, um etwa Netzwerke von Personen darzustellen, wobei solche Netzwerke als “zentrale Metapher für gesellschaftliches Geschehen” verstanden werden. Hierbei können Knoten etwa für Personen oder Orte stehen, während die Kanten Aussagen über die Beziehungen zwischen den Knoten treffen.

Im zweiten Teil des Vortrags ging es schließlich um die in der Arbeit mit Graphen eingesetzten Technologien. Wer sich schon einmal mit Konzepten wie dem Semantic Web auseinandergesetzt hat, wird schon einmal vom Resource Description Framework (RDF) gehört haben. Es beschreibt Beziehungen zwischen Entitäten in Tripeln, also im Muster Subjekt-Prädikat-Objekt. Dadurch entsteht ein Graph, in dem Entitäten zueinander semantisch in Beziehung gesetzt werden.

<!-- Beispiel eines RDF-Ausdrucks in XML -->

<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns="http://example.org/">
  <Person>
    <hasName>Sascha</hasName>
    <hasSister>
      <Person>
         <hasName>Eike</hasName>
      </Person>
      <Type>younger</Type>
    </belongsTo>
  </Person>
</rdf:RDF>

Ein anderer Ansatz ist der Labelled Property Graph (LPG), in dem die Knoten und Kanten nicht nur Namen, sondern auch Eigenschaften besitzen können. Diese Eigenschaften werden in key/value-Paaren angegeben und sollen eine bessere Übersicht gewährleisten.

// Beispiel desselben Ausdrucks in Cypher 

(p1:Person {name: "Sascha})-[:HAS_SISTER {type: "younger"}]->(p2:Person {name: "Eike"})

Hierfür gibt es verschiedene Technologien und Analysetools, unter anderem Neo4J, Blazegraph, NetworkX oder OrientDB. NetworkX etwa bietet eine Python-Bibliothek, die gerichtete und ungerichtete Graphen darstellen kann, setzt aber natürlich die Kenntnis von Python voraus. Neo4J hingegen bietet ein ganzes Ökosystem, das neben einer Graph-Datenbank samt proprietärer Softwarelösung für die lokale Anwendung auf dem eigenen Computer auch Cloud-Lösungen für kommerzielle Zwecke anbietet. Ein großer Pluspunkt ist dabei sicherlich die Benutzer:innenfreundlichkeit von Neo4J, dem allerdings das kommerzielle Geschäftsmodell entgegensteht. Für eine konsequente OpenScience-Praxis ist Neo4J damit nur bedingt nutzbar, als mächtiges Tool für die Arbeit mit Graphen aber sicherlich nicht zu unterschätzen, zumal von Haus aus auch der Import von Daten-Batches, sowie der Export in verschiedene Dateiformate wie .json und .csv unterstützt wird.

Dazu trägt auch die Query-Sprache von Neo4J bei, Cypher, in der – wie oben bereits gezeigt – ähnlich wie bei SQL mit einfachen und klaren Ausdrücken Graphenstrukturen geschaffen und abgefragt werden können. Folgende Abfrage gibt zum Beispiel alle Schwestern von Sascha aus.

// Ausgabe aller Schwestern der Person mit dem Namen "Sascha"

MATCH (:Person {name: 'Sascha'})-[:HAS_SISTER]->(p:Person)
RETURN p

In einem Beispiel aus dem Datensatz der Brief-Edition von Dehmel Digital wurde schließlich anhand eines kleinen Beispiels demonstriert, wie Neo4J zur Erkennung von Gemeinschaften und Zusammengehörigkeiten in einem Korrespondenznetzwerk genutzt werden kann. Hierbei kommt das Prinzip des Triangle-Count zur Anwendung, bei dem alle Sets von drei Knoten gezählt werden, die untereinander durch Kanten verbunden sind. Daraus resultiert der Clusterkoeffizient, der eine numerische Aussage über die Einbettung bestimmter Knoten in solche Dreier-Sets trifft und damit Aufschluss über die Quantität der Vernetzung von etwa Personen in einem Korrespondenznetzwerk gibt.

Dabei, wie auch in allen anderen Formen datengestützter Arbeit in den Geisteswissenschaften, gibt es natürlich immer zu bedenken, dass dererlei Aussagen immer nur auf der Basis eines kuratierten Datensatzes gemacht werden können: Ist der Datensatz über das Korrespondenznetzwerk nicht vollständig, ist die Aussage über eine solche “Cliquenbildung” nur begrenzt belastbar, bzw. bezieht sich allein auf den untersuchten Datenausschnitt.

Zusammenfassend gab der Vortrag einen guten Überblick über die Potenziale und Grenzen von Graphentechnologien und führte in einige Grundverständnisse und Theorien ein, die bei der Arbeit mit Graphen zugrunde liegen. Dabei wurde als Technologie-Beispiel Neo4J mit einem Beispiel aus der Dehmel-Edition vorgestellt.

Hieran anschließend wird am 27. Februar 2023 an der SUB ein Workshop stattfinden, an dem erste Erfahrungen mit Neo4J anhand von Beispieldatensätzen mit der Dehmel-Edition praktisch gesammelt werden können. Einige wenige Plätze sind noch offen, weitere Informationen gibt es im SUB-Blog.

Wer nicht teilnehmen kann, Neo4J aber trotzdem mal ausprobieren möchte, findet in der Neo4J-eigenen Graph Academy Online-Einführungskurse mit einem Sandbox-Server, auf dem verschiedene Szenarien ausprobiert werden können.

Die Folien des Vortrags wurden via GitHub bereitgetellt.