2009-10-08

Why are we changing our search architecture ? Waarom passen we onze zoekarchitectuur aan ?

This time a blogpost in Dutch. Why ? I feel the need to inform my colleagues in Wageningen, especially those in the library, a bit more on this issue. Sorry.

Ik kan natuurlijk een interne memo schrijven, maar een blogpost geeft me meer mogelijkheden tot het linken naar voorbeelden en is ook bereikbaar voor andere geïnteresseerden.

Op dit moment starten we met de ontwikkeling van een nieuwe zoekarchitectuur, gebaseerd op Solr. We hebben de afgelopen maanden nagedacht op welke manier we dat willen gaan doen, maar sind 1 oktober hebben we een nieuwe jonge collega, Joost van Ingen, die we voorlopig gaan vrijhouden voor dit project.

Op dit moment gebruiken we voor de indexering van het XML waarin we al onze informatie opslaan een product van Oracle, SQL text retrieval. We zijn niet zo ontevreden met dit product, maar er zit niet zo veel ontwikkeling in. Een aantal dingen die we graag zouden willen ondersteunt het niet en het is heel nauw gekoppeld aan de informatie die is opgeslagen in de Oracle data base. Daarom gaan we over op andere indexerings software (Lucene) en een andere manier van indexeren op basis van Solr.

Wat is er dan straks mogelijk ? Ik zal een aantal dingen noemen, niet noodzakelijkerwijs in volgorde van belangrijkheid.

  • Bladeren door grote resultaatlijsten. In de huidige situatie kun je in een set van meer dan een paar honderd resultaten niet goed bladeren. Na een pagina of 6 gaat het eigenlijk te traag en beginnen anderen last te krijgen met de snelheid van hun zoekactie door jouw geblader. Dit is doorgaans niet zo'n groot probleem, want je kunt je zoekset verkleinen en mensen bladeren meestal toch niet verder dan een paar pagina's. Het levert echter wel problemen op voor harvesters als Google en OAI harvesters, die wel alsmaar willen doorbladeren om alles te kunnen indexeren. Daarom staan we deze web crawlers niet toe verder te bladeren dan 600 resultaten. Voor OAI harvesters geldt dat niet, maar moeten we weer speciale dingen doen om het bladeren voor elkaar te krijgen. In een Solr/Lucene gebaseerde verzameling, zoals die van Gent, is dat geen probleem.
  • De totale resultaatset sorteren op titel, jaar van uitgave of iets anders. In de huidige situatie zouden we daar heel veel moeite voor moeten doen, voor iedere sorteringswens die er bestaat. Daarom sorteren we op dit moment alleen de resultaten per pagina. Als 'doekje voor het bloeden' geven we daarom vrij grote zoekresultaten per pagina terug, van wel honderd tot duizend titels per pagina. Dat is een vrij zware belasting voor zowel het systeem als je browser. De meeste zoeksystemen geven maar zo'n 10 titels per pagina terug.
  • Het sorteren van het zoekresultaat op relevantie. Dat kan nu wel, maar geeft in een verzameling metadata niet zo'n bevredigend resultaat. In Oracle worden daar traditionele technieken voor gebruikt uit de wereld van de full text retrieval. Meta data records in een resultaat set verschillen dan zeer weinig in relevantie. Ook in Solr worden standaard dezelfde soort technieken gebruikt om de relevantie te bepalen, maar bestaat de mogelijkheid om zelf nieuwe relevantie algoritmen te bedenken. We zouden bijvoorbeeld veel uitgeleende boeken een hogere relevantie kunnen geven. Tijdschriften met een hogere impact factor relevanter maken. Publicaties van vooraanstaande Wageningse auteurs belangrijker maken. Let wel, dit zijn meer of minder gelukkige voorbeelden, waarbij je weer kanttekeningen kunt maken. Ik verzoek dan ook om jullie creativiteit te gebruiken en met briljante oplossingen hiervoor te komen.
  • Op dit moment geven we de mogelijkheid om te zoeken in verschillende velden en die zoekresultaten in te perken op bepaalde kenmerken. Uit verschillende onderzoeken blijkt dat gebruikers enigszins geïntimideerd zij door deze complexe zoekschermen. Tijdens de cursussen die wij aan studenten geven blijkt dat men het zoeken met booleaanse operatoren en de daaraan gekoppelde verzamelingenleer niet zonder meer beheerst. Daarnaast kan bij het inperken vaak gekozen worden voor waarden van kenmerken die helemaal niet in de gevonden set voorkomen. Zo kan je zoeken naar alle publicaties met in de titel 'voedselkwaliteit in de Betuwe' beperkt tot die titels die in het Bulgaars zijn gepubliceerd. Of alles over waterbeheer in de categorie onkruidbestrijding. Men is gewend aan Google. Je hebt één vakje en daar tik je iets in en vanuit dat zoekresultaat zoek je weer verder. Zonde van al die metadata die we verzamelen, dus die willen we gaan gebruiken voor 'facettering' van het zoekresultaat. Je krijgt dan de mogelijkheid om in te perken op bepaalde metadata kenmerken, maar alleen op waarden die voorkomen in de gevonden set resultaten. Solr ondersteunt dit soort facettering zoals blijkt uit bijvoorbeeld de Gentse catalogus. We zien dit soort faciliteiten wel meer in combinatie met Lucene gebaseerde indexen, zoals bijvoorbeeld bij Discover van de TU Delft.
  • Meer content om op te zoeken. We willen misschien ook de volledige tekst gaan indexeren, zodat ook op de inhoud van de publicaties kan worden gezocht. Er is echter een probleem wanneer je gaat zoeken in een verzameling publicaties, waarvan maar een deel full text beschikbaar is. De andere records vallen dan weg in de resultaat sets. Dus voordat we dat gaan doen willen we vooralsnog op andere wijze de records gaan verrijken, voordat ze worden geïndexeerd. Op dit moment doen we veel aan verrijking van records, maar we doen dat op het moment van presentatie. Op dat moment halen we covers op, eventuele inhoudsopgaven van tijdschriften, abstracts, de betekenis van rubriekscodes, etc. Dat betekent dat deze informatie bij het opzoeken van deze titels niet kan worden gebruikt voor het vinden van die titels. In de nieuwe zoekarchitectuur zal een groot deel van de verrijking plaatsvinden vóórdat de titel gaat worden geïndexeerd. Dat betekent dat we de mogelijkheid krijgen om die extra informatie mee te indexeren.
  • Over meerdere collecties tegelijk kunnen zoeken. Op dit moment kunnen we tegelijkertijd zoeken over alle soorten titelbeschrijvingen die we verzamelen (artikelen, tijdschriften, boeken, webbronnen, etc). Dat bieden we onze gebruikers echter niet aan. In het verre verleden bleek dat mensen dan dachten dat alle artikelen van alle tijdschriften in de catalogus te vinden zouden zijn. Inmiddels zijn gebruikers veel meer bekend met heterogene bestanden en Solr biedt middels de facetten in ieder geval de mogelijkheid om te kunnen laten zien uit welke type titelbeschrijvingen het zoekresultaat is opgebouwd. Het zal ook mogelijk worden om de afwijkende beschrijvingen van Wageningse publicaties uit Metis mee te indexeren in een en dezelfde index. We krijgen dan wel veel dubbele titels in het zoekresultaat, dus wanneer we dat willen gaan doen moeten we goed bedenken hoe we hier mee om willen gaan. Ook kunnen we gaan overwegen of we ook andere dataverzamelingen in de index gaan meenemen. Bijvoorbeeld Wageningse onderzoeksprojecten of andere interessante dataverzamelingen waar we mee geconfronteerd worden. We kunnen ook gaan overwegen of we nog grotere verzamelingen van buiten mee gaan indexeren, zoals de Delftse Universiteitbibliotheek doet in Discover, waar men ook Elsevier tijdschrift artikelen mee indexeert.
Kortom. Onze nieuwe zoekarchitectuur zal ons vele nieuwe mogelijkheden bieden.
Onze oude manier van zoeken behouden we ook nog. Onze oude indexen zullen namelijk de enige indexen zijn die 'real-time' zullen blijven worden bijgewerkt, wanneer we mutaties uitvoeren. Het bijwerken van de krachtige Lucene indexen is namelijk een tijdrovend karwei. We zullen dit asynchroon gaan doen. Dat wil zeggen dat gewijzigde records zullen worden verzameld tot groepjes die in batch zullen worden geïndexeerd door Solr. Het is op dit moment onwerkbaar om de Solr index bij te werken op het moment dat een record wordt opgeslagen. Ten eerste zou het wachten na een recordwijziging onacceptabel lang duren. Daanaast beïnvloedt het bijwerken van de index ook de zoeksnelheid in negatieve zin. Solr maakt hevig gebruik van caching, waarbij de indexen permanent in het computergeheugen blijven staan, waardoor het zoeken zeer snel gaat. Wanneer we de index gaan bijwerken, zal de caching van Solr niet langer geldig blijven. De index is bijgewerkt op schijf en Solr zal de index opnieuw moeten gaan lezen en in het geheugen plaatsen, dit beïnvloedt de zoeksnelheid enorm. Hoe we met deze asynchroniciteit om moeten gaan moeten we de komende tijd ook gaan uitwerken.