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

[Michael Lackhoff]

Lieber Herr Berger,

> 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.

Fast genau so machen wir es jetzt auch. Meine vorige Mail bezog sich auf
den KiVK, bei dessen Entstehen (ausser Allegro ;-)) noch kaum eine der
heute wichtigen Werkzeuge breit verfuegbar waren.

Aktuell sieht dann ungefaehr so aus:
* was wir bekommen koennen, kommt in unseren Lucene/Solr Index, meist
  allerdings nicht als OAI-PMH aber vergleichbar.
* der Rest wird zusaetzlich als Metasuche eingebunden (mit stark
  abnehmender Tendenz)
* Die Datensätze haben einen Link in die Originaldatenbank, um die volle
  Pracht des urspruenglichen Datensatzes nutzen zu koennen.

Wir versuchen allerdings noch einen Schritt weiter zu gehen: Statt den
Nutzer ueber den Link von dannen ziehen zu lassen, gibt es erste
Ansaetze, das Original dann live noch mal ranzuholen.
Bisher haben wir das nur in unserem OPAC gemacht. Da ist eine einfache
Version des Satzes in Index, bei der Einzeltrefferanzeige wird aber noch
einmal der aktuelle Datensatz aus der Sisis-Datenbank geholt. Das hat
den Vorteil, dass wir den Index verhaeltnismaessig schlank halten
koennen (nur suchbare Felder) aber in der Anzeige doch alles anzeigen
koennen. Die Verfuegbarkeitsinformationen werden dabei gleich mit geholt.
Im Rahmen von Linked Data wollen wir dieses Konzept kuenftig noch
ausbauen und die Einzeltreffer gezielt live anreichern (online oder
ueber lokale Cache-Datenbank). Das ist aber noch in einer sehr fruehen
Phase. Eines der Ziele dabei ist natuerlich auch, den Nutzer moeglichst
im eigenen Portal zu halten und ihm eine Rundum-Loesung anzubieten aber
eben nicht mehr, indem wir alles doppeln sondern durch eine
differenzierte Architektur.

Insgesamt laesst sich sicher sagen, dass die Tendenz klar weggeht von
fetten Datensaetzen, hin zu einer sehr stark verknuepften Struktur. Was
dabei allerdings oft noch fehlt, sind zuverlaessige Identifikatoren,
ueber die dann die Verknuepfungen laufen koennen. Es gibt leider immer
noch viel zu viele Daten, die neben der lokalen ID nur noch eine ISBN
haben oder wenn es hoch kommt noch eine Verbund-ID, damit kommt man aber
nicht sehr weit, wenn man ueber den grossen Teich will. Mit VIAF gibt es
da erste Verbesserungen aber bei den Titeldaten hapert es oft noch.

Viele Gruesse
Michael Lackhoff