Normdatenbasierte Erschließung und raum-zeitliche Visualisierung von Quellen der sächsischen Wirtschaftsgeschichte

Von Julius Titz

Im Rahmen meines Masterstudiengangs “Digital Humanities” absolvierte ich von Oktober 2023 bis April 2024 ein Praktikum im Referat Saxonica und Kartensammlung der SLUB. Vom Ablauf und den Ergebnissen des Projekts möchte ich in diesem Blogbeitrag berichten.

Ziel des Praktikums war es, Möglichkeiten für eine Überarbeitung der Onlinepräsentation der Sammlung “Historische Briefköpfe sächsischer Unternehmen” zu entwickeln. Mittelfristig sollen alle Firmen in die “Gemeinsame Normdatei” (GND) der deutschen wissenschaftlichen Bibliotheken eingetragen und die Website, nach Vorbild der Sammlung “Historische Adressbücher”, deutlich interaktiver gestaltet werden, bspw. mit einer Karte, auf der die Standorte der Firmen angezeigt werden. Im Projekt versuchte ich, diesen Prozess modellhaft mit einem Datensatz aus etwa 150 Unternehmen durchzuführen und somit Möglichkeiten und Wege aufzuzeigen sowie Herausforderungen und Stolpersteine zu benennen.

Quellengrundlage des Vorhabens war die Sammlung “Historische Firmenbriefköpfe sächsischer Unternehmen” in der  SLUB, welche eigene Bestände sowie Sammlungen anderer Institutionen wie des Sächsischen Wirtschaftsarchivs und des Industriemuseums Chemnitz online präsentiert. Insgesamt sind dort aktuell 6.762 Briefköpfe von sächsischen Unternehmen, meist aus den ersten beiden Jahrzehnten des 20. Jahrhunderts, digitalisiert. Alle Digitalisate sind auf der Website “Sachsen.digital” recherchierbar. 

Briefkopf der Firma E. C. Flader in Jöhstadt, 1912 (Sächsisches Wirtschaftsarchiv, BK 75, CC BY-SA 4.0)

Firmenbriefköpfe entwickelten sich in der zweiten Hälfte des 19. Jahrhunderts zunehmend zu repräsentativen Aushängeschildern von Unternehmen. Nicht selten wurden Künstler*innen beauftragt, diese zu gestalten. Abgebildet waren oftmals Firmengebäude, Fabriken oder hergestellte Güter. Überstilisiert, bspw. durch veränderte Proportionen, entrückt aus der eigentlichen Umgebung und nicht selten geschmückt mit Medaillen, die es in dieser Form meist gar nicht gab, entwickelten sie sich um 1900 zu regelrechten Kunstwerken und stellen somit eine interessanten Quelle der Wirtschaftsgeschichte dar.

Ein wichtiges Arbeitsmittel des Projekts war die “Gemeinsame Normdatei” (GND). Die GND ist das zentrale Normdatenverzeichnis der deutschen wissenschaftlichen Bibliotheken und bildet als eine Art Infrastruktur einen digitalen Unterbau moderner Bibliotheksarbeit. Normdaten sind hilfreich bei der Katalogisierung, Unterscheidung, Vernetzung und Archivierung von Informationen und Gegenständen. Um davon auch für mein Projekt Gebrauch zu machen, musste ich die zu den Briefköpfen gehörenden Firmen in der GND als neue Entitäten anlegen. Dabei konnte ich auf die Vorarbeit einer studentischen Hilfskraft zurückgreifen, welche bereits die Daten für viele der Firmen zusammengetragen und als Word-Dokumente abgespeichert hatte. Im Detail besteht so ein Datensatz aus dem Namen der Firma, alternativen Namen, der Art des Eintrages (hier meist Körperschaft), dem geografischen Wirkungsbereich, dem Sitz, dem Wirtschaftszweig und wenn vorhanden: Gründung, Auflösung, Vorgänger, Nachfolger, Quellen, Anmerkungen sowie weitere GND-interne Katalogisierungsmarker. Nach Erstellung einer Entität wird ihr eine individuelle und eindeutige GND-Nummer zugeordnet. Als Quellen dienten, neben den Briefkopf-Digitalisaten, Scans von Adressbüchern, Archivinformationen sowie Webseiten noch existierender Unternehmen. Das Erstellen und Bearbeiten der GND-Datensätze wurde mit der Katalogisierungssoftware “WinIBW3” umgesetzt. Letztendlich wurde ein Datenset mit 148 Firmen in der GND neu angelegt oder, wenn die Entität bereits existierte, überarbeitet. Diese Datenobjekte liegen nun dauerhaft in der GND bereit und können auch für andere bibliothekarische Kontexte genutzt werden.  

Faktenblatt zum GND-Datensatz “E. C. Flader (Firma)” im GND-Explorer

Vor allem für verschiedene Visualisierungsmöglichkeiten, aber auch im Sinne des freien Wissenszugangs kann es sinnvoll sein, die Datenobjekte aus der doch recht abgeschlossenen GND in eine offene und kollaborative Datenbank zu exportieren. Hier bietet sich vor allem Wikidata an. Wikidata wird von der Wikimedia Foundation betrieben und ist damit ein Schwesterprojekt u. a. der Wikipedia. Ursprünglich gestartet, um die Informationen der Wikipedia einheitlich auszuzeichnen und zu vernetzen, können dort heute Datenobjekte zu jedweden Themen angelegt werden. Wikidata ist dabei deutlich benutzerfreundlicher als die GND und bietet weitreichende Visualisierungsmöglichkeiten wie Karten, Diagramme oder Netzwerke. Um die in die GND eingetragenen Objekte nach Wikidata zu exportieren, müssen sie zuvor aus der Gemeinsamen Normdatei extrahiert werden. Dafür bietet die GND verschiedene Schnittstellen. Für mein Vorhaben nutzte ich die Search/Retrieve via URL-Schnittstelle (SRU). Mithilfe von Suchindizes und -begriffen kann man hier die GND abfragen und erhält Ergebnisse in einem XML-Format. Unter Zuhilfenahme der SRU-Dokumentation erstellte ich ein Skript, welches die GND nach einer Liste von GND-Nummern abfragt. Mithilfe der Python-Bibliothek “pandas” wird die zurückgegebene XML-Struktur in ein “dataframe” umgewandelt, bearbeitet und schließlich als CSV-Datei gespeichert. Im Ergebnis lagen alle zuvor angelegten Unternehmen mit den für das weitere Vorgehen relevanten Informationen in einer CSV-Datei vor.

Um diese Informationen nun in Wikidata-Einträge umzuwandeln, nutzte ich das quelloffene Datenaufbereitungsprogramm “OpenRefine”. Damit lässt sich die Bereinigung, Bearbeitung und Umwandlung von großen Datenmengen deutlich vereinfachen. Im Aufbau ähnelt OpenRefine Tabellenkalkulationsprogrammen wie Excel, hat aber bezüglich der Datenbearbeitung deutlich mehr Funktionen. Es lassen sich wahlweise ganze Spalten und Zeilen gleichzeitig bearbeiten oder mithilfe von Filtern und Facets nur gezielte Werte auswählen. Zudem können innerhalb weniger Klicks bspw. verschiedene Schreibweisen angeglichen werden. Mittels OpenRefine lassen sich somit Schritt für Schritt die Daten anpassen und etwaige Fehler beheben. Das Hauptargument für die Nutzung von OpenRefine liegt aber darin, dass das Datenschema von Wikibase, also der Software hinter Wikidata, integriert ist. Dadurch ist es ohne großen Aufwand möglich, aus den extrahierten und bereinigten Informationen neue Datenobjekte in Wikidata anzulegen. Dafür mussten zunächst die Werte der CSV-Datei “reconciled” werden. Jeder Wert wird dabei in Wikidata gesucht und, wenn schon vorhanden, verknüpft. Wenn kein Wert zugeordnet werden kann, bestehen die Möglichkeiten, manuell zu suchen oder ein neues Wikidata-Datenobjekt anlegen zu lassen. Im zweiten Schritt müssen die Spalten der OpenRefine-Tabelle den Aussagen in Wikidata zugeordnet und somit die Formate in Einklang gebracht werden. Die Trefferquote von OpenRefine ist dabei erstaunlich hoch. In nur wenigen Fällen musste manuell nachgeholfen werden. Einzig in der Aussage “Wirtschaftszweig” gab es Lücken, da einige Firmen in weniger bekannten Branchen tätig waren und diese noch nicht als Wikidata-Objekte angelegt wurden. Insgesamt lässt sich sagen, dass OpenRefine ein mächtiges und gleichzeitig benutzerfreundliches und komplikationsarmes Tool ist, mit dessen Hilfe ich alle zuvor aus der GND extrahierten Entitäten nach Wikidata exportieren konnte.

Via SPARQL-Abfrage generierte tabellarische Ansicht von Firmendatensätzen aus Wikidata

Mit dem erfolgreichen Export nach Wikidata war die Arbeit an den Datenobjekten aber noch lange nicht erledigt. Zuerst musste ich mich um die Datenobjekte kümmern, die während des Reconciling neu angelegt wurden. Diese beinhalteten zunächst nur den Namen und mit “ist ein(e)” ein einziges Aussage-Wert-Paar und sollten somit um weitere Aussagen angereichert werden. OpenRefine arbeitet zudem auch nicht fehlerfrei und einige Objekte, die in Wikidata bereits existierten, wurden beim Reconciling nicht gefunden, bspw. aufgrund von Schreibfehlern oder anderer Schreibweisen. Demzufolge musste der gesamte Datensatz manuell gesichtet und mögliche Dubletten entweder in Relation gesetzt oder das Datenobjekt umgebaut werden, da es in Wikidata normalerweise nicht vorgesehen ist, Datenobjekte zu löschen.

Im letzten Abschnitt des Projekts galt es, den vollständigen und nun auch funktionalen Datensatz abzufragen und, im Hinblick auf die Überarbeitung der Website, erste Visualisierungen durchzuführen. Dafür verwendete ich den in Wikidata integrierten Abfrageservice mit der Abfragesprache “SPARQL”. Vereinfacht ausgedrückt, lassen sich mittels SPARQL Datenobjekte anhand ihrer Aussagen und Werte abrufen. Dieser Datensatz aus Wikidata-Objekten kann dann auf verschiedene Weise dargestellt werden. Ganz klassisch als Tabelle, aber auch Karten oder Netzwerkgraphen sind denkbar, wenn der Datensatz die dafür notwendigen Informationen bereithält und der SPARQL-Code entsprechend optimiert ist. 

Arbeitet man mit dem Query Service von Wikidata, so werden schnell dessen Stärken, aber auch Probleme offensichtlich. Grundsätzlich ist der Query Service ein mächtiges Tool, das frei zugänglich ist und spannende Visualisierungen ermöglicht, wie andere zahlreiche Beispiele beweisen. Die Dokumentation hinkt dem aber hinterher. Fast schon typisch für die Wikimedia-Dienste gibt es zwar eine Doku und diverse andere Anleitungen. Diese sind aber oft unübersichtlich, für Beginner zu kompliziert oder schwer zu finden. Auch die Ergebnisse von ChatGPT sind, zumindest im Moment, noch nicht zufriedenstellend und Ressourcen Dritter können oft nur eingeschränkt auf den eigenen Fall angewendet werden.

Somit bleibt vor allem das Prinzip “Learning-by-Doing” und sich bei Problemen an die hilfsbereite Community zu wenden. Entsprechend bin ich auch vorgegangen. Zuerst mit einfachen Anfragen, welche den vollständigen Datensatz ausgeben. Da allen Objekten das Aussage-Wert-Paar “beschrieben in” und “Historical letterheads of Saxon companies (database)” zugeordnet wurden, können diese relativ unkompliziert abgefragt werden. Indem weitere Items hinzugefügt werden, entsteht eine vollständige und übersichtliche Tabelle aller Daten. Bezieht man die Koordinaten der “Hauptsitze” mit ein, erscheint der Datensatz zudem visualisiert auf einer Karte.

Darauf aufbauend versuchte ich nun, Schritt für Schritt die Query um weitere Informationen anzureichern. Besonderer Dank geht hierbei an Christian Erlinger von der Universitätsbibliothek Luzern, der mir im Umgang mit SPARQL sehr weitergeholfen hat und mir viele Tipps gab. Dadurch konnte ich einige Fehler bereinigen, wie z. B. dass die Abfrage bei bestimmten Aussagen nur einen Wert ausgab, obwohl mehrere Werte enthalten sind.

Via SPARQL-Abfrage generierte, kartenbasierte Ansicht der Firmendatensätze mit farblicher Gestaltung der unterschiedlichen Branchen (© OpenStreetMap contributors)

Die finale Abfrage gibt nun alle für das Projekt relevanten Informationen aus. Zudem wurden mithilfe des SPARQL-Codes weitere Spalten mit Informationen erstellt, die nicht unmittelbar aus den Datenobjekten hervorgehen, wie die Darstellung der Jahrzehnte aus der Aussage “Zeitpunkt/Stand”. Auch die Visualisierung auf der geografischen Karte konnte verbessert werden, indem den jeweiligen Jahrzehnten Farben zugeordnet werden. Diese Layer sind auch für andere Aussagen, wie z. B. Wirtschaftszweige sinnvoll und möglich. Aufgrund von Zweigstellen, Vorgängern, Nachfolgern und Firmen, die bereits vor Projektbeginn in Wikidata existierten, ist der Datensatz mittlerweile auf 194 Einträge angewachsen.

Auch wenn das Praktikumsprojekt an dieser Stelle sein vorläufiges Ende findet, gibt es am Datensatz und der Abfrage noch viel Optimierungspotenzial. Zum einen können die Datenobjekte noch mit vielen weiteren Informationen angereichert und auch die Datenstruktur verbessert werden. Im Laufe der Arbeit stellte sich z. B. heraus, dass die Aussage “point in time” zu unpräzise ist und durch “Datum der Gründung…” bzw. “Datum der Auflösung…” ersetzt werden sollte. Zudem sind die Datenobjekte bisher nur in deutscher Sprache bezeichnet und beschrieben. Sucht man sie in anderen Sprachen, erscheinen nur die Q-Nummern statt der Titel. 

Ebenso lässt sich die Abfrage weiter verbessern und deutlich komplexer gestalten. Denkbar sind hier etwa weitere Layer und Filter auf der Karte oder eine netzwerkartige Darstellung zwischen den Vorgängern, Nachfolgern und Zweigstellen der Firmen. Im Hinblick auf die Überarbeitung der Sammlungswebsite könnte es ebenso von Interesse sein, die Digitalisate in den Wikidata-Objekten zu verlinken oder, wenn dies die Rechte ermöglichen, sie direkt in Wikimedia Commons hochzuladen. 

Abschließend lässt sich sagen, dass sich Wikidata sehr gut für dieses Projekt eignet. Die Vorteile dieser schon ausgereiften und sehr professionellen Datenbank liegen auf der Hand. Das Anlegen von Entitäten als auch in der Visualisierung des Datensets, lässt sich, trotz der oben beschriebenen Herausforderungen, verhältnismäßig einfach und niedrigschwellig umsetzen, vor allem wenn man es damit vergleicht, eigene Lösungen programmieren zu müssen. Das volle Potenzial von Wikidata kann aber insbesondere dann ausgeschöpft werden, wenn man damit kollaborativ arbeitet. Im Vergleich zu anderen Datenbanken, wie der GND, oder auch selbst entwickelten Lösungen kann man hier unkompliziert das Datenset gemeinsam erweitern und die Datenqualität verbessern.

Datenabfragen:

• einfache Liste: https://w.wiki/ANui
• Wirtschaftszweig als Layer: https://w.wiki/ANuk
• vollständige Abfrage + mit Angabe des Jahrzehnts der Firmengründung als Layer: https://w.wiki/9sYY

Autor

Julius Titz studiert Digital Humanities an der TU Dresden und arbeitet parallel als Werkstudent beim Sandstein Verlag. Im Bachelor studierte er Geschichte mit den Nebenfächern Politikwissenschaft und Soziologie.