Trip Report: Aleph SMUG DACH Meeting 2009

From MPDLMediaWiki
Jump to navigation Jump to search


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 are the User Groups in the German speaking countries which

Gründung von Dachela


Links and Resources[edit]

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.
Es funktioniert mittels eines Perl-Scriptes, das den Datenabgleich mit Bibsonomy mittels BibHashkey vornimmt.
Im OPAC 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:

  1. 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.
  2. Insgesamt aber ganz zufriedenstellende Ergebnisse.


Es gibt Überlegungen hierzu eine HBZ-Fortbildung als Workshop anzubieten mit Herrn Falltert (UB Mannheim), der das Ganze umgesetzt hat.
Die Skripte können nachgenutzt werden.

Frage zur Nutzung: In den ersten 10 Tagen wurden 240 Tags vergeben, ohne dass die Funktion beworben wurde.

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 gebraucht).
Abgefragt wird (mit Perl-Skript):

  1. per CGI die ISSN vom Apache Webserver
  2. Abfrage 1: Abo für ISSN prüfen
  3. Abfrage 2: Exemplare für ABo prüfen
  4. automatischer XML-Ausgabebefehl für RSS


Haußptprobleme
Anbindung an Papierexemplareingang funktioniert nicht bei "online only"

Generischer Link Resolver (GLR) - M. Kratzer (BSB München)[edit]

Grundziel: generischer Link-Resolver aus dem institutionelle Link-Resolver schöpfen können. DFG-Fördermittel vorhanden.
Zum allgemeinen Verständnis:

Auflistung der unterschiedlichen "Linking-level" von Volltexten:

  1. Zeitschrift (ISSN)
  2. Inhaltsverzeichnis von Band/Heft
  3. Artikel selbst (Angaben zu Vol, Iss., P. oder sonstige individuelle URL)

Bei freien Angeboten allerdings das Problem, dass hier oft nur Zugriff auf Zeitschriften-Ebene möglich ist, weil die Syntax-Analyse nciht greift, bzw. die Link-Konstruktion keine Auflösung zu Heft zulässt.

Vorgehensweise:

  1. In EZB grüne Zeitschriften URL wurde abgegriffen von den Zeitschriften-URLs und den Unterseiten.
  2. Auf der Basis dieser URL sollte mittels automatisierter URL-Analyse eine Trennung in Volltext-URLs und NICHT-Volltext-URLs erfolgen.
  3. Der Crawler, der die URLs abgreifen sollte stieß auf verschiedene Hürden:
    1. Volltexte befanden sich zum Teil nicht auf gleicher Domain wie die Journal-Homepage
    2. Volltexte waren zu.T. nur über interaktive Such-Applets zugänglich
    3. 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
  4. 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):
    1. fehlende Semantik-Informationen für die Analyse
    2. zufällige Dokumente-IDs aus CMS erzeugt und nicht analysierbar
    3. pro Zeitschrift musste EIN neuronales Netz trainiert werden
  5. es gab ein Web-Frontend zur Analyseprüfung
  6. gleichzeitig ein Webformular zur Registration freier Zeitschriften mit der Möglichkeiten Informationen für die Analyse einzugeben.

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 in Extraserver "edoc" gespeichert.
Workflow:

  1. Verbunddaten werden per FTP geliefert, Titeldaten in MAB2, dann Normalisierung in Aleph-Sequential
  2. Objekte werden abgeglichen und in edoc gespeichert und die Verbunddatenbank erhält ein Link-Update


Pläne und weitere Schritte:

  • Ideal wäre, noch eine Priosisierung der "Lieferanten"
  • Neuer Objekttyp "html" noch aufnehmen
  • Daten der DNB und des GBV
  • als Workflow sind halbjährliche Einspielungen geplant.

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, 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.
derzeitiger Stand:

  • Exlibris 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 österr. 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 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]

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) vorgesehen
  • offizieller Start geplant für 12.10.09
  • Einsatz als OPAC-Ersatz erst ab Version 3 (voraussichtlich 1.Quartal/2010) sinnvoll, wenn Ausleihe integriert ist

Vorgehen und Probleme:

  • Primo ist nicht "mandantenfähig", d.h. administrativ: jeder sieht alles (und kann Dinge anderer ändern), also kooperatives Arbeiten nötig!
  • Arbeitskreis Normalisierungsregeln ist/wird gebildet
  • OAI-Harvesting ist schlecht dokumentiert
  • Pipes für den Datentransfer anpassen
  • 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.

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.
Einbindung der Nationallizenzen. Hier wurde ein Konverter geschrieben von MAB2 zu MARC-XML
Empfehlungen:

  • GUT nachdenken, welche Daten in Primo geladen werden sollen (oder anderes Portal), weil sie neben den sehr akuraten bibliographischen MAB/MARC-Daten erscheinen.
  • 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)

In Version 3 (1. Quartal 2010):

  • volle Integration der OPAC-Funktionalitäten (Vormerkungen, ...)
  • Recommender Service
  • Metalib-Integration verbessern
  • Website-Harvesting
  • verbesserte Volltextindexierung

Montag: Aleph Session[edit]

Aleph 20 Upgrade - Martin Büscher (Exlibris)[edit]

Verbesserungen in folgenden Bereichen:

  1. 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.
  2. 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 Batch-Jobs
  3. Exemplarbearbeitung
    • "Exemplarset bearbeiten", hier wird es die Möglichkeit einer offline Bearbeitung geben, die dann erst nach "Set speichern" online gehen.
  4. OPAC
    • Meldung beim Einloggen sind möglich, z.B. ob es lokale/globale Sperren gibt,bei offenen Gebühren, bei überfälligen Ausleihen
  5. Systemvoraussetzungen
    • Neu als Datenbank: Oracle 11
  6. 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.
  7. 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]

Verbundschnittstelle für Digitalisierungsprojekte - S. Scholz (HBZ)[edit]

Funktionserweiterung für Aleph-Cluster im Bereich automatische Replikation z.B. von eBooks und ZDB-Daten (mittels Feld 078e)
Produktiv bei BVB ab 21.05.09.
Auslieferung mit Service Pack 2009.

Schnittstellen - von "offline" zu "online" - G. Hupfer (HBZ)[edit]

Vorteile dieses zu beobachtenden Wandels:

  • weniger Schritte notwendig
  • kein Zeitverzug
  • komfortablere Workflows

Nachteile:

  • Tests- und Abnahme bringen erhöhter Aufwand, weil die Umsetzung bei Verwendung dann ja unmmittelbar erfolgt, auch höhrere Aufwand bei Monitoring und Fehler-Handling
  • Abhängigkeit der Systeme untereinander bei sofortiger Wirkung von Datenfehlern, die sich dann entsprechend übertragen
  • Produktionsausfälle an einer Stelle wirken sich stärker bei den abhängigen Systemen aus.

Dateneinspielungen (eBooks) - V. Kriesen (UB Paderborn)[edit]

  • ZDB-Daten werden HBZ gespiegelt (Nutzung von p-manage-42)
  • E-Book-Pakete mit p-manage-18 der kleinen Datenpakete
  • Nationallizenzen - Erfahrung mit p-manage-18 des großen Datenpaketes hat gezeigt, dass es besser ist, hier Teilpakete einzuspielen!

Kassenautomat in Paderborn - J. Borbach-Jaene (UB Paderborn)[edit]

Pilotanwender ILL2 (SLNP) - A. Edelmann (UB FU Berlin)[edit]

Hier gabe 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.
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:
    1. Benutzerstatus fehlte in bor-request-expand
    2. Liste potentieller Lieferanten bietet keine vernünftige Suchmöglichkeit (behoben in V20)
    3. Ausleihnotiz nicht nachträglich korrigierbar
    4. Eingabefeld für Signatur fehlt, heißt jetzt: Bestand! (V20)
    5. Umständliche Navigation zu Exemplar
    6. Wenn migrierte Exemplare nicht sichtbar sind (tab_check_circ ILL-L)
    7. Bestellnummer in Signaturfeld

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 Online Hilfe vorhanden war!
Umstieg geplant für September 2009.

Montag: SFX/Metalib Session[edit]

Ressourcen Monitoring in Metalib - S. Lohrum (KOBV)[edit]

KOBV monitoring tool benutzt "util/s/4". Automatisches füllen des konfigurationsfiles und cronjob oben drauf. Verfahren:

  1. export der IRD mit "p_export". Die relevanten Suchparameter (z.B. Anfrage) sind in lokalen Feldern im IRD record untergebracht.
  2. initialisierung des konfig files aus den parametern im export
  3. aufruf util/s/4
  4. übermittlung der testergebnisse via HTTP request an an monitoring framework, z.B. Nagios

-> code kommt in el commons

Recommender Lösung bX - A. Kaschte (Ex Libris)[edit]

Deutsche Nationallizenzen in SFX - A. Sabisch (UB FU Berlin)[edit]

Dienstag: Plenum Session[edit]

MARC 21 - Stand und Ausblick der Aleph-Verbünde - BVB, hbz, KOBV, OBV[edit]

HBZ und OBV stellen vermutlich in naher Zukunft nicht auf MARC21 als Internformat um, sondern wird 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 spaeter kommen.

Der BVB wird vermutlich auf MARC21 als Internformat wechseln, weil man sich daraus eine Annäherung an die internationale Bibliotheksgemeinschaft erhofft, die auch den Übergang

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.

Digitale Langzeitarchivierung mit Ex Libris Rosetta - P. Hess (Ex Libris)[edit]

links:

Aleph-DACH Study Report - R. Schmidt (hbz), N. Jahn (UB Bielefeld)[edit]

Unter der Überschrift: "ILS - ein unvollendetes Projekt"? "beweiskraft qualitativ-gewonnener Ergebnisse liegt in ihrer narration"

link zu

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 den 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 effiziente Verwaltung von bestehenden Aufgaben, Tools zur Bewältigung von neuen Aufgaben

Kritik:

  • die studie geht zu stark ins detail?

Ex Libris: Strategie und Produktroad Update - A. Kaschte (Ex Libris)[edit]