vrijdag 29 januari 2010

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]

Geen opmerkingen: