Trip Report: DACHELA Meeting 2013

From MPDLMediaWiki
Revision as of 08:08, 28 February 2013 by Iarndt (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


Participants: Irina Arndt

Date: 26/27 February 2013 in Essen

Summary: DACHELA is an interest group (formerly Aleph-D.A.Ch and SMUG-D-A-CH-Li-Lux) representing ExLibris customers in German speaking countries. The group organizes annual meetings to facilitate an exchange of information among customers and between them and ExLibris. This year's meeting focused on following aspects:

  • Primo
  • special applications for Aleph


Links and Resources[edit]



Subjects/Talks[edit]

Dienstag, 26. Februar[edit]

Aktuelle Produktentwicklungen bei Ex Libris[edit]

Referent: Dr. Axel Kaschte, Strategy Director Europe, Ex Libris

  • Strategy 2013
  • PCI
  • 500 Mio recs
  • 1 Mio searches / day
  • Hosting/Cloud:
  • 59% aller neuen 2012-Projekte gehostet/cloud-basiert
  • Strategieleitsatz: "software as a service in every part of the company"
  • Hauptziel Alma derzeit: Umsetzung
  • Professional services:
  • Alma implementation team established
  • initial implementation knowledge built up
  • standard methodology developed
  • global implementation tools were developed (Daten Extraktiona aus Aleph auf "Knopfdruck", Feststellung, dass jedes Aleph anders genutzt wird)
  • FU Bozen live mit Alma & Primo since 2.1.2013 (von Bond)
  • parallel gab es in 2012 noch 8 neue Aleph-Projekte in Europa


  • Open Access in PCI:
  • open access articles from hybrid journals in PCI
  • harvest inst. repositories


  • Alma:
  • 10 live Alma
  • 120+ committed to Alma
  • 20 Implementierungsprojekte in Arbeit
  • Einsatz von Alma mit anderem discovery system möglich
  • "wer Alma nutzt, wird sein SFX damit ablösen", unklar, ob "kann" oder "muss"
  • ExL hat sich zu Aufgabe gemacht, einen zentralen Datenservice (z.B. auch mit eBooks-Metadaten) in der "community zone" von Alma zur Verfügung zu stellen
  • wer liefert in den community catalog? derzeit: Lieferantendaten ohne Qualitätsprüfung; nächster Schritt: Beiträge aus community auch möglich (noch keine Ideen zur Moderation, "Experimentierfeld")
  • Datenanalyse: descriptive analystics, prediction analytics, prescriptive analytics; vogefertigte reports können beliebig erweitert werden; basiert auf Oracle Business Intelligence fest in Alma integriert, Alma ohne dieses Produkt nicht vorgesehen
  • im Moment nur Szenarion für Alma als Lokalsystem, nicht für Alma als Verundsystem

Ex Libris Support Update[edit]

Referent: Martin Büscher, European Support Manager, Ex Libris

  • Verfügbarkeit Cloud (uptime)
  • extern garantiert: 99,5 %
  • intern 99,8 %
  • tatsächliche Uptime: 99,92%
  • nicht eingerechnet sind Wartungsfenster (z.B. Server Updates)
  • neue Telefonbefragung zu abgeschlossenen SIs, Kunden werden zu zufällig ausgewählte SIs befragt, 260 calls seit August (davon 62 calls zu Aleph), Kundenzufriedenheit bei Alma und Primo deutlich geringer als z.b. bei Aleph Support (7,3 zu 8,2)
  • Ergebnisse aus Telefonbefragung bisher:
  • häufigste Beschwerden: Beantwortung dauert zu lange
  • mehr Statusupdates erwünscht
  • erheblich mehr Supportincidents für Primo nach Primo-Versionswechsel von 3 auf 4
  • neues Infokonzept für Primo/Alma-Neuerungen: WalkMe = Information *im* Produkt über neue Funktionen nach einem Software-Update
  • Ziel: Zusicherung bestimmter Antwortzeiten je nach SI-Priorität basierend auf SLA, Pilotphase seit Feb. 2013
  • salesforce wird neues CRM (löst Pivotal ab, Ende 2. Quartal 2013 Einführung für alle Kunden und Produkte)


Entwicklung eines eigenständigen Primo-Frontends – Erfahrungsbericht[edit]

Referent: UB Paderborn: René Sprotte

  • UB Paderborn hat ein Primo Frontend basierend auf Ruby & Ruby on Rails entwickelt, enthält etliche "Paderborn-Besonderheiten" (z.B. keine Anzeige von Standorten möglich) und ist daher nur zu Inspiration, nicht aber zu Nachnutzung geeignet

Primo und das Semantische Netz[edit]

Referentin: UB Mannheim: Dominique Ritze


FAQ Session (Liste der gemeldeten Fragen)[edit]

Moderator: Andreas Sprick UB Essen

  • Fragen zu MARC/RDA-Umstieg werden im Rahmen der Session von Hrn. Hamedinger am Folgetag beantwortet


Mittwoch, 27. Februar[edit]

MARC - AlephSEQ(MAB): Wegebau zwischen Skylla und Charybdis[edit]

Referent: Österreichischer Bibliothekenverbund Wien: Wolfgang Hamedinger

  • Einleitung
  • DNB:
  • GND bereits im (adaptierten) MARC21-Format
  • Kollateralschaden im Rahmen GND-Implementierung: z39.50 zugang auf MAB2-Daten funktioniert nicht mehr
  • ab 1.7.2013 ausschließlich Lfg. in MARC21 (Dialekt DNB-MARC), ZDB, Deutsche Nat.Bibliographie, keine Lieferung von BNB-Daten mehr, Keine Lieferun von Casalini-Daten mehr
  • MAB2 als Austauschformat ist Vergangenheit
  • Internformat in Verbünden MAB2-basiert
  • Formatdefinition noch nicht ausreichend stabil
  • DMARC entspricht nicht LoC-MARC
  • DNB stellt Anpassungsanträge zu MARC21 an MARBI
  • Ankündigung der DNB für Juli 2013 erzeugte Handlungsdruck
  • Konsequenz: analog zum GND-Projekt wurde ein gemeinsames Vorgehen der 4 Aleph-Verbünde mit ExL aufgesetzt
  • Exkurs MARC/MAB
  • beide Formate sehr alt (krude Trennzeichen, MAB2-Zeichenkodierung vorsinflutlich und unbrauchbar für Orig.schriften)
  • Syntaxstrukturen für beide Formate ähnlich: Kategoriearchitektur, Feldbezeichnung, zwei Indikatoren, Unterfeldtechnik, Teilfeldtrenner
  • Abbildbarkeit in moderner Technologie möglich (UTF-8 bedingt: Verlust der Unterscheidung von Trema und Umlaut)
  • Aleph sequential format (ASEQ)
  • Internformat in MARC und MAB-Ausprägung (Grundsyntax identisch, Semantik unterschiedlich, Systemfunktionalitäten teilw. untersch.)
  • interne Codierung in utf-8
  • verwendet durchgängig MARC-inspirierte Unterfeldtechnik
  • Umweg über Erzeugen/Laden von MAB2 unnötig und bei erweitertem Zeichensatz kontraproduktiv
  • aus den MARC-Dateien wird direkt ASEQ erzeugt


  • Zum Projekt
  • BVB, hbz, kobv, obvsg (Projektleitung)
  • Start: 20.9.2012
  • Aufsetzen eines gemeinsamen Wikis beim kobv (für Konkordanz, Implementierungsdokumentation)
  • interner Workshop in Wien
  • Workshop mit ExL Ende Januar
  • Ziel: Ermöglichung von DNB/ZDB Titeldaten und ZDB-Bestandsdaten
  • Erstellung einer gemeinsamen Konverter-Version (1.0), Funktionsumfang ist im wiki beschrieben, enthält (noch) nicht Originalschriften
  • Szenario Österr. Verbund: Import/Export s. Grafik
  • Implementierung
  • DNB nun selbst unter Zeitdruck
  • daher Konkordanzen stark Pica-lastig , im Aleph-Umfeld mühsam zu verwenden
  • neutrale Formatbeschreibung fehlt (wie z.B. für ZDB-Titel)
  • Beschreibung oft unpräzise und unvollstädnig
  • man braucht Beispieldaten, um präzise testen zu können
  • dennoch: Erarbeitung der Konkordanz DNB/ZDB->Alephseq
  • Entscheidung über Art der Umsetzung:
  • Aufbohren Aleph-interner Methoden
oder
  • externer Konverter
  • Entscheidung für: Implementierung der convtb-Technik
  • convtb Grundlagen
  • Tabellengesteuerte Konvertierung (Mischung Konfiguration / Programmiersprache)
  • Erweiterung der schon vorhandenen convit-Fix-Funktion
  • Aufruf mehrerer Funktionen, Konditionen pro Feld möglich
  • Feldkonkordanz im wiki dokumentiert (in convtb-Tabelle nur schwer leserlich)
  • Erweiterung des Internformats war notwendig, um keine Informationen zu verlieren
  • gemeinsame Beauftragung von Erweiterungen für p_manage-42 /p_oairep_42
  • Spec der fehlende Methoden der convtb ist erfolgt
  • Version 1.0 des Konverters wird zum Bibliotekartag 2013 fertig sein
  • schrittweiser Einbau in Produktionsumgebung ab Mai 2013
  • Zusammenfassung
  • Verbünde stellen Datenversorgung für ihre Bibs sicher
  • Anforderung an DNB: Lieferschnittstelle muss stabil beschrieben werden
  • die Technik geht via ServicePack in Version 21 ein
  • allgemeine Prametrisierung für dnb-marc wird bereitgestellt
  • nicht selbsterklärend, muss Schritt für Schritt nachvollzogen werden -> Einarbeitungszeit bei Nachnutzung einkalkulieren
  • Geschwindigkeit der Weiterentwicklung des Marc Exports abhängig vom laufenden Projekt
  • Lokalsysteme müssen nicht zwingend bis Sommer auf V21 umstellen, aber Verbünde eigentlich schon
  • Verbünde empfehlen, auch die Lokalsysteme bald auf Version 21 zu migrieren
  • Nicht-Verbundteilnehmer sollten mit ExL klären, wie (und mit welcher Version) der Konverter (oder auch nur Teile davon) integriert werden kann; es empfiehlt sich zu analysieren, in welchem Kontext Fremddaten genutzt werden
  • Zeitplan für Pica-Verbünde sollte direkt an deren Lokalsysteme kommuniziert werden, hier sind den Aleph-Verbünden keine Details bekannt


Ein Buchbinde-Management-Modul[edit]

Referent: UB Trier: Jens Weber

  • Buchbindeaufträge wurden mit zwei Programmen (i3v, Excel) außerhalb von Aleph verwaltet
  • Entwicklung eines Zusatzmoduls außerhalb von Aleph
  • Hauptprogramm in cSharp entwickelt, Datenablage in MySQL DB, Desktop-Modul
  • lesende Anbindung an Aleph via X-Server
  • Übernahme Titel- und Aboinfos aus Aleph, aber keine Rückgabe von Infos an Aleph
  • Hinterlegung von Standards (Bindeart, Einbandfarbe etc.) möglich
  • Bindeanweisung direkt durchs Programm druckbar, ebenso Listen einer kompletten Buchbinderlieferung
  • Bei Rückgabe kann die Lieferung vollständig aufgerufen und komplett oder teilweise zurück gebucht werden
  • diverse Such- und Sonderfunktionen