DIE ÖSTERREICHISCHE BIBLIOTHEKENVERBUND UND SERVICE GMBH
ZUR LOGIK DER ZDB-BESTANDSDATENLIEFERUNG
WOLFGANG HAMEDINGER
VERBUNDTAG, KLAGENFURT 15. MAI 2018
• Ziel: Österreichische Bestandsangaben sollen in der ZDB nachgewiesen werden
• Liefererfordernisse
– Datensätze benötigen neben den inhaltlichen Angaben
▪ Bibliothekskennung der ZDB (BIK)
▪ (gültige) ZDB-ID
– Die Aktualisierung erfolgt inkrementell
– Die Lieferungen sind asynchron (Export aus den eigenen Datenquellen und Import in die ZDB erfolgen nicht zeitgleich)
• Freischaltung und Auswahl der liefernden Bibliotheken über Adressdatenbank – Umlenkung der Fernleihbibliotheken
– hierarchische Freischaltung von Teilbibliotheken (neu)
• Die zu liefernden Daten müssen selektiert werden:
– Keine Lieferung von Reiheneinträge an ZDB
– Keine Lieferung von Beständen mit unzureichenden Angaben
– Keine Lieferung von als noch zu prüfen gekennzeichneten Beständen aus der ZDB-Migration im Jahr – Keine Lieferung von erkennbar fehlerhaften Datensätzen2000
– ...
• Die Daten enthalten Fehler
Ausgangssituation und Vorgaben
Bisherige Verarbeitung auf Basis Aleph: Grobschematik
Verknüpfungs-, Selektions- und Verarbeitungslogik mit
Statusdatenbank
Datenprüfung Bestandsvor-→
selektion
SpiegelDB (MAB2-ASEQ)
Algorithmische Anreicherung mit
analytischen Angaben
Adressdatenbank (Aleph ACC09,
später Ersatz)
OWNBIK
Institutionshierarchie Fernleihumlenkungen Bibliotheksangaben
Freigabe
Konzentrations- logik,
MARC21- und Adressausgabe Aleph
(MAB2-ASEQ)
ACC01 ACC03 ACC60
MAB2 → MARC21
Letzte Lieferung 2013-11-22 vor Umstellung des Lieferformats auf MARC 21
Alma als neuer Verbundkern: Architektur im Parallelbetrieb mit Aleph-/Alephino
Community zone (CZ) Globaler bibliographischer Datenpool (Anwender
Knowledge base (Ex Libris) GND-
Spiegel Normdatei A
Normdatei B
Alma Netzwerkzone Master AC-Nummer
Bridge IZ externe Bestände
Aleph Bridge (ACC01)
Bestandsdaten (ACC60/Z300)
Online-Katalogisierung
Batchsynchronisierung
Aleph / Alephino
GUI
Aleph / Alephino
GUI
Katalogisierung
MAB2- MARC21-
Konver- ter
Externdatenquellen
Replikation (Aleph-spezifisch)
ZDB
Verbünde GND
Fremddatenpool ACC02 ...
ZDB-Spiegel ACC03 DNB
GND-Spiegel ACC18 Casalini
OAI-Synchronisation
Discovery (Primo et al.)
Bridg
Bridge IZ Alma IZ Inventory
Alma IZ Inventory
Alma IZ Inventory
Alma IZ Inventory
Alma statt Aleph: Grobschematik
Verknüpfungs-, Selektions- und Verarbeitungslogik mit
Statusdatenbank
ZDB-ID Satztyp BestandsdatenOWN
Alma ZDB-Export Alma ZDB-Export (MARC-21-XML) (MARC-21-XML)
Adressdatenbank (Aleph ACC09,
später Ersatz)
OWNBIK
Institutionshierarchie Fernleihumlenkungen Bibliotheksangaben
Freigabe
Konzentrations- logik,
MARC21- und Adressausgabe
Ergänzung Ergänzung analytische analytische Angaben (Kat 859) Angaben (Kat 859)
ZDB-ID ZDB-ID Spiegel Spiegel
Bestimmung von Neueintragungen,
Änderungen und Löschungen
• Bridge-IZs für Nicht-Alma-Bibliotheken → Alma Netzwerkzone kann alle Daten liefern
Einfache XSLT- Transformation vorhanden (für den Anfang ausreichend)
Die Rolle der Adressdatenbank
• Jeder Datensatz muss einer in der ZDB-Adressdatei eingetragenen Bibliothek zugeordnet werden (BIK) – Die Lieferfreischaltung erfolgt bei uns auf Ebene der Fachbibliothek
– Bestandsanfragen kommen über die Fernleihe und werden von einer oder (selten) mehreren Teilbibliotheken einer Einrichtung erledigt – üblicherweise der Hauptbibliothek
– Um den Melde- und Arbeitsaufwand gering zu halten, erhält die Fernleiheteilbibliothek die BIK – Alle anderen liefernden Teilbibliotheken werden nach außen auf diese umgelenkt.
• Abbildung der Fernleiheumlenkung in der Adressdatenbank
– Die Daten der liefernden Teilbibliotheken erhalten bei der Aufbereitung die BIK des Datensatzes auf den sie umgelenkt sind
– Sie behalten das eigene Sigel bzw. die eigene ISIL
– Sie erhalten (bisher) eine Ordnungshilfe, sodass die Anzeige im ZDB-OPAC für größere Einrichtungen strukturiert und in einer definierten Reihenfolge der Fachbibliotheken erfolgt (standardmäßig beginnend mit den Beständen der Hauptbibliothek)
• Abbildung der hierarchischen Struktur in der Adressdatenbank
– Seit mehreren Jahren werden nicht nur die physischen Teilbibliotheken erfasst, sondern – wo erforderlich – auch die Gesamtheit, z.B. die Universitätsbibliothek an sich
– Hierarchien werden mit Aleph-Mitteln wie im bibliographischen Bereich abgebildet – Lieferfreischaltungen sind damit inzwischen über ganze Bibliotheken einfach möglich
Rezept
Man nehme
• ZDB-Export („Publishing“) aus der Alma-Netzwerkzone als (inkrementelle) Ausgangsdaten
• Adressdatenbank (ACC09)
– Zuordnung der OWN-Codes zu tatsächlichen Bibliotheken (ISILs) – Deutsche BIK
– Freischaltkennzeichen
– Umlenkung auf Fernleihebibliothek
• Aktuelle Liste der ZDB-IDs
– Automatisch zu erzeugende Spiegeldatei
• Eine Statusdatenbank mit allen zur Lieferung grundsätzlich in Frage kommenden Bestandsdaten
• Eine passende Verarbeitungslogik und
1. Setze die Daten aus den Einzelteilen zusammen
2. Überprüfe den Unterschied zum letzten Verarbeitungslauf 3. Entscheide über Liefererfordernis
4. Aktualisiere den aktuellen Lieferstand
Das entstehende Gericht im Überblick
Quellen
Statusdatenbank
Lieferziele Rückmeldungen
Alma NZ
(Inkrementeller) Export Adressdatenbank Spiegel ZDB-IDs
Statusermittlung
Adressexzerpt Verknüpfungen Bestandsangaben Bestandsangaben Änderungen
Vorbereitung Bestandslieferung
Vorbereitung Adresslieferung
Adressaufbereitung Bestandsaufbereitung
ZDB
SBB Bestandsmeldungen Lademeldungen
Datenaufbereitung Alma Export
Fehlermeldungen Bestände Exzerpt Adressangaben und
Verarbeitungsanweisungen Exzerpt Überordnungen und Umlenkungen
Extrakt aktive ZDB-IDs
Aktualisierung Bestandsangaben
Neu Geändert
Gelöscht Neu
Geändert
Email Inkorrekte ZDB-ID ftp
Aktualisierung Lieferstatus Rücklieferung BIK
Ladefehler
Auswirkung der verschiedenen Ingredienzien: Beispiele
• Statusdatenbank muss alle Bestandsangaben enthalten, die theoretisch lieferbar wären – Keine Beanstandung in der Datenprüfung
– Erlaubter Typus (keine Serienstücktitel) – Formal korrekte ZDB-ID
• (Teil-)Bibliothek will in Zukunft liefern
– Freischaltungskennzeichen wird in der ACC09 gesetzt
– Im nächsten Lauf werden die Informationen an die SBB gesendet – Rücklieferung einer BIK aus der ZDB
– Keine Änderung der Bestandsdaten → keine Änderungen aus Alma – Lieferlogik nimmt die Daten der Statusdatenbank für die Lieferung
• Maskierte ZDB-ID wird inaktuell
– ZDB-ID ändert sich in der Quelle (Split, Umlenkung, …)
– Maskierte ZDB-ID in Alma wird nicht aus der Quelle aktualisiert
– Keine Änderung der Bestandsdaten → keine Änderungen aus Alma – Bestandsdatensatz kann nicht mehr mit ZDB synchronisiert werden – Löschdatensatz erzeugen und liefern
• Fernleihebibliothek ändert sich
– Keine Änderung der Bestandsdaten → keine Änderungen aus Alma – Akualisierungen der Bestandsdaten sind zu liefern
Erschwernisse: Daten aus vielen Jahren [1]
• Verwendete ZDB-Sätze enthalten – Korrekte und aktive ZDB-IDs
– Maskierte ZDB-IDs („ZDB-“) mit korrekter Struktur – Sonstige Eintragungen
▪ Maskierte/Unmaskierte IDs mit fehlerhafter Struktur
▪ Kennzeichnung neuer Datensätze
▪ Unsinn
• Österreichisches Kontingent aus der ÖZZDB-Zeit bis zum Jahr 2000 – Nummern 450.000-490.000 und 650.001 bis 700.000
▪ Daraus wurde zumindest noch bis ins Jahr 2016 vergeben!
• Alle Fälle müssen geprüft und gegebenenfalls abgefangen werden
– Die Aktualität einer ZDB-ID muss gegen die Daten der Original-ZDB geprüft werden; erfordert
▪ Buchführung über die Aktualisierungslieferungen von Seiten der ZDB
▪ Direkte Prüfung in der ZDB bei der Erzeugung der Lieferung (Overhead, Systemlast)
– Alternative: nach einer Basisprüfung werden nur mehr aktive Datensätze (ohne Präfix „ZDB-“ und korrekter Struktur) geliefert
Erschwernisse: Daten aus vielen Jahren [2]
Statistik (Basis Aleph-Bridge, bibliographische Datensätze Stand 2018-04-20):
• Insgesamt
• Maskierte IDs mit weiteren Meldungen
• Strukturell korrekte und (vermutlich) aktive IDs:
Datensätze mit Kategorie 025z 380.243
ID mit fehlerhafter Struktur 1.289
ID maskiert 289.069
ID aus dem österreichischen Kontingent 43.060
Kennzeichnung eines Neueintrags 32.207
Maskierte IDs mit weiteren Meldungen 73.663
davon mit fehlerhafter Struktur 510
davon aus dem österreichischen Kontingent 43.010
davon Kennzeichnung eines Neueintrags 30.143
Austausch von Bestandsdaten in der ZDB
• Reinitialisierung
– Löschen des gesamten Bestandes einer Bibliothek
▪ Verwendung eines entsprechenden Programms der DNB/ZDB
▪ läuft als Standardprocedere einmal im Vierteljahr – Lieferung des neuen Grundbestandes
• Inkrementelle Lieferungen
• Somit besteht die Möglichkeit in gewissen Intervallen entstandene Inkonsistenzen von Grund auf zu beheben
• Eine Strategie zur Verbesserung der Datensituation im OBV wäre jedenfalls sinnvoll
