Alweer een engelse term? Ja zeker want oude wijn moet periodiek in nieuwe zakken en engelstalige zakken doen het dan altijd beter. Federated search is een fenomeen dat de laatste jaren voornamelijk bij universiteitsbibliotheken een grote rol gespeeld heeft en nu ook, langzaam, richting de HBO bibliotheken trekt. Het is een ontwikkeling die nu geassocieerd wordt met ‘de digitale bibliotheek’ en klantvriendelijk zoeken. Federated search heeft als doel om een gebruiker met 1 zoekactie meerdere databases te laten doorzoeken waarbij het niet meer nodig is je te verdiepen in de zoekstructuur van elke individuele database. Het wordt vaak als ‘Portal’ bestempeld en eigenlijk is Picarta een fraai voorbeeld van een federated search principe aangezien deze bron zelf ca. 10 verschillende deeldatabases doorzoekt.
Ik werd er mee geconfronteerd afgelopen vrijdag tijdens een (lange) SHB (Samenwerkingsverband Hogeschool Bibliotheken) vergadering waar een nieuw bestuurslid van de Hogeschool van Arnhem en Nijmegen meldde dat zij zich aan het orienteren waren op een dergelijk product zodat alle databases die zij aanbieden, via 1 zoekstructuur te doorzoeken zal worden. De Haagse Hogeschool kent al een variant hierop doordat zij Aquabrowser geimplementeerd hebben en het onderwerp is actueel door het Omega project van de Universiteit van Utrecht (zie de InformatieProfessional van afgelopen juni) waarin een zoekmachine ontworpen is voor alle elektronische tijdschriftartikelen waarover de UU beschikt. Ook wij als Mediacentrum hebben ons geörienteerd op dit soort producten in de vorm van VSpaces van Infor, die ook ons bibliotheeksysteem Vubis Sm@rt levert.
Nu ben ik zelf niet 100% overtuigd van het echte nut van federated search. Het argument is voornamelijk dat het iets is dat de klant wil en daar twijfel ik geen seconde aan. Het succes van Google waar je alleen een balk ziet waar je 1 term in typt, heeft dit wel aangetoond. Je hoeft echter alleen naar Picarta te kijken om de nadelen te zien: alles-in-1-keer doorzoeken werkt niet geweldig als je verschillende soorten bestanden combineert waar hele verschillende materiaaltypen in te vinden is. De structuur van een database die afbeeldingen of bladmuziek herbergt wijkt flink af van de structuur en zoekmogelijkheden van een database met boeken of artikelen. Het nuttig doorzoeken van meerdere databases wordt daarmee gereduceerd tot die zoeksleutels die al die bestanden met elkaar gemeen hebben, veelal titel, auteur en trefwoord. Alle andere zoeksleutels zijn specifiek voor aparte materiaaltypen dus wie zoekt er dan nog op componist, illustrator, bestandsformaat, citatiegegevens enz? Je zou idealiter ook verwachten dat trefwoord vlekkeloos zou functioneren maar trefwoordensystemen verschillen in bijna 100% van de gevallen nog meer van elkaar dan materiaalsoort. Het maakt nogal uit voor je trefwoorden of ze zijn toegekend in een hele vakspecifieke database of dat ze zijn toegekend in een algemene database maar je verwacht met federated search wel dat je alles vindt … en die verwachting is lastig waar te maken.
Gebruikers zien niet meer in welke database de informatie te vinden is en zijn dan ook niet meer in staat hun zoekgedrag aan te passen hierop. In de Chemical Abstracts zoeken op ‘chemie’ is nutteloos terwijl het in onze eigen Vubis catalogus wel een goed trefwoord kan zijn.
De energie van leveranciers van federated search oplossingen is dan ook gericht op het koppelen van soortgelijke bronnen: Omega van de UU ontsluit alleen elektronische tijdschriftartikelen en kan daarmee een mooie uniforme zoekmachine aanbieden die ook goed functioneert in de praktijk. Aquabrowser gebruikt een visuele weergave van zoektermen op basis van frequentie van voorkomen in de databases, om een beeld te geven van de inhoud van de diverse databases en zo zullen andere leveranciers ook ongetwijfeld hun beste technische beentje voortzetten om de voor de hand liggende valkuilen te vermijden.
Ik denk dat federated search een mooi middel kan zijn om inderdaad gelijksoortige bronnen qua inhoud aan elkaar te koppelen en deze voor de gebruiker via 1 zoekmachine aan te bieden. Ik denk ook dat het geen wondermiddel is om al je databases, ongeacht inhoud en zoekstructuur, maar op 1 hoop te kunnen gooien onder het noemer ‘gemakkelijk voor de gebruiker’. Ik vond een artikeltje via webfeat.org (uit 2003!) dat mooi de bestaande mythen doorprikt en ook al is dit postje al te lang, ik quote het toch hieronder:
Federated searching is a hot topic that seems to be gaining traction in libraries everywhere. As with many technologies that are rapidly adopted,there are some misconceptions about what it can do. WebFeat, a provider of federated search technology to more than 900 public, academic, and corporate libraries, including more than half of the top 10 U.S. public libraries, has compiled this list of the five most commonly repeated misconceptions about federated searching.
1. Federated search engines leave no stone unturned.
Reality: Not all federated search engines can search all databases, although most can search Z39.50 and free databases. But many vendors that claim to offer federated search engines cannot currently search all licensed databases for both walk-up and remote users. Why? Authentication. It’s very difficult to manage authentication for subscription databases, particularly for remote users. Before buying, ask vendors to demonstrate that they can search all of your library’s databases using your library’s own authentication, both locally and remotely.
2. De-dupe really works.
Reality: For federated search engines, true de-duplication is virtually impossible. In order to de-dupe, the engine would have to download all search results and compare them. The limiting factor is not federated search engine technology, but the way databases return results: 10 or 20 records at a time. Completing a true de-dupe operation would take hours because a single search might produce 100,000 hits. These hits or citations typically come back 10 to 20 at a time. If it takes 5 seconds to download 20 hits, it would take hours to download them all. And the same citation may appear in different places in results sets from different databases. So to completely de-dupe search results, it’s necessary to download all results from all databases. Vendors that claim to do true de-duping usually are just de-duping the first results set returned by the search.
3. Relevancy rankings are totally relevant.
Reality: It’s impossible to perform a relevancy ranking that’s totally relevant. A relevancy ranking basically counts the occurrence of words being searched in a citation. Based on this frequency of occurrence, items will be moved closer to the top or farther down the results list. Here’s the problem: When attempting to relevancy-rank citations, the only words you have to work with are those that appear in the citation. Often, the search word doesn’t even appear. The abstract and full-text data, as well as the indexing that content providers use to relevancy-rank their content, are unavailable to federated search engines. The content providers have the full article and indexing to work with, but not the federated search engines. They have only the citation to search on.
4. Federated searching is software.
Reality: It certainly is software, but it’s best consumed as a service. A federated search engine searches databases that update and change an average of 2 to 3 times per year. This means that a system accessing 100 databases is subject to between 200 and 300 updates per year—almost one per day! Subscribing to a federated searching service instead of installing software eliminates the need for libraries to update translators almost daily so they can avoid disruptions in service. (Translators convert search queries into something that can be understood by the database that’s being searched.) Without frequent updates to these translators, entire databases can become periodically unavailable for searching. It’s unacceptable for a database subscription that couldcost a library $10,000 or more per year to be offline for any amount of time.
5. We don’t make your search engine. We make your search engine better.
Reality: You can’t get better results with a federated search engine than you can with the native database search. The same content is being searched, and a federated engine does not enhance the native database’s search interface. All federated search does is translate a search into something the native database’s engine can understand. But it’s restricted to the capabilities of the native database’s search function. A federated search can’t do a three-term search with Boolean operators in a native database whose interface doesn’t support it. Federated searching cannot improve on the native databases’ search capabilities. It can only use them.
