This is a read only archive of pad.okfn.org. See the
shutdown announcement
for details.
bibtag15_data-hub-workshop
Offroad-Workshop zu Open Bibliographic Data auf dem #bibtag15
- Thema: Austausch zwischen NutzerInnen freier Discovery-Systeme, insbesondere zu einem Data Hub "light"
- Zielgruppe: IT-Menschen in Bibliotheken, die freie Discovery-Systeme einsetzen und ggf. weiterentwickeln
- Termin: Mittwoch, 27.5. 19-23 Uhr (gemäß Doodle http://doodle.com/knt2k529nv59beke)
- Ort: Privatwohnung direkt beim Messegelände/Bibliothekartag: Saturnweg 23, 90471 Nürnberg (https://www.google.de/maps/place/Saturnweg+23,+90471+Nürnberg/ ) - bitte unter 0179/6605650 "klingeln"
- Rahmen: Als "Social Event" mit Pizza-Bestellen, Eis und Bier
Ausgangsidee:
- Kooperation zwischen Discovery-System-BetreiberInnen im Geiste des "Libraries Empowerment Manifesto": https://speakerdeck.com/lobid/the-libraries-empowerment-manifesto | http://etherpad.lobid.org/p/LEM
- Konzept des libOS-Antrags https://www.hbz-nrw.de/dokumentencenter/veroeffentlichungen/libos_antrag.pdf aufgreifen und zunächst als ersten Schritt am Beginn der Prozesskette ansetzen, also Standardisierung im Bereich der Datenquellen -> ein Data Hub "light" aufbauen.
- Alle Bibliotheken,die ein freies Discovery-System einsetzen, müssen sich derzeit Metadaten-Pakete mühsam zusammenklauben. Ein zentrales Register mit beschreibenden Daten wäre eine Hilfe für alle, ganz unabhängig von den eingesetzten Werkzeugen und der Verbundzugehörigkeit.
- Zur Bereitstellung von offenen Datensätzen hat sich die Software CKAN der Open Knowledge Foundation gut etabliert, vgl. http://ckan.org/ | https://github.com/ckan/ckan . Unter http://datahub.io/organization/bibliographic liegen bereits einige Datensätze oder Verweise, die jedoch nicht gepflegt werden.
- Vorschlag: Jemand aus der Gruppe setzt eine CKAN-Instanz auf und alle erklären sich bereit dort ihre Datenquellen für die Discovery-Systeme abzulegen und zu dokumentieren. Jede Datenquelle erhält eine ID und wird damit referenzierbar. Es werden über die Kommentarfunktion Tipps zur Prozessierung ausgetauscht. Ein Maintainer je Datenquelle erklärt sich bereit diese aktuell zu halten (Daten + Dokumentation).
- CKAN hat eine schöne API http://docs.ckan.org/en/latest/api/index.html mit der Upload und Download automatisiert werden können. Damit wäre es möglich, die dort hinterlegten Daten als Quelle für die Discovery-System-Updateroutinen einzusetzen. Datenanbieter können ebenfalls Daten automatisiert hochladen. Interessant wäre es auch neben den Quelldaten die von den jeweiligen Bibliotheken prozessierten Metadaten abzulegen (als Orientierung und ggf. zur Nachnutzung). CKAN hat Harvesting-Funktionen, so dass bereits offen bereitstehende Daten zusammengeführt werden können, siehe http://ckan.org/features/#federate.
- Ein Teil der üblichen Skript-Vorprozessierung könnte innerhalb CKAN erfolgen, da Extensions (Python) http://extensions.ckan.org/ möglich sind. Denkbar wären Hintergrundprozesse, die einfache Formatmigrationen erlauben, sobald eine Datei hochgeladen wurde - damit diese automatisch in mehreren Formaten zur Verfügung steht.
- Zur Einordnung siehe auch Skizze zum Datenfluss im Tweet: https://twitter.com/felixlohmeier/status/598275088828473344
Agenda / Ergebnisse:
1. Vorstellungsrunde und Bestandsaufnahme Werkzeuge/Datenquellen
- siehe unten (TeilnehmerInnen)
2. Vorstellung und Diskussion der Idee mit CKAN kurzfristig ein zentrales Register für bibliografische Datenquellen aufzubauen
- siehe oben (Ausgangsidee)
- Politische Rahmenbedingungen: Verbünde müssen einbezogen werden
- Rechtliche Rahmenbedingungen: Lizenzverträge verhindern häufig die Weitergabe der Daten
- Erster Schritt: Register für Datenquellen
- Technische Dokumentation der Bezugsquelle
- Austausch von Erfahrungen, Dokumente anhängen
- Kriterien, welche die Inhalte der Lizenzverträge beschreiben
- Mögliche Adressaten: FID Kompetenzzentrum für Lizenzierung elektronischer Ressourcen
3. Erwerbung und Discovery durch Manifesto verknüpfen?
- Eine Mischung aus Erwerbungsrichtlinien (Nationallizenzen)
- Fünf-Sterne-Maß für Nachnutzbarkeit der Datenquellen
4. Austausch zu präferierten Formaten, Schemata, Konventionen
- Gemeinsamer Nenner auf Basis von Openurl als Parallelformat zu MARC (Beispiel Volume/Issue)
- Solr als Document Storage statt nur als Suchmaschinenindex analog zum Vorbild GBV Findex, wo Bibliotheken sich Daten abziehen können (mit Updates)
- sollte Link zum Fullrecord beinhalten
5. Mögliche Analogien
- Sherpa/Romeo
- Repository Ranking
Nächste Schritte:
- Geteilte Knowledge Base Dresden/Leipzig? Rücksprache mit Erwerbungsabteilungen
- Rücksprache mit BSZ (Stefan Winkler) + GBV (Till Kinstler, Gerald Steilen)
- BSZ: UB Leipzig
- GBV: TUB/HH + SUB HH
- ggf. Thema in jährliches VuFind-Treffen einbringen (UB Leipzig)
- ggf. Rücksprache mit Erwerbungskonsortien (GASCO, usw.)
- Prüfung Software für Register (CKAN, Sherpa/Romeo, Repository Ranking, ...)
Termine
Weitere Fragen (nicht diskutiert):
- Technischer Austausch zu Funktionen der Software
- Welche bestehenden Systeme könnten angezapft werden (Harvesting)?
- Welche Dokumentationen von Datenquellen liegen schon vor (z.B. intern in Bibliotheken)?
- Wer hätte Interesse die zentrale CKAN-Instanz zu betreiben?
- Organisatorisches (Schema für Beschreibung der Datenquellen, Formate, auch nicht-offene Datensätze in privaten Repositories dokumentieren?, ...)
- Erweiterungen: Was kann ggf. "innerhalb CKAN" bereits prozessiert werden? Wer würde Erweiterungen entwickeln wollen?
- Externe Datenanreicherungstools könnten CKAN-API nutzen für Down- und Upload
- Maintainer für Datenquellen, wer übernimmt organisatorische Verantwortung
- Allgemeines
- Austausch zu Werkzeugen (Datentransformation, Datennormalisierung, Anreicherung, Präsentation)
- Gründung einer Initativgruppe von Betreibern freier Discovery-Systeme?
TeilnehmerInnen:
- Hans-Georg Becker (UB TU Dortmund) | Index Summon + ILS-Daten | Frontend Eigenentwicklung (https://www.ub.uni-dortmund.de/katalogplus/, Java/XML/XSLT, Entscheidung gegen VuFind, da Einbindung des Index in unterschiedlichen Produkten) | wir wollen CrossRef und mehr
- Lambert Heller (TIB Hannover) | bisher PICA-basierter Katalog, zusätzlich Eigenentwicklung "getInfo" (https://getinfo.de/ ,160 Mio. Datensätze, Index aus unterschiedlichen Datenquellen, Volltexte, siehe Datenbankauswahl auf der Webseite, Metadaten CC0) | Interessenschwerpunkt: open metric (Crossref-DOI-Eventtracker)
- Felix Lohmeier (SLUB Dresden) | finc+d:swarm, eigenes TYPO3-Katalogfrontend (typo_find SUB Göttingen)| fincAI-Artikelindex (siehe Björn M.) | gemeinsame Infrastruktur mit UB Leipzig
- Jan Frederik Maas (SUB Hamburg) | VuFind (beluga) | Primo Central (ursprünglich eigener Solr-Index, dann mit Version 2.0 GBV-Discovery Index und erst mit Version 3.0 zu Primo Central) | Konsortialsystem mit 11 Bibliothekskatalogen
- Sebastian Meyer (SLUB Dresden) | s. Felix L.
- Björn Muschall (UB Leipzig) | finc (+Nutzergemeinschaft), VuFind-Katalogfrontend | fincAI-Artikelindex (CrossRef, JSTOR, Zielgruppe Sachsen), zahlreiche Datenquellen (>50) | Interesse Idee von Stefan Winkler vor einigen Jahren: Solr-Indizes dezentral | Technik: Solr (Index, Mandantenfähig), SolrFusion (https://github.com/outermedia/solr-fusion, Zusammenschalten mehrerer Solr-indicies mit unterschiedlichen Schemas, Ranking-Problematik)
- Jens Nauber (SLUB Dresden) | s. Felix L.
- Beate Rajski (UB TU Hamburg/Harburg) | VuFind (beluga / TUBfind) / Primo Central (Lizenz bis Ende 2016, zusammen mit SUB Hamburg)| + GBV zentral + lokaler Index (Repository, Website + Katalogdaten(Fallback))
- Leander Seige (UB Leipzig) | s. Björn M.
Weitere Interessenten (die aus Termingründen nicht teilnehmen können):
- Jens Ludwig (SBB PSK Berlin)
- Rudolf Mumenthaler (HTW Chur)
- Heinz Pampel (GFZ Potsdam)
- Roland Bertelmann (GFZ Potsdam)
- Christian Pietsch (UB Bielefeld - BASE) @ChPietsch
- Adrian Pohl (hbz)
- Christof Rodejohann (SLUB Dresden)
- Jan Schnasse (hbz)
- Ralf Stockmann (SBB PSK Berlin)
- Jens Wonke-Stehle (SUB Hamburg)
- Martin Blenkle (SuUB Bremen)
- Johann Rolschewski (ZDB)
- Stefan Winkler