A growing organism

To tab or not to tab: Eine Discovery-Gretchenfrage

Posted in Kataloge et. al. by Anne Christensen on 4. Oktober 2012

Die Einführung eines Discovery-Tools stellt uns in Bibliotheken in der Regel vor die Frage, welche Daten wir eigentlich “entdecken” lassen wollen. Da wird man sehr schnell sehr gierig: Alle abonnierten Print- und E-Zeitschriften auf Artikelebene, bitte, die E-Books mit Kapitel und dann auch noch alle bibliografischen Datenbanken, wenn es geht. Dass das nicht so gut klappt, wie wir uns das wünschen, ist oft weder unsere Schuld noch die des Discovery-System-Anbieters, sondern die der Content-Anbieter, die ihre Daten – aus einer breiten Palette aus Gründen zwischen Nicht-Wissen, Unverstand und bewusstem Aussperren einiger Aggregatoren – nicht oder nicht in der wünschenswerten Erschließungstiefe bereit stellen.

Unabhängig von diesem Frust, dem man sich als auf Vollständigkeit getrimmte Bibliothekarin abholen kann, stellt sich dann noch eine ganz andere Frage, nämlich die danach, ob man die Daten aus dem Anbieter-Index und die aus der eigenen Bibliothek gemeinsam oder getrennt recherchierbar machen sollte. Viele Bibliotheken entscheiden sich für etwas, das ich jetzt  mal “getabbte” Lösung nenne: Ein Reiter mit den Lokaldaten, ein Reiter mit dem gekauften Index. Der KatalogPlus der UB Freiburg ist dafür ein Beispiel, hier wird nach “Büchern und mehr” und “Artikeln und mehr” unterschieden. Ich weiß von einigen Bibliotheken, in denen die Frage des Umgangs mit diesem Problem ausgesprochen kontrovers diskutiert wird- und in der Tat glaube ich, dass das so eine Art Gretchenfrage bei der Einführung von Discovery-Systemen ist.

Die Akzeptanz von Discovery-Systemen bei Bibliothekarinnen und Bibliothekarinnen wird unter anderem davon herausgefordert, dass die Trefferliste in Quantität und Qualität sehr viel unberechenbarer sind als beim herkömmlichen Katalog. Mit der getabbten Lösung holen wir uns etwas von der alten Welt zurück: Klassischer Katalog-Content und Zeitschriftenartikel sind für uns zwei grundverschiedene Paar Schuhe und  wurden klassischerweise über unterschiedliche Instrumente nachgewiesen. Die getabbte Lösung macht es uns einfach, unser Modell von der Suche auch auf Discovery-Systeme zu übertragen.

Bei allem Verständnis für das heimelige Wohlgefühl, das von getabbten Lösungen auszugehen scheint: Ich bin der Meinung, dass man mit getabbten Lösungen wieder in die Ära der Metasuche zurückfällt die Vorteile von Discovery-Systemen verspielt. Eine Idee von Discovery ist doch auch, dass die bibliothekarische Unterscheidung in selbständige und unselbständige Werke keine Rolle mehr spielen braucht – jedenfalls nicht am Anfang der Suche. Nachher, beim Verfeinern: Keine Frage. Aber gleich zu Beginn der Suche? Sollten wir nicht froh sein, dass wir uns den Sermon darüber, was man im Bibliothekskatalog findet und was nicht und das Zeitschriften etwas anderes sind als Zeitschriftenartikel, vielleicht künftig öfter mal einsparen können? Ist es nicht viel mehr Erleichterung als Bürde, die wir empfinnden sollten?

Discovery-Services sind Tools für NutzerInnen. Studien zu deren Informationsverhalten sowie Usability-Tests zeigen, dass NutzerInnen – vorsichtig formuliert – keine Lust haben, sich mit Publikationsformen auseinanderzusetzen. Sie wollen relevante Treffer vorn. Ob es eine Monographie, ein Buchkapitel oder ein Aufsatz ist, ist egal – entscheidend für die Auswahl ist in dem meisten Fällen ohnehin, wie bequem sich die Treffer auf dem Bildschirm anzeigen lassen. Wer versierter ist, nutzt Facetten oder muss auf den Trichter gebracht werden, dass es noch andere Tools als Discovery gibt mit oft besseren Suchmöglichkeiten.  Mein Traum von Discovery ist eigentlich, dass die Leute nach einiger zu mir kommen und sagen, dein Discovery-Dings ist ja schön und gut, aber für meine Suche nach Placebo-kontrollierten Studien über Kopfschmerztablettenkonsum bei 35-40-jährigen Frauen in republikanisch regierten US-Bundesstaaten komme ich hier nicht weiter. An der Stelle zücke ich dann diejenigen “schweren Waffen”, die wir dem Bibliothekspublikum sonst nur mühselig aufschwatzen können, also die ganzen guten und teuren bibliografischen Datenbanken, für deren Benutzung  wir mit unserem bibliothekarischen Spezialwissen (“…und hier der pfiffige Thesaurus”) trumpfen können.

Fazit: Ich bin – leidenschaftlich – gegen getabbte Lösungen. Ich verstehe aber, warum sie uns (und wer weiß, vielleicht auch unseren NutzerInnen) sympathisch sind. Und es gibt auch gute Umsetzungen – die Brown University Library zum Beispiel hat in ihrer Discovery-Lösung einen Suchschlitz, bereitet die “Bücher und mehr” und “Artikel und mehr”-Treffer aber in zwei nebeneinanderstehenen Listen ab. Es gibt sicher auch vernünftige Kompromisse. Und am Ende des Tages ist das Thema Discovery ja im Moment nichts anderes als ein Wimpernschlag in der Geschichte von Bibliothekskatalogen, und in ein paar Jahren vielleicht werden wir und unsere NutzerInnen mehr Erfahrungen damit gesammelt haben und dann schlauer sein als im Moment. Eine polemische Zusammenfassung sei aber noch gestattet:  Getabbte Lösungen sind eine Art  Methadon-Programm dafür, uns BibliothekarInnen beim Entzug vom klassischen Bibliothekskatalog zu helfen. Sie sind aber auch in hohem Maße dafür geeignet, NutzerInnen für die vielen anderen Instrumente der Recherche anzufixen.

About these ads

21 Antworten

Subscribe to comments with RSS.

  1. Doerte (@bibliothekarin) said, on 4. Oktober 2012 at 4:35 nachmittags

    Danke Anne,
    du hast mir damit aus vollster Seele gesprochen. Wir nehmen mit getabbten Lösungen, mit denen wir unseren kleinen, lokalen Bestand promoten, unseren Nutzern die Möglichkeit, die besten Ergebnisse auf einen Blick zu erhalten. Und ist nicht gerade neben der Möglichkeit, Inhalte zu entdecken, das tolle an einem solchen System, dass ich nur an einer einzigen Stelle suchen muss und so die Chance habe, sofort das Richtige, was ich als Nutzer benötige, zu finden? Ein nachträgliche Einschränkung auf Content, zu dem ich dann schnellstmöglich Zugang erhalten kann, ist ein Serviceangebot der Bibliothek, aber keine Bevormundung mehr.

    Gruss
    Dörte

  2. Oliver Goldschmidt said, on 5. Oktober 2012 at 9:25 vormittags

    Hej Anne,

    auch von mir ein herzliches Dankeschön für diesen fantastischen Beitrag. Ich kann mich Dörte nur anschließen, dass Du auch mir damit voll aus der Seele gesprochen hast.
    Ein kleiner, eher technischer Nachtrag, sei allerdings noch gestattet: Technisch ist das Problem des Mischens von Ergebnislisten nur äußerst schwer lösbar (zumindest, wenn man ein vernünftiges Relevanzbewertungsverfahren bewahren möchte). Das mag ein Grund sein, warum die Discovery-System-Anbieter eher zu getabbten Lösungen neigen. Dass es lösbar ist, zeigt die finc-Vufind-Lösung in Leipzig.
    Auch die Facetten sind bei der Ergebnislistenmischung nicht unproblematisch (zum Beispiel bei unterschiedlichen Autoren-Schreibweisen oder Facettierung auf Klassifikationssysteme, die in Discovery-System-Indizes in der Regel nicht enthalten sind). Dieses Problem verschwindet aber keineswegs, wenn man die Ergebnislisten in verschiedene Tabs verbannt…

    Es gibt also durchaus Baustellen bei der Mischung von Ergebnislisten, aber diese sind sicherlich lösbar! Zudem ist es für den Nutzer ja nicht unbedingt nachvollziehbar, was nun warum in welchem Tab steht, und wenn man weitere Quellen in die Suche mit aufnehmen wollte, wäre die einzige Lösung, noch mehr Tabs hinzuzufügen (was der Übersichtlichkeit aus meiner Sicht eher schadet). Daher schließe ich mich vorbehaltlos dem Statement an: eine einzige Ergebnisliste ist diversen Tabs absolut vorzuziehen.

    • Anne Christensen said, on 5. Oktober 2012 at 10:09 vormittags

      Lieber Oliver, danke zurück! Was die technische Frage angeht: Ich bin beim Schreiben von einem Discovery-System mit einem zentralen Index ausgegangen, in das die lokalen Daten eingespielt werden. In dem Fall sind sowohl Ranking als auch Facettierung unproblematisch – und wenn das schon mehrfach gerade auch von euch erwähnte Sharding eingesetzt wird, doch auch, oder?

      • Oliver Goldschmidt said, on 5. Oktober 2012 at 10:55 vormittags

        In erster Linie ist die Relevanzbewertung gerade beim Sharding problematisch. Hintergrund: Beim Sharding werden mehrere Indizes parallel abgefragt, aber für jeden einzelnen wird die Relevanz bewertet. Wenn die Indizes verschieden groß sind, kann das zu erheblichen Unterschieden bei der Gewichtung führen. Das muss in der Praxis nicht ganz so schlimm sein, aber man sollte es wissen, um dann ggf. auch gezielt gegensteuern zu können (z.B. durch Pushing ganz bestimmter Treffer an den Anfang der Ergebnisliste). Du hast aber recht, dass dies weniger problematisch sein dürfte, wenn man einen einzigen Index hat (was ja in eurem Fall so ist).

        Bei der Facettierung sehe ich in jedem Fall Probleme, ob man nun mischt oder nicht.
        Erstens fehlen wie gesagt bestimmte Merkmale (z.B. Klassifikationen) in den dazugekauften Indizen. Mischt man nun die Ergebnislisten, möchte aber nach wie vor eine Facettierung auf Klassen anbieten, so wird diese zwangsläufig scheitern bzw. keine Treffer aus dem dazugekauften Index liefern (damit ist der Mehrwert dieser Daten in dieser Konstellation weg). Mischt man die Ergebnislisten nicht, sondern greift auf verschiedene Tabs zurück, dann kann diese Facette im zusätzlichen Tab nicht angeboten werden. Letzteres ist aus meiner Sicht etwas konsistenter, in diesem Fall wäre eine Tab-Ansicht also vielleicht weniger verwirrend.
        Bei Autorennamen gibt es bisweilen so viele verschiedene Varianten, dass eine Facettierung darüber allgemein schwierig sein kann. Ein dazugekaufter Index sorgt dabei im Zweifelsfall für noch mehr verschiedene Varianten, was nicht unbedingt hilfreich ist.
        Letztlich kann auch die Formatfacette (meiner Meinung nach eine der hilfreichsten Facetten) durch uneinheitliche Belegung eher verwirrend wirken. Ich bin nicht sicher, wie Summon das mittlerweile handhabt, anfangs gabs da ziemliche Schwierigkeiten…

      • Till Kinstler said, on 9. Oktober 2012 at 10:19 vormittags

        Hmmm, warum kann ich auf Olis Beitrag nicht antworten, sondern nur auf Anne? Egal, dashier bezieht sich auf Olis Anmerkungen zum Sharding:

        Zur Berechnung des Rankings beim Sharding bei Solr: Die Datenmenge in den Shards spielt dabei eigentlich keine erhebliche Rolle, sondern, wie immer beim Vektorraummodell, die Termverteilung: Bei der Berechnung der Termgewichte (die auch nur ein Faktor in der Berechnung des Rankings sind), spielt TF und IDF eine wesentliche Rolle. TF ist die term frequency und zählt einfach, wie oft ein term in einem Index-Dokument vorkommt, also kein Problem auch bei Sharding.
        IDF ist die inverse document frequency, ein relatives Maß dafür, wie häufig ein Term über den gesamten Dokumentbestand im Index vorkommt. Dieser Wert wird bei Solr nur pro Shard berechnet, nicht über den gesamten “vereinten” Index. Wie das mit relativen Werten so ist, ist das ein Problem, wenn die Termverteilung in den Shards sehr unterschiedlich ist. Ich würde das bei typischen, ausreichend großen, “bunten” Bibliotheksdatenbeständen aber schlicht nicht erwarten… Da IDF aber eben ein relativer Wert ist, spielt die Anzahl der Dokumente in einem Index keine Rolle.
        Eine Berechnung des IDF über die vereinigten Shards ist technisch nicht trivial, da dazu eben Vorkommenshäufigkeiten zwischen den Shards ausgetauscht werden müssten (was bei dynamischem Sharding bei jedem Request passieren müsste und einfach Zeit braucht). Christian Kohlschütter und Kollegen hatten sich darüber schonmal Gedanken im Rahmen von Vascoda gemacht: http://www.base-search.net/about/download/FedSearchReport.pdf (wobei damals anscheinend keiner verstehen wollte oder konnte, was sie da eigentlich sagen…, ein schönes Beispiel, wie technische Realität in Projekten “politisch” zerrieben werden kann :-)
        Das Sharding-Verfahren in Solr ist schon ein ein guter Kompromiss, es ist wesentlich besser als das simple Mischen irgendwelcher sortierter Trefferlisten aus unterschiedlichen Quellen. Die ursprüngliche Idee dahinter war allerdings nicht das Mischen unterschiedlicher, verteilter Datenbestände (der alte Traum des Bibliothekswesens), sondern die Aufteilung großer “einheitlicher” Datenmengen zur Verbesserung der Suchgeschwindigkeit (ich vermute, dass das z.B. bei Summon intern eh gemacht wird).
        Sorry, dass das ein wenig technisch ist, aber da schwirren so viele lauwarme Vorstellungen von Sharding und verteilter Suche durch die Bibliothekswelt… Dabei ist es eigentlich ganz einfach, wenn man einfach mal auf die Technik schaut…
        Und wie es hier schon ein paar Mal steht: Die “getabten” Lösungen haben oft technische Gründe. Dass man in VuFind Suchergebnisse aus Summon oder WorldCat in eigenen Listen bekommt, liegt schlicht daran, dass sich diese Trefferlisten nicht sinnvoll mit den Treffern aus dem lokalen Solr-Index mischen lassen. Dass das dann gelegentlich wieder mit “für die Benutzer ist das ja auch besser” erklärt wird, liegt schlicht daran, dass man in dieser Branche ja nicht “zu technisch” argumentieren darf, weil einem dann ja die Zuhörer weglaufen (und nicht nur einschlafen, wenn man nach ihnen vertrauten Mustern argumentiert ;-).

        Facettierung (von Sacherschließung) auf Bibliotheksdaten funktioniert nach meinem Eindruck selbst bei den “Katalogdaten” einzelner Bibliotheken nicht wirklich gut. Dafür ist die Erschließung typischerweise einfach zu heterogen (oft nur unvollständig vorhanden, manchmal historisch bedingte Wechsel der Erschließungssystematiken…)… Und ich finde es schade, dass man über das simple Anzeigen der Facetten als Listen irgendwo neben den Suchergebnissen, bisher wenig kreative Ideen zur Nutzung dieser Statistiken hat… So wird das nix…
        Ich finde, wir machen zu wenig aus den Möglichkeiten, die wir hätten (bzw. “fressen” wieder, was wir für viel Geld vorgesetzt bekommen)… Deswegen ja auch meine zunehmende Skepsis, ob wir uns überhaupt noch mit diesen Discovery-Tools beschäftigen sollten.

  3. Anne Christensen said, on 5. Oktober 2012 at 10:19 vormittags

    Ich möchte gern eine von Kathi Woitas aka library_pirate auf Twitter begonnene Diskussion des Beitrags hier beantworten. Sie ist von meiner Argumentation nicht ganz überzeugt und schreibt: “untersch. Nutzergruppen brauchen untersch. Publikationen, Erstis keine spezifischen Artikel. Warum es nicht leicht machen?”; “Dann das Problem, dass Artikel meistens geboostet werden und der eigene/selbständige Bestand “untergeht”.” und “Und schliesslich viell einfach didaktisch sinnvoll, das gleich so prominent zu unterscheiden? Wir wissen ja eben um die Probleme…”

    Ein Urteil darüber, welche Nutzergruppen welche Publikationen brauchen, finde ich schwer zu fällen. In meiner Praxis sind es sogar die SchülerInnen mit den Facharbeiten, die die schwierigsten Fragestellungen haben (“Einfluss des Zusammenbruchs der DDR auf den Profifussball”), die sich fast ausschließlich mit Artikeln beantorten lassen. Aber ich verstehe das Argument – und habe mich ja selbst zum Beispiel gerade bei beluga dafür eingesetzt, Lehrbücher und andere Werke mit einführendem Charakter zu boosten. Die Möglichkeiten, das Ranking bei einem gekauften System individuell zu beeinflussen, sind natürlich recht gering. Ich würde der These, dass der eigene Bestand untergeht, aber aus meiner Erfahrung vehement widersprechen. Das ist bei unserer Summon-Installation beispielsweise nicht der Fall, und mein Eindruck ist auch, dass die Anbieter das schon sehr klar haben, dass wir als Kunden wollen, dass auch der “Bücher und mehr”-Kram gut sichtbar ist. Und zu dem letzten Argument: Ich finde durchaus, dass Studierende an einem gewissen Punkt bewusst darüber nachdenken sollten, welche Publikationstypen es gibt. Dazu kann ein Discovery-Tool anregen. Aber gleich am Anfang zu einer Differenzierung gezwungen zu werden, finde ich nicht gut – Dörte Böhner sprach hier sogar von Bevormundung (siehe erster Kommentar).

  4. Jan F. Maas said, on 8. Oktober 2012 at 5:55 nachmittags

    Hallo Anne,

    Ich stimme darin überein, dass im Fall eines idealen Relevanzrankings eine ein-Listen-Lösung der Idealfall wäre. Ich bin aber skeptisch, ob ein solches Ranking im allgemeinen Fall auf beliebigen Metadaten überhaupt möglich ist. Schon im Fall von reinen OPACS auf Suchmaschinenbasis – also ohne RDS-Daten – sind die bekannten Rankings m.E.n. noch mit Vorsicht zu genießen. Auch bei beluga wird der Prozess des Optimierens der Sortierung wohl nie wirklich abgeschlossen sein, auch wenn ich sehr zuversichtlich bin, dass wir das Ranking graduell immer weiter verbessern werden.

    Der Grund für diese Problematik ist, dass wir im Gegensatz zu Google bei Literatur meist nur Metadaten und keine Volltexte zur Verfügung haben, aber die dem Data Mining und der Websuche entlehnten Indexingalgorithmen in diesen nur eine unzureichende Basis für ihre Arbeit vorfinden. Durch die Hinzunahme der gewaltigen Mengen an Metadaten eines RDS, die dann oft in Form von volltextindexierten Daten und obendrein anderer Metadatetypen vorliegen, wird die Entwicklung eines entsprechenden Boostings der Relevanzsortierung aufgrund der Heterogenität der Datenmenge extrem schwer. Ob sich die Daten in einem einzelnen Index befinden oder durch Sharding hinzugeholt werden, macht in diesem Fall keinen Unterschied – das Problem entsteht schon bei der Relevanzsortierung in einem einzigen Index mit Mischdaten, nicht erst im Fall der nachträglichen Mischung von Ergebnissen (obgleich es in diesem Fall tatsächlich noch schwerer wird).

    Gerade weil ich den Gruppen von Nutzern keine Vorgaben machen will, welche Literatur sie verwenden sollen, möchte ich sie nicht durch eine suboptimale Relevanzsortierung beeinflussen, die die Daten des einen oder anderen Typs begünstigt oder schlimmstenfalls willkürlich mischt und damit die Idee der Relevanz ad absurdum führt. Bei einer getabbten Lösung kann ich aber individuelle Boostingfaktoren einführen, die die individuelle Datenlage – zumindest theoretisch – berücksichtigen, bzw. die Daten liegen von Anfang an getrennt vor. (Ich bin nebenbei bemerkt auch der Ansicht, dass die Frage der Relevanz im Idealfall immer mit Blick auf die Nutzergruppe zu beantworten ist. Deswegen möchte ich auch zukünftig Ansätze der Beeinflussung des Boostings durch query type detections verfolgen, wie sie ja schon früh in beluga implementiert wurden.)

    Zugegeben ist das Problem natürlich auch stark vom Anwendungsfall abhängig – wenn Du für Lüneburg mit der Sortierung von Summon gute Erfahrungen gemacht hast würde dies natürlich sehr darauf hindeuten, dass das Problem wider meine momentane Skepsis doch zufriedenstellend lösbar ist. Zumindest für bibliotheksübergreifende Kataloge stellt sich dann aber trotzdem noch die Frage, ob ein gutes Ranking für den einen Fächerkanon auch gut für einen anderen ist – interessant ist da ja z.B. die unterschiedliche Relevanz von Monografien oder Aufsätzen in technischen oder geisteswissenschaftlichen Fachgebieten.

    Ich denke, wir haben in diesem Gebiet aber so oder so noch sehr spannende Zeiten mit vielen interessanten Fragestellungen vor uns =)

    Viele Grüße,
    Jan F.

  5. Jens Lazarus said, on 8. Oktober 2012 at 9:20 nachmittags

    Unbedingt Not to tab!

    In der UB Leipzig (und in der kommenden Woche dann auch in der UB Chemnitz, UB Freiberg und HMT Leipzig) fahren wir seit einem halben Jahr mit nur einer Ergebnisliste. Wir haben in der Regel positives Feedback von den Nutzern, manchmal schlägt uns geradezu Dankbarkeit entgegen. Kritik kommt meist von Spezialisten (auch aus dem eigenen Haus), die sich gut auskennen. Das ist in Ordnung, denke ich. Es signalisiert erst mal Engagement und den Wunsch, die Dinge besser zu machen. Und natürlich ist es immer auch der Abschied vom Vertrauten. Insgesamt haben wir relativ wenige Rückmeldungen – was ich auch vorsichtig positiv werte.

    Ich bin mir dabei gar nicht sicher, ob es wirklich immer eine Grundsatzentscheidung ist. Vielleicht sind es doch eher pragmatische Dinge, die zu „getabbten“ Lösungen führen: man spart sich hierbei wirklich eine ganze Reihe von Problemen und Entwicklung auf technischer Seite – zumindest wenn man es mit mehr als einem Index zu tun hat. Und dann ist es doch eher eine Frage der verfügbaren Kapazitäten, als ein bewusst entwickeltes Statement, oder? Vielleicht ist es aber auch eine Frage, mit welcher Fehlertoleranz man die Sache angeht.

    Natürlich haben wir mit all den Problemen zu tun, die Oliver und Jan F. ansprechen. Das ist nicht trivial. Ich denke, wir kommen damit ganz gut klar und sind ganz sicher noch nicht am Ende der Fahnenstange. Aber wir haben auch das wirklich seltene Glück, mit zusätzlichen Leuten in einem gut aufgestellten Projekt zu arbeiten. Ich springe deswegen jeden Morgen im Dreieck vor Freude.

    Grüße, Jens

  6. Viola said, on 10. Oktober 2012 at 8:55 vormittags

    Zum Thema interessant vielleicht der zweite Teil der Serie “How are libraries designing their search boxes?” im Blog “Musings about librarianship”: http://musingsaboutlibrarianship.blogspot.de/2012/10/how-are-libraries-designing-their.html

  7. Clemens Kynast said, on 10. Oktober 2012 at 10:22 vormittags

    moin,
    sehr interessante Diskussion!

    Grundsätzlich ist es sicher so, wie Jens bereits beschrieben hat: eine 2-Spalten-Lösung ist vornehmlich eine technische Erleichterung und relativ easy ohne viel man-power zu bewerkstelligen. Außerdem machen es ja auch andere so, wie zB Brown-Uni oder SteenLibrary: zwei Spalten nach der Suchanfrage und tiefer tauchen nach Klick auf Books oder Articles. Dadurch haben wir es etwas leichter bei der Bewerbung unseres Vorhabens. Aus Nutzersicht ist das aber sicher irgendwie seltsam. Daher wollen wir natürlich auch gern eine einheitliche Liste für alle Inhalte.

    Wir in Jena haben uns aber bewußt gegen eine Darstellung des Katalogs im Summon-Index entschieden und nutzen den Solr-Index aus Göttingen. Perspektivisch ist sicher auch eine von Summon unabhängige Integration unserer lokalen Repositories denkkbar. Dadurch stehen wir vor dem Problem drei Indizes in einer Liste erscheinen zu lassen. Bisher sehe ich jedoch keine Möglichkeit, verschiedene Indizes geschickt miteinander zu vereinen. Zumal hier keine lokalen Indizes vorliegen, sondern via Summon-API und findex auf “Fremdangebote” zugegriffen wird. Ich weiss nicht, ob Sharding da überhaupt funktioniert und wie die Laufzeiten generell ausfallen.
    Eventuell haben wir ja mit Vufind2 ein besseres Tool an der Hand. Zu diesem Dilemma würd ich mich über Feedback aus der Expertenecke freuen.

    viele grüße,
    cle.

    • Till Kinstler said, on 10. Oktober 2012 at 12:27 nachmittags

      Hallo,
      nein “Sharding” wird nicht funktionieren. Das ist ja nicht “Wunder-Metasuche aus der Dose”. Sondern ein (eigentlich interner) Mechanismus in Solr zur verteilten Suche über mehrere (weitgehend) gleich strukturierte Solr-Indexe. Die Idee dahinter war nicht, unterschiedliche, verteilte Datenbestände zu vereinen, sondern die Suche in großen Solr-Indexen durch Parallelisierung auf mehreren Maschinen zu beschleunigen. Was wir da mit findex und lokalen Solr-Indexen treiben, ist eigentlich schon ein grenzwertiger Missbrauch dieses Prinzips. Und es funktioniert eben nur unter sehr exakten Rahmenbedingungen: Solr und weitgehend gleiches Index-Schema.
      Man wird mit Solr-Sharding aber keine andere Suchtechnik einbinden können. Und obwohl Summon intern wohl Solr benutzt, hat man meines Wissens bei denen keinen direkten Zugriff per SOLR-API (“HTTP”) auf deren Suchmaschinen, sondern muss über deren eigene API (die ja nicht schlecht ist) gehen. Damit ist es für Solr aber “andere Suchtechnik”.
      Wir geben bei findex hingegen direkten Zugriff auf Solr (aus diversen Gründen, u.a. aber auch, weil wir die Entwicklung einer zusätzlichen API darüber gar nicht leisten können). Deswegen kann man da Sharding mit anderen Solr-Indexen machen.
      Die Treffer, die man aus unterschiedlicher Suchtechnik bekommt, lassen sich aber nicht mehr sinnvoll vereinen, zumindest solange man bei einem einigermaßen sinnvollen mathematischen Modell für die Berechnung des Rankings bleiben will.
      Deswegen setzt VuFind (auch VuFind2) ja auf die Lösung mit den Tabs bei der Einbindung anderer Suchmaschinen wie Summon, WorldCat oder dem EBSCO-Dienst. Ausnahme ist hier Primo Central, da ExLibris diese “PC bridge” anbietet, die die Treffer aus dem lokalen Index und Primo Central mischt. Was das Ding genau tut, weiß ich aber nicht. Und ich weiß auch nicht, wie auskunftsfreudig ExL an der Stelle ist. Mathematische Wunder kann das Ding aber auch nicht leisten…
      Wo soll es auch herkommen? Die Mathematik bleibt für alle gleich und ändert sich auch nicht in 10 oder 5 Jahren (damals, beim “Metasuch-Zyklus” hat man ja schon von “vereinten Trefferlisten” geträumt, jetzt beim “Discovery-Zyklus” tut man es wieder). Nochmal den Hinweis auf das Vascoda-Papier von Kohlschütter et. al: http://www.base-search.net/about/download/FedSearchReport.pdf Das beschreibt echt ganz gut die Lage. Die Lösung darin ist, dass man schlicht alle Daten, die bei den Partnern “rumliegen” einfach nochmal neu in einheitlich strukturierten Lucene-Indexen bereitstellt und dann darüber sucht. Nennt sich dann “Plugin”. Klingt “harmloser” als: Ihr müsst alle die gleiche Suchtechnik betreiben. Deswegen gibt es aber immer noch Leute, die glauben, verteilte Suche mit allen Features über Lucene/Solr und Fast sei damals möglich gewesen… Nein, selbst Vascoda konnte Mathematik nicht ändern…
      Deswegen ist aber auch nicht zu erwarten, dass es eine bessere Lösung geben wird, wenn der Traum von verteilter Suche mit einer Ergebnisliste nach Ende dieses Zykluses in ein paar Jahren wieder heißgekocht wird in der Bibliothekswelt.

  8. Anne Christensen said, on 10. Oktober 2012 at 1:13 nachmittags

    Ich freue mich sehr über die lebhafte Diskussion hier – vielen Dank an alle Beitragenden! Kleiner Versuch der Zusammenfassung des bisher Gesagten:

    1. Ein empirischer Blick darauf, wie Discovery angeboten wird, zeigt, dass nur knapp die Hälfte eine Box für alles anbieten (Viola)
    2. Wenn man mehr als einen Index hat, kommt man um die Tabs fast nicht herum (Till).
    3. Das liegt daran, dass nicht getabbte Lösungen ein richtig gutes Ranking voraussetzen, das wir in oft nicht haben, weil a) nur mit Metadaten und nicht wie bei “richtigen” Suchmaschinen (für die die Technik erfunden wurde), mit Volltexten gearbeitet wird unn b) die Frage der Relevanz von Parametern wie Fach oder Standort anhängt und damit c) vorerst nicht perfekt sein kann (Jan F.)
    4. Aus diesem Grund kann festgestellt werden, dass getabbte Lösungen in der Regel den pragmatischsten Weg darstellen, mit der Komplexität umzugehen (Jens, Clemens)
    5. Wir sind alle nicht die ersten, die mit diesen Problemen kämpfen – Till erinnert zu Recht an vascoda. Es ist aber gut, dass die Probleme jetzt auf einer etwas breiteren Basis mit vielfältigeren Erfahrungen und Einsatzszenarien diskutiert werden.

    Aus dem letzten Grund stimme ich Jens und Jan F. zu, dass wir da gerade in einer spannenden Phase stecken. Jetzt schon das Thema Discovery aufzugeben, wie Till andeutet, finde ich zu früh – allein deswegen, weil wir noch zu viel darüber nicht wissen (zum Beispiel zum Thema Sharding oder auch darüber, wie NutzerInnen das alles finden).

    • kathi (@library_pirate) said, on 13. Oktober 2012 at 3:57 nachmittags

      Liebe Anne

      Zunächst auch von mir einen herzlichen Dank an alle Beitragenden, die Diskussion und all die darin enthaltenen Infos sind denke ich mehr als nützlich für alle, die sich mit dem Thema befassen.
      Was mir diese Diskussion auch gezeigt hat: Mit einem kleinen Tweet kann man sehr viel bewirken ;)
      Ich freue mich sehr, dass das Thema Untergliederung in Suchräume jetzt hier so differenziert angegangen wird. Auch wenn ich nun etwas spät dran bin, möchte ich vielleicht nochmal erläutern, wie ich zu meinem Tweet bzw. meiner Verwunderung über das vehemente pro zur Ein-Tab-Lösung gekommen bin.

      Erstaunlicherweise war es nämlich gerade das Leipziger VuFind-Blog bzw. die User-Kommentare dort, die mich zu dieser Einschätzung (vor Deinem Artikel) haben kommen lassen, um genau zu sein, die Kommentare zu diesem Post: http://blog.ub.uni-leipzig.de/?p=97
      Was mir dort Bauchschmerzen machte, ist, dass die Nutzer anscheinend generell an den grossen Treffermengen und dem Prozedere des Drill-Downs zweifeln – etwas, das durch die Ein-Tab-Lösung eben unausweichlich ist:

      „Zum anderen, es sind einfach viel zu viele Treffer, die man auf eine Suchanfrage bekommt und es dauert ewig, bevor man sich zu dem durchgeklickt hat, was man eventuell gebrauchen kann. Ich bin Germanist, komme in die Bibliothek, um Bücher und die elektronischen Angebote benutzen zu können. Ich brauche keine Hinweise auf Zeitschriftenaufsätze, die dann doch nicht da sind und erst beschafft werden müssen.“
      “Hatte eine Chemie-Ressource (ich glaub es war ein Artikel, kann aber auch ein Buch gewesen sein, bin nicht mehr sicher) gesucht und wurde erschlagen mit tausenden Treffern, die nichts mit meiner Suche zu tun hatten. Von daher: alles rausschmeißen aus der Datenbank, was man rausschmeißen kann, wäre mein Vorschlag, also z. b. Artikel, die sowieso nicht online verfügbar sind.”
      Diese Aussagen stammen von einem Geistes- und einem Naturwissenschaftler – an den disziplinären Mindsets kann es also weniger liegen. (Dem Germanisten sind auch die unzähligen Rezensionen als „Bücher“ übel aufgestossen – das scheint dann im Primo Central wie im EDS zu sein). Es ist wirklich fraglich, ob alle User den unified index bevorzugen: http://bibwild.wordpress.com/2011/08/08/article-search-and-catalog-search/

      Und ehrlich gesagt – zumindest ich kann es ihnen voll nachempfinden. Ob Leute mehr Spass daran haben, mit einer riesigen Informationsmenge konfrontiert zu sein, und diese dann wieder explorativ einzuschränken – oder sich vorher genau zu überlegen, wo und nach was sie suchen – das ist vielleicht eine individuelle Präferenz?
      Bevor das aber in eine Fundamentalkritik zu RDS abgleitet…zurück zum Thema “to tab or not to tab”: Durch das Anbieten verschiedener Suchräume kann man verschiedenen Nutzerpräferenzen entgegen kommen. That’s it. Warum nicht einfach 3 Tabs anbieten? “Books & more”, “Articles & more”, “Books & Articles”? Problem gelöst – für jeden was dabei.

      Bleiben noch die genuin “bibliothekarischen” Bauchschmerzen. Ich sehe ebenso wie Oliver Goldschmidt und Jan Maas eben das Problem darin, Sachen gemeinsam zu ranken, die sehr unterschiedlich Voraussetzungen mitbringen. Facetten anzubieten mag schön aussehen, leider spiegeln wir hier aber implizit etwas vor, was einfach nicht da ist: Eine konsistente Erschliessung – das ist zwar nun auch nichts Neues, in diesem Ausmass jedoch schon. Und hier lässt sich durch eine Gliederung in Suchräume eben etwas Übersichtlichkeit und Verlässlichkeit einbauen.
      (Ganz zu schweigen von den Sachen, die nicht im Index sind…und dies ist ja auch ein sehr fragwürdiges Problem, inwieweit sich man sich (bzw. seinen Nutzer) dort einem Anbieter und seiner Marktstrategie ausliefert. Aber das ist noch ein anderes Thema. Da mag man sich auch streiten, was “bevormundender” ist: die offensichtliche und klare Gliederung in Suchräume oder schon generell die Bevorzugung von bestimmten Inhalteanbietern durch einen kommerziellen Index in der prominenten “Katalogsuche”.)

      Nun ich tendiere auch aus dem Kontakt mit “Erstis” heraus dazu, eine solche Gliederung in Tabs zu bevorzugen. Die Verwirrung bei Ihnen ist wirklich gross ob der Informationsvielfalt, und die Unterscheidung von Publikationstypen, und wie sie sie am besten auffinden, ist nun meistens nicht das, was sie (verständlicherweise) prioritär interessiert und was sie oft erst nach und nach in der Bedeutung begreifen. Schliesslich finde ich eben, gerade weil wir den Unterschied zwischen Publikationstypen predigen und das als Grundwissen ansehen, sollten wir das auch prominent im Informationszugang widerspiegeln. Und dass man (nicht nur) den Erstis damit eine Menge Frust und Abschreckung ersparen kann, sollte ebenfalls bedacht werden.

      Wichtiger finde ich da die Frage: Welches Tab sollte die Default-Einstellung sein? Auch darüber liesse sich trefflich streiten… ;)

      Viele Grüsse

      • Jens Lazarus (@louisemilida) said, on 16. Oktober 2012 at 10:47 vormittags

        @kathi

        Nochmal kurz aus Leipzig: In dem erwähnten Post ging es ursprünglich noch um eine andere Sache, nämlich ob auch bibliographische Daten, für die wir keinen Bestand oder Zugang haben mit in den Katalog sollen oder nicht (wie zum Beispiel MLA-Daten und aus anderen rein bibliographischen Datenbanken).

        Wir haben die Entscheidung gegen die Anzeige von Metadaten ohne Bestand oder Volltext getroffen, auch wenn es durchaus auch Stimmen dafür gab. Dabei waren die Kommentare im Blog aber sehr viel stärker noch die massiven Nachfragen im Chat und an den Theken ausschlaggebend: was angezeigt wird, soll auch erreichbar sein; andernfalls wird es als Fehler (und nicht als zusätzliche Information) wahrgenommen. Auch die Rezensionen aus Primo Central haben wir in diesem Zusammenhang unterdrückt. Aber das ist alles schon wieder ein neues Thema, glaube ich …

        Viele Grüße, Jens

  9. Oliver Goldschmidt said, on 10. Oktober 2012 at 4:01 nachmittags

    Danke für die Zusammenfassung, Anne. Ich hab die Diskussion kurz aus den Augen verloren, will aber gerne nochmal einsteigen.

    Zunächst vielen Dank, Till, für die Ergänzungen und Erklärungen zur These, dass der unterschiedlich große Datenbestand an sich kein entscheidender Faktor für die Relevanzbewertung ist.

    Im Wesentlichen hat Till schon alles gesagt. Ich will aber trotzdem noch ein paar Details ergänzen. Achtung: es wird ziemlich technisch…

    Sharding ist eine Solr-eigene Technik, verteilte Indizes miteinander zu vereinen. Das bedeutet, wie Till schon richtig sagte, dass das nur dann funktioniert, wenn alle beteiligten Indizes die gleiche technische Grundlage haben (Solr) und in etwa gleichartig strukturiert sind. Kleine Unterschiede können in VuFind (1 und 2) über die Konfiguration ausgeglichen werden. Solr selbst hat nur mit dem Lucene SearchHandler Probleme mit unterschiedlichen Strukturen, mit Dismax habe ich noch keine Probleme festgestellt (außer, man verwendet Facetten, die nicht in allen Indizes vorhanden sind; aber die lassen sich ja einfach herauskonfigurieren). Der LuceneHandler ist weitaus stärker von einer einheitlichen Indexstruktur abhängig: sobald man in einem Feld sucht, das nicht in jedem Index vorhanden ist, scheitert die Suche komplett. Daher verwendet VuFind in diesem Zusammenhang “Field Stripping”: Felder, die nicht in allen Indizes vorhanden sind, müssen aus der Suchanfrage entfernt werden. David Maus hat darauf hingewiesen, dass sich dadurch unerklärbare Suchergebnisse ergeben können (weil ja ein Feld aus der Suchanfrage entfernt wird, das bei einer alleinigen Abfrage eines Index Treffer liefern könnte, siehe http://vufind.org/jira/browse/VUFIND-661). Ich denke zwar nicht, dass das so schwer erklärbar ist und halte eher das Verhalten von Solr an dieser Stelle für verbesserungsbedürftig, aber sei’s drum. Zumal Field Stripping wie gesagt nur für LuceneHandler-Anfragen genutzt wird (der LuceneHandler in VuFind wird benutzt, wenn man die erweiterte Suche nutzt oder wenn man z.B. trunkiert sucht).

    Im Grundsatz funktioniert Sharding jedenfalls, wenn alle beteiligten Indizes auf Solr laufen UND wir Zugriff auf diesen Solr-Server direkt haben, wie Till auch schon gesagt hat. Mit API-Lösungen wie von EBSCO oder Summon kann sowas nicht gemacht werden (auch das hat Till bereits eingeworfen).

    Ich werde auf dem VuFind-Summit, der nächste Woche stattfindet, zu genau diesem Thema etwas vorstellen (der Vortragstitel lautet “Sharding in VuFind”). Dort gehe ich auch auf die Probleme ein, die sich bei der Anwendung von Sharding stellen. Wer mag, kann gerne reinhorchen, der Vortrag ist für 19 Uhr dt. Zeit am Dienstag geplant und es soll wohl einen Live-Stream geben.

    Ich denke nach wie vor, dass eine gemeinsame Ergebnisliste der einzig sinnvolle Weg ist, um die Ergebnisliste dem Nutzer zu präsentieren. Die Baustellen, auf die in dieser Diskussion auch von mir hingewiesen wurde, sind sicher zu bewältigen, wenn das Verständnis für diese Thematik weiter vertieft wird. Getabbte Ansätze lösen diese Probleme jedenfalls nicht, sie gehen ihnen nur aus dem Weg. Ich denke, von der einheitlichen technischen Lösung sind wir gar nicht so weit entfernt. Es gibt übrigens auch für Summon eine Bibliothek, die die Summon-Ergebnisliste mit lokalen Ergebnissen mischt: die Staatsbibliothek in Aarhus in Dänemark (http://en.statsbiblioteket.dk/). Leider haben die aber lokal kein Solr, so dass sich ihre Lösung hierzulande vermutlich nur schwer nachnutzen ließe.

  10. Anne Christensen said, on 10. Oktober 2012 at 4:40 nachmittags

    Wo du Aarhus erwähnst, Oliver: Für die hat Serials Solutions offenbar Sharding erlaubt, jedenfalls hat mir das der Support so erklärt, als ich dort mal nach Sharding gefragt habe. Hinter Summon liegt ein Lucene Index. Die Standard-API von Summon geht gar nicht auf den Lucene Index, sondern das Interface. Für die Lösung in Aarhus wurde offenbar die API des Index freigegeben, so dass die Daten aus Katalog und Summon jeweils on the fly vermischt werden.

    • Clemens Kynast said, on 10. Oktober 2012 at 5:13 nachmittags

      klingt spannend. für einen live-merge ist das ding aber echt fix!

    • Oliver Goldschmidt said, on 10. Oktober 2012 at 6:01 nachmittags

      Diese Auskunft vom Support kann nicht ganz korrekt sein – wie gesagt benutzen die Dänen kein Solr! Daher können sie auch kein Sharding machen. Ich hatte Kontakt mit dem Entwickler dieser Lösung und er erklärte mir, dass sie dort eine ältere Lucene-basierte Lösung nutzen. Aber wie gesagt, fürs Sharding wäre Voraussetzung, dass auf beiden Seiten Solr gefahren wird.
      Für die Aarhuser wurde tatsächlich eine kleine Sonderlösung auf Summon-Seite gebastelt. Diese Sonderlösung besteht allerdings lediglich darin, dass die Scoringinformation mit über die API-Rückgabe geliefert wird. Mehr nicht. Das ist Voraussetzung, damit die Aarhuser sinnvoll mergen können.

      Ich gebe Dir aber recht: die Lösung ist klasse und ich bin auch ganz begeistert davon. Aber wie gesagt, bei der deutschen Konstellation lässt sich das so nicht nachnutzen.

  11. Clemens Kynast said, on 10. Oktober 2012 at 4:52 nachmittags

    Till, Oliver, vielen Dank für eure Ausführungen.
    Was das sharding betrifft, war mein Bauchgefühl richtig und kommt demnach nicht in Frage.

    Da sogar die Bibliothek in Villanova eine Zwei-Spalten-Ansicht betreibt, gibt es aus technischer Sicht betrachtet, wohl nur zwei Möglichkeiten: ich importiere mir alles in meinen eigenen Solr-Index bzw. überlasse es einer Firma. Oder ich spar mir diesen zusätzlichen Aufwand und zeige die zwei Spalten bzw. Tabs.

    Kleine ketzerische Nebenbemerkung: am Ende ist es dann vielleicht ja doch eine Design-Frage und die Aufregung nicht wert: solange die Haptik meiner Webpräsenz stimmt und alle zufrieden sind, wozu noch Gedanken über Tabs machen? Aber vermutlich gibt es doch noch einen Unterschied zwischen Tab- mit Zwei-Spalten-Anischt…

  12. Dale said, on 18. Oktober 2012 at 6:48 nachmittags

    Wie schon so oft, Anne, schon wieder eine angenehm geschriebene und solid argumentierte Ausarbeitung einer Kernfrage unserer Zunft. Das ist gewiss dein Superpower. Könnten meine Kollegen und Kolleginnen nur Deutsch lesen.


Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ photo

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 26 Followern an

%d Bloggern gefällt das: