Federatief zoeken

Tijdens de NVB-HB dag gisteren over federatief zoeken zijn mij een aantal dingen opgevallen die in ter plekke niet gelijk wilde roepen of vragen, maar de mi toch wel belangrijk zijn om te vermelden. Ik heb gemerkt dat de kennis bij een deel van de bibliothecarissen/informatiespecialisten over dit soort toepassingen nog heel pril is en dat alle aanvullende informatie van harte welkom is. Vandaar deze posting.

Er bestaan allerlei aanvullende tools die een bibliotheek nodig kan hebben op het moment dat het aantal e-journals en/of het aantal databases toe neemt en je eea niet meer handmatig in bv je catalogus kunt of wilt verwerken. Denk dan aan een link resolver en aan een federatieve zoekmachine. De aanschaf van beide oplossingen loopt vaak gelijk op. Een eindgebruiker haakt nl af als je iets gevonden hebt en het is niet mogelijk om door te kunnen klikken naar de fulltext. Idealiter schaft een bibliotheek dan ook gelijktijdig beide oplossingen aan. Als je toch moet kiezen, zou ik afhankelijk van de aard van de bronnen, in eerste instantie een link resolver kiezen.

Bij toename van het aantal bronnen (denk dan aan vele duizenden e-journals ‘verborgen’ in de databases) krijg je in toenemende mate behoefte aan het inzicht in die bronnen. Dan komt een ERM (electronic resource management) oplossing om de hoek kijken. Vergelijk dit voor het gemak maar even heel simpel gesteld als een soort tijdschriftenmodule voor je electronische bronnen.

Tot slot heb je nog te maken met het hele toegangsbeheer, problemen met thuistoegang, wachtwoorden etc.

Wat mij gisteren opviel was het volgende:

Tijdens de presentatie van Infor kon Filip, PiCarta niet als bron selecteren omdat hij van buiten kwam. V-link presenteerde echter wel een link naar PiCarta. Dat is vreemd want een link resolver hoort ook ‘real time on the fly’ (zoals de uitvinder van OpenURL linken, Herbert van de Sompel altijd zegt) te checken of je überhaupt toegang hebt. Dat gebeurde blijkbaar niet? (reactie Infor???)

Hans-Peter vertelde dat het bundelen van te doorzoeken bronnen op onderwerp bedoeld is als extra service voor de gebruikers. Tijdens CIL2008 werd door verschillende experts echter verteld dat de belangrijkste reden waarom bijna alle producten deze functionaliteit bieden, de hoeveelheid maximaal gelijktijdig te doorzoeken bronnen is. Als je heel veel (ik weet niet waar de grens van ieder product ligt) bronnen tegelijkertijd zoekt, kan je zoekmachine vast lopen of onacceptabele responstijden geven.

Wat mij ook verbaasde was het uitblijven van vragen over de toekomst van WebFeat. Vorige week vertelde de Director International Sales van Serials Solutions (waar WebFeat nu onder valt) nog ten overstaan van een grote groep Nederlandse informatiespecialisten, dat alle connectoren van WebFeat nu met een snelheid van meer dan 50 per week worden omgezet naar 360 SEARCH…

Reacties zijn van harte welkom…

4 Reacties to “Federatief zoeken”

  1. Dymphie Says:

    Hoi,

    Ik ben het met je eens dat als je maar een optie kunt kiezen je het beste kunt beginnen met een linkresolver.
    Als je zorgt dat je databases daarmee ‘verbonden’ zijn heb je al heel veel gewonnen: je klanten kunnen dan doorklikken naar de full-text, waar het ze immers om te doen is.

    Veel federatieve zoekmachines hebben dezelfde problemen als de metasearchengines van vroeger: de bijzondere facetten van bepaalde databases kun je niet meer gebruiken, dus je zoekactie wordt altijd oppervlakkiger, terwijl je potentiële resultaten (want meer bronnen) vergroten.
    Ikzelf zie bijv dat mensen soms (afhankelijk van het onderwerp) liever kiezen voor een gespecialiseerde database als Medline of Psycinfo dan voor een grote algemene database als Scopus. En dan heb ik het nog niet eens over een federatieve zoekmachine.

    Van een federatieve zoekmachines worden soms de snelste bronnen eerst getoond: dat hoeven niet de beste te zijn.

    Een ander probleem komt om de hoek kijken als je je eigen catalogus ook meteen wilt laten doorzoeken: als die achter een firewall zit worden de kosten een factie 10 hoger, omdat je de software zelf moet gaan hosten.

    ’t Is nog niet zo eenvoudig …

  2. Maart Hekman Says:

    De hint is duidelijk:

    Ronald, kun je ons misschien nog iets zeggen over de plannen van Proquest met Webfeat?

  3. rvandieen Says:

    Hallo Dymphie, dank voor je reactie. Het is inderdaad niet eenvoudig en vanuit het standpunt van de informatieprofessional klopt het dat je beter afzonderlijk in een database kunt zoeken om te profiteren van de specifieke zoekfunctionaliteiten van die specifieke database.
    Onlangs heb ik ook een stuk gelezen dat de resultaten van federatief zoeken en specifiek zoeken in de afzonderlijke databases echter niet zoveel verschillen. Als je tegelijkertijd bedenkt dat de gebruikers wel federatief willen zoeken… dan is dat de belangrijkste reden om die optie aan te bieden.

  4. rvandieen Says:

    Hallo Maarten,

    Vorige week vertelde Matt Drury dat voor het eind van dit jaar alle connectoren van WebFeat zijn geintegreerd in 360 SEARCH. Een conservatieve schatting ging uit van minimaal 50 per week.

    Op zich is het qua geschiedenis wel interessant. De eerste fed. zoekmachine van Serials Solutions bevatte veel connectoren die men van WebFeat in licentie had. Uiteindelijk zijn die door de jaren heen allemaal vervangen door eigen connectoren. En nu hebben ze WebFeat gekocht…


Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s

%d bloggers op de volgende wijze: