ÜBERGANG DER ALEPH-SHARING-EINRICHTUNGEN

(1)

DIE ÖSTERREICHISCHE BIBLIOTHEKENVERBUND UND SERVICE GMBH

ÜBERGANG DER ALEPH-SHARING-EINRICHTUNGEN

WOLFGANG HAMEDINGER VERBUNDTAG

KLAGENFURT, 15. MAI 2018

(2)

Hinweis

Bei etwaigen Unklarheiten siehe auch:

Ablöse des Modells Aleph-Sharing:

Erläuterungen zur „Information“

Wolfgang Hamedinger

Aleph-Sharing-Tag, 9. November 2017, OBVSG

(3)

Übergang der Aleph-Sharing-Einrichtungen - Verbundtag, 15. Mai 2018 3

Von alt nach neu: Festlegungen und Pläne

• Einheitliches Lizenzmodell für Umstieg auf Alma vereinbart

• Kostenaufstellung für alle betroffenen Verbundteilnehmer

– Individuelle Kostenberechnung durchgeführt – Kostenangaben und Rahmenbedingungen

des Modells ausgeschickt

• Umstieg erfolgt in Gruppen („Waves“) – Wave 3 (April – September 2018) läuft

▪ Universität für Bodenkultur Wien

▪ Universität Klagenfurt

▪ Fachhochschule Burgenland

– Wave 4 (August 2018 – Jänner 2019) – Wave 5 (Februar 2019 – August 2019) – Wave 6 (~ Herbst/Winter 2019/2020) – Wave 7 (~ Sommer 2020)

– Wave 8 (~ Herbst/Winter 2020/2021) – Wave 9 (~ Sommer 2021 [Reserve])

• Abschaltung der Aleph-Bridge (Aleph- Zentralsystem) auf Basis der Planungen:

4. Quartal 2021

– Damit verbunden auch Einstellung des Dienstes „Aleph-Sharing“

• Stand Umstiegsentscheidungen:

– Eigenständige Lokalsysteme (Option 1):

▪ Eine Bibliothek hat sich dezidiert gegen Alma ausgesprochen

▪ Vier Bibliotheken halten sich die Entscheidung noch offen

▪ Alle anderen anderen steigen um

– Aleph-Sharing (Option 2 und Neuteilnehmer):

▪ Einundzwanzig Zusagen (zwei noch vorbehaltlich Kostengenehmigung)

– Einige Einrichtungen prüfen Alternativen, de facto die Einsatzmöglichkeit von Koha

• Eintakten in die verfügbaren Waves – Wave 4 wäre noch zu haben!

• Abschluss der neuen Teilnahmeverträge – Im wesentlichen fertig vorbereitet – Verzögerung durch DSGVO:

▪ Muster der

Auftragsverarbeitungsvereinbarung vorbereitet

▪ Systemangaben werden durchgereicht

▪ Endfassung erfordert noch die entsprechende Vereinbarung der Auftraggeber mit Ex Libris

– Versandfertige Fassungen für Juni erwartet

(4)

Diskussion: Lokale Alternativen zu Alma und Verbund

• Diskussion über lokale Alternativen zu Alma – Unbehagen über Abhängigkeit von Ex Libris – Bestechende Idee des Open Source Gedankens

– Kostensteigerung beim Umstieg von Aleph nach Alma

• Vorstellungen:

– Einsatz einer Lokalsystemalternative

– Verbleib im Verbund / Nutzung von Verbundleistungen (Umfang offen)

• Natürlicher Kandidat: Koha

– Quellkatalogisierungsformat im Verbund ist inzwischen MARC21

– MAB2-basierte System erfordern eine komplexe Formatkonversion und fallen daher aus

▪ Aleph

▪ Alephino

– Freie Internformate erfordern ebenfalls eine Formatkonversion und erfordern daher ebenfalls dauernden Aufwand

– Kommerzielle Systeme schaffen ebenfalls Abhängigkeiten – Koha

▪ MARC21-basiert

▪ Open Source

▪ Bereits im Einsatz

▪ Anwendergemeinde vorhanden

• Nebenbemerkung:

– Jedes System muss parametrisiert werden

– Systembibliothekarische Tätigkeiten sind also immer erforderlich

(5)

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

(6)

Lokalsystem und Verbundfunktionalität: Minimalanforderungen

• Die Katalogisierungsformate zentral und lokal müssen im Wesentlichen gleich sein

• Die Abbildung von Metadatenstruktur und Bestandsinformationen muss zwischen den Systemen möglich sein

– Hierarchische Katalogstruktur

• Das Lokalsystem muss sich programmtechnisch an die API-Struktur von Alma anbinden lassen – Primärkatalogisierung über die Oberfläche des Lokalsystems in Alma

▪ Nutzung vergebener AC-Nummern

– Replikationsverfahren per Programm bzw. periodischen (häufigen) Datenexport

▪ Bibliographische Daten: Alma → Lokalsystem

▪ Bestandsdaten: Lokalsystem → Alma (Ablage externer Bestandsangaben)

• Weitergehende Anforderungen sind denkbar, z.B.

– Vernünftige Normdatenarbeit über die Oberfläche des Lokalsystem

(7)

Organisatorische Auswirkungen und finanzielle Konsequenzen

• Drittsystem → Bruch der Homogenität

– Tiefgreifende Kenntnisse des Drittsystems aber auch von Alma erforderlich – Erforderliche Qualität und Umfang (Redundanz) ist sicherzustellen

• Entwicklung von Alma bzw. Drittsystem sind nicht aufeinander abgestimmt – Laufende Überwachung der Änderungen

– Analyse der Auswirkungen

– Rechtzeitige Anpassung der Anbindung(en)

▪ Hilfreich: bestehende Entwicklungspläne

• Kopplung von Alma und Drittsystem ist Basisfunktionalität – Jedenfalls sicherzustellen

• Grobschätzung ohne genaue Evaluierung:

– 2-3 VZÄ Dauerbetrieb

– Temporäre Zusatzaufwendungen bei größeren Entwicklungsschritten

• Kostenbandbreite:

– 150.000 – 250.000 € pro Jahr

(8)

Position der OBVSG

• Ein Homogenitätsbruch ist wegen der dauerhaften Auswirkungen nicht erstrebenswert

• Die OBVSG will sich einem massiven Wunsch von Teilnehmern aber auch nicht verschließen

• Bedingungen:

– Verbindliche Zusage der Interessenten zur dauerhaften Übernahme von Kosten im genannten Umfang – Durchführung eines Vorprojekts durch die OBVSG

▪ Evaluierung der Möglichkeiten

▪ Konzeption des Dienstes mit Kostenveranschlagung

– Beteiligung an den Kosten des Vorprojekts durch die Interessenten

• Bei positiven Ergebnissen des Vorprojekts wird der Dienst kostenpflichtig implementiert (mit Mindestbezugsdauer

Siehe dazu auch:

Alma im OBV: Anbindung von Drittsysteme sowie Discovery (Stand: 2017-10-23)