In OpenBib und beim Referenzeinsatz im KUG wurde nun schon seit mehr als einem Jahr die Zugreifbarkeit und nutzbringende Verwendung von Katalogdaten durch verschiedene Mechanismen ermöglicht und so versucht den Datensilo Bibliothekskatalog aufzubrechen. Am meisten Aufmerksamkeit bekam sicherlich die Exportmöglichkeit von Katalogdaten nach BibSonomy, aber OpenBib bietet noch verschiedene andere Möglichkeiten der Weiterverwendung der Bibliotheksdaten, wie u.a. die strukturierte Übernahme via UnAPI (z.B. in Zotero).

Die damals eingeführte Integration von BibSonomy ermöglichte auf einfache Art die Nutzbarkeit der Daten in einem gemeinschaftlichen Kontext – lokale Katalogisate konnten einfach übernommen und mit eigenen Tags versehen werden. BibSonomy ermöglichte dann über die vergebenen Tags andere potentiell interessante Quellen (Publikationen und Internetquellen) zu finden.

Wenig später wurde OpenBib um eine eigene Tagging-Funktion erweitert. War diese zunächst noch eine zeitgemäße Alternative zu klassischen strukturierten Merklisten, wurde wenig später durch die Öffnung öffentlich markierter Tags für andere auch eine gemeinschaftliche Nutzung ermöglicht. Dieses Social-Tagging auf lokaler Ebene bringt jedoch auch Probleme mit sich:

  1. Kritische Masse und Zersplitterung der Nutzer. Die potentielle Nutzerschaft für einen lokalen Katalog ist typischerweise begrenzt. Für ein gewinnbringendes Social-Tagging ist aber eine kritische Masse an Nutzern notwendig, die entsprechend aktiv ist. Durch die Existenz diverser Bibliothekskataloge (eine Uni, eine UB, ein Katalog) findet aber zwangsläufig eine Zersplitterung statt. Der mögliche erreichbare Nutzen ist nicht optimal.
  2. Lokale Tags werden neues Datensilo. Zwar sind die Katalogdaten ‚befreit‚, die lokal vergebenen Tags sind aber in der lokalen Katalogsanwendung eingeschlossen und bilden ein neues Datensilo. Auch das ist nicht optimal.

Vor diesem Hintergrund ist es daher sehr sinnvoll, den Weg hin zu einer oder mehreren übergeordneten Instanzen wie z.B. BibSonomy weiter zu verfolgen, die Katalogdaten und Tags von vielen verschiedenen Quellen (insbesondere gerade Bibliothekskatalogen) vereint und damit als großer Datenaggregator auftritt.

Der Nutzen einer solchen übergeordneten Instanz ist umso größer, je mehr Daten von verschiedenen (Katalog)Quellen in diese übernommen werden, und je besser diese Instanz wiederum in einen lokalen Katalog integriert werden kann.

Daher wurde die Integration von BibSonomy in der Version 2.2 von OpenBib grundlegend erweitert. Diese Version ist bereits produktiv und unter kug.ub.uni-koeln.de verfügbar.

Konkret wird in dieser Version

  1. ein Browser fuer BibSonomy-Quellen und
  2. eine Spiegelung der lokalen Tagging-Aktionen

nach BibSonomy integriert.

Hintergrund von 1) ist der Wunsch über die zentrale Datenbasis von BibSonomy anhand von Tags weitere thematisch infrage kommende Quellen zu entdecken (Publikationen und Bookmarks). Damit wird dem Aspekt „Ich möchte auch etwas finden, was ich nicht gesucht habe“ Rechnung getragen, der so bei einem Treffen mit Wissenschaftlern im Rahmen des beluga-Projektes geäussert wurde.

Dazu wird mit dem Bibkey (konkreter: dem derzeitigen inter-hash key von BibSonomy) für Publikationen bei der Einzeltrefferanzeige eines Titels ein Lookup in BibSonomy gemacht und gegebenenfalls die dort zugehörigen Tags angezeigt.

Da nicht jeder Titel aus dem KUG schon in BibSonomy vorhanden ist, andererseits aber zu entsprechenden relevanten Tags weitere interessante Titel in BibSonomy gefunden werden können, werden zusätzlich die im KUG-Titel verwendeten Schlagworte ‚taggifiziert‘ und mit BibSonomy abgeglichen. Auf diese Weise erhält der Nutzer effektiv eine Tag-Liste, über die er in den Bestand von BibSonomy eintauchen kann. Das ganze geschieht vollintegriert (über das BibSonomy-API) in der KUG-Oberfläche.

Anhand der in BibSonomy gefundenen Bibkeys für Publikatinen wird dann on-the-fly jeweils wieder ein Lookup im KUG-Bestand gemacht, so dass für die in BibSonomy erbrowsten Titel dann wieder die lokale Verfügbarkeit in den KUG-Katalogen sofort mit ausgegeben werden kann. Dazu wird jeder Titel im KUG mit einem Bibkey angereichert – so er über alle relevanten Informationen für dessen Bildung verfügt.

Es kann natürlich vorkommen, dass ein und derselbe Titel in KUG und BibSonomy leicht verschieden aufgenommen ist – speziell die Kodierung von Umlauten/Diakritika ist hier ein Problem – und damit die Bibkeys differieren. Daher bedeutet eine gefundene negative Verfügbarkeit fuer den KUG nicht zwangsläufig, dass der Titel dort wirklich nicht vorhanden ist – das ist aber der Preis der gezahlt werden muss…

Ein Beispiel, das diese neue Funktion ganz gut illustriert ist der folgende Titel aus dem Produktions-System mit der neuen Version:

http://kug.ub.uni-koeln.de/portal/connector/permalink/inst006/6439/1/inst006/index.html

Unter der Titel-Daten-Kategorie ‚BibSonomy-Tags‚ verbergen sich die relevanten Tags, über die in den Datenbestand von BibSonomy eingetaucht werden kann.

Stellt 1) einen Weg dar, BibSonomy in den eigenen Katalog zu integrieren und als die angesprochene ‚gemeinsame‚ Datenbasis lokal zu nutzen, wird mit 2) genau die dazu notwendige Öffnung des Datensilos OPAC und ein verbesserter (Katalog- und Tagging-) Datenfluß nach BibSonomy forciert. Dazu bekommt der Nutzer ab dieser KUG-Version die Möglichkeit seine Tagging-Aktionen im KUG vollautomatisiert nach BibSonomy zu spiegeln.

Konkret taggt er dann wie vorher munter im KUG. Nur werden seine Tags und Titel nicht nur im KUG gespeichert. Darüber hinaus werden die Titel im KUG (so in seinem BibSonomy-Account noch nicht vorhanden) automatisch in seinem BibSonomy-Account eingetragen und mit den lokal im KUG vergebenen Tags und der Sichtbarkeitsinformation (öffentlich oder privat) versehen. Ändert er seine Tags im KUG, so werden diese Änderungen auch in BibSonomy automatisch nachgezogen.

Auf diese Weise können die Nutzer weiterhin lokal den OPAC mit all seinen Funktionen nutzen, die Daten wandern aber zusätzlich zu der geforderten gemeinsamen ‚Datenzentrale‚ BibSonomy über die der Nutzer weitergehende Dienste angeboten bekommt, die er anderseits aber wieder rückgekoppelt im lokalen Kontext als Datenquelle verwenden kann.