Heinke Schumacher

Die auf dieser Seite präsentierten Netzwerkgraphen sind im Rahmen einer Projektarbeit des Zertifikatskurses Data Librarian 2021/22 am Zentrum für Bibliotheks-und Informationswissenschaftliche Weiterbildung der TH Köln entstanden. Ziel der Projektarbeit war es, mit Personendaten der Hamburg-Bibliographie, die in der Staats- und Universitätsbibliothek Hamburg Carl von Ossietzky erstellt wird, familiäre Strukturen in einem Netzwerkgraphen sichtbar zu machen, der mit der Python-Library Pyvis erstellt wird. Zusätzlich zu diesem Ansatz werden auch Relationen zwischen Personen und Berufen dargestellt. Die Ergebnisse lassen sich besser im Zusammenhang mit der Ausarbeitung und den Skripten verstehen, die dazu entstanden und auf diesem Repository einzusehen sind. Beim Aufrufen der Graphen können zum Teil hohe Ladezeiten entstehen, da in einigen Fällen große Datenmengen zugrunde liegen. Im Folgenden sind die Visualisierungen mit den Erläuterungen der Projektausarbeitung versehen:

Bezeichnung Erläuterung
graph#1 Datenpool: relation_fam; layout-algorithm: repulsion; node-distance: -259; smooth=False; hamburg-node; random hex-colors. - Der erste Graph zeigt verwandtschaftliche Zusammenhänge. Diese werden durch die Farbgebung unterstützt. Die Generierung der zufälligen Hex-Colors für die Nodes wird durch die abhängige Iteration an die Verwandten weitergegeben (Ausnahmen begründen falsche Originaldaten). Ebenso sind die Nodes durch die Visualisierung der Edges von dem Hamburg-Node (vgl. Ausarbeitungstext sowie Anhang 1) zu den Familien gruppiert. Besonders macht diese Visualisierung der hohe Node-Abstand aus, definiert im Layout-Algorithmus “repulsion” und in abstossendem Zusammenhang mit dem Node-Abstandswert, der die Nodes mit Hilfe von geraden Edges weiträumig gruppiert.
graph#2 Datenpool: relation_fam; layout-algorithm: repulsion; central-gravity=1.1. - Die zweite Visualisierung zeigt einen Graphen, der ohne die Verbindung von Edges mit dem Hamburg-Node von einzelnen Familiensubnetzen geprägt ist und durch “weiche” Edges einen schwungvollen Charakter erhält. Die Nodes sind dabei durch einen leicht erhöhten Wert der central_gravity als Argument der Algorithmusfunktion “repulsion” in die Mitte gezogen. Die farbliche Dualität spiegelt Nodes mit und ohne “title”-Information wieder.
graph#3 Datenpool: job; layout-algorithm: repulsion. LANGE LADEZEIT! Hier werden die Beziehungen zwischen Personen und Berufen dargestellt. Es sind die Default-Einstellungen des Algorithmus “repulsion” gewählt, der farbliche Unterschied der Nodes scheidet in Personen und Berufe. Es werden bei diesem Graphen andere Netzstrukturen generiert werden, als bei den Graphen mit einzelnen Subnetzen der Familien, die untereinander nicht verknüpft sind, da alle Teilnehmer theoretisch mit allen Berufen verknüpft sein können.
graph#4 Datenpool: job; layout-algorithm: force_atlas_2based; gravity=-10. LANGE LADEZEIT! Auch hier sind wieder Berufsbeziehungen dargestellt. Der Layoutalgorithmus “force_atlas_2based” in Kombination mit einem leicht niedrigeren Gravity-Wert als per Default vorgegeben bewirkt hier eine stärkere Anziehung, was den zusammengeballten Eindruck entstehen läßt. Der gravity-Faktor ist bei diesem Layoutalgoritmus zentral “[…] the central gravity model, which is here distance independent, and the repulsion being linear. […]” (Pyvis 2022b).
graph#5 Datenpool: relation_fam; layout-algorithm: repulsion; central_gravity=1.1; smooth=False. Wie stark visuelle Eindrücke durch nur kleine Veränderungen differieren können, zeigt der Graph #5 im Vergleich zu Graph #2. Allein durch die Veränderung der Edges zu geraden Linien entsteht individuell gefühlt ein völlig anderer Graph.
graph#6 Datenpool: relation_fam; layout-algorithm: force_atlas_2based; spring_length=-10; overlap=0; spring_strength=0.099; smooth=False; hamburg-node, random hex-colors. Ein gänzlich anderer Ansatz zeigt Graph #6. Er ist einerseits wieder bestimmt durch strahlenförmig auskragende Edges durch die Verbindung mit dem Hamburg-Node bei den Familienrelationen. Die Edges werden hier aber durch den hohen negativen Wert der spring_length (wie lang die Edges auseinander “federn/schnellen”) im Vergleich zur default-Einstellung bestimmt sowie besonders durch den Null-overlap-Wert, der die höchste Überlappungsstufe der Nodes bedeutet, was den zusammengezogenen Eindruck der Nodes auf einer Linie bewirkt.

Die nächsten drei Visualisierungen zeigen Varianten, die - will man die Informationen, die in den Daten des Netzwerkgraphen enthalten sind, transportieren - trotz aller Interaktivität der Software dazu nicht so geeignet sind. Zwar können visuell interessante Eindrücke entstehen, aber will man Zusammenhänge oder Node-Labels erkennen, mögen diese Varianten nicht sehr hilfreich sein.

Bezeichnung Erläuterung
graph#7 Datenpool: relation_fam; layout-algorithm: hrepulsion. LANGE LADEZEIT! In diesem Graphen werden Familiensubnetze dargestellt, unverbunden mit dem Hamburg-Node. Er ist mit den Default-Einstellungen des Layoutalgorithmus “hrepulsion” erstellt. Dieser Algorithmus ist grundsätzlich schwierig, will man Label-Text lesen können, da sehr stark in den Graphen gezoomt werden muss, bis die Labels lesbar sind. Der Algorithmus basiert ausserdem auf Abstossung der Nodes. Diese funktioniert besser, je mehr Nodes ein Netz hat. Durch die Nutzung des Datenpools, der auch Familienbeziehungen mit nur einem Verwandeten beinhaltet, entstehen “Zweiernetze”, deren Nodes dadurch, hier begünstigt durch die Werte von spring_length und spring_strength, übereinandergelagert werden. Auch nicht komfortabel für eine Nutzung.
graph#8 Datenpool: relation_fam; layout-algorithm: force_atlas_2based; spring_length=220; central_gravity=0.05; overlap=1. Hier wird die Unpraktikabilität durch die Unseparierbarkeit der einzelnen Familienubnetze bedingt. Auch hier sind Familienbeziehungen ohne Verbindung zum Hamburg-Node dargestellt. Der Zug der einzelnen Subnetze zum Graphmittelpunkt, will man sie aus dem Konglomerat herausziehen, um zu erkennen, welche Personen dazu gehören, ist so stark, dass dieses Separieren per Drag nicht optimal funktioniert.
graph#9 data-pool: relation_fam; layout-algorithm: barnes_hut; hamburg-node. Dieser Graph wurde auf Grundlage der Verbindung der Familiennetze mit dem Hamburg-Node mittels den Default-Einstellungen des Layoutalgorithmus “barnesHut” erstellt. Auch hier entsteht eine hübsch anzusehende Sonne mit ihren sich leicht bewegenden Planeten, aber auch hier ist der Zoom-Faktor so groß, dass - ist die Information erst einmal erreicht - sie nicht mehr visuell in den Beziehungszusammenhang gebracht werden kann, ohne wieder zurück zoomen zu müssen.