Zusammenfassung
Die Bibliographia Cartographica ist seit fast 50 Jahren eine wichtige Recherchequelle der internationalen kartographischen Fachcommunity. Ursprünglich als Druckausgabe veröffentlicht und dann in eine Datenbank migriert, muss sie aktuell, funktional und erweiterbar bleiben. Aus diesem Grund wurden ihre Daten aus veralteten Datenbankstrukturen in den Verbundkatalog des GBV migriert. Der Artikel beschreibt Herausforderungen und Arbeitsschritte dieses Migrationsprojekts, in dessen Mittelpunkt das Werkzeug OpenRefine stand. Weiterhin werden alle dafür verwendeten Tools vorgestellt und das erforderliche Mapping der Daten ins PICA-Format beschrieben.
Abstract
The Bibliographia Cartographica has been a major search resource for specialists and professionals in the cartographic community across the globe for the last 50 years. Originally a print edition, it has been migrated to a database, which must be functional, extendable and permanently updated. The data have seen a migration from rather outdated database structures to the GBV union catalogue. The paper describes the challenges and procedures of this migration project in which OpenRefine was instrumental. We introduce tools that were used and describe the process of mapping the data in PICA format.
1 Was ist die Bibliographia Cartographica?
Die Bibliographia Cartographica (BC)[1] ist eine internationale Fachbibliographie für Kartographie, Geschichte der Kartographie und Geoinformation. Sie wird seit 1974 von der Kartenabteilung der Staatsbibliothek zu Berlin herausgegeben und enthält bibliographische Angaben zu Monographien, Zeitschriften und Aufsätzen aus aller Welt in vielen unterschiedlichen Sprachen.
Als Fortsetzung der von 1957–1972 erschienenen Bibliotheca Cartographica wurde die BC einmal jährlich in gedruckten Bänden im K.G. Saur Verlag (Heute: De Gruyter Saur) verlegt. Seit 1989 wurden die Druckdaten mit der Bibliothekssoftware Allegro aufgenommen und verwaltet. Ab 2003 wurden die Datensätze der BC in eine MySQL-Datenbank mit einer in PHP programmierten Oberfläche migriert und 2007 der Öffentlichkeit in elektronischer Form zugänglich gemacht. In diesem System hatte die BC eigene Erfassungsregeln und ein eigenes System der Sacherschließung, das den Nutzer*innen die fachspezifische Suche erleichterte.
Auch heute wird die BC stetig erweitert. Bei einem Zuwachs von jährlich 1.500 wissenschaftlichen Publikationen wertet die Redaktion fortlaufend ca. 180 kartographische Fachzeitschriften aus. Mittlerweile enthält die BC über 62.000 nachgewiesene Titel, darunter zunehmend auch online frei zugängliche Publikationen.
Die ursprüngliche MySQL-Datenbank wies aufgrund der bei der Konzeption nicht bedachten fehlenden Normalisierung[2] Probleme auf, und die seit 2007 genutzte PHP-Anwendung war nach 12 Jahren veraltet, sodass sie nicht mehr gemäß aktuellen Sicherheitserfordernissen upgedatet werden konnte. Es wäre eine komplette Neuimplementierung notwendig gewesen. Aus diesen Gründen wurde eine technische Alternative gesucht. Als Lösung wurde eine Migration der Daten ins PICA-Format und damit in den Verbundkatalog des GBV und des SWB (K10plus) beschlossen. Als Vorbild galten hierbei diverse andere Fachdatenbanken, die ebenfalls PICA-basiert vom Bibliotheksverbund GBV gehostet werden, z. B. die Leibniz-Bibliographie[3].
Die Vorteile für die BC lagen auf der Hand:
Mitnutzung der bestehenden Infrastruktur durch den K10plus (dazu zählen z. B. zentraler Support, Updates, künftige Migrationen und Datenmanagement),
Verwendung eines bestehenden Regelwerks, ggf. automatisierte zentrale Datenanpassungen,
Nachträgliche Anreicherung der Daten im Verbund, z. B. durch Normdaten,
Nachnutzung der von anderen teilnehmenden Verbund-Bibliotheken erfassten bibliographischen Datensätze,
einfachere Abbildung bisher nicht erfasster Publikationsformen (Weblogs o. ä.),
verbesserte Recherche-Ergebnisse durch Nachnutzung von zusätzlichen Sacherschließungselementen aus kooperativer Sacherschließung oder Fremddateneinspielung,
einfaches Abrufen und Weiterverarbeiten der Daten über bereits vorhandene definierte Schnittstellen (z. B. SRU),
Export der bibliographischen Daten durch Nutzende in Literaturverwaltungsprogrammen (z. B. Citavi oder EndNote).
Einige Zeitschriften im alten Frontend der BC.
2 Ablauf der Migration
2.1 Planung und Beteiligte
Im Sommer 2019 begann an der Staatsbibliothek zu Berlin die Planung der Migration der Bibliographia Cartographica unter Beteiligung der Kartenabteilung[4], sowie der Abteilung Informations- und Datenmanagement[5] und dem Metadatenbeauftragten der Staatsbibliothek[6]. Zuerst wurden die Daten der BC in mehreren OpenRefine-Projekten hinterlegt[7], damit sie in ihrem ursprünglichen Zustand gesichtet und analysiert werden konnten. Dadurch konnte in Erfahrung gebracht werden, welche Transformationen nötig waren, um die Daten im K10plus als valide Datensätze zu integrieren. Auch zuvor hatte die Kartenabteilung das Tool OpenRefine bereits genutzt, um im MySQL-System mögliche Fehler in den Datensätzen identifizieren zu können. Es gab also bereits einige wenige Erfahrungen mit dieser Software. Entsprechende Korrekturen wurden jedoch vorerst noch in der Bearbeitungsmaske des bisherigen Erfassungssystems vorgenommen.
Die Erfassungsmaske der alten BC.
Im Januar 2020 begann die direkte Arbeit in OpenRefine[8]. Vollständig migriert waren die Daten im Verbundkatalog des GBV im November 2021.
2.2 Verwendete Tools
Für die Arbeitsplanung und Abstimmung unter den Projektbeteiligten wurde die Projektmanagement-Software Redmine[9] verwendet. Redmine ermöglicht eine sehr individuelle Projektorganisation über ein Ticketsystem und konnte dem Migrationsprozess optimal angepasst werden.
Ticketzuweisung in Redmine.
Der erste Schritt für die Migration war ein Mapping der Daten. Es wurde jeweils eine Beschreibung des Ausgangs- und des Endzustands erstellt, also die Benennung des Datenfeldes in der BC und seiner jeweiligen Entsprechung als PICA-Kategorie. Dies wurde zunächst im Tabellentool Excel begonnen, doch durch den wachsenden Umfang des Projektes wurde das Mapping bald nach Redmine übertragen. Eine Übersichtstabelle aller zu bearbeitenden Felder erlaubte es, den Überblick über den komplexen Migrationsprozess zu behalten.
Zu den notwendigen Bearbeitungsschritten des jeweiligen Feldes wurden wiederum einzelne Redmine-Tickets erstellt und in der Übersichtstabelle verlinkt. So konnte eine präzise Übersicht über die einzelnen Vorgehensschritte dargestellt und abgearbeitet werden.
Auszug aus der Übersicht über die zu bearbeitenden Felder.
Zur Bereinigung und Umwandlung der Daten kam erneut OpenRefine zum Einsatz. Der große Vorteil von OpenRefine bei der Bearbeitung von großen Datenmengen ist eine graphische Benutzeroberfläche, die alle Daten in einer Tabelle anzeigt. So können alle Arbeitsschritte sofort an den Daten nachvollzogen und überprüft sowie Fehler erkannt und behoben werden. Des weiteren ermöglicht OpenRefine auch Personen mit wenig Programmiererfahrung die Bearbeitung der Daten, da viele Funktionen im System vorgegeben sind und leicht angewendet werden können.
Für komplexere Umwandlungen sollten dennoch grundlegende Kenntnisse in imperativer oder funktionaler Programmierung vorhanden sein, wobei die für OpenRefine wichtigste DSL (Domain-specific Language) GREL an Python angelehnt ist. Das dafür nötige Programmierungs-Know-how eignete sich das Projektteam im Migrationsprozess selbst an (die Lernkurve war enorm). Da OpenRefine auch in der Bibliothekswelt immer beliebter wird, gibt es hierzu einige Anleitungen online (z. B. LibraryCarpentry[10] hat sich dabei als sehr nützlich erwiesen), die sich speziell an die Datenbearbeitung in Bibliotheken richten.
Während der Bearbeitung wurden alle zur Umwandlung der BC-Daten ins PICA-Format nötigen Arbeitsschritte in GitLab dokumentiert[11]. Praktischerweise bietet OpenRefine zudem die Möglichkeit, sämtliche vorgenommenen Transformationen aus OpenRefine im JSON-Format zu extrahieren, sodass auch diese in GitLab gesichert werden konnten. Dieses Vorgehen bietet zum einen die Möglichkeit der Wiederverwendung der Arbeitsschritte bei ähnlichen Projekten und erleichtert zudem eine nachträgliche Fehlerbehebung. Fehler können einfach nachvollzogen und rückgängig gemacht werden, ohne dass alle folgenden Schritte erneut ausgeführt werden müssen.
Ein Redmine-Ticket, in dem das Vorgehen beim Typ des Eintrags beschrieben wird.
2.3 Arbeitsschritte in OpenRefine
Nachdem die Daten der BC analysiert und auf die entsprechenden K10plus-Felder gemappt worden waren, begann die Bearbeitung der einzelnen Tabellenspalten mittels OpenRefine. Dazu wurde jeweils eine Kopie der Original-Spalte angelegt, um Fehler sofort erkennen zu können. Diese kopierte Spalte bekam, wenn möglich, sofort die Nummer der Ziel-PICA-Kategorie als Benennung. Dann wurden zunächst einfache Bearbeitungsschritte vorgenommen (dazu zählte z. B. das Entfernen überflüssiger Spatien). Dies half den Bearbeiterinnen, zunächst die Struktur der Daten kennenzulernen, bevor komplexere Schritte mithilfe von GREL vorgenommen werden konnten.
Voreingestellte Bearbeitungsschritte in OpenRefine.
Anleitung für einen Schritt der Bearbeitung in GitLab, mit JSON-Datei der Änderungsschritte.
Danach fand die detaillierte Bearbeitung der Daten statt. Häufig vorkommende Bearbeitungsschritte waren u. a.:
Dateien aus weiteren Tabellen integrieren: Da es sich bei der ursprünglichen BC um eine relationale Datenbank handelte, die aus mehreren Tabellen bestand, mussten diese für die Migration in den K10plus in eine einzige Tabelle zusammengefasst werden. So befanden sich z. B. die Körperschaften, Band / Jahrgang und die Systematik in unterschiedlichen Tabellen. OpenRefine bietet die Möglichkeit, mithilfe der Funktion „cell.cross()“ Daten aus unterschiedlichen Tabellen über einen gemeinsamen Identifier zusammenzufügen und am Ende nur eine Tabelle mit allen Daten zu erhalten.
Clusterfunktion: In einigen Fällen, wie z. B. dem Sprachen-Feld, mussten die vorhandenen Daten einem neuen Standard (in diesem Fall ISO-Norm 639-2/B) angeglichen werden. Dies passierte mit der Clusterfunktion von OpenRefine, welche automatisiert ähnliche Daten zusammenfasst und als Vorschlag eine zu validierende angeglichene Zelle ausgibt.
Splitten / Verbinden: Zellen wurden auf mehrere Zeilen oder Spalten aufgeteilt. In anderen Fällen mussten mehrere Spalten in eine Zelle zusammengefügt werden.
Ersetzen: Des Weiteren mussten die bereits vorhandenen Satzzeichen durch die PICA-eigenen Indikatoren für Unterfelder ($a, $n usw.) ersetzt werden und neue Spalten für die Anreicherung der Daten durch RDA-konforme Felder (z. B. die IMD-Typen in den PICA-Kategorien 0501, 0502, 0503) erstellt werden.
Das Ziel all dieser Bearbeitungsprozesse war, aus der Datenmenge in OpenRefine eine Datei im txt-Format zu extrahieren. Diese Datei sollte fortlaufend alle BC-Datensätze in PICA-Format enthalten, um in den Verbundkatalog eingespielt werden zu können. Dafür bietet OpenRefine praktische Export-Funktionen. Das BC-Team hat die Templating-Funktion genutzt, um die bearbeiteten Daten in der gewünschten Form zu extrahieren. So konnte die txt-Datei kleingehalten und aufs Wesentliche reduziert werden.
Sämtliche leere PICA-Felder wurden mit „null“ gefüllt, um sie nach dem Export leicht durch Regular Expressions[12] in einem Text-Editor entfernen zu können. Die Datei, die dieser Prozess produzierte, konnte schließlich per E-Mail an die Verbundzentrale des GBV zur Einspielung übersandt werden.
Templating in OpenRefine, um BC-Daten zu extrahieren.
2.4 Kooperationen und Zwischenlösungen
Bei allen Schritten des Projektverlaufes gab es eine rege und wertvolle abteilungsübergreifende Zusammenarbeit an der Staatsbibliothek. Gemeinsam mit der Abteilung Bestandsentwicklung[13] und Metadaten wurden die zukünftige Struktur der BC-Daten erarbeitet und Fachfragen zur Katalogisierung und zum PICA-Regelwerk geklärt. Bei technischen Fragen war die Abteilung Informations- und Datenmanagement eine große Unterstützung. Besonders hervorzuheben ist hierbei, dass mitunter neue Lösungen originär für die BC programmiert wurden, z. B. ein Tool, das bei der Übersetzung zwischen den Datenformaten PICA3 und PICA+ behilflich ist (s. u.). Ergänzende Hilfe kam aus der SBB-internen Arbeitsgruppe Metadatenmanagement[14]. In dieser Gruppe fanden regelmäßige Treffen statt, in denen Kontakte unter Kolleg*innen geknüpft werden konnten und wertvolles Know-How ausgetauscht wurde.
Im gesamten Migrationsprozess war die Verbundzentrale des GBV (VZG) in Göttingen eine wichtige Ansprechpartnerin für das Team der Kartenabteilung. Von der VZG kamen die exakten Vorgaben, in welcher Form die BC-Daten geliefert werden mussten, um maschinell in den Verbundkatalog eingespielt werden zu können. Abweichend vom ursprünglichen geplanten Mapping der BC-Daten in PICA3 verlangte die VZG die Daten im internen Format PICA+. Hierfür kam das bereits erwähnte, eigens in der SBB programmierte Transformationstool zum Einsatz.
Auszug aus der txt-Datei, die an die VZG geschickt wurde.
Im Dialog mit der VZG wurden außerdem gesonderte PICA-Kategorien und Abrufkennzeichen festgelegt, über welche der Zugriff des nunmehr öffentlich zugänglichen BC-Frontends auf die Datensätze erfolgt. Hierfür wurde gemeinsam eine Struktur für BC-eigene Exemplarsätze entwickelt, in denen auch die Sacherschließung der Bibliographie verzeichnet wird.
Durch wiederholte Einspielungen von Datenproben in eine Testumgebung des GBV konnten nach und nach weitere Fehlerquellen in den Daten entdeckt und behoben werden. Auch die Dublettenbereinigung erfolgte in mehreren Durchläufen durch die VZG.
Absprachen erfolgten darüber hinaus mit der ZDB, da auch Zeitschriftentitel Bestandteil der BC sind. Hierfür wurde gemeinsam mit dem GBV eine SBB-interne Lösung entwickelt, durch die die ZDB sich nicht an der praktischen Ausführung der Migration beteiligen musste. Die Zeitschrifteneinträge der BC wurden außerdem durch den Fachreferenten für Geographie der SBB[15] auf eine Auswahl kartographisch relevanter Kernzeitschriften gekürzt.
Eine Titelaufnahme in der WinIBW. Ab E001 folgt der BC-Exemplarsatz.
Um den Service für die BC-Benutzer*innen während der Migrationsphase aufrecht zu erhalten, wurde als Interimslösung die sogenannte „Übergangs-BC“ eingerichtet. Diese Webseite hat die Grundfunktionen der BC für die Nutzer*innen zugänglich gemacht, während hinter den Kulissen an den Daten selbst gearbeitet wurde. Auch für die Übergangs-BC wurden einige Anpassungen an den Daten in OpenRefine vorgenommen.
2.5 Herausforderungen im Migrationsprozess
Das Mapping der zwei verschiedenen Generationen von BC-Daten (aus der Zeit in der Allegro-Datenbank und aus der späteren MySQL-Datenbank) ins PICA-Format stellte das Projektteam vor einige Herausforderungen. Eine Schwierigkeit war z. B. die hierarchische Gliederung der Daten: Die „alten“ BC-Daten wichen völlig ab von der gängigen bibliothekarischen Lösung im GBV. Hier mussten also Tausende von Datensätzen mittels OpenRefine in mehreren Arbeitsschritten umgebaut werden. Weiterhin wurden Daten strukturell vereinheitlicht, um z. B. Angaben zu den Seitenzahlen aus sehr verschiedenen Formaten (p. 3–8, 5 S., 13p, 12 Seiten, etc.) in mehreren Schritten an die neue PICA-gerechte Form (z. B.: 4070 Seite 3–8; 4060 5 Seiten, etc.) anzupassen. Bei über 62.000 Datensätzen war die händische Bearbeitung nicht sinnvoll, also wurden jeweils alle Titel auf einmal mithilfe von Regular Expressions bearbeitet. Es musste also darauf geachtet werden, dass alle möglichen Formate gleichzeitig bedacht und transformiert wurden, es war also ein äußerst komplexes Vorgehen.
Die Webseite der Übergangs-BC.
Dazu kam, dass manche Informationen, die in der BC in einem Feld und somit in OpenRefine in einer Spalte standen, je nach bibliographischer Gattung des Titels auf verschiedene PICA-Felder aufgeteilt werden mussten.
Auch auf Seiten der ursprünglichen MySQL-Datenbank gab es Probleme, da diese auf einer Druckdatenbank basierte. So gab es z. B. mehrere Tabellen für die Band-, Jahrgang- und Heft-Angaben, die in den Werken unterschiedlich (und manchmal doppelt) befüllt wurden. Hier mussten die Daten zunächst genau analysiert und mit der Anzeige der BC verglichen werden, bevor sie in die entsprechenden PICA-Felder transformiert werden konnten.
Ein weiteres Problem war, dass die BC-Daten einige Inkonsistenzen aufwiesen, die entstanden sind, da über lange Zeiträume viele verschiedene Personen (hauptsächlich ohne bibliothekarisches Fachwissen) die BC-internen Erfassungsregeln mitunter sehr unterschiedlich ausgelegt hatten. Dadurch entstand mit den Jahren eine recht heterogene Datenqualität.
Zur Versinnbildlichung ein Beispiel: In der Allegro-Datenbank der BC gab es das Feld „Bemerkungen“. Dieses wurde auf verschiedenste Weise befüllt, z. B. mit Reihentiteln oder Kollationsvermerken. Auch weitere Ungenauigkeiten wurden teilweise in Kleinarbeit bereinigt, z. B. als Elektronische Ressource gekennzeichnete Datensätze, die jedoch eindeutig gedruckte Werke waren oder unlogische hierarchische Verknüpfungen wie Aufsätze, die an Reihendatensätzen hingen.
3 Ergebnis und Ausblick
Im November 2021 wurden der Dublettenabgleich und die Korrektur der Titel abgeschlossen, die BC war damit also komplett fertig migriert. Ihre Daten sind nun im K10plus recherchierbar, werden aber wie geplant nicht im StabiKat (und natürlich auch nicht in anderen Katalogen von Verbundteilnehmern) angezeigt, da kein Bestand suggeriert werden soll, der nicht existiert.
Die weitere Erfassung von BC-Daten erfolgt nun im K10plus. Diese ist nicht ganz RDA-konform, jedoch stark daran angelehnt. Die entsprechenden Richtlinien dazu wurden in der Kartenabteilung erstellt. Anschließend können die Titelaufnahmen der BC im Verbund weiter genutzt und gegebenenfalls hochkatalogisiert werden.
Die BC hat nun seit Juni 2022 wieder ihren eigenen neuen Online-Auftritt[16]. Das Frontend, das die BC-Daten abruft und darstellt, wurde von der Verbundzentrale des GBV (VZG) erstellt. Es ist eine Lösung, die mit den Web-Auftritten von vielen anderen Bibliotheken kompatibel ist und das einheitliche VZG-Design aufweist. Das neue Frontend hat noch nicht alle Funktionalitäten, die die BC besonders machen, aber es wird weiterentwickelt, um es noch praktischer für die Nutzer*innen zu gestalten. Die neue Webseite der BC ist inzwischen live und macht nun wieder über 62.000 kartographische Titel aus aller Welt der Öffentlichkeit zugänglich.
Die Kartenabteilung arbeitet auch mit weiteren Mitteln an der Ausweitung der Daten, die der BC hinzugefügt werden: Aktuell ist ein Projekt in Arbeit, bei dem per OCR (maschinelle Texterkennung) die bisher nur gedruckt vorliegenden Bände der BC (Bibliotheca Cartographica 1954–1973 und Bibliographia Cartographica 1974–1989) digitalisiert werden. Auch diese Bände, die ca. 61.000 Titel enthalten, werden in den K10plus integriert werden. Dazu wird der hier erarbeitete Prozess nachgenutzt.
Das Know-how, das bei der Migration der BC-Daten in der Kartenabteilung und in der Staatsbibliothek erworben wurde, ist auch für zukünftige Projekte nützlich: Aktuell plant die Kartenabteilung ein Projekt, das die GeoPhoKa (Literaturdatenbank GEOdäsie, PHOtogrammetrie, KArtographie, ca. 65.000 Titel von 1984–2005) ebenso in den K10plus migrieren soll. Die Herausgeberin, das Bundesamt für Kartographie und Geodäsie, hat die Rohdaten dazu bereits zur Verfügung gestellt. Auch hierbei werden die Erfahrungen aus dem erfolgreichen Prozess der BC-Migration helfen, diese Daten den Nutzer*innen wieder zugänglich zu machen.
Ein weiteres aktuelles Projekt in der Staatsbibliothek, das sich das Angleichen von WorldCat-Werkdaten zu E.T.A. Hoffmann[17] zum Ziel gesetzt hatte, verwendete das Werkzeug OpenRefine. Diese wurden im Anschluss in den Geo-Browser | DARIAH eingespielt und werden dort angezeigt. Das Ziel war eine Rezeptionsanalyse der Werke, die nun anhand von Orten oder Zeiträumen sortiert und angezeigt werden können. Hier wurde zusätzlich auf die Reconcile-Funktion von OpenRefine zurückgegriffen, die es ermöglicht, auf Schnittstellen (z. B. WikiData, GND) zuzugreifen und die Daten so anzureichern. So konnten die WorldCat-Daten um Koordinaten und Länder erweitert werden.
Das Projekt BC-Migration hat 62.000 kartographische Titel in den K10plus-Verbundkatalog überführt und somit auch einem neuen Kreis an Nutzer*innen zugänglich gemacht. Darüber hinaus werden die in dem Projekt mit viel Neugier und großer Experimentierfreude erworbenen Kenntnisse und Erfahrungen auch in anderen Projekten der SBB nachgenutzt und an Kolleg*innen weitergegeben.
Wenn auch Sie ein Migrationsprojekt planen oder durchführen, würden wir uns freuen, wenn wir uns vernetzen und austauschen können.
About the authors
Franziska Engelhardt
Nicole Freitag
Miriam Wildermuth
4 Weitere Informationen
Klute, Ursula: ETL-Prozesse für Bibliothekarische Metadaten – die Migration lokaler Katalogisate im GBV. Wildau 2018, https://opus4.kobv.de/opus4-th-wildau/frontdoor/deliver/index/docId/1227/file/Klute_Thesis_ETL-Prozesse_final.pdf [Zugriff: 02.11.2022].Search in Google Scholar
Diedrichs, Reiner: Metas Daten in der VZG – eine Übersicht. 26. Verbundkonferenz des GBV, Halle (Saale), 24. September 2022, https://verbundkonferenz.gbv.de/wp-content/uploads/2022/08/VK26_2022_FAGEI_Metas_Daten_in_der_VZG.pdf [Zugriff: 02.11.2022].Search in Google Scholar
Seidlmayer, Eva; Müller, Rabea; Förstner, Konrad U.: Data Literacy for Libraries – A Local Perspective on Library Carpentry. In: Bibliothek – Forschung und Praxis 44 (2020), S. 485–489, http://dx.doi.org/10.18452/22009.10.1515/bfp-2020-2038Search in Google Scholar
Jevon, Graham: Clean. Migrate. Validate. Enhance. Processing Archival Metadata with Open Refine. 21.04.2020, https://blogs.bl.uk/digital-scholarship/2020/04/clean-migrate-validate-enhance-processing-archival-metadata-with-open-refine.html [Zugriff: 02.11.2022].Search in Google Scholar
Wittwer, Barbara: Von NEBIS bis SLSP – Wie die Datenmigration des größten Schweizer Verbundes umgesetzt wurde. In: O-Bib – Das offene Bibliotheksjournal 8.3 (2021), S. 1–15, https://doi.org/10.5282/o-bib/5738.Search in Google Scholar
© 2023 bei den Autorinnen und Autoren, publiziert von De Gruyter.
Dieses Werk ist lizensiert unter einer Creative Commons Namensnennung 4.0 International Lizenz.
