[Allegro] Zentraler Nachweis für Fach- und Spezialbibliotheken im KVK

[Thomas Berger]

Am 20.08.2012 13:21, schrieb Michael Lackhoff:

> Problematisch war immer die Doublettenbereinigung bzw. die
> Normalisierung auf ein einheitliches Format. Es gab eine enorme
> Bandbreite bei der Erschliessungstiefe und auch bei der
> Katalogisierungspraxis. Die Interpretation von Regelwerk und
> Kategorienformat war da schon mal etwas eigenwillig oder zumindest nicht
> einheitlich.
> Eine Metasuche stoesst mit steigender Zahl der durchsuchten Kataloge
> schnell an Grenzen, sowohl was die Parallelitaet angeht (jede Suche
> loest sehr viele Subprozesse aus) als auch was die Ergebnisdarstellung
> angeht. Dann kommen eben immer wieder dieselben Treffer aus zig
> Bibliotheken.
> Zusammenspielen im Vorfeld ist da besser aber eben auch aus den
> genannten Gruenden sehr muehsam. Man muss staendig sehr hohen Aufwand in
> die Qualitaetskontrolle stecken.

Der aktuelle Stand der Technik ist eher "hybrid":

* Es wird nicht versucht, eine kumulierende Datenbank
  aufzubauen (Uneinheitlichkeit der Datenformate, Logistische
  Probleme, halbwegs aktuelle "Datenlieferungen" zu bekommen)

* Es wird nicht mehr versucht, eine verteilte Suche zu
  veranstalten (Uneinheitlichkeit der unterstuetzten Z39.50-
  Attribute bzw. deren Interpretation, Systemlast bei allen
  Teilnehmern).

Vielmehr werden aktuelle Daten aller Teilnehmer moeglichst
geharvestet, dabei darf es aber Verlust an Differenzierung
geben, auch Dublin Core ist nich bah!, Trennschaerfe ist
im Zweifelsfall wichtiger als Ausdifferenzierung, und daraus
(ggfls. noch einen Grad weniger differenziert) Volltext-
Suchindizes (SolR laesst gruessen).

Im Ergebnis kann man dann ein Server schnell aufgrund einer
rein lokalen Suche Ergebnismengen bilden, praesentieren,
vom Benutzer reduzieren lassen und irgendwann - sofern
gewuenscht - auf die Einzeltreffer in ihrem "natuerlichen"
Habitat, den jeweiligen Herkunftskatalogen mit tendenziell
ganz anderer Kontextualisierung - weiterleiten.

Noch aktueller sind dann Weiterentwicklungen, die m.E.
versuchen, besser zu skalieren: Lokale Suche ueber mehrere,
distinkte Indizes, Replikation von Indizes etc.

Ein "Teilnehmer" braucht dann natuerlich nicht nur seien
(von aussen verlinkbaren) OPAC, sondern auch eine "im
Internet" angesiedelte Moeglichkeit, seine Daten maschinen-
lesbar einem Harvesten auszusetzen, etwa durch OAI-PMH-
Schnittstellen.

Ich halte diese Ansaetze fuer technisch und auch inhaltlich
angemessen: Durch die Einsicht, dass man

1. trotz einheitlicher Datenformate und Abfragesprachen niemals
   einheitlichen Daten bekommt (und dass das auch kein "Fehler"
   ist, an dem man mit immer ausgefeilteren Schnittstellen
   herumdoktern kann),

und
2. "records" in verschiedenen Kontexten unterschiedlich nutzen
   kann (so dass ein uebergreifender Nachweis komplementaer
   ist aber kein Ersatz: Weder ist der InterGalacticCat der Tod
   des lokalen Katalogs noch seine Aufhebung im Sinne eines Heils-
   versprechens): Auch die Nutzer agieren (jeder einzelne) in
   unterschiedlichen fachlichen und Anforderungs-Kontexten, und
   weder Groesse an sich noch Bestandsgebundenheit sind Garanten
   dafuer, dass im Katalog x die Beduerfnisse beliebiger Benutzer
   besser bedient werden als im Katalog y.

also indem man Heterogenitaet akzeptiert und auch selbst nicht
verspricht, fuer alle Anwendungsfaelle die beste Loesung zu stellen,
kann man auf viele Konversionen (und die dazugehoerigen Datenanalysen
und bilateralen Absprachen) verzichten, die auf eine "verlustlose"
Verpflanzung von Records abzielten, und statt dessen technisch
effiziente Suchen auf ziemlich aktuellen Datenbestaenden realisieren.

Obwohl es standardisierte Schnittstellen, Protokolle und Software-
Bibliotheken gibt, entstehen uebergreifende Nachweisinstrumente
aber immer noch nicht von selbst, und sie benoetigen Hardware,
Energie und Bandbreite. "allegro" steht da auch nirgendwo drauf,
das liegt in der Natur der Sache (andere Bibliothekssysteme haben
moeglicherweise interne Replikations- oder Kommunikationsmechanismen,
damit "Austausch" zwischen Produkten desselben Herstellers irgendwie
einfacher oder blinkender ist als bei Nutzung von Standards).
[Es lassen sich aber auch dezentrale Ansaetze denken, ganz ohne
zentrale Suchmaschine, indem der Benutzer ausgehend von Treffern
oder Nicht-Treffern im Katalog x auf Kataloge y und z verwiesen
wird, in denen Treffer garantiert werden]

Aber auch auf Ebene eines Einzelsystems, auf dem "allegro" drauf
steht, ist nicht alles automatisch fuer das oben geschilderte
vorbereitet: Die Staerke, dass man die Software lokal auf dem
Dateisystem abwirft und draufloskatalogisiert, bedeutet ja, dass
man nicht automatisch auch einen Web-Katalog hat. Und wenn man
einen Web-Katalog hat, bedeutet das nicht automatisch, dass der
persistent adressierbar ist und/oder Harvesting von Daten
zulaesst. Gerade letzteres war ja vor einigen Jahren noch etwas
ganz ganz heikles, weil da immer ein Begriff von "Eigentum"
herumgeisterte und einige hatten Angst, dass ihre kostbaren Autopsate
geraeubert wurden, die meisten aber Angst davor, dass eventuell
Dritte Ansprueche auf selber uebernommene Fremdkatalogisiate geltend
machen koennten.

Diese Problematik ist noch nicht ganz aus der Welt (vgl. die
OLC-Datenbanken des GBV, die noch nicht einmal frei recherchierbar
sind, die grosse Aufregung, als OCLC vor zwei Jahren seine
Geschaeftsbedingungen (=Eigentumsanspruch auf alles) noch einmal
verschaerfen wollte oder ganz aktuell aus diesem Monat, dass
in den Open-Data-Bereitstellungen des HBZ ausgerechnet die
Katalogisate zu den Titeln aus Nationallizenzen-Paketen nicht
enthalten sein duerfen ...

Ganz konkret kann ich (besonders fuer "allegro"-)Bibliotheken raten,
"offen" zu sein fuer die Eventualitaet "zentraler Nachweise" aus
dem Subject der heutigen Mails:

1. Nicht an einen, sondern an viele "zentrale" Nachweise denken

2. Zentrale Nachweise ersetzen keinen eigenen Web-Katalog. Vielmehr
   setzen aktuelle "Suchmaschinenbasierte" Nachweisinstrumente einen
   eigenen Web-Katalog (mit bestimmten Eigenschaften) sogar voraus

3. Im Webkatalog auch den Zugriff auf maschinenlesbare Daten
   erlauben (ermoeglicht Harvesten, spart das regelmaessige
   Exportieren fuer die Kooperation mit xy, das entweder schnell
   einschlaeft oder zuviel Arbeitskraft bindet)

4. Herausfinden, ob die eigenen Daten an irgendeiner Stelle
   juristisch gebunden sind und "Open Data" entgegen stehen
   (unfreie Daten machen alles recht kompliziert: Man muss
   das eigene Angebot gegen Unbefugte Nutzung sichern und
   allen befugten Nutzern genau mitteilen, was diese wiederum
   mit den Daten tun bzw. nicht tun duerfen)

viele Gruesse
Thomas Berger