Warum zwei Reiter?
Wir haben nicht viel Feedback auf unseren TUBfind-Relaunch mit der Zwei-Reiter-Lösung bekommen. Offenbar wurde er sogar für einen Aprilscherz gehalten. Dass es uns ernst damit ist, hat sich inzwischen aber wohl gezeigt. Drei Reaktionen, die über Twitter geäußert wurden, sind oben im Screenshot festgehalten.
Wir möchten aus diesem Anlass nochmal kurz erklären, weshalb wir die Lösung mit den zwei Reitern realisiert haben. Wir würden auch lieber nur eine Liste anbieten, und mit PrimoCentral ist theoretisch die Möglichkeit dazu gegeben (im Finc-Katalog der UB Leipzig wird die Vermischung bereits seit Jahren praktiziert, das ist ein weitaus passenderes Beispiel als Google Universal Search, das technologisch mit unserer Umgebung nicht vergleichbar ist). Im Vorfeld haben wir uns intensiv damit beschäftigt, aber unsere Testergebnisse waren eben (leider) nicht so positiv. Sowohl innerhalb des GBV-Index (der sich hinter dem „Bücher und mehr…“-Reiter verbirgt) als auch im PC-Index werden Suchergebnisse nach Relevanz gewichtet. Mischt man die Ergebnisse aus beiden Indizes in einer Ergebnisliste, kann es vorkommen, dass die Treffer aus *einem* Index sehr dominant sind.
Der für die Mischung derzeit verantwortliche Algorithmus kann aber heterogene Daten nur sehr begrenzt innerhalb eines kleinen Ergebnissets mischen. Weitere Probleme entstehen im Bereich der Facetten sowie bei der Möglichkeit, das Suchergebnis auszuweiten (über den Button „Auch in anderen Bibliotheken suchen“ bzw. „Weitere Ergebnisse“). Deshalb bieten wir die Ergebnisse nun getrennt an.
Wir behalten das im Auge und werden weiterhin versuchen, die Ergebnislisten zu vereinheitlichen und wieder zusammenzuführen. Zum jetzigen Zeitpunkt waren unsere Testergebnisse aber nicht überzeugend genug, um eine gemeinsame Ergebnisliste in die Öffentlichkeit zu entlassen. Bis es so weit ist, kann der Mehrwert, der sich aus dem erweiterten Datenschatz ergibt, immerhin schon genutzt werden.
6 Comments
Die unterschiedlichen Relevanz- und Indexierungsalgorithmen der jeweiligen Indexlieferanten bergen das von Weier treffend beschriebene Risiko mit den entsprechenden Konsequenzen.
Aus diesem Grund stellt sich die Frage, die Metadaten der in Primo enthaltenen Pakete mittelfristig mit Hilfe des GBV selbst zu beziehen und zu indexieren, damit auch bei diesen Metadaten die Relevanzberechnung und Facettierung homogen verläuft.
Dieses Vorgehen hat den Nachteil, dass der personelle Aufwand für die Metadatenintegration und -aktualisierung steigt. Für unseren Nutzern sollte dies jedoch wert sein, um die Reiternavigation zu vermeiden
Wir würden es auch begrüßen, wenn der GBV-Index weiter ausgebaut wird. Die technische Basis für eine Erweiterung wäre wohl gegeben mit der Solr-Cloud.
Es bedarf aber einer strategischen Entscheidung des GBV, ob dies ein zentraler 7*24 Service mit entsprechendem personellen Unterbau wird.
Wenn man sich einzelne Daten aus den unterschiedlichen Quellen mal anschaut, wird schnell klar, wie unterschiedlich die Qualität ist. Auf unserer VUfind Konferenz hat Gerald Steilen das mit ernüchernden Beispielen deutlich gemacht.
TUBfind mit Primo-Central in einer eigenen Ergebnisliste sehe ich trotzdem als einen Gewinn an. TUBfind ist weiter auf dem Weg und wer weiß, wo wir am Ende des Jahres stehen werden.
Die Probleme, die der Kollege beschrieben hat, kann ich nur bestätigen. Meiner Meinung nach läßt sich das Problem auf lokaler Ebene aber langfristig nicht beheben. Die hohe Änderungsrate vor allem in der externen Datenquelle und die Natur der Berechnung der score-Values lässt ein stabiles und sinnvolles Einmergen der parallel entstehenden Treffermenge zu einem unvorhersehbaren Problem werden. Die Konsequenz aus der Problematik kann allerdings meiner Meinung nach nicht sein, dass man zusieht, dass man alle externen Datenpakete von den Lieferanten regelmäßig kopiert und einen immer größer werdenden Index vorhält. Allein das enorme Wachstum der Datenmenge und der dadurch steigende kostenintensive Betrieb machen das Vorgehen bereits mittelfristig zu einer Herausforderung. Ich bin darüber hinaus der Meinung, dass wir uns von der Idee verabschieden müssen, dass jede Institution die immer wieder gleichen großen Datenmengen aufbereitet und speichert. Die einzige Lösung sehe ich in einer der großen Cloud basierten Datenmanagementlösungen mit einer für alle Mandanten zentralen Katalogisierung in einen „Masterdatentopf“.
Ich stimme Dirk Kußmann zu und halte die momentane Praxis für eine Fehlentwicklung, deren sichtbare Auswirkung diese „Reiter-Problematik“ ist (als wäre es eine Frage der Benutzeroberflächengestaltung). Ich bezweifle auch, dass der von Heiko Weier angesprochene Mehrwert den Aufwand und die Kosten rechtfertigt. Wenn zusätzliche Daten im Katalog, dann aber bitte gleich richtig machen und das einmal aus der Nutzerperspektive denken.
Wenn ich Dirk Kußmann richtig verstehe, dann spricht er sich nicht gerade dafür aus, die Daten in den eigenen Katalog zu packen, so wie Elmar Haake und Heiko Weier es postulieren (in unserem Fall: Erweiterung des GBV Index). Herr Kußmann spricht von einer „cloudbasierten Datenmanagementlösung“ mit einer zentralen Katalogisierung für alle. Sowas haben wir im GBV (aber eben begrenzt auf den GBV) in Form des CBS. Der GBV Index geht schon jetzt über das CBS hinaus, aber bezieht eben nicht alle von uns als wünschenswert empfundenen Daten ein (z.B. IEEE). Um diese Daten zu bekommen gibt es drei mögliche Ansätze:
1. Den GBV um eine Erweiterung des Index bitten (was nicht in allen Fällen möglich ist)
2. es selbst machen (was uns in diesem Fall auch nicht möglich ist)
oder
3. einen kommerziellen Index einsetzen, der eben solche Daten enthält.
Wir haben uns für die dritte Lösung entschieden, weil sie am schnellsten realisierbar war. Sie hat allerdings (ich kann mich nur wiederholen: leider) momentan die geschilderten Nebeneffekte (die bei jedem anderen externen Index auch so gegeben wären).
Es ist ja nicht so, dass wir „zusätzliche Daten in den Katalog“ gepackt haben – wenn dem so wäre, hätten wir diese Probleme nicht. Wir haben sozusagen einen zweiten Katalog (einen völlig eigenständigen, separaten Index) neben den vorhandenen gestellt. Für die Nutzer ergibt sich aus meiner Sicht ohne Zweifel ein Mehrwert, da jetzt wesentlich mehr Daten auf Artikel- und Buchkapitelebene gefunden werden können.
Ich kann die Wucht der geäusserten Kritik nicht ganz nachvollziehen. Sicherlich wäre die aus Nutzersicht beste Lösung die Präsentation nur einer integrierten Trefferliste aus allen beteiligten Datenquellen. D’accord. Bei allem Verständnis, sich bei technischen Lösungen an diesem Ziel zu orientieren, dürfen aber dennoch nicht die technischen Realitäten ignoriert werden, die eben genau diesem Ziel im Wege stehen und sowohl im Artikel wie auch den Kommentaren bereits angeklungen sind.
Selbst unter Verwendung der kommenden Cloud-Systeme (z.B. WMS, Alma) oder der bestehenden Discovery Indexes (z.B. EDS, Primo Central) werden sich zukünftig IMHO nicht alle wünschenswerten Quellen dort beliebig unterbringen lassen. Ich denke bei uns da z.B. an temporaere wechselnde E-Book Kollektionen, Spezialindizes mit PDA-Beständen für Print/E-Books usw.
D.h. wir werden es auch zukünftig immer mit Daten aus verschiedenen Quellen/Indizes zu tun haben und müssen für eben dieses Problem geeignete nutzerorientierte Lösungen finden.
Nahe an die o.g. Ideallösung kommt man heutzutage fast nur durch Low-Level Zugriffe innerhalb eines gegebenen Suchmaschinen-API’s. Das Mischen und Ranken funktioniert dann idR ganz gut, wenn einheitlich jeweils z.B. dezentrale Lucene oder SOLR oder Xapian oder ElasticSearch-Indizes angesprochen werden. In der Realität kommt das aber kaum vor. In der Realität – wie in Hamburg-Harburg, oder bei uns in Köln – hat man mehrere Suchmaschinen-Indizes aus verschiedenen Systemen, typischerweise einen eigenen Index mit den lokalen Katalogen bzw. anderen Datenquellen unter eigener Kontrolle und einen Discovery-Index für lizensierte Zeitschriftenartikel, den man extern einkaufen muss.
Und genau dann läuft man beim Mischen und Ranken in die angesprochenen Probleme und muss zwangsläufig „tricksen“, um dem Endnutzer die unter diesen Randbedingungen „bestmögliche“ Nutzerführungen und Ergebnisqualität zu bieten.
Ob die bestehenden Lösungen wie die doch recht gängige Zwei-Reiter-Variante oder unsere Suchprofil-Variante der Weisheit letzter Schluss sind, kann man diskutieren. Das Einstreuen von Ergebnis-Teasern aus externen Discovery-Indizes wäre eine andere „Trickserei“-Lösung, die eventuell vom Endnutzer besser aufgenommen/verstanden werden könnte.
Zielführend wäre es – nach meiner Einschätzung – eine unter den gegebenen Randbedingungen bestmögliche Lösung für den Endnutzer zu finden, sich von anderen Vorgehensweisen ala Google Universal Search inspirieren zu lassen aber bei alledem die „technischen Bodenhaftung“ nicht zu verlieren…. sagt ein bibliothekarisch sozialisierter Nicht-Bibliothekar 😉