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.

Using Worldcat services in the library catalog

For the first time we have implemented features into our library catalog that are 'invisible' to most of our library users.

I was inspired to build in these features during my participation in the Worldcat mashathon in Amsterdam on 13-14 May 2009. It was easy to build them in and I hope we do serve unexpected audience this way.

So what are these features ?

If you have ever tried searching worldcat you have probably noticed you can see which libraries hold the title you have just found. At the mashathon I learned that there is an API to give you a list of all the libraries holding copies of a title that is identified by a specific OCLC number. In our library catalog we do not hold the OCLC number, but as I described in a previous post, we can address a OCLC Pica service to get the OCLC number belonging to the dutch PPN which we do hold.

This allowed me to look up all libraries holding copies of a title in our catalog and show them in our full record display. Well, this is not really true. Worldcat will only return the libraries in your 'neigborhood'. This is a pretty large area that is defined by the IP address you are using the service from.

OK, it worked, but I had two problems with it. Firstly. Why would we bother our users with other libraries when we hold the title ourselves ? And secondly. The service always returned libraries in the Wageningen area, since the service was addressed from our server, based in Wageningen. Even though this is a pretty large area, showing not only Dutch libraries, but also German and British libraries and sometimes even libraries on the east coast of Canada and the USA, this is not what you want.

Fortunately, the service allows you to provide an IP address in the request, which will make it ignore our server IP address and will use the IP address provided to decide which libraries to show. So now we pick up the IP address from the browser user. If this a 'Wageningen IP address' we will not invoke the Worldcat API service, so our users will not be bothered by other library holdings. For other IP adresses we will take the IP adress and provide the user with a list of other libraries in their 'neighborhood' holding the title.

If you follow a link like this you may not only notice this new feature, but you may also notice another feature. A feature that will only be shown to you when your IP adress can be related to a library in the Worldcat registry. And only if the person that registered that library also registered a base URL of an OpenURL resolver for that library.

In that case, we will show a link to your local OpenURL resolver to provide you with (mostly full text) services your library will provide for the title you have found in our catalog. Isn't that great !!

One drawback however. Pretty hard to test for us :)

So I am glad Sarah Miller from the library at the National Science Foundation contacted us about a problem they had with this last service. Her SFX button did not lead to a full text link, for a journal they hold. She even pointed out why. We should add 'sfx.ignore_date_threshold=1' to the OpenURL to show full text links from the journal record. She was right. We had this problem when we implemented SFX years ago. A that time the only way to solve this problem was to add year=999 to the OpenURL. We did not do this, but added this to the OpenURL when it was parsed and discovered to be coming from our own journal catalog record. This still works, but only with our own SFX server. We changed this, so you may actually be able to use this new feature.

There is one potential problem with this service. OCLC restricts access to the Worldcat search API to 5000 requests a day. I hope we do not hit that limit very often. It will be so if more than 5000 requests of a full display of a catalog record a day occur. Well this does happen, mostly because of crawlers. I try to filter out a few known crawlers and do not hit the Worldcat service if they request a full record display. And now just hope for the best. ..

Moving to SOLR

We are currently running tests with SOLR to index the content of our Library Content Management System. At this moment the system is relying on Oracle Text Retrieval. We do not feel this meets our demands and we find it too tightly knit to our storage solution, which we want to be data base independant. We are planning an architectural description of our complete environment before we start developing, but I do have some ideas on which way to go of course.

We will start leaving our complete system as it is to start with and add an extra index layer. This will allow us to gradually leave Oracle text retrieval and evolve the sytem in stead of disrupting it.

The idea is to store the record id and a root table name after a record is succesfully entered or updated. So imagine someone changes a title of a publication. The id and table containing the bibliographic description is added to a list. The same id and table name will also be registered when a record pointing to it (for example of a book item) is modified. This list has the form of a list of URL's, since every record in our Library CMS is uniquely identified by a URL.

There will be a process reading this file retrieving each URL. The URL will return an XML file, that will be processed by an XSLT. This XSLT can enrich the XML via web services.

For example our own web services, to add information about the book-items to the bibliographic description. We can also add OCLC numbers and LCC headings by consulting web services at both OCLC Pica and OCLC Worldcat.

Many other enrichment of the data may be done before it will be offered to SOLR to index it. This way we will be able to retrieve the records by keys that are not present in the actual record, but which are added just before indexing.

This has great potentials. We can for example check our SFX server for information and add a flag to know before hand a publication is electronically available. We can check Worldcat and add better normalized author names and lots of stuff we might think of later.

We will remain compatible with our current way to search and present results.

We will store the same XML representation in the SOLR index as is stored in our CMS, so we can still use all XSLT's that are currently used to present results.

We will also 'hide' the query interface of SOLR behind our current SRU like interface. Of course we will have to add ways to make use of the new sorting and facetting features we will be able to work with.

This way we also keep our Z39.50 working since it makes use of the same interface to search the LCMS.

Well these are our first ideas, so we will do a lot of tests and rethinking I suppose. I just like to share it with the readers of this blog, so anyone can jump in with even better ideas.

I hope to share some more results with you at the end of this summer. I am really excited about this new journey we are taking.

RSS services from journals in library catalog

About a month ago, Terry Bucknell of the University of Liverpool announced on the code4lib list. that the ticTOCs project (a project funded by JISC in the UK to create a single, freely available source of RSS feeds for tables of contents - see http://www.tictocs.ac.uk/ ) is exposing their information about journals and their RSS feeds as a TAB delimited file.

I immediately spent two hours to develop a way to read that table into our Library Content Management System and join this table to our catalog records using their ISSN. It took a little longer to get everybody to agree on the way this should be presented in the user interface, but today it can be seen in our production environment. RSS buttons appear in our Journal A-Z list and also in the full record presentation of a journal. Within the full presentation we also pick up the feed and show the recent articles within the record presentation. Most of the discussion during implementation was about whether these recent articles would appear directly or whether they should be hidden to begin with. The hiders won.

Terry mentioned that they were thinking of making an API for this service, but because our LCMS is completely based on XML services, I accidentally created the API Terry is mentioning : http://library.wur.nl/WebQuery/toc/xml?toc=1530-9932. (Leave out the /xml and it will give you the RSS feed itself transformed with our local stylesheet)

It is this kind of services that should be shared more often between libraries in the world. We already discovered journals that are missing from Terry's list and will send them to him to update this wonderful service.

At Wageningen we are able to add this sort of services to our library catalogue easily, since we develop it all ourselves, but if you are using something you have bought from a library vendor, you might be able to so the same thing.

If you are able to add some javascript to your full record presentation, and can pick up the issn from the record, you could use javascript to retrieve the URL of the RSS and  present this to the user. For this you could ask our service, but this will be costly when you present a list of journals and have to go to the service for each journal. If this would become very popular we would also have a performance issue on our side I'm afraid.

If you are using a Open URL linker, I think the best way is to convince your supplier to process the http://www.tictocs.ac.uk/text.php and populate your link menu with RSS links. Or if you are using SFX and are familiar with Perl, put the file on your SFX server and write a parser to find the URL's for the relevant issn's and use that to add links to your SFX menu.