Difference between revisions of "Trip Report: Aleph SMUG DACH Meeting 2009"
| Line 22: | Line 22: | ||
=== Verbundübergreifende Kataloganreicherung - J. Brandauer, V. Babitchev (OBV) === | === Verbundübergreifende Kataloganreicherung - J. Brandauer, V. Babitchev (OBV) === | ||
=== Primo-Einführung im OBV J.Brandauer, V.Babitchev (OBV) === | === Primo-Einführung im OBV - J. Brandauer, V.Babitchev (OBV) === | ||
=== Primo-Einführung im KOBV S.Lohrum (KOBV), A.Sabisch (UB FU Berlin) === | === Primo-Einführung im KOBV - S. Lohrum (KOBV), A. Sabisch (UB FU Berlin) === | ||
=== Abbildung heterogener Metadaten in Primo M.Pfeffer, B.Kaldenberg (UB Mannheim) === | === Abbildung heterogener Metadaten in Primo - M. Pfeffer, B. Kaldenberg (UB Mannheim) === | ||
=== Primo Update S.Kuck (Ex Libris) === | === Primo Update - S. Kuck (Ex Libris) === | ||
== Montag: Aleph Session == | == Montag: Aleph Session == | ||
Revision as of 10:08, 12 May 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 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]
Benachrichtigungsdienst für ZSen-Abos über RSS - M. Pfeffer (UB Mannheim)[edit]
Generischer Link Resolver (GLR) - M. Kratzer (BSB München)[edit]
Verbundübergreifende Kataloganreicherung - J. Brandauer, V. Babitchev (OBV)[edit]
Primo-Einführung im OBV - J. Brandauer, V.Babitchev (OBV)[edit]
Primo-Einführung im KOBV - S. Lohrum (KOBV), A. Sabisch (UB FU Berlin)[edit]
Abbildung heterogener Metadaten in Primo - M. Pfeffer, B. Kaldenberg (UB Mannheim)[edit]
Primo Update - S. Kuck (Ex Libris)[edit]
Montag: Aleph Session[edit]
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:
- export der IRD mit "p_export". Die relevanten Suchparameter (z.B. Anfrage) sind in lokalen Feldern im IRD record untergebracht.
- initialisierung des konfig files aus den parametern im export
- aufruf util/s/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]
s. http://www.exlibrisgroup.com/category/ExLibrisRosettaOverview
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"
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
- nutzer möchten zugang zu lokalen und verteilten informationen
- 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)