Migration von Metadaten aus elektronischen Nachweissystemen

_{Von Michael Becker und Thoralf Hanstein}

Eigentlich sollte man denken, dass die Übernahme von bereits in digitaler Form vorliegenden Beschreibungsdaten von Handschriften viel einfacher und „moderner“ ist als die händische Übernahme solcher Informationen aus gedruckten Altkatalogen aus dem 19. Jahrhundert. Aber in der Projektpraxis steckt oft viel konzeptionelle Arbeit dahinter. Bis zum erfolgreichen Import braucht es viel Geduld, denn die Vorbereitung beinhaltet viele kleine, aber komplexe Arbeitsschritte, die geduldig abgearbeitet werden müssen. Sogar nach erfolgtem Import sind eigentlich immer noch händische Korrekturen in einzelnen Datensätzen nötig.

Allheilmittel Migration?

Natürlich kann man mit einem Import schnell mal über 9.000 Datensätze ins System holen, aber passen diese Daten auch wirklich zum bisherigen Bestand? Oder leidet eventuell die Konsistenz der Daten?

Laut Projekt-Planung sollten Metadaten aus Anwendungen in Gotha, Leipzig, Freiburg, Halle/Saale, aber auch aus Indonesien und Österreich in das neue Portal Qalamos migriert werden. Auch wenn mit Gotha und Leipzig ebenfalls MyCoRe-Anwendungen auf die Migration warteten, zeigte der Arbeitsaufwand sich erst im Detail. Durch die gute Schnittstellenfreundlichkeit von MyCoRe lag die größte Problematik nicht wirklich an den zu erstellenden Skripten, sondern am Datenbestand an sich.

Dubletten vermeiden!

Qalamos baut die Datenhaltung sehr fokussiert auf Normdaten auf, u. a. für Personen. Gibt es beispielsweise eine Person mit fester ID in Qalamos, und aus einer zu migrierenden Anwendung kommt eine Person desselben oder ähnlichen Namens dazu, muss dies unbedingt abgeglichen werden, um Personendubletten zu vermeiden.

Zu diesem Abgleich konnten wir in einem ersten Schritt ein von Sarah Winkelmann im Rahmen ihrer Bachelorarbeit an der HTWK Leipzig entwickeltes Script nutzen, das über eine Ähnlichkeitsabfrage Listen von potentiellen Personendopplungen generierte.¹ Dies war eine enorme Hilfe, denn allein aus der Leipziger Anwendung kamen mehr als 1000 Personen-Datensätze für einen Import in Frage.

Index aufräumen!

Doch auch wenn diese Listen für uns eine große Arbeitserleichterung bedeuteten, konnten sie uns die „Hand“-Arbeit natürlich nicht völlig abnehmen. Jede Liste musste von den Projektmitarbeiter:innen durchgesehen und abgeglichen werden. Dabei wurde festgelegt, welche Personen-Datensätze bei der Migration zusammengeführt, überschrieben oder auch neu angelegt werden sollten. Das „Aufräumen“ des Personenindexes war bei mehreren Tausend Personendatensätzen immer noch ein sehr arbeitsintensiver und wiederholt notwendiger Prozess, an dem alle Projektmitarbeiter:innen beteiligt waren.

• 

Migration ≠ Migration

Deutlich komplizierter wurde die Migration jedoch bei Anwendungen, die aus anderer Intention und auch technischem Unterbau gewachsen waren. Ein aktuelles und sehr gutes Beispiel hierfür ist die Migration der Daten aus dem B3Kat der Bayerischen Staatsbibliothek in München.

In der Konzeption wurde hier nicht „nur“ ein einmaliger Abzug der Daten zu einem bestimmten Termin geplant, sondern ein turnusmäßiger Datenexport nach Qalamos. Anders als bei der Migration der MyCoRe-Anwendungen aus Gotha und Leipzig kommt über den B3Kat eine ganz andere Datenstruktur zum Tragen. Diese musste daher zunächst auf das Datenmodell von Qalamos gemappt werden, bevor zum schon bekannten, händischen Personenabgleich übergegangen werden konnte.

Zum Teil musste das Datenmodell um neue Kategorien erweitert werden, aber auch pragmatische Kompromisse waren manchmal notwendig. Für den turnusmäßigen Abzug der Münchner Daten muss das Skript auch zukünftig immer aktuell gehalten werden, um die Stabilität des Imports zu gewährleisten.

Mapping und pragmatische Aufwand-Nutzen-Kalkulation

Insbesondere beim Import von Daten aus externen Anwendungen, die nicht auf MyCoRe basieren, ist die Zusammenarbeit zwischen IT und Fachanwender:innen relevant. Dies ist u. a. beim Mapping von Klassifikationen zu beachten.

Während es beispielsweise für Sprachen mittlerweile ISO-Standards gibt, die in verschiedenen Anwendungen genutzt werden können, sieht dies bei der Klassifikation von Inhalten schon wieder ganz anders aus. Hier unterscheiden sich Anwendungen oftmals im Detailgrad der Klassifikation, aber auch in der verwendeten Terminologie. Die IT alleine kann z. B. nicht entscheiden, ob eine Kategorie wie Kalif auf die Kategorie Islam oder die Kategorie Geschichte abgebildet wird.

Deshalb muss man bei der Konzeption einer Migration auch den Aufwand abwägen: schreibt man ein Skript, erstellt vorher ein aufwändiges Mapping und führt danach eine ebenso arbeits- und zeitaufwändige, händische Indexbereinigung durch? Oder lässt man die Möglichkeiten der IT auch mal außen vor und nimmt gleich eine händische Konversion der Daten vor, also quasi ein Mapping und eine Personenintegration on the fly?

Bei der Sammlung der Franckeschen Stiftungen in Halle/Saale mit ca. 130 relevanten Texten haben wir uns beispielsweise für die letztere Strategie entschieden. Bei größeren Sammlungen wie den über 2.000 Datensätzen der OMAR-Datenbank für mauretanische Handschriften war eine Migration ohne Unterstützung der IT natürlich undenkbar.

Migration, und was dann?

Im Zuge der Migration von Daten muss immer auch entschieden werden, wie mit den alten Systemen weiter verfahren wird. Werden diese einfach abgeschaltet, hat das zur Folge, dass existierende Verlinkungen auf diese Systeme nicht mehr funktionieren. Dies ist insbesondere bei Nachweissystemen, die auch im Rahmen wissenschaftlicher Arbeiten genutzt werden, ärgerlich.

Bei Qalamos wurde hierbei der Ansatz verfolgt, alte Identifier auch im neuen System verfügbar zu machen. Dies bedeutet, dass z. B. die Identifier der genannten OMAR-Datenbank (z.B. mfmau2090) auch im neuen Portal aufgerufen werden. Damit ist eine einfache Weiterleitung und somit eine kontinuierliche Bereitstellung der Daten möglich.

Unsere Erfahrungen mit der Datenmigration aus diversen Systemen und Anwendungen haben gezeigt, dass es keine immer anwendbare Strategie für die Migration von Daten gibt, sondern vieles bedacht und konzipiert werden muss. Eine Vorgabe dabei ist jedoch immer klar: die Konsistenz der Daten und der Indizes im Portal sind Qualitätsgaranten für die Nutzenden und sollen bei einer Migration immer Hauptaugenmerk sein.

1. Sarah Winkelmann, “Ermittlung zusammengehöriger Personendaten aus Katalogisierungsprojekten orientalischer Handschriften”; https://cmswiki.rrz.uni-hamburg.de/hummel/MyCoRe/DiplomArbeiten/PersonendatensatzDuplikate. [↩]

---

---