OpenBibBlog

Das Blog zu OpenBib und OPAC 2.0
Optionen:

Rollenspiele mit Berechtigungen

In der KUG Recherche-Infrastruktur werden Berechtigungen in verschiedenen Bereiche über ein Rollen-Konzept abgebildet. Benutzer sind Rollen zugeordnet, die wiederum fest definierte Aktionen zulassen. Bisher waren genau drei Rollen definiert:

  • admin (Administrator): Nutzer mit dieser Rolle haben kompletten Zugang zu allen Bereichen der Web-Administration. Sie können also entsprechende Resourcen einsehen, erzeugen, ändern und löschen (CRUD)
  • librarian  (Bibliothekar): Nutzer mit dieser Rolle sind typischerweise Institutsbibliothekare und können die von ihnen angelegten Literaturlisten für die Studiengänge des Instituts gesondert als „Offizielle Literaturliste des Instituts“ kennzeichen. Auf diese Weise ist im KUG Recherche-Portal anhand eines Tempel-Icons direkt ersichtlich, welche Literaturlisten von „normalen Nutzern“ erstellt wurden und welche von den jeweiligen Fachbereichen.
  • viewadmin (Portal-Administrator): Nutzer mit dieser Rolle verwalten in der Regel ein eigenes Recherche-Portal, wie z.B. Gentz digital und bekommen gesondert die Berechtigung Textinhalte des Portals über einen Web-Editor selbständig zu ändern.

Jenseits dieser Standard-Rollen ist in der jüngsten Vergangenheit unterschwellig ein Bedarf entstanden, feiner granuliert auf bestimmte Bereiche der Web-Administration zugreifen zu können. Bisher konnte das nur über den Voll-Administrator-Zugriff gelöst werden, was weder in unserem allgemeinen Sicherheitsinteresse noch im Interesse der jeweiligen Nutzer lag.

Aus diesem Grund haben wir unser Rollenkonzept noch einmal punktuell überarbeitet:

  1. Für die Bereiche der Web-Administration können nun zentral in der Konfigurationsdatei portal.yml der Intrastruktur sogenannte Scopes definiert werden. Scopes bezeichnen Gültigkeitsbereiche, für die eigene Berechtigungen definiert werden können. Mögliche Berechtigungen leiten sich direkt aus der REST-Natur des Portals ab und sind create (Erzeugen), read (Lesen), update (Ändern) sowie delete (Löschen) der zugeordneten Resourcen in der Web-Administration.
  2. Zusätzlich können Rollen auf eine oder mehrere Portal-Sichten (views) eingeschränkt werden.

Nutzer mit der Admin-Rolle können ab sofort in der Web-Administration selbständig Rollen definieren und diesen zu allen in portal.yml unter dispatch_rules definierten Scopes CRUD-Rechte zuweisen bzw. sie auf views einschränken. Auf diese Weise könnten nun auch beliebige „Unterbereiche“ in der Administration separat mit Rechten versehen werden und damit auch komplexe Berechtigungs-Szenarien abgebildet werden. Der Einfachheit halber haben wir jedoch lediglich Scopes zu jedem Menu-Punkt der Web-Administration definiert.

Beispiel aus portal.yml für die Aktionen in der Cluster-Verwaltung:

- # Repraesentation: admin_loc/clusters_loc
scope: 'admin_clusters'
module: 'OpenBib::Handler::PSGI::Admin::Clusters'
rule: '/portal/:view/admin/clusters[get]'
runmode: 'show_collection'
representations:
- none
- html
- json
- rdf


- # Repraesentation: admin_loc/clusters_loc
scope: 'admin_clusters'
module: 'OpenBib::Handler::PSGI::Admin::Clusters'
rule: '/portal/:view/admin/clusters/id/:clusterid[get]'
runmode: 'show_record'


- # Repraesentation: admin_loc/clusters_loc: Record show form
scope: 'admin_clusters'
module: 'OpenBib::Handler::PSGI::Admin::Clusters'
rule: '/portal/:view/admin/clusters/id/:clusterid/edit[get]'
representations:
- none
- html
runmode: 'show_record_form'


- # Resource: admin_loc/clusters_loc: Create Record
scope: 'admin_clusters'
module: 'OpenBib::Handler::PSGI::Admin::Clusters'
rule: '/portal/:view/clusters[post]'
runmode: 'create_record'


- # Resource: clusters_loc: Update Record
scope: 'admin_clusters'
module: 'OpenBib::Handler::PSGI::Admin::Clusters'
rule: '/portal/:view/clusters/id/:clusterid[post]'
runmode: 'update_record'


- # Resource: clusters_loc: Update Record
scope: 'admin_clusters'
module: 'OpenBib::Handler::PSGI::Admin::Clusters'
rule: '/portal/:view/clusters/id/:clusterid[put]'
runmode: 'update_record'


- # Resource: clusters_loc: Delete Record
scope: 'admin_clusters'
module: 'OpenBib::Handler::PSGI::Admin::Clusters'
rule: '/portal/:view/clusters/id/:clusterid[delete]'
runmode: 'delete_record'

Hat ein Nutzer dann noch nicht einmal die Leseberechtigung für einen Bereich, dann können wir die Anzeige des jeweiligen Menu-Punktes im entsprechenden Template einfach unterdrücken. Auf diese Weise bekommt ein Nutzer nur die für ihn freigegebenen Bereiche übersichtlich zur Auswahl.

Übersicht aller Rollen

Übersicht aller Rollen

Einschränkung auf Views

Einschränkung auf Recherche-Portale (Views)

Vergabe von Rechten pro Gültigkeitsbereich (scope)

Vergabe von Rechten pro Gültigkeitsbereich (Scope)

Für die Erweiterung des Rollen-Konzeptes musste die Systemdatenbank um die zwei Tabellen role_right und role_view erweitert werden:


CREATE TABLE role_view (
id BIGSERIAL,
roleid BIGINT NOT NULL,
viewid BIGINT NOT NULL
);


CREATE TABLE role_right (
id BIGSERIAL,
roleid BIGINT NOT NULL,
scope TEXT default '', /* eg admin, admin_clusters, ... */
right_create BOOL default false,
right_read BOOL default false,
right_update BOOL default false,
right_delete BOOL default false
);

Und darauf aufbauend musste – unabhängig von der Konfigurierbarkeit in der Web-Administration selbst – schließlich nur noch die Authentifizierungsmethode authorization_successful in OpenBib::Handler::PSGI::Admin entsprechend erweitert werden.

Insgesamt haben wir nun alle Möglichkeiten an der Hand, um gezielt Informationen aus der Web-Administration in der USB und der Universität freigeben zu können.

Unbefriedigende Ausgangslage

Die Aktualisierung von Katalogen in der KUG Recherche-Infrastruktur (Kölner UniversitätsGesamtkatalog) beruht seit jeher auf der Einspielung einer Komplettlieferung der Daten eines jeden Katalogs.

Auf diese Weise werden Tag für Tag mehr als 150 Kataloge mit ihren Daten eingespielt, der überwiegende Restbestand an Katalogen wird wöchentlich aktualisiert und einige wenige (z.B. Digitalisate aus der OpenLibrary) in längeren Abständen.

Obwohl die Aktualisierung in drei Threads parallel abläuft, sind die Datenänderungen des Vortags inzwischen in der Regel erst ab 15 – 16 Uhr des Folgetags für den Endnutzer recherchierbar.

Durch die Migration von Institutsbeständen in den USB-Katalog und zusätzliche Anreicherungen ist allein dessen Aktualisierungszeit von früher durchschnittlich 10 Stunden auf aktuell mehr als 15 Stunden angewachsen.

Aus diesem Grund haben wir nach Möglichkeiten gesucht, bei der nur Titeländerungen (gelöscht, neu angelegt, oder geändert) in einem Recherche-Katalog Einzug in dessen Aktualisierungsprozess halten. Folgende Anforderungen sollten erfüllt werden:

  • Wegen der Heterogenität der Daten-Quellen muß eine systemunabhängige Lösung gefunden werden, die auf alle Kataloge anwendbar ist. Es reicht z.B. nicht, wenn in einigen Datenquellen das Bibliothekssystem die Titel-IDs der Änderungen vorbildlich liefert, in anderen aber keine solche Funktionalität bereitgestellt wird. Die Programmierung verschiedener inkrementeller Aktualisierungsroutinen für verschiedene Daten-Quellen ist nicht zielführend.
  • Eine Lösung sollte sich möglichst nahtlos in die bestehenden Phasen des Ablaufs einer Aktualisierung integrieren und diese unangetastet lassen. Das ist umso wichtiger, da u.a. Katalog-Anreicherungen und katalogspezifische „Sonderbehandlungen“ Teil dieses Ablaufs sind. Daher sollen weiterhin Gesamtlieferungen aller vorhanden Katalogdaten zwingende Voraussetzung auch für eine inkrementelle Aktualisierung sein.

Die grundsätzliche Strategie ist daher:

  1. Nehme eine neue Gesamtlieferung,
  2. bestimme anhand des bisherigen Katalogbestands den Teilbestand der Datensätze, die für eine Aktualisierung überhaupt relevant sind und
  3. Aktualisiere nur diese Datensätze anstelle aller.

Umsetzung der inkrementellen Aktualisierung

Eine wesentliche Voraussetzung für unsere triviale Umzusetzung eines inkrementellen Updates wurde bei den Änderungen der letzten OpenBib-Versionen geschaffen – die Umstellung des MAB2-basierten Metadaten-Formats, in das alle gelieferten heterogenen Daten vereinheitlicht werden, auf eine Kodierung in JSON (JavaScript Object Notation).

Jeder Normdatensatz liegt in den Dateien des Metadaten-Formats (meta.title.gz, meta.person.gz, meta.corporatebody.gz meta.classification.gz, meta.subject.gz und meta.holding.gz) als eine Zeile in JSON-Kodierung vor, z.B. :

{„fields“:{„1209“:[{„content“:“UNummer“,“subfield“:““,“mult“:“001″}],“0412″:[{„content“:“Ebering“,“subfield“:““,“mult“:“001″}],“0435″:[{„content“:“8¹“,“subfield“:““,“mult“:“001″}],“0009″:[{„content“:“HBZ“,“subfield“:““,“mult“:“001″}],“4400″:[{„content“:“lendable“,“subfield“:““,“mult“:1}],“0331″:[{„content“:“Experimentelle Bestimmung und thermodynamische Berechnung der Dampfdrucke von Toluol, Naphthalin und Benzol“,“subfield“:““,“mult“:“001″}],“0038″:[{„content“:“y“,“subfield“:““,“mult“:“001″}],“0519″:[{„content“:“Berlin, Univ., Diss., 1909″,“subfield“:““,“mult“:“001″}],“0027″:[{„content“:“V“,“subfield“:““,“mult“:1}],“0003″:[{„content“:“02.05.2008″,“subfield“:““,“mult“:1}],“0010″:[{„content“:“TT002403298″,“subfield“:““,“mult“:“001″}],“0011″:[{„content“:“TL002408293″,“subfield“:““,“mult“:“001″}],“0100″:[{„supplement“:““,“id“:“1400548″,“subfield“:““,“mult“:“001″}],“0002″:[{„content“:“23.04.2008″,“subfield“:““,“mult“:1}],“0015″:[{„content“:“ger“,“subfield“:““,“mult“:“001″}],“0800″:[{„content“:“a“,“subfield“:““,“mult“:“001″}],“0425″:[{„content“:“1909″,“subfield“:““,“mult“:“001″}],“0359″:[{„content“:“von Jonathan Tong Barker“,“subfield“:““,“mult“:“001″}],“0433″:[{„content“:“39 S.“,“subfield“:““,“mult“:“001″}],“0036″:[{„content“:“m“,“subfield“:““,“mult“:“001″}],“0554″:[{„content“:“U 09.136″,“subfield“:““,“mult“:“001″}],“0410″:[{„content“:“Berlin“,“subfield“:““,“mult“:“001″}]},“id“:“6096939″}

Damit können wir für jeden Datensatz sehr einfach mit kryptographischen Hashverfahren wie SHA1 oder MD5 einen Fingerabdruck, hier z.B.  aa12433a662965b80f706fa82748e4ba generieren.

Zusätzlich wurden die Normdaten-Tabellen in den zugehörigen PostgreSQL-Datenbanken (title, person, corporatebody, classification, subject und holding) um eine Spalte „import_hash“ erweitert, in die beim Einladen der zuvor aus der Einladedatei erzeugte Hashwert wandert.

Auf diese Weise ist es nun sehr einfach möglich, aus den IDs und Hashwerten in der Datenbank und denen einer neuen Lieferung punktgenau die zwischen beiden Datenständen erfolgten Änderungen zu bestimmen:

  • Ein Datensatz muß in der Datenbank gelöscht werden, wenn seine ID nicht mehr in der neuen Datenlieferung vorkommt
  • Ein Datensatz muß neu in die Datenbank aufgenommen werden, wenn seine ID aus der neuen Datenlieferung noch nicht in der Datenbank vorhanden ist
  • Ein Datensatz muß in der Datenbank geändert werden, wenn seine ID sowohl in der Datenbank wie auch der neuen Datenlieferung vorhanden ist, die Hashwerte sich aber unterscheiden
  • Ein Datensatz kann ignoriert werden, wenn seine ID sowohl in der Datenbank wie auch der neuen Datenlieferung vorhanden ist, aber die Hashwerte gleich sind

Diesen Entscheidungsprozessen geht ein Scan der IDs und Hashwerte aus der Datenbank und der neuen Datenlieferung voraus, dessen Ergebnis in einer Datenstruktur status_map festgehalten wird. Aus dieser Datenstruktur kann dann beim regulären Umwandeln der Metadaten mittels meta2sql.pl sehr einfach mit einer Methode analyze_status_map die notwendige Aktion bestimmt werden.

In der konkreten Umsetzung werden diese Aktionen noch weiter vereinfacht, indem Datensatzänderungen als Datensatzlöschung mit nachfolgender Erzeugung eines neuen Datensatzes modelliert werden. Dadurch können auch schnelle Bulk-Insertverfahren auf Seite der PostgreSQL-Datenbank genutzt werden.

Zuerst werden daher alle relevanten Zeilen aus den beteiligten Tabellen (per delete) gelöscht (gelöschte und geänderte Datensätze) und danach alle neuen Zeilen (neue und geänderte Datensätze) eingeladen (per bulk COPY).

Nach dem Scan werden die IDs der zu löschenden und neu anzulegenden Datensätze zusätzlich in zwei eigenen Dateien mit den Suffixen .delete und .insert abgelegt, z.B. title.delete und title.insert. Diese Dateien sind hilfreich, da sie sowohl für eine weitere Beschleunigung des Aktualisierungsprozesses verwendet werden können, als auch für nachgelagerte Programme mit einer eigenen inkrementellen Aktualisierung nachnutzbar sind.

  • Für eine Beschleunigung der datenbankseitigen delete-Aktion in den verschiedenen Tabellen werden die IDs der zu löschenden Datensätze per bulk COPY in eine eigene temporäre Tabelle title_delete geladen, anhand der dann sehr schnell eine Löschung relevanter Zeilen in anderen Tabellen durchgeführt werden kann, z.B. mit

DELETE FROM title_title WHERE source_titleid IN (select id from title_delete);

  • Mit dem Programm update_all_titles_table.pl wird anhand verschiedener Kriterien (ISBN13, BibKey, ISSN, WorkKey) zentral in unserer Anreicherungsdatenbank festgehalten, welche Titel-ID in welchem Katalog welche ISBN13, ISSN usw. besitzt. Mit diesen Informationen werden Funktionen wie „Gleicher Titel in anderen Katalogen“ oder „Andere Ausgaben des Titels“ für den Endnutzer umgesetzt. Ebenso können für Aussonderungsaktionen von Institutsbibliotheken so sehr einfach Titelabgleiche zwischen verschiedenen Katalogen durchgeführt werden. Daher gehört zu einer Aktualisierung des Datenbestandes eines Katalogs auch immer die Aktualisierung der entsprechenden zentralen Tabellen (all_titles_by_isbn, all_titles_by_bibkey usw.). Bisher wurden diese Informationen bei der Aktualisierung eines Katalogs für diesen jeweils komplett gelöscht und danach mit dem neuen Stand wieder eingespielt. Auch hier kann nun sehr einfach mithilfe der beiden Titel-ID-Dateien title.delete und title.insert zielgenau nur noch der sich tatsächlich geänderte Teilbestand aktualisiert werden.

Neben den Einladedateien für die PostgreSQL-Datenbank eines Kataloges erzeugt das um die inkrementelle Aktualisierung erweiterte Programm meta2sql.pl auch Einladedateien für den zugehörigen Xapian-Suchmaschinenindex.

Dementsprechend musste auch das Aktualisierungsprogramm für den Suchindex file2xapian.pl um die inkrementelle Änderung nur einzelner Dokumente erweitert werden. Auch hier wurde bisher ein komplett neuer Index erstellt, der dann den bisherigen ersetzte.

Vorher – Nachher

Welche Änderungen haben sich nun durch die Einführung inkrementeller Updates ergeben. Als Beispiel bietet sich der Katalog der USB-Köln mit knapp 3.35 Millionen Titelnachweisen an.

Bisher dauerte die Komplett-Aktualisierung des Katalogs 15:19:26 Stunden. Wesentliche Anteile sind:

  • 15596.5 Sekunden für die Erzeugung der Einladedateien für PostgreSQL-Datenbank und Xapian-Suchmaschinenindex
  • 6193.86 Sekunden für das Einladen der Daten in die PostgreSQL-Datenbank
  • 17432.3 Sekunden für das Einladen der Daten in den Xapian-Suchmaschinenindex
  • 8580.2 Sekunden für die Aktualisierung der zentralen Daten mit update_all_titles_table.pl

Bei der inkrementellen Aktualisierung des Katalogs kommen wir mit 02:41:18 Stunden aus. Die entsprechenden Anteile sind hier:

  • 1613.76 Sekunden für die Erzeugung der Einladedateien für PostgreSQL-Datenbank und Xapian-Suchmaschinenindex
  • 1220.33 Sekunden für das Einladen der Daten in die PostgreSQL-Datenbank
  • 655.64 Sekunden für das Einladen der Daten in den Xapian-Suchmaschinenindex
  • 274.3 Sekunden für die Aktualisierung der zentralen Daten mit update_all_titles_table.pl

Nahezu konstant bleiben bei diesem Katalog die durchgeführten Schritte der Vorverarbeitung mittels Plugin post_unpack.pl. Hier werden u.a. Teilbestände markiert, so dass sie später einfach geschlossen recherchiert und facettiert werden können. Dazu gehören z.B. Teilbestände einzelner Fach- oder Institutsbibliotheken im USB-Katalog mit anderem Standort ebenso wie thematische Teilbestände (Kunst).

Diese Vorverarbeitungsschritte liegen sowohl bei kompletter wie auch inkrementeller Aktualisierung bei knapp 50 Minuten und gehen zwar in die Gesamtlaufzeit ein, sind aber nicht – wie einige andere auch – gesondert aufgeführt.

Für die Routine-Aktualisierung von Katalogen in der KUG Recherche-Infrastruktur wird wochentags inzwischen nur noch die inkrementelle Variante verwendet. Am Wochenende wird – mit Katalogstand Freitag 18 Uhr – weiterhin komplett aktualisiert. Die Komplett-Aktualisierung hat den Vorteil, dass dann geänderte Parametrisierungen für Recherche-Kategorien für die gesamten Kataloge wirksam werden – und nicht nur für die geänderten und neuen Sätze.

In der Regel sind so wochentags Datenänderungen des Vortags vor 6 Uhr morgens des Folgetages recherchierbar. Die Erweiterung der Aktualisierungsprogramme um ein inkrementelles Update hat sich also gelohnt.

Seit der letzten großen Umstellung von OpenBib in eine REST-basierte Infrastrukturlösung sind bereits etwas mehr als 2 Jahre ins Land gegangen in denen sich in der Perl-Welt – und darüber hinaus – einiges getan hat.

Mehr Möglickeiten mit PSGI

Eine der Entwicklungen betrifft das in die Jahre gekommene Common Gateway Interface (CGI) für Web-Anwendungen. Dieses wird in der Perl-Welt nun mehr und mehr durch ein moderneres Verfahren abgelöst: PSGI, die Perl Web Server Gateway Interface Specification. Inspiriert von WSGI aus der Python-Welt wird durch die Verwendung der PSGI-Spezifikation eine Abstraktionsebene in die Web-Anwendung eingeführt, so daß diese fortan unabhängig vom verwendeten Webserver wird.

Das führt unmittelbar zu deutlich mehr Auswahl an Betriebsmöglichkeiten mit Web- oder besser gesagt PSGI-Servern unter denen die Anwendung ohne Code-Anpassungen betrieben werden kann – egal ob mit Apache2 unter mod_perl oder mod_psgi, FastCGI, uWSGI-basierten Servern, neuen Perl-Servern wie starman oder das mitgelieferte Plack, nginx mit embedded perl und insbesondere auch stand-alone Perl-Programme, mit denen die Anwendung aufgerufen werden kann. Gerade durch letzteres eröffnen sich deutlich verbesserte Debugging- und Testmöglichkeiten, da ein Web/PSGI-Server dazu gar nicht benötigt wird. Die Requests werden einfach an die PSGI-Schicht der Anwendung selbst geschickt.

Zusätzliche Flexibilität geben sogenannte Middlewares. Das sind Verarbeitungsschichten, die in den Abarbeitungsfluss – ähnlich den Request-Cycles in mod_perl – eingreifen und Inhalte on-the-fly verändern können. Beispiele sind z.B. Debugger, Profiler, Umleitung statischer Inhalte (css,images) in Verzeichnisse, SizeLimits als Gegenmaßnahme zu sich aufblähenden Server-Prozessen usw.

Bei der Umstellung auf PSGI haben wir den alten CGI-Modulen vollständig den Rücken gekehrt. Dementsprechend sind in OpenBib auch nicht die Perl-Module CGI::PSGI oder CGI::Emulate::PSGI im Einsatz, mit denen wir Ballast von CGI (und speziell CGI.pm) dann doch weiterhin mit uns herumgeschleppt hätten. Stattdessen haben wir auf Grundlage von Plack::Request ein eigenes Request-Modul OpenBib::Request erstellt, das von Plack::Request erbt.

Für den Einsatz haben wir verschiedene PSGI-Server getestet und gebenchmarkt. Informationen dazu finden sich im Wiki-Artikel „Umstellung auf PSGI„. Unsere Wahl fiel auf den PSGI-Server starman. Dieser beinhaltete den besten Mix aus Performance und Zuverlässigkeit. Wie schon mit Apache2/mod_perl ist ihm ein lighttpd und haproxy vorgeschaltet.

Interessant sind in dieser Hinsicht unsere Benchmarks mit Apache Bench, um die optimale Zahl an Workern für die beste Performance zu bestimmen. Die Benchmarks sagen aus, dass das Optimum bei 4 Workern liegt.

Die Realität sieht hier leider vollkommen anders aus. Mit 4 Workern hält die KUG Recherche-Infrastruktur im Produktionsbetrieb gerade einmal 30 Sekunden durch, bevor sie keine Anfragen mehr beantwortet. Daher betreiben wir sie jetzt zuverlässig mit 20 Workern ohne jegliches Problem. Zum Vergleich: Vorher unter Apache2/mod_perl hatten wir 50 Worker (preforked processes) im Einsatz…

Insgesamt bedeutet PSGI für OpenBib mehr Flexibilität, Einsatzmöglichkeiten (z.B. Web-Spaces mit FastCGI-Support) sowie eine erhöhte Zukunftsfähigkeit als die bisher von OpenBib verwendete konventionelle Web-Serverarchitektur aus Apache2 und mod_perl. Mit starman als PSGI-Server hat sich zusätzlich auch noch die Geschwindigkeit erhöht. Der Preis hierfür war ein sehr umfangreicher Umbau des Programmcodes von OpenBib.

Responsive Webdesign statt eigene Mobil-Version

Ein weiterer Trend bei Webanwendungen ist die einheitliche Bereitstellung der Inhalte über alle Aufruf-Plattformen wie Smartphone, Tablet oder PC hinweg. Komplett separate „Mobil-Versionen“ sind out. Stattdessen wird das von der Web-Anwendung gelieferte HTML je nach Aufruf-Plattform durch CSS3 mit Media-Queries und gegebenenfalls JavaScript so aufbereitet, dass eine an die vorhandenen Gegebenheiten (Bildschirmgröße) optimierte Darstellung und Nutzbarkeit gewährleistet ist.

Gerade hier hatte der Kölner UniversitätsgesamtKatalog KUG mit OpenBib deutlichen Nachholbedarf, da die Web-Version sich nur mühsam auf Smartphones und Tablets nutzen ließ und die anvisierte „Mobil-Variante“ nie zum Einsatz kam. Daher wurden die CSS im Rahmen von Responsive Webdesign für den KUG komplett überarbeitet.

In den folgenden Screenshots ist die Darstellung des KUG für verschiedene Bildschirmbreiten aufgeführt.

Der KUG mit 320 Pixel

Der KUG mit 320 Pixel

 

Der KUG mit 450 Pixel

Der KUG mit 450 Pixel

 

Der KUG mit 600 Pixeln

Der KUG mit 600 Pixel

 

Der KUG mit 900 Pixel

Der KUG mit 900 Pixel

 

Der KUG "in voller Schönheit" mit 1100 Pixel

Der KUG „in voller Schönheit“ mit 1100 Pixel

Ausgehend von der vollständigen Darstellung wurden für immer kleiner werdende Bildschirmauflösungen sukzessiv Änderungen vorgenommen:

  • Anpassung der Suchschlitzbreite und der Logos im Banner-Bereich
  • Reduktion erweiterter Suchmöglichkeiten
  • Entfernung der Icons für andere Repräsentationen der Seite
  • Einklappen zusätzlicher Inhalte für mehr Übersichtlichkeit
  • Entfernung der Breadcrumb-Navigation, weil schlicht die Bildschirmbreite nicht mehr ausreicht
  • Vergrößerte Schrift zur besseren Selektion auf Touch-Displays

Nicht alles hiervon ist optimal, in der Regel immer dann, wenn Informationen oder Bedienelemente entfernt wurden, wie bei der Breadcrumb-Navigation. Hier wird es sicherlich zukünftig weitere Verbesserungen geben. Andererseits erhöht eine solche Reduktion auf das Wesentliche häufig die Übersichtlichkeit und damit die Usability. Insofern stellen wir uns auch die Frage, ob an einigen Stellen überhaupt Handlungsbedarf besteht. Verglichen mit der bisherigen Version führen die Änderungen aber zu einer deutlich erhöhten Nutzbarkeit.

Weitere Optimierungen

Über PSGI und Responsive Webdesign hinaus wurden viele Bereiche im Programmcode optimiert. Dazu gehört insbesondere die Nutzung von Datenbankverbindungen. Hier gab es in den letzten zwei Jahren drei Mal ein „Aufschaukeln“ der Verbindungen zur zentralen Systemdatenbank, so dass der KUG für einige Stunden nicht erreichbar war. Beteiligt waren hierbei der Connection Spooler pgbouncer, der übermäßig Verbindungen im Idle-Zustand beließ anstelle sie zu schliessen, und einige Singleton-Objekte im Code, die ebenfalls bereits bestehende Verbindungen nicht immer wiederverwendeten, sondern zum Teil neu aufbauten.

Bereits der Verzicht auf pgbouncer hatte deutliche Verbesserungen bei der Stabilität gebracht und auch die Performance hatte darunter nicht spürbar gelitten. Für die neue Version wurden alle Singleton-Objekte mit Datenbankverbindungen eliminiert und durch „normale Objekte“ ersetzt. Die Folge war eine nun nötig gewordene umfassende Umstrukturierung des Programmcodes.

Verlauf der Datenbankverbindungen zur System-Datenbank

Verlauf der Datenbankverbindungen zur System-Datenbank

Sehr schön demonstriert das die Grafik des Verlaufs der PostgreSQL-Verbindungen über die letzten 12 Monate. Die grün eingekreisten Stellen zeigen die Zahl der Datenbankverbindungen mit der neuen OpenBib Version 3.1, die seit einigen Wochen beim KUG im Einsatz ist.

Verbesserungen gibt es auch in der Web-Administration. Hier wurde die Usability erhöht und zusätzliche Funktionalitäten, wie z.B. der Synchronizitäts-Status von Datenbanken auf den Servern innerhalb eines Clusters integriert. So lässt sich auf einen Blick feststellen, welche Kataloge auf welchen Servern innerhalb eines Clusters verschiedene Titelzahlen aufweisen und dann geeignete Gegenmaßnahmen einleiten.

Schließlich wurde in der neuen Version das „Kölner Modell“ zur Provenienzverzeichnung für den Endnutzer praktisch umgesetzt. Vorhandene Provenienzinformationen werden im Kontext des entsprechenden Exemplars verlinkt (Beispiel) und mit den Normdaten (GND) verknüpft.

Zahlen

Wieviel hat sich nun konkrete in Zahlen von OpenBib 3.1 zur letzten Version 3.0 getan. Git ist unser Freund:

git diff –stat origin/master origin/stable-3_0-mod_perl-branch — ‚*’|tail -1
1108 files changed, 70801 insertions(+), 50292 deletions(-)

Hierbei ist allerdings zu beachten, dass die Handler-Module in ein neues Verzeichnis verschoben wurden und hierbei komplett mitgezaehlt  wurden, unabhängig von den tatsächlichen Änderungen, die in jeder dieser Dateien jedoch vorgenommen wurden. Vom Umfang sind das exakt  34810 Zeilen, die zu einem unbestimmten Teil geändert wurden. Dementsprechend liegt die untere Grenze der durchgeführten Änderungen bei 1108 Dateien mit 35991 eingefügten und 15492 gelöschten Zeilen. Die Realität liegt darüber.

Von Google Code zu GitHub

Am 12.3.2015 ließ Google verlauten, dass der Dienst Google Code – wie so viele Google Dienste vorher – in verschiedenen Stufen abgewickelt wird. Grund genug sich nach einer neuen Heimat für den Programmcode von OpenBib umzusehen.

Ursprünglich wurde der Programmcode von OpenBib auf BerliOS in einem CVS-Repository gehostet, aber BerliOS stellte 2011 den Betrieb ein. Also zog OpenBib weiter zu Google Code in ein Subversion-Repository. Dies bot den Vorteil mit Subversion – nach CVS (und RCS) – ein weiteres Versionsverwaltungssystem kennenzulernen.

Bereits seit einigen Jahren beobachte ich das verteilte Versionverwaltungssystem git und die – gerade bei Open Source Software – inzwischen sehr dominante Plattform GitHub. Nicht umsonst sind auch einige von Googles Projekten dorthin umgezogen. Selbst Microsoft hat einige wichtige Projekte von der eigenen Plattform Codeplex auf GitHub migriert.

Und so kommt es, wie es kommen musste: Mit git als System der Wahl auf GitHub.

Positiv ist anzumerken, dass Google eigens für GitHub einen Projekt-Exporter bereitstellt, so dass alle Inhalte in Google Code (Code, Issues, Wikiseiten) mit einem Klick dorthin migriert werden können. Dieser Exporter funktionierte bei OpenBib sehr gut.

Damit findet ab heute die Entwicklung von OpenBib mit git auf GitHub statt:

https://github.com/oflimm/openbib

Bereits seit 2008 werden andere Ausgaben, also andere Auflagen und Sprachversionen einer Titelaufnahme im KUG ausgegeben. Die Integration war damals sehr einfach möglich, da die Bücher-Plattform LibraryThing, deren Nutzer diese Art von Information intellektuell erfassen, alle ihre diesbezüglichen Daten kostenfrei als Feed in der Datei thingISBN.xml.gz zur Verfügung gestellt hat.

Leider wurden diese Daten von LibraryThing immer seltener aktualisiert – die letzte Datenlieferung datiert von Herbst 2012. Ebenso waren dort keine der von uns erworbenen E-Book-Ausgaben enthalten. Grund genug, sich diesem Thema noch einmal intensiver zuzuwenden und nach Verfahren zu suchen, um diese Titelverknüpfungen selbst automatisch – idealerweise in Echtzeit – zu bestimmen.

Durch die Integration von BibSonomy in den KUG haben wir bereits Erfahrungen im Titel-Fingerprinting über sog. BibKeys sammeln können. Beim Bibkey werden zur Erstellung des bibliographischen Fingerabdrucks die Informationen aus den Feldern für Verfasser/Personen, (Hauptsach)Titel sowie Erscheinungsjahr normiert, kombiniert und dann mit einer kryptographischen Hash-Funktion verkürzt. So kann schnell bestimmt werden, ob ein Titel des KUG auch in BibSonomy enthalten ist und umgekehrt.

Dieses Verfahren haben wir als Grundlage genommen und für den neuen Anwendungsfall  angepasst.

Bei der Bestimmung anderer Ausgaben muss ein unschärferer Titel-Fingerabdruck als beim BibKey verwendet werden, da hier gerade keine identischen Titel bestimmt werden sollen.

Welche Fälle sind dabei zu bedenken?

  • Die Autorenschaft kann sich verändern, indem Autoren dazukommen oder verschwinden
  • Die Titelaufnahme kann von einer Auflage zur nächsten den Verlag oder gar den (Hauptsach)Titel wechseln
  • Auflageninformation können schwer zu bestimmen sein, wie z.B. ‚2. Nachdruck der 3. Auflage‘

Nicht für alle diese Fälle gibt es Lösungen, wie z.B. bei Änderungen des (Hauptsach)Titels, da – wenn überhaupt – entsprechende Informationen lediglich in Fußnoten abgelegt werden und sich nicht maschinell zuverlässig verarbeiten lassen.

Dennoch lassen sich auch so sehr gute Ergebnisse erzielen. Dazu gehen wir zweigleisig vor, da die Aufgabe nicht nur darin besteht

  1. zu einer Titelaufnahme die Menge aller verschiedenen Auflagen zu bestimmen, sondern auch
  2. die Eingrenzung auf die „anderen Auflagen“ ausgehend von einer konkreten Titelaufnahme

Zusätzlich müssen wir auch Seiteneffekte der Katalogisierung nach RAK bedenken, die in der Auftrennung der Titelinformationen in verschiedene Hierarchieebenen begründet sind. Nach unserer Erfahrung haben wir es mit einer „ordentlichen“  Titelaufnahme zu tun, wenn alle BibKey-relavanten Informationen – Verfasser/Person, (Hauptsach)Titel und Erscheinungsjahr – in einer Titelaufnahme besetzt sind. Nur solche „ordentlichen“ Titelaufnahmen verarbeiten wir im Folgenden.

Um die Menge aller Auflagen zu einer Titelaufnahme bestimmen zu können, konstruieren wir in Anlehnung an den BibKey normierte Zeichenketten für eine Titelaufnahme. Wegen der benötigten Unschärfe verwenden wir hierzu lediglich die Kategorien für Verfasser/Person und Hauptsachtitel sowie Einheitssachtitel (für andere Sprachversionen) . Allerdings bilden wir wegen des Problems wechselnder Autorenschaft sowie verschiedener Sprachversionen nicht nur einen „WorkKey“ für eine Titelaufnahme, sondern mehrere. So besteht ein WorkKey immer nur aus einem Verfasser bzw. einer Person sowie einer Titelkategorie – Hauptsachtitel oder Einheitssachtitel. Bei einer Titelaufnahmen mit 2 Verfassern und sowohl vorhandenem Hauptsachtitel wie auch Einheitssachtitel werden also 4 WorkKeys gebildet. Eine Erweiterung um zusätzliche Titel-Kategorien wie AST oder WST wäre möglich, um noch höhere Identifizierungsquoten zu erreichen. Aber auch ohne diese zusätzlichen Kategorien sind die von uns beobachteten Resultate bereits sehr gut.

Um die „anderen“ Auflagen bezogen auf die aktuelle Titelaufnahme auf der mit dem WorkKey bestimmten Titelmenge bestimmen zu können, benötigen wir eine zusätzliche Information über die Auflage. Gleichzeitig müssen Sprache und Publikationform (print/online) damit unterscheidbar sein.

Während die Publikationsform online noch sehr einfach über den Zugriffsstatus in der (vorher angereicherten) Kategorie T4400 zu bestimmen ist, wird dies bei der Auflagenbezeichnung und der Sprache schon schwieriger.

Bei der Auflagenbezeichnung ist zwischen

  • dem Problem der Bestimmung der korrekten Auflage aus dem Kategorieinhalt von T0403 (2. Nachdruck der 3. Auflage) und
  • dem Problem verschiedener Auflagen im selben Jahr

abzuwägen. Dementsprechend würde man entweder die Zahl der Auflage aus T0403 oder das Erscheinungsjahr aus T0425 bzw. T0424 verwenden. Wir haben uns erst einmal für die Jahreszahl aus Charakteristikum für die Auflage entschieden.

Die Sprache, in der ein Titel erschienen ist, kann leider häufig nicht in der Titelaufnahme gefunden werden. Das ist bereits bei der Facettierung nach Sprache ein Problem. Deshalb haben wir bereit seit einiger Zeit eine Spracherkennung auf Grundlage linguistischer Methoden mit dem Perl-Modul  Lingua::Identify::CLD integriert (Nutzung der Spracherkennung des Chrome-Browsers), falls keine Sprache in der Titelaufnahme erfasst wurde. Dieses Verfahren haben wir für die Bestimmung der verallgemeinerten Auflagenbezeichnung durch eine Analyse des Sprach- bzw. Ländercode in der ISBN erweitert. Beispielsweise kennzeichnet der ISBN-Anfang 9780 bw 9781 englische, 9872 französische und 9873 deutsche Titel. Zwar kann auch hier der Fall auftreten, dass ein deutscher Verlag ein englischsprachiges Buch herausbringt, aber die Auswirkungen sehen wir als nicht gravierend an.

Beispiel 1

Anhand des Titels „Programming perl“ von Tom Christiansen, Larry Wall und John Orwant in der 3. deutschen Auflage aus dem Jahr 2001 wird die konkrete Vorgehensweise veranschaulicht.

In der ersten Stufe werden die Basis-WorkKeys anhand der belegten Titelkategorien mit der Funktion gen_workkeys bestimmt und in der Titelkategorie T5055 abgelegt. Dieser hat die Form „WorkKey <Auflage>“ und enthält zwei Anteile, den eigentlichen WorkKey und eine verallgemeinerte Auflagenbezeichnung in spitzen Klammern. Im konkreten Fall werden folgende Basis-WorkKeys generiert:

  • programmingperl [l.wall] <2001ger>
  • programmierenmitperl [l.wall] <2001ger>
  • programmingperl [t.christiansen] <2001ger>
  • programmierenmitperl [t.christiansen] <2001ger>
  • programmingperl [j.orwant] <2001ger>
  • programmierenmitperl [j.orwant] <2001ger>

Für alle Kataloge werden diese Informationen durch das Programm update_all_isbn_table.pl selektiert und in einer speziellen Tabelle all_titles_by_workkey unserer zentralen Anreicherungsdatenbank abgelegt. In dieser Tabelle werden WorkKey und verallgemeinerte Auflagenbezeichnung getrennt und zusammen mit Katalogname und -ID eines jeden Titels abgelegt. Die Bestimmung anderer Auflagen in beliebigen Katalogmengen kann dann – in Echtzeit – für einen Titel bestimmt werden.

Dazu werden zunächst für alle WorkKeys eines Ursprungs-Titels die jeweiligen anderen Titel gesucht, die den gleichen WorkKey besitzen. Aus dieser Menge werden dann jene Titel selektiert, deren verallgemeinerte Auflagenbezeichnung sich vom Ursprungs-Titel unterscheidet. Zusätzlich wird eine absteigende Sortierung nach den Auflagenbezeichnungen vorgenommen, so dass aktuellere Auflagen am Anfang ausgegeben werden.

Beispiel 2

Beim zweiten Beispieltitel handelt es sich um ein Buch, dass sowohl in Print-Form vorliegt als auch frei im Netz. Es ist die erste Auflage aus dem Jahr 1999, heisst „Open sources“ und wurde von Chris DiBona und Sam Ockman geschrieben. Hier sind die Basis-WorkKeys in 5055:

  • opensources [c.dibona] <1999engonline>
  • opensources [s.ockman] <1999engonline>

Zusätzlich zum Erscheinungsjahr und der Sprache wird hier auch noch der Publikationsstatus online hinzugefügt.

Fazit

Mit relativ wenig Aufwand konnten wir die Unzulänglichkeiten der bisherigen Bestimmung der anderen Auflagen eines Titels beseitigen. Das beschriebene Verfahren kann an verschiedenen Stellen noch weiter optimiert werden. So könnten durch ein mehrstufiges Suchverfahren – gerade bei nicht durchgängig besetzten Einheitssachtiteln – noch mehr infrage kommende Titel in anderen Auflagen bestimmt werden. Allerdings muss immer gewährleistet sein, dass der zusätzliche Zeitaufwand für den Endanwender noch hinreichend responsiv bleibt.

 

 

 

Nachweise von E-Books dank Open Data

Nichts ist ärgerlicher als teuer lizensierte E-Book-Pakete, die für den Nutzer mehr oder weniger unsichtbar sind. Ein Beispiel hierfür sind die E-Books des Pakets Nomos online Premium von der Beck-Online-Plattform. Anders als z.B. das Beck-Online Hochschulmodul wird dieses nicht im hbz erfasst und ist damit nicht automatisch in unserer lokalen Recherche-Infrastruktur für USB-Portal und KUG auffindbar. Ebenso ist das Paket nicht in dem von uns lizensierten Dienst EBSCO Discovery Search enthalten. Lediglich in Beck-Online.beck.de selbst können die E-Books recherchiert werden. Das ist alles andere als optimal.

Aus diesem Grund sind wir an Beck herangetreten, um von dort idealerweise die Metadaten der von uns lizensierten E-Books des Pakets zu erhalten, aber leider kann uns Beck diese Daten für den Nachweis nicht liefern. Normalerweise wäre hier jetzt – bis auf Selbstkatalogisieren – Schluss und wir müssten uns in unser Schicksal fügen.

Eine kurze Google-Recherche lieferte jedoch eine sehr informative Webseite des SWB, in der weitergehende Informationen über die Beck’schen Pakete zu finden sind. Demnach hat der SWB bereits damit begonnen, die Nomos-Titel unter dem Kennzeichen ZDB-18-NOI in seinem Verbundkatalog zu erfassen.

Da der SWB wie auch das hbz, heBIS und BVB/KOBV bereits seinen Verbundkatalog als Open Data freigegeben hat, waren diese Katalog-Dumps unser neuer Ansatzpunkt. Sind die Linked Open Data-Dumps für die Erstellung eines eigenen Recherchekatalogs wegen der z.T. verschiedenen verwendeten Ontologien weniger geeignet, bietet der SWB die Daten auch in MARC-XML an.

Nach der Selektion der betreffenden Records mit einem kleinen Program, war es danach sehr einfach möglich, daraus einen eigenen Katalog nomos zu erstellen und in unsere Recherche-Infrastruktur einzubringen. Die ersten Nomos-Titel waren in der SWB-Update-Lieferung von Juli 2014 zu finden, so dass erst ab diesem Zeitpunkt die SWB-Daten sukzessive extrahiert werden müssen.

Der neue Katalog nomos ist seit gestern im USB-Portal und dem KUG freigeschaltet und kann nun – wie alle anderen Nachweise auch – recherchiert werden.

Beispiel:

http://www.ub.uni-koeln.de/usbportal?query=nomos:282602623

bzw.

http://kug.ub.uni-koeln.de/portal/kug/databases/id/nomos/titles/id/282602623.html?l=de

Diese schnelle Integration relevanter Bestände wäre ohne die Öffnung der Daten von Verbund-  sowie einzelner Bibliothekskataloge so nicht möglich gewesen und demonstriert sehr eindrucksvoll welchen praktischen Mehrwert sich aus der Open Data-Bewegung ziehen lässt.

Zur schnellen Nachnutzung haben wir die extrahierten bibliographischen Daten des E-Book-Pakets im MAB2-basierten JSON-Format abgelegt unter

http://opendata.ub.uni-koeln.de/dumps/ZDB-18-NOI/

CIB vs. libOS – Eine Analyse

Analog zu Christian Hauschkes „Operation Frühjahrsputz“ einige Gedanken, die ich im April 2013 kurz nach der DFG-Entscheidung zusammengefasst hatte, aber die bisher im Blog auf Halde lagen.

Mit der Bewilligung des CIB-Antrages von HeBIS, KOBV und BVB im Bereich „Neuausrichtung überregionaler Informationsservices“ durch die DFG wurde eine weitreichende Weichenstellung für die zukünftige deutsche Bibliothekslandschaft getroffen. Das alternative Konzept libOS von hbz, GBV, SWB und DNB hat die DFG augenscheinlich nicht überzeugen können. Vereinzelt sind bereits Reaktionen auf die Entscheidung gefolgt, wie z.B. die Analyse des CIB-Antrages durch Adrian Pohl, eine große Diskussion darüber in der betroffenen bibliothekarischen Fachöffentlichkeit findet aber – an der Durchschlagskraft der DFG-Entscheidung gemessen – derzeit nur ansatzweise auf InetBib statt.

CIB

Kurz gefasst wird im CIB-Antrag der Weg zu einem internationalen Verbund von kommerziellen Cloudsystemen der Anbieter OCLC und ExLibris skizziert, der auf die deutsche nationale Bibliothekslandschaft heruntergebrochen und durch die antragstellenden Verbünde geregelt vollzogen werden soll. Dabei soll u.a. möglichst viel Offenheit und Gestaltungsmöglichkeiten bei den Anbietern herausgehandelt werden. Grundlage sind verschiedene Prognosen:

  • Die Katalogisierung wird in internationalen Verbünden stattfinden
  • Die Cloudlösungen können für lokale Belange auf Deutschland-Ebene heruntergebrochen werden via Schnittstellen oder Abzug
  • Die Verbund- und Lokalsysteme verschmelzen im Cloudsystem

Auch wenn ich diesen Weg für bedenklich halte, so ist nach meiner Einschätzung das präsentierte Konzept auf den ersten Blick in sich durchaus stimmig und umfassend, gerade wie es die Zukunft von Lokal- und Verbundsystemen und die Konsequenzen skizziert. Allerdings sind viele grundlegenden Annahmen sehr schwammig und zu euphemistisch, wie z.B. zu offenen APIs, Datenschutzanforderungen, Linked (Open) Data (man beachte: mit Klammen um Open) usw. Die wesentlich zu leistende Arbeit im Antrag besteht darin, die beiden Hersteller-Clouds miteinander vertraglich und technisch zu verheiraten und synchronisieren, so dass bestehende nationale Dienste (Fernleihe, Datenanreicherungen, usw.) weiterhin funktionieren können sowie – laut Antrag – den „technischen, organisatorischen, finanziellen und (datenschutz)rechtlichen Übergang“ zu gestalten.

libOS

Demgegenüber soll mit libOS technisch und organisatorisch eine vollständig offene und herstellerunabhängige deutschlandweite Erschließungs- und Nachweisplattform für bibliographische Daten  geschaffen werden, die von den beteiligten Verbünden anteilig entwickelt und betrieben wird. Damit sollen dann Endnutzer und Bibliothekssysteme versorgt werden. Durch die Bereitstellung von Basisdiensten sollen komplexe Abläufe und Anwendungen realisiert werden können. Die Informationsversorgung verbleibt explizit in öffentlicher Hand.

Anders als CIB setzt libOS auf eine Optimierung der Zusammenarbeit der Katalogisierungszentren mit dem Ziel einer einheitlichen nationalen Infrastruktur und nicht auf eine de-facto Abschaffung der bestehenden Informationsstrukturen. Technisch kann libOS auf bereits bestehende eigenentwickelte und offene Plattformen, wie CultureGraph, zurückgreifen. Bemerkenswert bei libOS ist aus meiner Sicht, dass die beteiligten Verbünde das Wagnis eingehen die neue Infrastruktur selbst in Kooperation zu erschaffen, während CIB lediglich das bestehende System „abwickelt“ und in kommerzielle Cloud-Strukturen überführt.

Probleme mit CIB

Bezogen auf den CIB-Antrag sehe ich gerade die Herstellerabhängigkeit als zentrales Problem. Viele vergessen vielleicht, dass es diese Abhängigkeit bereits jetzt schon gibt. Denn bisher stellen dieselben Hersteller auch die jeweiligen Verbund- und einen Großteil der universitären Lokalsysteme. Das ist auch grundsätzlich kein Problem. Wenn die jeweiligen Systeme die Anforderungen besser als andere (auch Open Source-Systeme) erfüllen, spricht nichts dagegen, dass das jeweilige kommerzielle System angeschafft wird.

Der wesentliche Unterschied ist jedoch, dass im bisherigen Ist-Zustand der Betrieb und die Datenhaltung der deutschen Verbundsysteme in öffentlicher neutraler Hand war und dieser zukünftig in die private Hand der beiden Cloud-Anbieter überführt werden soll, die potentiell auch von Eigeninteressen geleitet sein könnten.

Folgen ergeben sich auch für die Verbünde, da die neuen Cloudsysteme bereits selbst Verbundsysteme sind. Durch ihren Einsatz werden in letzter Konsequenz alle deutschen Verbünde überflüssig – wenn im CIB-Antrag auch nur von den Verbundsystemen gesprochen wird:

Die Arbeit in dieser internationalen Infrastruktur macht die herkömmlichen regionalen Verbunddatenbanken entbehrlich, sie können nach einer Übergangsphase abgeschaltet werden. Ebenso ist eine eigenständige nationale Katalogisierungsumgebung für deutsche Bibliotheken funktional nicht mehr notwendig.

Darüber können auch nicht die Themenfelder ‚App-Entwicklung‘, ‚Lokale Cloud-Knoten‘ und ‚regionaler Support‘ hinwegtäuschen, die einige Verbünde in diesem Umfeld zukünftig besetzen wollen – und als Überlebensstrategie letztendlich auch müssen.

Nicht minder problematisch ist die Gewährleistung der bisherigen Servicequalität und weitere grundlegende Probleme der kommerziellen Cloudsystem, die ich bereits im Artikel Wieviel Cloud braucht das Land thematisiert habe:

Es ist nachvollziehbar, dass die Hersteller die Entwicklung ihrer jeweiligen Systeme vereinheitlichen, zentralisieren und letztlich unnötige Kosten in Parallelentwicklungen (und Sonderanpassungen für die Bibliotheken ) einsparen möchten. In Bezug auf die vorhandenen Funktionalitäten wird dabei gerne von ‘entschlacken’ gesprochen.

Insofern profitieren die Anbieter zuallererst selbst von einer Cloud-Lösung – wo aber Bibliotheken, Verbünde und deren Nutzer ihren konkreten Mehrwert gegenüber den bestehenden Lösungen ziehen, muss thematisiert und klarer dargestellt werden.

Einen guten Überblick von den Chancen und Risiken von Cloudsystemen hat bereits Herr Diedrichs vom GBV auf dem Bibliothekartag 2012 in einem Vortrag gegeben.

Bei der Überführung eines bestehenden lokalen Bibliothekssystems in das Cloudsystem des jeweiligen Anbieters wird man zukünftig zwangsläufig mit der Vereinheitlichung und Entschlackung konfrontiert werden. Von Hause aus bringen die neuen Cloudsysteme folglich nicht mehr all das mit, was man bisher gewohnt ist und worauf die lokalen Arbeitsabläufe optimiert sind. Gleiches gilt für etablierte lokale Sonderanpassungen.

Gelöst werden soll dieses Problem laut den Anbietern ganz einfach über bereitgestellte APIs,  auf deren Grundlage man dann – einheitlich – Sonderanpassungen erstellen und in der jeweiligen Cloud-Community austauschen kann.

Die entscheidende Frage ist hier aber: Werden die APIs überhaupt so umfangreich sein, dass der Status-Quo gehalten werden kann – einmal abgesehen davon, dass man alles noch einmal selbst programmieren darf und damit effektiv – unbezahlt – für den Anbieter arbeitet und dessen Produkt aufwertet. Aber auch das ist nichts Neues, wandert bibliothekarische Expertise bereits seit Jahrzehnten in Form von Konzepten, Change Requests und Aufträgen aus den Verbünden und Bibliotheken zu den Anbietern. Wäre es nicht vorzuziehen diese Expertise endlich für eigene offene Systeme zu nutzen?

Wie offen werden diese APIs sein? Neben den Bibliotheken wird diese Frage vor allem alle anderen Anbieter konventioneller Bibliothekssysteme interessieren, die an die Cloudsysteme andocken wollen. Ist ohnehin schon von einer gewissen Sogwirkung von anderen Anbietern hin zu den beiden Cloudsystemen auszugehen, so wird dies durch mangelnde Offenheit oder im Fall von Open Source System durch potentielle Lizensierungskosten des APIs weiter verschärft.

Neben der Dienstqualität ist auch die zukünftige Datenqualität ein Problem, wie Prof. Wiesenmüller auf InetBib anmerkt:

Betont wird im CIB-Antrag auch, dass die deutschen Daten ja schon im WorldCat seien. Nun ja – aber man muss doch fragen: In welcher Qualität? M.W. müssen bisher erhebliche Abstriche gemacht werden. Auch hier kann man natürlich hoffen, dass durch das CIB-Projekt alles viel besser wird. Aber was passiert, wenn dies nicht der Fall ist? Müssen wir dann letztlich akzeptieren, was die amerikanischen Partner bereit sind, uns zu geben – einfach, weil wir keine Alternative haben?

Probleme mit libOS

Für die zukünftige Enwicklung der deutschen Bibliothekslandschaft ist meines Erachtens die Entwicklung im Bereich der Lokalsysteme entscheidend. Das ist ein Bereich, der im libOS-Antrag – anders als bei CIB – nach meiner Wahrnehmung nur einen nebenläufigen Charakter hatte. Bei libOS wird davon ausgegangen, dass die Struktur der Lokalsysteme im Wesentlichen so (heterogen) bleibt wie bisher, wenn sie nicht durch Open Source Systeme sogar noch heterogener wird. Davon ist aber nicht auszugehen, wenn die bisherigen Lokalsysteme der grossen kommerziellen Anbieter auslaufen und von Cloudsystemen abgelöst werden.

Es reicht nicht im libOS-Antrag eine offene Katalogisierungsplattform zu erschaffen, wenn sich auf Lokalsystemseite niemand daran andocken kann – denn grundlegende Lokalsystem-Funktionalität stellen im täglichen Routine-Betrieb in deutschen Bibliotheken die Bereiche Ausleihe und Erwerbung dar. Wenn die aktuell etablierten kommerziellen Lokalsystem auslaufen ist es unrealitisch zu erwarten, dass große Universitätsbibliotheken freudig auf ein anderes kommerzielles oder Open Source Lokalsystem, wie z.B. Koha umsteigen werden. Im Hinblick auf den eigenen Betriebsfrieden und den Migrationsaufwand vom alten System ins neue ist sicherlich ein Systemwechsel innerhalb des jeweiligen aktuellen Anbieters deutlich entspannter.

Prognosen

Meine Prognose ist daher ziemlich genau die des CIB-Antrags: Durch die herstellergetriebene Verschmelzung von Lokal- und Verbundsystem werden die Universitätsbibliotheken im Rahmen von typischen Upgrade-Pfaden quasi automatisch integraler Teil des jeweiligen Cloud-Verbunds. Damit einher wird zwangsläufig ein Riss quer durch Deutschland, Verbund für Verbund, gehen – zumindest was die großen Universitätsbibliotheken angeht – zwischen den Bibliotheken, die in die OCLC-Cloud und denen, die in die ExLibris-Cloud wandern.

Wozu dann noch das künstliche Artefakt von zusätzlichen regionalen deutschen Verbünden? Und das umso mehr, wenn man die Tendenz betrachtet, dass  Verbünde – politisch gewollt –  in privatwirtschaftliche Strukturen überführt werden und ihren Unterhalt zukünftig selbst von den Bibliotheken erwirtschaften sollen. Warum als Bibliothek dann für den regionalen oder nationalen Verbund noch zahlen, wenn man ohnehin sein Lokalsystem bezahlt und damit der (private) Cloud-Verbund all-inklusive ist?

Der Lock-In im Cloud-System, das unbezahlte Katalogisieren für die Datenbasis des Cloudherstellers, was sind das schon für Hindernisse, wenn das Geld im Bildungsbereich, und da speziell bei den Bibliotheken, ohnehin knapp gesäht ist? Nicht ohne Grund touren die Hersteller der grossen Cloudsysteme beständig durchs Land und suggerieren den Entscheidern in Präsentationen mit Worten wie „Rechfertigungsdruck der Bibliotheken“ usw. dringend gewünschte Einsparungen, die durch den Wegfall der lokalen Systembetreuung und die weltweite gemeinschaftliche Katalogisierung entstehen (könnten).

Die Verbünde haben dann nur noch die Wahl sich arbeitstechnisch als Dienstleister für die Cloudsysteme aufzuteilen, z.B. das hbz und der KOBV betreuen die ExLibris-Kunden und  BVB sowie GBV die OCLC-Kunden. Können Verbundzentralen durch die neue Dienstleistung „Programmierung für das Cloudsystem“ noch künstlich am Leben gehalten werden, so wird so manche Hochschule versucht sein ihre Bibliotheks-IT deutlich zu schrumpfen oder ganz auflösen – analog dem Status-Quo bei Öffentlichen Bibliotheken. Für den lokalen Betrieb und die Verbindung sämtlicher Bibliotheks-Services zu einem stimmigen Ganzen für den Nutzer wäre das eine Katastrophe. Lokales Know-How wird vernichtet und muss später wieder teuer von externen Dienstleistern oder dem Hersteller selbst eingekauft werden.

Alternativstrategien

Eine Alternativstrategie müsste – ausgehend von der bisherigen Analyse – zwingend eine offene Katalogisierungsplattform und ein (offenes) Lokalsystem umfassen. Bemerkenswert ist hier die breite aktuelle Aufstellung des SWB, der frühzeitig bei der Lokalsystemseite auf Koha gesetzt hat. Idealerweise würden sich die aktuellen Verbünde mit ihren Entwicklungskapazitäten entsprechend der Anforderungen der Bibliotheken die Arbeit an der Plattform und einem offenen Lokalsystem aufteilen. Das ist umso wichtiger, als dass speziell beim Design und der Einführung eines neuen Lokalsystems „die Bibliotheken und ihre Mitarbeiter mitgenommen werden müssen“. Dafür wäre aber die wesentliche Voraussetzung, dass alle, Verbünde und Bibliotheken, an einem Strang ziehen – wovon bei der unterschiedlichen Ausrichtung derzeit nicht ausgegangen werden kann. Und damit sehe ich jegliche Alternativstrategie realistisch von vorherein zum Scheitern verurteilt. So bleibt als letztes formales Hindernis gen internationale Cloud-Systeme lediglich der Datenschutz bei Ausleihe und Erwerbung, aber dort wird man sicherlich kreative Lösungen finden…

Wir sehen uns dann…. in der Cloud und versuchen wie immer das Beste für unsere Nutzer daraus zu machen.

Kooperative Bearbeitung von Sammlungs-Portalen

Die KUG Recherche-Infrastruktur mit OpenBib war seit jeher nicht als Content-Management-System (CMS) konzipiert. Inhalte und Logik für dynamische Inhalte werden über ein Templating-System organisiert. Durch dessen Objektorientierung kann über Vererbungs-Mechanismen elegant und mit wenig Aufwand eine Vielzahl von Sammlungs-Portalen – derzeit 26 zuzüglich weiterer 14 für die RheinlandBib – verwaltet werden. Die zugehörigen Templates sind auf jedem der derzeit vier Recherche-Server in einer Verzeichnis-Struktur abgelegt. Insgesamt umfasst die gesamte Recherche-Infrastruktur über alle damit realisierten Portale hinweg derzeit 1585 Templates.

Sollen Inhalte geändert werden, so muss das zugehörige bearbeitete Template auf jeden der vier Rechner übertragen werden. Durch die Verwendung des öffentlichen Subversion-Repositories ist das mit wenig Aufwand über die Abteilung UniversitätsGesamtKatalog der USB Köln möglich.

Gerade bei Sammlungs-Portalen, die in Zusammenarbeit mit Wissenschaftlern aus den verschiedenen Fachbereichen der Universität entstehen, Stichwort Forschungsdaten, kommt diese zugrundeliegende Organisation von Inhalten durch Templates an ihre Grenzen.

Ist die Konzeption einer Recherche-Infrastruktur auf einen zentralen Dienstleister und Betreiber ausgerichtet, so besteht nun der nachvollziehbare Wunsch der Wissenschaftler dezentral Texte auf der Einstiegs- oder weiteren Informationsseiten des jeweiligen Portals selbständig ändern zu können. Andererseits können wir als Betreiber der Infrastruktur von den Wissenschaftlern nicht verlangen, dass sich diese mit Template- oder Markup-Sprachen auseinander zu setzen haben, nur wenn sie Texte ändern oder Zahlen aktualisieren wollen.

Weiterlesen »

Nachdem vor knapp 2 Wochen Rudolf Mumenthaler im Bibliotheksdienst das Fehlen von offenen E-Books in vielen Bibliothekskatalogen monierte und den möglichen Ursachen nachging, haben wir uns einem Bereich zugewandt, bei dem es noch viel düsterer aussieht – der Integration von offenen Lern- und Lehrmaterialien, den Open Educational Resources (OER). Ähnlich wie bei den offenen E-Books existieren zwar inzwischen verschiedene Aggregationsplattformen wie z.B. OERCommons, aber leider stellen diese ihre Metadaten meist nicht offen ins Netz, so dass diese auch nicht geharvestet und in eigene Recherche-Infrastrukturen der Bibliotheken integriert werden können.

Gerade die Bereitstellung der Metadaten ist aber eine wesentliche Voraussetzung dafür, dass die unzähligen über den Globus verteilten Vorlesungs-Materialien auch überall gefunden werden. Hier müssen die OER-Plattformen mit dem Fehlen von Synchronisierungsmechanismen wie OAI-Schnittstellen oder bibliothekarischen Standard-Datenformaten im Vergleich zu den klassischen OpenAccess-Materialen (Hochschulschriften, Institutional Repositories, Pre-Print-Server) noch massiv aufholen. Die Dezentralität von Resourcen wurde im klassischen OA-Bereich bereits vor vielen Jahren gemeistert. So ist eine Aggregation aller vorhandenen OERs in dem Umfang wie es BASE bei klassischen OpenAccess-Materialien macht, im Moment geradezu utopisch.

Der Weg der OERs in die lokalen Recherche-Infrastrukturen ist derzeit also noch etwas steinig. Dennoch gibt es auch bereits jetzt pragmatische Lösungen, um einzelne ausgewählten OER-Bestände zu integrieren – vorausgesetzt, die Metadaten sind verfügbar.

Einzelne Plattformen

Als Aggregator stellt das OpenCourseWare Consortium seine Daten sowohl über eine eigenes API wie auch über eine Excel-Tabelle bereit. Diese Daten sind grundsätzlich brauchbar, auch wenn im Bereich der Personenerfassung klassische Fehler ausgemacht werden können (keine einheitliche Ansetzungsform, Ansetzungsformen verschiedener Personen mit Komma getrennt).

Alternativ steht auch ein RDF-Abzug im Turtle-Format samt SPARQL-Endpoint auf datahub.io bereit – dort sind Personen aber z.T. ins Nichts verlinkt, so dass die regelmäßig aktualisierte Excel-Tabelle hier ganz klar vorzuzuiehen ist. Für den KUG wurde die Excel-Tabelle zunächst mit LibreOffice in eine CSV-Datei umgewandelt und dann mit einer geeigneten Parametrisierung für das Programm simplecsv2meta.pl in einen eigenen KUG-Katalog geladen.

Eine weitere Plattform mit API ist die Khan Academy. Für die Erkundung des API’s wird neben einer Dokumentation eigens ein API-Explorer bereitgestellt. Für eine Integration bietet sich hier insbesondere der topictree-Call an, mit dem sämtliche Inhalte in einer hierarchischen Struktur heruntergeladen werden können. Für die JSON-Inhalten des topictree-Calls haben wir ein eigenes Konvertierungsprogramm und eine Parametrisierung erstellt.

YouTube

Auch wenn viele OER-Plattformen selbst kein API oder Dumps ihrer Metadaten anbieten, so nutzen viele von ihnen aber YouTube als zentralen Dienstleister für die Bereitstellung ihrer Kurs-Videos. YouTube selbst hat die dem Bereich Bildung zugeordneten Videos zentral unter http://youtube.com/edu virtuell zusammengefasst.

YouTube selbst bietet ein API in verschiedenen Versionen an. Version 3 gilt offiziell noch als experimentell, Version 2 des Google Data API für YouTube wird aber  von verschiedenen Programmiersprachen durch entsprechende Programm-Module unterstützt. Die Programmiersprache Perl wird zwar offiziell nicht unterstützt, mit dem Modul WebService-GData steht aber eine gute Umsetzung bereit, die lediglich in Kombination mit der encode_json-Methode aus JSON::XS mit doppeltem UTF8-Encoding patzt. Mit to_json aus dem JSON-Modul wird aber auch UTF8 korrekt umgesetzt.

Wichtig war uns bei einer Integration von OER aus YouTube, dass wir selbst festlegen können, welche Channels wir in den KUG integrieren, denn nicht alle unter youtube.com/edu angebotenen Videos scheinen uns hierfür geeignet. Und selbst bei einzelnen Channels, wie z.B. bei der Stanford University müssen die Kurse erst noch ausgefiltert werden.

Darüberhinaus ermöglicht uns die Übertragung einzelner Channels in einzelne KUG-Recherche-Kataloge das Mischen von OERs aus verschiedenen Quellsystemen. Ein gutes Beispiel hierfür ist die Khan Academy, die zwar ein API und die Daten bereitstellt, aber nur für die englischsprachigen Kurse. Die deutschsprachigen Kurse der Khan Academy sind in diesen Daten gerade nicht enthalten, aber stattdessen im YouTube-Channel KhanAcademyDeutsch. So können wir die Original API Daten der englischen Khan Academy dem zugehörigen YouTube-Channel vorziehen, uns zusätzlich aber des deutschen Channels bedienen und so beide Sektionen der Khan Academy abdecken.

Im Vergleich mit den dedizierten Plattformen wie OCW Consortium oder der Khan Academy stellt YouTube weniger Daten bereit, die zum Set der klassischen bibliographischen Daten gehören. Insbesondere fehlen idR Personeninformationen – einziger author-Name im YouTube-API ist der Username des Channelerstellers. Dennoch sind die Daten selbst gut strukturiert.

Normalerweise wird ein ganzer Kurs als Playlist organisiert, in der die einzelnen Video-Lektionen enthalten sind. Dadurch erst lässt sich die kursspezifische Zusammenfassung der Videos auch 1:1 in den zugeordneten KUG-Katalog übertragen. Dennoch ziehen wir ganz allgemein die potentiell reichhaltigeren originalen Daten ala OCW oder Khan Academy denen von YouTube vor. Bis solche Daten aber irgendwann einmal für alle OER-Quellen bereitgestellt werden, ist YouTube die bestmögliche Lösung, um diese Materialien überhaupt im lokalen Bibliotheksumfeld sichtbar zu machen.

Gestartet sind wir in dem neuen Bereich der OER mit folgenden Katalogen im KUG:

Das sind insgesamt 43.389 Nachweise. Weitere OER-Quellen lassen sich – speziell im Bereich der YouTube-Channels – einfach durch Nennung des Channel-Namens in entsprechenden Parametrisierungsdateien für das generelle Harvesting-Programm youtube2meta.pl festlegen.

Die Sichtung weiterer geeigneter Quellen und Aggregationsplattformen mit vorhandenen Metadaten ist nach wie vor das gravierendste Problem bei der Integration von OERs in die lokalen Recherche-Infrastrukturen. Die allgemeine Zugänglichmachung von Informationen zu solchen OER-Quellen von jedweder Seite würden wir daher sehr begrüßen. Die nächste neue OER-Plattform, die wir uns genauer anschauen werden, ist sicherlich learningregistry.org mit eigenem API.

Seit heute haben wir im Kölner UniversitätsGesamtkatalog KUG die Zahl von 200 gemeinsam recherchierbaren Datenquellen erreicht. Davon entfallen knapp 150 auf klassische Bibliothekskataloge der Universität zu Köln und die restlichen 50 auf Sonderbestände und freie E-Books bzw. sonstige elektronische Materialien. Gerade die freien Inhalte tragen massgeblich zu der stattlichen Zahl von 19.5 Millionen Nachweisen bei, denn die klassischen Bibliothekskataloge machen hiervon lediglich knapp 7 Millionen Titel aus.

Insgesamt schlüsselt sich der Bestand im KUG von 19.539.367 Nachweisen aktuell auf in

  • 414.092 Zeitschriften bzw. Serien,
  • 450.813 Artikel/Aufsätze sowie
  • 10.823.009 digital verfügbare Medien.

Bereits seit vielen Jahren haben wir in den KUG freie digital verfügbare Inhalte aufgenommen, wie z.B.

  • KUPS, den Kölner UnversitätsPublikationsServer
  • GDEA, das Graph Drawing E-Prints Archive
  • DFG Nationallizenzen
  • Digitalisierte Bücher der Open Library
  • RePEc, Research Papers in Economics
  • DRIVER Forschungsdaten
  • Digitalis-Projekt des Seminars der Wirtschafts- und Unternehmensgeschichte der Universität zu Köln
  • Volltexte des ehem. SSG BWL
  • Texte von de.wikisource.org
  • Internationales Projekt Gutenberg
  • Directory of Open Access Books

von denen viele, aber leider nicht alle, in ihren Metadaten frei verfügbar sind.

Durch die Vereinheitlichung des Harvesting von OAI-Quellen mit REPOX vor einigen Wochen konnten wir sehr schnell weitere Quellen integrieren, wie z.B.

  • Gallica (1.198.908 Objekte)
  • Göttinger Digitalisierungszentrum (85.064 Titel)
  • HathiTrust (1.182.308 Titel)
  • LoC (242.394 Objekte)
  • Münchener Digitalisierungszentrum (924.580 Titel)
  • National Libray of Australia (233.148 Objekte)
  • National Science Digital Library (122.928 Titel)
  • ZVDD (296.830 Tite, via OAI leider ohne MDZ und einige andere)
  • E-Lis – EPrints in Library and Information Science (16.055 Titel)
  • InTech Open E-Books (39.126 Titel)
  • Networked Digital Library of Thesis and Dissertations (3.613.947 Titel)

Jenseits der 200 Datenquellen, die über das zentrale KUG-Rechercheportal kug.ub.uni-koeln.de, den „KUG“, angeboten werden, sind in die allgemeine KUG-Rechercheinfrastruktur viele weitere Datenquellen integriert, die ausserhalb des „KUG“ entweder in eigenen Recherche-Portalen – z.B. Sammlungen wie die Totenzettel-Sammlung der USB oder die Sammlung DDR-Kinderbuch der ALEKI – bereitgestellt werden, oder ausschliesslich in das USB-Portal integriert sind, wie z.B. die Daten von Print- und E-Book PDA-Projekten.