Het volgende Omega-decennium (5)

[aflevering 1]
[aflevering 2]
[aflevering 3]
[aflevering 4]

Omega is nooit opgezet of bedoeld geweest als alternatief voor de bibliografische databases op diverse vakgebieden waarvoor de UU via de bibliotheek licenties heeft. Deze databases bieden een vollediger overzicht van wat gepubliceerd is, ook in tijdschriften waarop de universiteit geen (digitaal) abonnement heeft (en waaruit artikelen dus meestal moeilijker verkrijgbaar zijn). Vaak hebben die databases ook speciale zoekmogelijkheden die specifiek zijn voor een bepaald vakgebied, in veel gevallen ook met gebruik van voor zo'n vakgebied ontwikkelde, gestandaardiseerde onderwerpsingangen en thesauri.

Ter verlichting van het probleem dat voor veel onderwerpen gezocht moet worden in een aantal verschillende databases, die vaak werken met zoeksystemen met uiteenlopende gebruikersinterfaces en functionaliteit, hebben veel bibliotheken er in het verleden voor gekozen deze databases via federated search (metasearch) beschikbaar te stellen. In Utrecht is dat niet gebeurd. De nadelen - die intussen ook elders meer en meer worden onderkend - wogen onzes inziens onvoldoende op tegen de voordelen. Eén van die nadelen was bijvoorbeeld dat je ook bij metasearch vrijwel geen gebruik kunt maken van al die mooie vakgebied-specifieke zaken.

Zelfs de eerste hinderpaal die gebruikers vaak ondervinden, de keuze welke bestanden voor een vraag in aanmerking komen, wordt in nu beschikbare systemen voor federated search onvoldoende opgelost:

• Het is niet mogelijk (en meestal ook niet gewenst) om in "alle" beschikbare bestanden tegelijk te zoeken, zodat toch nog keuzes gemaakt moeten worden.
  
• Ook al zijn hiervoor voorgedefinieerde groepen aanwezig, dan nog zal bij de gebruiker enige kennis over die bestanden aanwezig moeten zijn.
  
• Voorgedefinieerde groepen zijn niet afgestemd op elk soort vraag, zodat gebruikers ze vaak toch nog naar eigen wensen moeten aanpassen.
  
• Niet alle bestanden blijken in metasearch mee te nemen, zodat meestal toch nog aanvullend in een paar losse bestanden gezocht moet worden.

Daarnaast is er een aantal zoektechnische problemen:

• Via metasearch kan alleen een grootste gemene deler van de zoekfunctionaliteit van de afzonderlijke zoeksystemen worden geboden; meer gesofisticeerde functionaliteit ontbreekt dus en ook zal niet goed gebruik gemaakt kunnen worden van de hierboven genoemde specifieke vakgerichte zoekfunctionaliteit van de afzonderlijke databases.
  
• Metasearch is traag, want de uiteindelijke responsetijd wordt beperkt door de response van het traagste systeem.

Voor de veeleisende gebruiker (die niet genoeg heeft aan Omega en/of de catalogus) heeft het dus ontegenzeggelijk voordeel als die (aanvullend) in het native interface van de betreffende systemen zoekt. Alleen blijft daarbij nog steeds als noodzakelijke voorwaarde dat de gebruiker moet weten in welke systemen voor een bepaalde zoekvraag gezocht moet worden. Daartoe zouden gebruikers ondersteund kunnen worden door een automatische "recommender", die bij elke vraag de daarvoor meest in aanmerking komende bestanden opsomt.

Het in Groningen ontwikkelde PurpleSearch bevat een "recommender" die daarvoor gebruikt zou kunnen worden. In het volledige PurpleSearch-systeem worden vragen in de praktijk ook meteen automatisch uitgevoerd in de top-tien bestanden die uit de recommender komen. Om alleen de aanbevelingen als verlengstuk voor Omega in te zetten, zou het handig zijn als deze functie als webservice beschikbaar is, wat nu nog niet het geval is.
Bij nader inzien is het echter de vraag of een tamelijk complex systeem als de PurpleSearch recommender in onze situatie wel nodig is (en zelfs of die wel tot optimale resultaten leidt). In PurpleSearch moeten de suggesties voor bestandskeuze gedaan worden op basis van alleen de paar door de gebruiker ingetikte zoektermen. Daartoe wordt op de achtergrond een zoekactie gedaan in vrij willekeurig verzameld materiaal uit die databases, teneinde een verband te kunnen leggen tussen de zoekvraag en de inhoud van de individuele databases. Het resultaat van die achtergrondzoekactie zelf wordt verder niet voor de zoeker gebruikt.
Onze situatie is een andere. Daarbij kan een zoekactie sowieso al in Omega worden gedaan, waarvan de gebruiker het resultaat ook te zien krijgt. Op basis van dat zoekresultaat is veel eenvoudiger - en misschien ook nog wel betrouwbaarder - een match te maken met meest in aanmerking komende externe databases.

Dat kan bijvoorbeeld door zogenaamde vectorrepresentaties te gebruiken van zowel de bij ons beschikbare databases, als van het resultaat van de zoekvraag. Die vector-representaties kunnen gebaseerd zijn op tijdschrifttitels (of hun ISSN's). Van al onze ca. 100 (?) in aanmerking komende databases kunnen eenmalig, vooraf vector-vingerafdrukken gemaakt worden, die aangeven welke tijdschriften in welke onderlinge verhouding karakteristiek zijn voor de inhoud van elk van die bestanden. Uit het resultaat van een Omega-zoekactie kan ook zo'n vingerafdruk worden gegenereerd, op basis van de tijdschriften waar de al gevonden artikelen uit afkomstig blijken te zijn. Een best-match tussen die vraagresultaatvector en de database-vectoren levert dan eenvoudig een op relevantie/belang geordend lijstje op van voor dat onderwerp te doorzoeken databases. Daarvoor is geen enkele menselijke interpretatie nodig welke databases of welke tijdschriften voor welk vakgebied belangrijk geacht worden. Alleen zal misschien nog wat gespeeld moeten worden met de weging van de vectorcomponenten in de vingerafdrukken. Rekentechnisch is het werken met deze vectoren een al lang door informatici opgelost probleem.

In eerste instantie zouden de zoekvragen (zoals uitgevoerd in Omega) nog niet vertaald hoeven worden naar de zoeksyntax van de betreffende databases, teneinde ze meteen al te laten uitvoeren. Om van bestandspecifieke functionaliteit gebruik te kunnen maken, zal de gebruiker zijn zoekvraag immers toch nog zelf aan de situatie moeten aanpassen. Toch zou het prettig zijn als wel al een eerste indicatie van de te verwachten opbrengst gegeven kan worden, zodat we die vertaling in een later stadium misschien toch nog moeten ontwikkelen.

[dit was voorlopig (?) de laatste aflevering van deze serie]

Het volgende Omega-decennium (3)

[aflevering 1]
[aflevering 2]

De eerste post in deze serie ging over nieuwe ontwikkelingen rond "geïntegreerd zoeken". De tweede ging in op algemene voor- en nadelen van verdergaande integratie, met het huidige Omega als uitgangspunt. Dit keer wat specifieker over retrievalproblemen die daarbij kunnen optreden.

Het overgrote merendeel van de artikelen in Omega bevat uitgebreide inhoudelijke metadata in de vorm van samenvattingen, die geheel doorzoekbaar zijn. Van het fysieke materiaal, zoals dat in Aleph gecatalogiseerd is, hebben we daarentegen nauwelijks inhoudelijke metadata. Behalve een vaak korte en soms ook weinigzeggende titel, zijn er hoogstens nog twee of drie tamelijk algemene trefwoorden toegekend. Dat verschil in hoeveelheid en specificiteit van de aanwezige zoekingangen voor die beide soorten materiaal, maakt dat daar op heel verschillende wijze in gezocht moet worden om een enigszins optimaal resultaat te krijgen.
Om de gespecialiseerde artikelen in Omega te vinden, zijn zoekacties op vrij specifieke zoekwoorden nodig. Maar die zullen in Aleph-materiaal vrij weinig opleveren. Zelfs boeken die wel degelijk informatie over het gezochte specialisme bevatten, zullen niet gevonden worden, omdat ze alleen vindbaar zijn op een paar titelwoorden en enkele veel algemenere trefwoorden (zo die al zijn toegekend). Die problematiek had ik in zijn algemeenheid al eens beschreven in een digitale bijdrage aan InformatieProfessional, "De mythe van de catalogus".

Om fysiek materiaal uit de catalogus te kunnen vinden, is het dus vaak nodig om op vrij algemene zoekwoorden te zoeken. Maar die zullen in Omega-materiaal juist weer weinig opleveren, omdat artikelen veel vaker specialistische deelonderwerpen behandelen dan zulke algemene onderwerpen. Wel degelijk aanwezige gespecialiseerde artikelen over onderdelen van het gevraagde onderwerp zullen daarbij voor het grootste deel gemist worden, omdat gebruikte algemene zoektermen daar niet in voorkomen, en er ook geen hiërarchische thesaurus is, waarmee zogenaamd "generiek" gezocht kan worden. Daarbij had een zoekvraag automatisch uitgebreid kunnen worden met in zo'n thesaurus beschikbare specifieke zoekwoorden.
Zoeken in de catalogus vraagt dus in de meeste gevallen een andere zoekaanpak dan zoeken in het huidige Omega. Deze zoekaanpakken zullen pas op termijn naar elkaar toegroeien, als ook van het merendeel van het in de catalogus beschreven materiaal uitgebreider gegevens digitaal beschikbaar en doorzoekbaar zijn, zoals inhoudsopgaven, samenvattingen, inleidingen en/of besprekingen. Op termijn zullen dat hopelijk ook de volledige teksten zijn, als meer E-books aan onze collectie worden toegevoegd. Daarmee kan voor dit materiaal dan ook meteen de Omega-meerwaarde van de "instant satisfaction" verwezenlijkt worden.

[wordt vervolgd]

Het volgende Omega-decennium (2)

In mijn vorige blogpost keek ik naar ontwikkelingen met betrekking tot geïntegreerd zoeken. Daaruit bleek dat er steeds meer aanhang komt voor de weg die we in Utrecht 10 jaar geleden met Omega waren ingeslagen - met een eigen zoekmachine zelf zo veel mogelijk materiaal indexeren, in plaats van een metasearch-oplossing. Of kortweg "integrated search" in plaats van "federated search".

In dit kader wil ik eens bekijken of en hoe we meer soorten materiaal dan alleen wat nu in Omega zit, op een betere manier geïntegreerd kunnen aanbieden. Steeds verdergaande integratie past in elk geval in een trend. We zagen dat al bij enkele van de vorige keer gesignaleerde ontwikkelingen.
We zagen het recent ook bij OCLC, dat in Worldcat niet alleen de fysieke collecties van deelnemende bibliotheken doorzoekbaar maakt, maar die sinds kort integreert met de inhoud van OAIster. Die zoekmachine voor OAI materiaal, met ruim 20 miljoen publicaties die zijn geoogst uit institutionele repositories (niet beperkt tot OCLC-bibliotheken) heeft OCLC onlangs overgenomen van de Universiteit van Michigan. Hij is zelfs zover geïntegreerd, dat het OAIster-materiaal niet meer apart kan worden doorzocht.
We zien het ook bij webzoekmachines zoals Google. Onder het motto "Universal search" mengt die - op bescheiden schaal - resultaten uit image-search, video-search, News, Scholar, Books, blog-search en (sinds kort) "real-time web" (o.a. Twitter) door zijn gewone zoekresultaten.

Ook al is iets een kennelijke trend, toch blijft de vraag of verregaande integratie altijd wenselijk is. Wil iemand die op zoek is naar inhoudelijke informatie uit websites, worden afgeleid door afbeeldingen, video's of 2-regelig tweets die wellicht iets met het gezochte onderwerp te maken hebben (Google)? Wil iemand die op zoek is naar een eenvoudig leerboek ook superspecialistische OAI-artikelen over dat onderwerp vinden, of bij een zoekactie naar vrij online toegankelijke artikelen, juist afgeleid worden door boeken uit onbereikbare collecties aan de andere kant van de wereld (Worldcat)?

In onze situatie verdient de vraag hoe nauw en hoe volledig ander materiaal met het huidige Omega geïntegreerd zou moeten worden, dus zeker enige aandacht. Verregaande integratie, waarbij je alles in één grote vergaarbak gooit, heeft ontegenzeggelijk voordelen. Gebruikers hoeven niet vooraf te bepalen waarin ze gaan zoeken en bovendien lopen ze hierdoor de kans informatie te vinden die ze anders nooit zouden zijn tegengekomen. Toch spelen de nadelen waarop ik net zinspeelde ook in onze situatie en rol.

• Gebruikers lopen de kans een grote verscheidenheid aan soorten materiaal te vinden waarnaar ze niet op zoek waren, waardoor het gezochte materiaal (in het slechtste geval) aan het oog wordt onttrokken door de overmaat aan ander materiaal.
  
• Gebruikers vinden zowel materiaal dat zij meteen op het scherm kunnen krijgen (zoals zij intussen van Omega gewend zijn), als materiaal dat alleen fysiek beschikbaar is en waarvoor zij dus ergens heen moeten om het op te halen (en dat op dat moment misschien zelfs helemaal niet beschikbaar is, omdat het is uitgeleend of vermist).

Voor deze nadelen kan een te ontwikkelen "faceted search" in principe een oplossing bieden. Als resultaat van een zoekvraag kunnen gebruikers dan een uitsplitsing van hun zoekresultaat te zien krijgen
- naar aard van het materiaal,
- naar full-text digitale beschikbaarheid / fysieke beschikbaarheid,
- naar andere nog nader vast te stellen geformaliseerde kenmerken.
Van elke afzonderlijk aanklikbare deelverzameling zal daarbij vermeld staan, hoeveel van het oorspronkelijke resultaat die bevat. Dat vereist natuurlijk wel dat alle materiaal consistent en uniform van metadata voor deze kenmerken is voorzien. Nadeel voor gebruikers blijft dat bij deze methode nog altijd een extra keuzeactie nodig is. Bijvoorbeeld voor zo iemand die uit is op de "instant satisfaction" die het thema was van mijn column in het november-nummer van InformatieProfessional, die bij voorbaat dus al uitsluitend op zoek is naar direct digitaal op het scherm verkrijgbaar materiaal.

Belangrijker nog, is dat faceted search functionaliteit geen oplossing biedt voor zoek-technische problemen die optreden als gegevens uit ons huidige Omega worden gemengd met gegevens uit de catalogus. Enerzijds is er een retrievalprobleem: voorlopig zijn nog heel verschillende aanpakken vereist voor die twee soorten materiaal. Anderzijds worden in een catalogus vaak andersoortige zoekacties gedaan, die ook andere zoekfunctionaliteit vereisen. Op deze twee punten zal ik in een volgende aflevering verder ingaan.

[wordt vervolgd]
[vorige aflevering]

Het volgende Omega-decennium (1)

In mijn vorige blogpost keek ik 10 jaar terug naar de voorloper van ons Omega-systeem, het zoeksysteem waarmee we zelf de Elsevier tijdschriften doorzoekbaar maakten. In deze en volgende blogposts wil ik eens vooruit kijken naar mogelijke nieuwe ontwikkelingen op het terrein van geïntegreerd zoeken.
Al eerder beschreef ik hier en hier dat ook andere UB's intussen een voorkeur beginnen te krijgen voor de oplossing voor geïntegreerd zoeken zoals die bij ons de afgelopen 10 jaar vorm heeft gekregen in Omega.
Die voorkeur voor "integrated search" (zoeken via de index van een eigen zoekmachine waarin je alles integreert), boven "federated search" (een metasearch in een verscheidenheid aan zoeksystemen met nogal diverse indexeertechnieken) zien we overigens ook bij leveranciers doordringen.
Delft en Tilburg gebruiken Meresco (waarvan de ME van "metadata", de RE van "repository" en de S van "search" komt). Dat komt weliswaar uit de Open Source gemeenschap, maar wordt wel door een commercieel bedrijf ontwikkeld, onderhouden en geïmplementeerd.
Als zeer commercieel bedrijf is ook ExLibris een paar jaar geleden met Primo begonnen, een zoeksysteem gebaseerd op dezelfde Open Source zoekmachine Lucene/Solr als Meresco. Dat was aanvankelijk nog stevig gecombineerd met hun MetaLib metasearch. Maar intussen verzet men de bakens meer richting afzonderlijke Primo-indexen, die vanwege toepassing van dezelfde indexeertechniek makkelijk te combineren zijn. En zelfs kun je de te indexeren metadata, of die nu afkomstig zijn van tijdschriftuitgevers of uit je eigen catalogus, extern bij ExLibris laten hosten (en dus ook daar laten indexeren) onder de naam Primo Central. Een oplossing die ExLibris ons uiteraard ook probeert aan te smeren.
En een soortgelijke oplossing wordt nu ook door SerialsSolutions aangeboden onder de naam Summon. Hetgeen niet toevallig erg lijkt op Summa, een ooit bij Deense bibliotheken opgezet systeem op basis van Lucene, waarover ik ook ooit al eens blogde. Summon is intussen onder meer in gebruik bij de Universiteit van Liverpool en bij Dartmouth College en wordt ook een dezer dagen op proef bij onze Rotterdamse collega's in gebruik genomen.
Sommige van deze producten kunnen ons op ideeën brengen voor functionaliteit die we op dit moment nog niet in Omega gerealiseerd hebben. In volgende posts wil ik echter vooral kijken in hoeverre ook wij de integratie van onze zoeksystemen nog verder kunnen verbeteren.

[wordt vervolgd]