Difference between revisions of "Trip Report: Aleph SMUG DACH Meeting 2009"
(twitter link removed) |
|||
| Line 14: | Line 14: | ||
* [http://www.hbz-nrw.de/aleph/ Conference web site] | * [http://www.hbz-nrw.de/aleph/ Conference web site] | ||
* Presentations have been loaded to the [ftp://ftp.hbz-nrw.de HBZ FTP-Server] (login available via Silvia and/or Inga) | * Presentations have been loaded to the [ftp://ftp.hbz-nrw.de HBZ FTP-Server] (login available via Silvia and/or Inga) | ||
<br><br> | <br><br> | ||
Revision as of 15:55, 9 June 2009
Participants (MPG): Elke Bürger (Dienstag), Cora Molloy, Silvia Munding, Inga Overkamp, Daniel Zimmel (Montag)
Date: 11/12 May 2009 in Cologne
Summary: Aleph-D.A.CH and SMUG-D-A-CH-Li-Lux have been product specific interest groups representing ExLibris customers in German speaking countries. The groups organize annual meetings to facilitate an exchange of information among customers and between them and ExLibris. This year's meeting focused on following aspects:
- next generation discovery tools (-> Primo projects arise everywhere ;)
- MAB2MARC
- merging Aleph-D.A.CH and SMUG-D-A-CH-Li-Lux into a joint organization (= DACHeLA)
Links and Resources[edit]
- Conference web site
- Presentations have been loaded to the HBZ FTP-Server (login available via Silvia and/or Inga)
Subjects/Talks[edit]
Montag: Plenum Session[edit]
Aleph Web-OPAC goes Web 2.0 - C. Hänger (UB Mannheim)[edit]
Entstanden aus dem DFG geförderten Projekt "Tagging" wird hier die Sacherschließung durch die Nutzer mittels Tagging unter Verwendung von Bibsonomy (Entwicklung und Hosting an der Uni Kassel; 4.000 aktive Nutzer) im OPAC angeboten. In der Vollanzeige wird in einem iFrame eine - ebenfalls aus Bibsonomy generierte Tag-Cloud angezeigt.
Details zur Implementierung:
- Der Service basiert auf JavaScript (asynchrones Laden mittels AJAX) und ein Perl-Modul, das den Datenabgleich mit Bibsonomy mittels BibHashkey vornimmt.
- In der OPAC-Vollanzeige findet sich ein Link zu Bibsonomy, wo man sich einloggen muss und dort den Tagging-Eintrag vornimmt.
- Tags werden nicht in den Aleph-Index aufgenommen.
Mittels des Analysetools Sentinel wurde eine Qualitätsanalyse der getaggten Titel im Verhältnis zur automatisierten und durch Fachreferenten vergebenen Sacherschließung vorgenommen. Das Tagging wurde von Studenten vorgenommen. Ergebnisse der Analyse waren:
- bei theoretischen Fragen waren die intellektuelle Verschlagwortung im klaren Vorsprung. Zwischen Fachreferent und Studenten zeigte sich, dass die Studenten eher weitläufige Begriffe wählten.
- Insgesamt aber ganz zufriedenstellende Ergebnisse.
Es gibt Überlegungen hierzu eine HBZ-Fortbildung als Workshop anzubieten mit Herrn Falltert (UB Mannheim), der dem Dienst umgesetzt hat. Die Skripte können nachgenutzt und sollen über El Commons zur Verfügung gestellt werden.
Frage zur Nutzung: In den ersten 10 Tagen wurden 240 Tags vergeben, ohne dass die Funktion beworben wurde.
Weiterlesen: Im Blog der UB Mannheim und der Vortrag von Christof Niemann auf dem Dt. Bibliothekartag
Benachrichtigungsdienst für ZSen-Abos über RSS - M. Pfeffer (UB Mannheim)[edit]
Hier geht es um die Information zum Hefteingang mittels RSS. Dies funktioniert bei Online-Inhaltsverzeichnissen von SWETS. Da SDI hier nicht funktionierte, Überlegungen bezüglich RSS, genauso verwendbar für Neuerwerbungslisten ...
Derzeit ist die Benachrichtigung gekoppelt an den Hefteinang des gedruckten Heftes. Es wurden XML-Dateien erstellt, mit 1 "Channel" pro Zeitschrift und "item" pro Heft (hier wird eine eindeutige ID [guid, global unique id] benötigt).
Der Link im Feed führt zu SFX; die Haupttitelanzeige erfolgt in Aleph.
Abgefragt wird (mit Perl-Skript):
- per CGI die ISSN vom Apache Webserver
- Abfrage 1: Abo für ISSN prüfen
- Abfrage 2: Exemplare für Abo prüfen
- automatischer XML-Ausgabebefehl für RSS
Die Liste der Abos (alphabetisch sortiert) für die Website wurde per Skript erzeugt, ist aber statisch.
Auch hier ist die Nachnutzung der Skripte möglich.
Hauptproblem: Anbindung an Papierexemplareingang funktioniert nicht bei "online only"
Generischer Link Resolver (GLR) - M. Kratzer (BSB München)[edit]
Es handelt sich dabei um ein 2-jähriges DFG-Projekt, inspiriert von SFX, dessen Laufzeit beinahe zu Ende ist.
Ziele:
- verbesserte linking syntax für freie Journals
- generischer Link-Resolver, aus dem jeder institutionelle Link-Resolver freie Volltext-Services schöpfen kann. Problem: Ohne produktübergreifende Schnittstellen wird die Akzeptanz gering sein.
Zum allgemeinen Verständnis: Auflistung der unterschiedlichen "Linking-level" von Volltexten:
- Zeitschrift (ISSN)
- Inhaltsverzeichnis von Band/Heft
- Artikel selbst (Angaben zu Vol, Iss., P. oder sonstige individuelle URL)
Bei freien Angeboten besteht allerdings das Problem, dass hier oft nur Zugriff auf Zeitschriften-Ebene möglich ist, weil die Syntax-Analyse nicht greift, bzw. die Link-Konstruktion keine Auflösung zum Heft zulässt.
Vorgehensweise:
- In EZB grüne Zeitschriften URL wurde abgegriffen von den Zeitschriften-URLs und den Unterseiten ("Green Crawling").
- Auf der Basis dieser URL sollte mittels automatisierter URL-Analyse eine Trennung in Volltext-URLs und NICHT-Volltext-URLs erfolgen.
- Erzeugung von URL-Schablonen : Base-URL, Jahr, Band, Heft, Seite -> Linkkonstruktor
- Der Crawler, der die URLs abgreifen sollte, stieß auf verschiedene Hürden:
- Volltexte befanden sich zum Teil nicht auf gleicher Domain wie die Journal-Homepage
- Volltexte waren z.T. nur über interaktive Such-Applets zugänglich
- nicht alle EZB-grün-Zeitschriften tatsächlich "frei" genug. D.h. Crawler-geschützt oder nur für bestimmte Zeiträume tatsächlich frei
- Danach zeigen sich Analyse-Hürden (ideal ist ein optimales Trainingsnetz für neuronales Netz des Analyse-Tools mit einem Positiv-Set, einem Negativ-Set):
- fehlende Semantik-Informationen für die Analyse
- zufällige Dokumente-IDs aus CMS erzeugt und nicht analysierbar
- pro Zeitschrift musste EIN neuronales Netz trainiert werden
Ergebnis:
- URL-Datenbank mit 275 Journals, über 15 Mio Titel
- 1 neuronales Netz für alle, ist nicht realisierbar, aber für fast jeden Zeitschriftentitel
ToDo:
- Web-Frontend zur Bewertung von Query-URLs
- ein Webformular zur Registration freier Zeitschriften mit der Möglichkeiten Informationen für die Analyse einzugeben (inbound linking syntax).
- Transformator für URL-Schablonen
Bis zum Projektende werden nicht alle Punkte realisiert werden können, aber die bisherige Arbeit soll nicht ungenutzt bleiben.
Weiterlesen: Auf der Homepage des Projektes
Verbundübergreifende Kataloganreicherung - J. Brandauer, V. Babitchev (OBV)[edit]
Im Österreichischen Verbund werden Daten aus den dt. Verbundkatalogen zur Kataloganreicherung verwendet, hier ist die Dublettenerkennung besonders wichtig.
- Als Objekttypen werden Inhaltsverzeichnisse, Klappentexte, Rezensionen in pdf, txt und jpg-Format verwendet.
- Es erfolgt ein Abgleich der ISBN, Jahr, Satztyp, Auflage, Umfang, Band, Titel, Verlag.
- Metadaten und Objekte werden auf dem Dokumentenserver "edoc" gespeichert.
Workflow:
- Verbunddaten werden per FTP geliefert, Titeldaten in MAB2, dann Normalisierung in Aleph-Sequential
- Objekte werden abgeglichen und in edoc gespeichert und die Verbunddatenbank erhält ein Link-Update
2 denkbare Verfahren:
- Batch (Daten müssen lokal vorliegen)
- online
Beide Verfahren sollen gemeinsam zur Ergänzung eingesetzt werden.
Pläne und weitere Schritte:
- Ideal wäre, noch eine Priorisierung der "Lieferanten"
- Neuer Objekttyp "html" noch aufnehmen
- Daten der DNB und des GBV
- als Workflow sind halbjährliche Einspielungen geplant.
- Analyse der nicht berücksichtigten Objekttypen
- Evaluierung
- Diskussion mit AG „Kooperative Verbundanwendungen“ über das weitere Vorgehen.
Fazit:
- viele Ziele wurden erreicht: Verbesserung aus Benutzersicht
- Technisch/organisatorisch: Probleme konnten an die AG weitergegeben werden
- Aufbau eines Workflows mit den Verbünden
- 170.000 Objekte konnten eingespielt, 150.000 weitergegeben werden
Primo-Einführung im OBV - J. Brandauer, V.Babitchev (OBV)[edit]
Hier ist die erste Verbund-Nutzung von Primo!
Als Lokalsysteme liegen Aleph500, Alephino und "Aleph-Sharing" für kleinere Bibliotheken vor. Installation soll als ein zentrales Primo-System erfolgen (Chance für kleine Bibs), aber der Anspruch auf individuelle Views und Verfügbarkeitsinformationen sind wichtige Ziele!
Darüber hinaus soll auch die Anbindung lokaler Nicht-Aleph-Daten im 2. Schritt erfolgen.
Man ist sich der Mängel von Primo hinsichtlich der Konsortiumstauglichkeit bewußt; Alternativen zu Primo werden nicht gesehen.
Derzeitiger Stand und weitere Pläne:
- Ex Libris wird bis 2011 ein Datenmodell für Verbünde erstellen. Derzeit wird der Index als ein Bestand genommen, wobei der Gesamtbestand dann pro Teilnehmer dupliziert werden muss, da in den österreichischen Verbunddaten die lokale Systemnummer (die bei Primo Grundlage für die Bestandsinfo ist) nicht vorhanden ist.
- Hierarchien insbesonders bei mehrbändigen Werken
- 2010 soll die Integration von Fremddaten (Swets) eingerichtet werden
- Seit März läuft das inkrementielle Update, nachdem der Index initial aufgebaut worden ist.
- Javascript für Enrichtment plug-in (d.h. während Pipe werden Daten angereichert) bzw. für Enrichment Indexing Plug-in (MySQL, Aleph Publ. Records) für Primo in El Commons
- Produktionsbeginn ist für Oktober 2009 (an der Uni Wien und Uni Innsbruck) vorgesehen.
Es gibt zahlreiche Probleme, aber Primo wurde bewußt als "Werkzeugkasten" gekauft und die Problemfelder in Kauf genommen.
Primo-Einführung im KOBV - S. Lohrum (KOBV), A. Sabisch (UB FU Berlin)[edit]
Organisatorischer Rahmen:
- Gemeinsam für FU, HU und TU Berlin.
- Hosting in der KOBV-Zentrale.
- Hier werden 19 Pipes und 5 Views erstellt.
- Integration lokaler Quellen (Aleph, Dok.Server, Metalib, Imagekatalog) vorgesehen, erst danach Einbindung externer Quellen
- offizieller Start geplant für 12.10.09 (Vertragsabschluss war zum Jahreswechsel)
- Einsatz als OPAC-Ersatz erst ab Version 3 (voraussichtlich 1.Quartal/2010) sinnvoll, wenn Ausleihe integriert ist
Ziele:
- one-shop-stop
- geringerer Aufwand
- Synergiegewinne z.B. durch gemeinsame Nutzung von Datenpools
- Optimierung der Literaturversorgung
Vorgehen, Probleme, Ergebnisse:
- Erheblicher Aufwand erforderlich; viele Abteilungen müssen miteingebunden werden
- Primo ist nicht "mandantenfähig", d.h. administrativ: jeder sieht alles (und kann Dinge anderer ändern), also kooperatives Arbeiten nötig!
- Primo ist nicht auf den konsortialen Gebrauch ausgerichtet. Jede Frage diesbzgl. wird nach Israel weitergeleitet.
- Arbeitskreis Normalisierungsregeln ist/wird gebildet (Normalisierungen sind sehr aufwändig, die MAB-default-Normalisierung ist nicht hilfeich, die Ergebnisse der UB Mannheim sind besser)
- OAI-Harvesting ist schlecht dokumentiert
- Pipes für den Datentransfer anpassen; der Austausch untereinander ist gut möglich, evtl. über El Commons?
- Metalib-Einbindung macht Probleme
- Eingriffsmöglichkeiten in Prozesse (z.B. manuelles beenden und starten) sind gering, hier bleibt zum Teil nur Neustart des Backend.
- Deployment von Testsystem nur komplett auf Produktivsystem, nicht in Teilen, wie dies bei Aleph möglich ist.
Eine Liste mit Anforderungen ging an Ex Libris in Israel.
Offene Punkte / Ausblick:
- Pro/Contra Einbindung freier Daten
- Nachweis Nationallizenzen? Mit welchen Aufwand pflegt man Daten in verschiedenen Systemen? Was wird in Aleph und was in Primo eingespielt?
- Integration von Zeitschriften-Backfiles?
- Wie geht man mit unterschiedlichen Sacherschließungen von unterschiedlichen Datenquellen um? Inhaltlicher Streit und inhomogene Datenquellen
- Probleme mit manchen Katalogisierungsregeln
- Zusammenarbeit und Austausch muss organisiert werden
- PDS, SingleSign-on ist noch eine Herausforderung, auch im Hinblick auf Aleph und Metalib
Abbildung heterogener Metadaten in Primo - M. Pfeffer, B. Kaldenberg (UB Mannheim)[edit]
Kurze Darstellung der Probleme bei der Einrichtung. Hier insbesonders Stillstand der Oracle-Datenbank, da es in dem ongoing Publishing-Prozess zu einem Fehler kam (Platzbedarf sprengt tablespaces). Darüber hinaus erscheint OAI-PMH für den Datenaustausch mit Aleph nicht geeignet, weil MAB nicht dokumentiert ist. Für das Laden von Metadaten zu den nationallizenzierten Produkten wurde ein Konverter von MAB2 zu MARC-XML geschrieben.
Empfehlungen:
- GUT nachdenken, welche Daten in Primo geladen werden sollen (oder anderes Portal), weil sie neben den sehr akuraten bibliographischen MAB/MARC-Daten erscheinen. Das Laden der Daten aus MADOC (Mannheimer PubServer), arXiv.org und Citeseer im OAI-Dublin Core-Format war zwar unproblematisch, aber die Datenqualität ist nicht sehr gut.
- Für's Drilldown werden Sacherschließungsinformationen benötigt. Was ist sinnvoll bei Anreicherung der Daten? Pfeffer sieht hier in Basisklassifikation eine gute Möglichkeit, gerade weil es nicht zu tiefgehend ist.
Primo Update - S. Kuck (Ex Libris)[edit]
- neu: die Möglichkeit einer Quick-Search-Box (Deskbar)
- Verfügbarkeitsanzeige in Kurzliste (real-time)
- Mobile device integration (Titel als SMS, aufs iPhone)
- Integration in Facebook, MySpace
Neue Funktionalitäten für Version 3 (1. Quartal 2010):
- volle Integration der OPAC-Funktionalitäten (Vormerkungen, Benutzerausweis ...)
- Durchsuchen des persönlichen Bereichs ("Shelf")
- Recommender Service bx (Testlauf mit Karlsruhe)
- Metalib-Integration verbessern (Did you mean?, Smart use of cache -> Geschwindigkeitszuwachs)
- Website-Harvesting
- verbesserte Volltextindexierung
Montag: Aleph Session[edit]
Aleph 20 Upgrade - Martin Büscher (Exlibris)[edit]
Verbesserungen in folgenden Bereichen:
- MA-Zugriffsrechte (V19, die wir ja überspringen)
- Module als Reiter, mit Buttons für einfachere Vergabe (alle/erlauben, alle/verweigern, alle/löschen) und optisch übersichtlichere Aufteilung.
- Batch-Jobs (V19)
- Task-Manager als Modul mit Reitern und erweiterten Funktionen fürs Batch-Protokoll.
- Inkluse Statusbericht mit Kontrolle und evlt. Fehlerbericht und Zusammenfassung
- Neuer Batch sys-90 = Bericht der gelaufenen Batch-Jobs
- Exemplarbearbeitung
- "Exemplarset bearbeiten", hier wird es die Möglichkeit einer offline Bearbeitung geben, die dann erst nach "Set speichern" online gehen.
- OPAC
- Meldung beim Einloggen sind möglich, z.B. ob es lokale/globale Sperren gibt,bei offenen Gebühren, bei überfälligen Ausleihen
- Systemvoraussetzungen
- Neu als Datenbank: Oracle 11
- Releaseplanung
- Minor Release (= größeres ServicePack) 20.1.0 am 15.10.09
- SP 20.1.1 am 01.2.10
- Neu ist: dass auch MAB und andere Deutschland-spezifische Fragen in zentraler Installation in Israel gepflegt wird, dadurch sind alle MAB-bedingten Änderungen auch in den Service Packs enthalten.
- Upgrade Aleph 18-20
- 2 Software Kits 18-19 und 19-20, erst Oracle Daten von Aleph 18 auf 20.
- was OPAC und Druckformulare angeht, so sind es manuelle Änderungen, aber insgesamt die Änderungen recht gering, damit auch kein so hoher Aufwand (Hoffentlich!)
- Neu: Schritt-für-Schritt-Anleitungen auch für die unterschiedlichen Fälle beim Upgrade.
Schnittstellen[edit]
Funktionserweiterungen Aleph-Cluster[edit]
Funktionserweiterung für Aleph-Cluster im Bereich automatische Replikation z.B. von eBooks und ZDB-Daten (mittels Feld 078e)
- automatische Replikation neuer Titelsätze
- Versorgung der Aleph-Lokalsysteme mit ZDB-Lokaldaten über die Replikation
- Zentrale Titelumlenkungen
- automatische Übernahme von Überordnungen
Produktiv bei BVB ab 21.05.09.
Auslieferung mit Service Pack 2009 (Jan 2009).
Voraussetzung: Version 18 und die Servicepacks
Verbundschnittstelle für Digitalisierungsprojekte - S. Scholz (HBZ)[edit]
Ziele:
- Automatisierung der Erfassung von Titeldatensätzen für Digitalisate
- Aufwand der manuellen Katalogisierungen minimieren
Projektpartner: dilibri, Fa. Semantics und weitere
Schnittstelle basiert auf offenen Standards und steht allen HBZ-Bibliotheken offen
Schnittstellen - von "offline" zu "online" - G. Hupfer (HBZ)[edit]
Vorteile dieses zu beobachtenden Wandels:
- weniger Schritte notwendig
- kein Zeitverzug
- komfortablere Workflows und neue Funktionen
Nachteile:
- Tests- und Abnahme bringen erhöhter Aufwand, weil die Umsetzung bei Verwendung dann ja unmmittelbar erfolgt, auch höherer Aufwand bei Monitoring und Fehler-Handling
- Abhängigkeit der Systeme untereinander bei sofortiger Wirkung von Datenfehlern, die sich dann entsprechend übertragen auf andere Schnittstellen
- Produktionsausfälle an einer Stelle wirken sich stärker bei den abhängigen Systemen aus.
Optimierungsmöglichkeiten:
- Updates vermeiden/reduzieren/verlagern
- erneute Entkopplung von Online-Prozessen, z.B. nicht sofort laden, erst reduzieren, damit nicht so viel auf einmal läuft
Gedanken:
- Wie viele Daten müssen überhaupt mehrfach vorliegen?
- Wie viele Fremdaten müssen wir in unserem Verbundsysystem vorhalten?
Fazit:
- Werden durch zentrale Lösungen einige Schnittstellen überflüssig?
- Mehr Komfort für Bibs und IT
- Hoher Koordinierungsaufwand
Dateneinspielungen (eBooks) - V. Kriesen (UB Paderborn)[edit]
ZDB:
- Bereitstellung und Abholverfahren 1x wöchentlich
- Anpassung an p-manage-42 (Daten werden in’s Zielverzeicnis kopiert und umbenannt)
- Skript setzt Parameter und sichert Logfiles; Wochencodes werden händisch angepasst
- Nachbereitung (Sicherung der Logfiles, "händische" Mail an’s HBZ)
- Ausblick: erweiterte Replikationsmechanismen
Springer:
- Abholung vom FTP-Server mit Skript
- Aufbereitung für p-manage-18 (hauptsächlich Dateiumbenennungen)
- Nachbereitung (Logfiles sichern), Sonderfall: Ausgleich für zu geringe Titelmengen
- Sonderfall: LNCS: Erfassung erfolgte zunächst manuell nach Titellisten, inzwischen im Paket
Nationallizenzen:
- Eher schlechte Erfahrungen
- Abholung vom FTP-Server per Skript
- p-manage-18
- Nachbereitung (Logfiles sichern, Benachrichtigungen)
- Problem großer Datenmengen (z.B. Early English Books): Phrasenindex dauert sehr lange, Oracle-Partition zu zu klein. Fazit: zukünftig in kleinere Pakete aufteilen. Bedeutet allerdings auch mehr Aufwand, weil p-manage-18 öfter angestossen werden muss
Kassenautomat in Paderborn - J. Borbach-Jaene (UB Paderborn)[edit]
Bisher konnten Gebühren nur zu ca. 60% der Öffnungszeit bezahlt werden; außerhalb der Öffnungszeiten gab es keine Möglichkeiten; die Zahlung mit EC-Karte wurde nicht unterstützt.
Einführung von HESS MultiPay 200:
- wichtig: Schnittstelle zu Alpeh
- selbst bedienbar
- Sperren wegen Nichtzahlung werden automatisch aufgehoben
- EC-Zahlung möglich
- Kommunikation über sip2-Schnittstelle
- funktioniert mit Bibliotheksausweis
Pilotanwender ILL2 (SLNP) - A. Edelmann (UB FU Berlin)[edit]
Hier gab es im deutschsprachigen Raum 2 Piloten für die SLNP-Funktionalität die UB FU Berlin, für die ISO-FL Graz, wobei die sich sang- und klanglos als Pilot verabschiedet haben, aufgrund dringenderer Projekte.
Wesentliche Änderungen:
- fast komplett neue Datenstruktur: lib40 ersetzt lib20
- pro ADM eine Fernleihbib
- komplett neue Moduloberfläche, orientiert am GUI-Design der Version 16
- Umsetzung der ISO-Fernleih-Funktionalitäten
Hinweise/Erfahrungen:
- Migration der Stati - Unbedingt Prüfen, ob die richtig migriert sind!
- Lieferantencodes werden von 20 auf 12 Zeichen abgeschnitten
- Fehler in passiver FL:
- Benutzerstatus fehlte in bor-request-expand
- Liste potentieller Lieferanten bietet keine vernünftige Suchmöglichkeit (behoben in V20)
- Ausleihnotiz nicht nachträglich korrigierbar
- Eingabefeld für Signatur fehlt, heißt jetzt: Bestand! (V20)
- Umständliche Navigation zu Exemplar
- Wenn migrierte Exemplare nicht sichtbar sind (tab_check_circ ILL-L)
- Bestellnummer in Signaturfeld
- bei der aktiven Fernleihe traten deutlich weniger Probleme als bei der passiven Fernleihe auf; Workflow ist unkomplizierter
- Die starke Orientierung an der ISO-Fernleihe erschwert die SLNP-Fernleihe
- Funktionalitäten sind verloren gegangen
Hilfen:
- KB 16384-3393 (offene Probleme)
- KB 16384-5283 (Hinweise für den Umstieg auf MAB-SLNP
- Aleph Tips & Advice No. 20
Umstieg wird verschoben auf Wechsel zu Version 20!
ILL2 Werkstattbericht - J. Borbach-Jaene (UB Paderborn)[edit]
Bemängelt Doku, die aus so vielen Dokumenten zusammengesucht werden muss (Hier inzwischen auf FTP-Server von Exlibris schon von Herrn Büscher ein zusammengeführtes Dokument) und z.T. nur in der Online Hilfe vorhanden war!
Zeitplan konnte nicht eingehalten werden. Es besteht allerdings auch kein großer Druck, weil die neue Fernleihe nicht viele Vorteile bringt. Umstieg geplant für September 2009.
Montag: SFX/Metalib Session[edit]
Ressourcen Monitoring in Metalib - S. Lohrum (KOBV)[edit]
Das KOBV Monitoring Tool besteht aus einem cronjob, der die Admin-Routine "util/s/4" regelmäßig ausführt. Die dafür benötigten Konfigurationsdateien werden automatisch generiert.
Verfahren:
- Export der IRD mit "p_export". Die relevanten Suchparameter (z.B. Anfrage) sind in lokalen Feldern im IRD record untergebracht.
- Initialisierung der Konfigurationsdatei aus den Parametern des Exports
- Aufruf util/s/4
- Übermittlung der Testergebnisse via HTTP Request an das KOBV Monitoring Framework, z.B. Nagios
Stefan Lohrum will den Programm-Code über El Commons zur Verfügung stellen.
Recommender Lösung bX - A. Kaschte (Ex Libris)[edit]
bX ist ein gehosteter Dienst von Ex Libris, der auf Grundlage von Nutzungsstatistiken der beitragenden SFX-Instanzen für eine spezielle OpenURL-Anfrage "Empfehlungen" ermittelt (Motto: "Nutzer die nach dieser Referenz gesucht haben, waren auch an diesen Referenzen interessiert"). Der Service basiert auf einem Forschungsprojekt am Los Alamos National Laboratory (Johan Bollen und Herbert Van de Sompel) und ist seit Mai 2009 im produktiven Einsatz.
Details:
- Neben der derzeitigen Standard-Einbindung in SFX ist auch eine "offene Schnittstelle" geplant ueber den der Service in beliebige Umgebungen integriert werden kann.
- Für die Auswertung der Statistikdaten muss eine "Nutzer-Session" identifiziert werden. Dies geschieht nicht ueber einen Browser-Cookie sondern über eine autmatische Gruppierung der Anfragen von einer bestimmten IP. Dieses Verfahren trägt potentiell die Gefahr einer Verfälschung (Firewalls)
- Der kostenpflichtige bX-Dienst (3.000 Euro im Jahr) kann auch von SFX-Anwender subskribiert werden, die ihre Statistikdaten nicht beisteuern wollen. Allerdings werden die Empfehlungen umso besser/detaillierter je mehr Institutionen sich mit Daten beteiligen.
Weiterlesen: Auf den Webseiten zum bX Recommender Service
Deutsche Nationallizenzen in SFX - A. Sabisch (UB FU Berlin)[edit]
Leider sind die deutschland-weit lizenzierten Informationsangebote noch nicht als "Targets" in der SFX Knowledge-Base definiert, was die Aktivierung und Pflege dieser Bestände relativ aufwändig macht. Mittlerweile hat sich ExLibris bereit erklärt, ein Target "National_License_Germany" einzurichten, unter dem die einzelnen Angebot als Subtargets gelistet sein sollen. Die benötigten Informationen zur Einrichtung und Pflege der Targets (z.B. initiale Titellisten als Dataloader-Listen) müssten aber von den SFX-Anwendern zur Verfügung gestellt werden. Herr Sabisch regt hier die Einführung eines "Paten"-Konzepts an, im Idealfall würden die verhandlungsführenden Bibliotheken die Patenschaft übernehmen.
In der anschliessenden Diskussion zeigt sich, dass
- noch nicht alle Institutionen davon überzeugt sind, dass eine autarke Pflege der Titeldaten in SFX überhaupt notwendig ist, da diese ja auch über einen EZB-Export nach SFX geladen werden können (z.B. via SMS oder MMS). Mathias Kratzer (BVB) führt dazu aus, das der "Mighty Mapping Service" die nationallizenzierten Bestandseinträge ignoriert, da diese zu Problemen bei der automatischen Aktivierung in der SFX Knowledgebase geführt haben.
- die meisten Anwesenden dem "Paten-Konzept" zwar grundsätzlich zugestimmt haben, aber zu wenig verhandlungsführende Bibliotheken vertreten waren, die eine konkrete Mitarbeit angeboten haben.
- zum Teil auch unterschiedliche Strategien angewendet werden, z.B. belässt die UB TIB Bestandseinträge in der EZB auch wenn der Inhalt auf eine andere Plattform verschoben wurde. Die anwesenden SFX-Administratoren sind sich einig, dass solche Einträge nicht in der
Weiterlesen: Im El Commons wurde eine Wiki-Seite zur Dokumentation der Integration von NL-Ressourcen in die SFX KB begonnen.
Dienstag: Plenum Session[edit]
MARC 21 - Stand und Ausblick der Aleph-Verbünde - BVB, hbz, KOBV, OBV[edit]
Zusammenfassung: HBZ und OBV stellen in naher Zukunft vermutlich nicht auf MARC21 als Internformat um, sondern werden intern zunächst bei MAB bleiben und MARC21 ausschliesslich als Austauschformat verwenden. Es sollen mögliche Anpassungen an den bibliothekarischen Datenformaten (z.B. Anforderungen aus RDA, Entwicklungen im Bibliotheksbereich wie URM). Der "grosse Umstieg" wird dann später kommen.
Der BVB wird auf MARC21 als Internformat wechseln, weil man sich daraus eine Annäherung an die internationale Bibliotheksgemeinschaft erhofft, die auch den späteren Übergang in ein neues Format (FRBR, RDA) erleichtert.
Vertreter von Aleph-Lokalsystemen verdeutlichen, dass sie sich eine gemeinsame Strategie der Verbünde erhoffen (die es aber nicht mehr zu geben scheint). Die Vertreter der Verbünde versichern, dass die Auswirkungen dieser strategischen Entscheidungen die Lokalsysteme möglichst nicht betreffen sollen.
HBZ[edit]
Formate für bibliographische Metadaten lassen sich wie folgt kategorisieren:
- Austauschformat (Kommunikation zwischen den Systemen, z.B. MAB2 und MARC21; internationale, bzw. nationale festgelegt)
- Erfassungsformat (optimiert für anwendende Personen)
- Internformat (optimiert für Speicherung; Kundenentscheidung)
Die Entscheidung zum Umstieg auf MARC21 als Austauschformat wurde von der Kultusministerkonferenz KMK getroffen. Mit der Umsetzung wurde die DNB (Arbeitsstelle für Standardisierung), der Standardisierungsausschuss, AG Verbund und Verbundvertreter beauftragt
Diskussion: wie soll MARC21 eingeführt werden? 1:1 oder soll versucht werden deutsche Funktionalitäten unterzubringen?
Definierte Ziele:
- möglichst keine Datenverluste
- Funktionalitäten aufrecht erhalten
- Beibehaltung des Datenmodels (Hierarchien, Verknüpfungen)
Zur Erreichung der Zeile de eine Konkordanz MAB2 – MARC21 erstellt. Darüber hinaus existiert seit Ende 2007 eine Kooperation der Aleph-Verbünde, um Umstiegsszenarien zu entwickeln und Spezifikationen für Ex Libris zu erstellen.
Arbeitspakete:
- Analyse von MARC21 für Katalogisierung, Schlagwortketten, Verknüpfungsstrukturen von Titel und Normdaten
- Untersuchung / Identifikation von Schnittstellen für die der Umstieg relevant sind, z.B.
- DNB
- Normdaten
- Versorgungsschnittstelle für Nicht-Aleph-Lokalsysteme
- Programme für MAB2-Datenübernahme
Es gibt bereits MARC21-Schnittstellen, z.B. für ebook-Import, Digitool, z39.50-Gateway
Die fachlichen Vorarbeiten wurden Ende 2008 abgeschlossen und die Anforderungen an Ex Libris weitergegeben. Da das Angebot Januar 2009 von Ex Libris zu hoch war, wurde nach alternativen Varianten gesucht, die zu unterschiedlichen Entscheidungen der Verbünden geführt haben.
Entscheidungskriterien
- politische Zielrichtung / Strategie (Dringlichkeit, Prioritäten)
- Systemarchitektur im eigenen Verbund (homogen/heterogene Verbundmodelle, logistische Umsetzung)
- funktionale Verbesserungen
- Zeitaspekte des Umstiegs
- Position Ex Libris (wie lange wird MAB2 noch unterstützt?)
- Produktzyklus von Aleph
HBZ-Position: Internformat in den nächsten Jahren beibehalten, Austauschformat dort umstellen, wo es dringend notwendig ist. Ziel: Mitte 2010 MARC21-Export. Dies ist momentan noch eine Empfehlung; die endgültige Entscheidung steht noch aus. Argumente für diese Position:
- Minimierung des Aufwands
- Berücksichtigung der Infrastruktur
- Marktbeobachtung, z.B. URM
Zu bedenken ist:
- laufende Konvertierungen sind notwendig (Dateninkonsistenzen)
- MAB2 wird nicht weiterentwickelt und Aleph ist ja ein MARC-basiertes System mit Adaption für MAB2
- gemeinsames Normdatenformat mit DNB? Wie geht man damit um? Ab 2011 soll es von der DNB nur noch MARC21-Normdaten geben
- auch Beibehalt des Internformat kostet
Dennoch
- es entstehen keine Nachteile
- es geht noch ein paar Jahre
- MARC21 ist wahrscheinlich auch nicht dauerhaft
BVB[edit]
Umstieg auf MARC21 für alle Formate. Entscheidungen Standardisierungssausschuss:
- MARC21 als datenformat
- AACR2 (RDA) als Katalogisierungsregelwerk
Stand der Vorbereitungen:
- RAK und MAB werden eingefroren
- AACR2 wird zu RDA weiterentwickelt
Argumente pro MARC:
- MAB ist eingefroren
- gemeinsames Normdatenformat?
- Worldcat wird immer wichtiger, bisher muss immer nachbehandelt werden, dann möglichst 1:1-Übernahme
- da man mit Schablonen arbeitet, ist die Umstellung für die Katalogisierer nicht sehr groß
- Datenverluste bei der Konvertierung -> Nacharbeiten sind erforderlich
- Import- und Exportroutinen müssen auf jeden Fall angepasst werden
-> Katalogsysteme der Zukunft werden MAB nicht mehr unterstützen
Ziele der Expertengruppe:
- Übertragung ohne Datenverlust
- Verwendung der 9er-Felder für anwenderspezifische Felder
- Beibehaltung der Verknüpfungen (Buch und Aufsatz-Vernküpfungen sind vorhanden, Serien und Stücke, sowie Mehrbändige Werke sind Problembereiche)
- Erfassung kompletter Bandsätze (d.h. um Verknüpfungsinfo angereicherr mit geringem Katalogisierungsmehraufwand)
- Beibehaltung Schlagwortketten
Nächste Schritte:
- Konvertierung der Titeldaten
- Aufbau und Setup einer marc-basierten Datenbank
- Test der Aleph-Funktionalitäten in der Marc-Umgebung
- Konzept für die notwendigen Funktionalitätenerweiterungen
- ggf. Konzept für Schlagwortketten
- Konzept für Kommunikationsschnittstelle mit Normdaten
- Optimierung der Schnittstellen mit dem Lokalsystem
- Zeitplan
- Kostenabschätzung mit Ex Libris
Der Umstieg wird als wichtig erachtet, um in eine zukünftige Systemwelt zu kommen. Der BVB sieht einen Umstieg jetzt als kostengünstiger an.
OBVSG[edit]
Argumente:
- zusätzliche Funktionalitäten sind notwendig, Verschlechterungen sind zu erwarten, Schulungen werden erforderlich, weniger Leistungsfähigkeit, z.B. bei Verlinkung, usw.
- URM kommt; ist MARC21 dann vorteilhaft?
- Umstellung betrifft alle Lokalsysteme -> viel Aufwand und hohe Kosten
Da keine Vorteile gesehen werden, wird der OBSVG nicht umsteigen
Digitale Langzeitarchivierung mit Ex Libris Rosetta - P. Hess (Ex Libris)[edit]
Motivation: Es kommt immer wieder zu Datenverlusten, weil die entsprechende Software oder Hardware nicht mehr vorhanden ist. Eine regelmäßige Anpassung der gespeicherten Daten ist immer dann notwendig, wenn es Änderungen bei der Hard- oder Software gibt. Alle Institutionen, die digitale Daten speichern und verwenden, müssen sich dieser Verantwortung stellen und entsprechende Workflows planen bzw. Systeme einsetzen.
OAIS-Referenzmodell (Open Archival Information System) regelt das Zusammenspiel von
- submission information package (producer)
- ingest, archival information package
- dissemination information package (consumer)
National Library of New Zealand ist seit Ende 2008 mit Rosetta in Produktion. Ursprünglich hatten sie Digitool evaluiert und 72 Punkte bemängelt, die nicht erfüllt wurden, für die Langzeitarchivierung aber erforderlich sind. Es wurde eine Entwicklungspartnerschaft von 2007-2010 abgeschlossen. Die Entwicklungen sollen aber natürlich für alle Kunden relevant sein, deswegen wurde eine Peer Review Group (weltweite Besetzung) miteingebunden.
Open-Platform-Eigenschaft ermöglicht die einfache Integration von Dritt-Tools z.B. für Web Harvesting. In Neuseeland wurde z.B. das deposit-tool durch das Webcurator Tool (entwickelt in Kooperation mit British Library) ersetzt.
Zusammenfassung
- Der Launch von Rosetta war im Januar 2009
- Erfolgreiche, professionelle Umsetzung
- Dank der Open-Platform-Strategie werden die Vorteile einer Standardsoftware, wie z.B. Investitionsschutz und Nachhaltigkeit mit der Flexibilität von OpenSource verbunden. Communityaufbau wird noch mal betont.
Was leistet die Software? (Nachfrage während der Diskussion)
- Formatdatenbank: welche Formate sind risikoreich, Risikomanagement
- Unterstützung bei Strategieentwicklung: wie reagiert man auf Risiken, Wie geht man mit den Daten um
Weiterlesen:
- http://www.exlibrisgroup.com/category/ExLibrisRosettaOverview
- http://de.sun.com/sunnews/events/2009/bibsummit/pdf/13-philip-hess.pdf (sehr ähnliche Folien)
Aleph-DACH Study Report - R. Schmidt (hbz), N. Jahn (UB Bielefeld)[edit]
Unter der Überschrift "ILS - ein unvollendetes Projekt?" stellt N. Jahr die Ergebnisse einer Befragung zur Zukunft von Integrierten Bibliothekssystemen vor, die 2008/2009 unter Aleph-Anwendern durchgeführt wurde.
Ausgewählte Kernaussagen:
- grosse Bandbreite an Wahrnehmungen über die Anforderungen an Bibliotheksautomation. Häufig wurde die Einschätzung gegeben, dass Aleph als Gesamtsystem zu "mächtig" ist; man wünscht sich eher ein Basis-/Kern-System mit funktionsbezogenen Modulen (wenig konkrete Beispiele)
- gefühlte Diskrepanz zwischen dem Wunsch, Arbeitsgänge zu rationalisieren und den technischen Lösungen, z.B. die getrennte Administration von physikalischen und digitalen Medien. Fazit: Aleph ist ineffizient in der Anschaffung und Betreuung, weil man nicht alle administrativen Aufgaben in der Bibliothek damit abdecken kann
- Bedarf an Entwicklung von lokalen Lösungen (-> aber Eigenentwicklungen wurden torpediert, weil sie nur schwierig auf neue Aleph-versionen migriert werden konnten -> Webschnittstellen)
- Metadatenaustausch als Schlüsselanforderung für die Rationalsierung von Arbeitsgängen (-> Integration von Drittanbietern)
- Support und Kundenbeziehung: sehr emotional - sowohl positiv als auch negativ. Befürchtung bzgl. Einstellung von Aleph -> Loyalität und reibungsarmer Übergang
- Wunsch nach flexiblen Preismodellen (wenn im Rahmen der "Open Software Strategie" stärker Eigenleistungen erbracht werden, muss sich dass auch im Preis niederschlagen)
Stellungnahme von ExLibris:
- Die Aussagen aus der Studie bestätigt den eingeschlagenen Weg (URM) -> Flexibilität der Lösung versus monolitisches System
- Widersprüchlich: Wir brauchen was neues, aber es darf sich nichts ändern
- Schwerpunkt auf Tools zur effizienten Verwaltung von bestehenden Aufgaben, Tools zur Bewältigung von neuen Aufgaben
Weiterlesen: Weiterführende Informationen zur Studie finden sich auf der IGeLU-Webseite
Ex Libris: Strategie und Produktroad Update - A. Kaschte (Ex Libris)[edit]
Die Erwerbung von Print- und elektronischen Medien erfolgt nicht mehr getrennt. Dieser Workflow sollte sich auch in einer gemeinsamen Software spiegeln: URM (Unified Resource Management)= Aleph + Verde + neue Funktionalitäten
Da die Kunden schlankere Module wollen, werden nicht alle Funktionalitäten in URM übernommen werden.
Zum neuen Ex Libris Framework gehört auch URD (Unified Resource Dissemination and Discovery)= Primo + MetaLib
Ein dritter wichtiger Bestandteil sind die Data Services (SFX Knowledge Base + metadata management [Katalogisierung]), die sowohl für URM als auch für URD relevant sind.
Neue Features / innovative services in URM:
- web2.0-Features (z.B. Chat, Foren, ...) für Bibliotheksmitarbeiter, die zusammenarbeiten, z.B. bei Verbünden
- user-driven and pay-per-user acquisition
- fuller integration with campus systems
URM is offered as a SaaS (hosting)
- web browser user interface only (es muss kein Client mehr installiert werden)
- global and local saas installations
URM technology
- one installation can install it all (functionality enabled separately)
- one service pack for all
- one architecture
- one data base for all
- one solution for consortia, scalability
- one Ex Libris infrastructure (es gibt für jedes Modul dieselben Funktionalitäten, z.B. logging, statistics, usw.)
- one hardware
- one standard for APIs (x-services, webservices, soa)
- one software infrastructure
- one set of tools
Inventory
- verschiedene contents verwalten
- support advanced func, z.B. versionierung
- keine descriptitve metadaten
metadata management
- centralized environment
- Kosten reduzieren bei der Verwaltung
library zone (neu eingeführt)
- die volle hoheit über meine titeldaten (MAB wird es nicht mehr geben)
- peer-to-peer cataloging (crosswalks), im Prinzip Fremddatenübernahme
community zone
- Verbundkatalog, Replikation, Normdaten, Katalog eines Anbieters als Service vorgehalten
- mehrere Sektionen, z.B. Mehrsprachigkeit, spezifische Verschlagwortung
- transparent für andere
virtual zone
- keine Datenhaltungszone, sondern Zugriffsprogramme, z.B. Z39.50-Server
- Zugriffe zu DNB, WorldCat, ...
- Kommunikation mit Drittanbietern
Administrative hierarchy
Konfigurationen und Zugangsrechte können vererbt werden: von root über consortia, institution bis department.
Es ist aber auch möglich völlig unabhängig von den anderen zu arbeiten; man sieht nur die eigene Sicht und auch die anderen haben keinen Einblick.
Aleph wird weiterhin unterstützt, aber es wird keine Verbesserungen mehr für MAB geben.