Is het een handige vorm van faceted search of is het vooral een dommere vorm van zoeken? Of juist een hele grafische? De toekomst misschien?
Wat do you suggest http://whatdoyousuggest.net is een zoekhulp die gebruik maakt van door Google verzameld gedrag om suggesties te doen om je zoekopdracht te verfijnen. De userinterface is zeer grafisch en nogal, ehm, Zwartwit.
zaterdag 15 mei 2010
Even voorstellen
donderdag 4 februari 2010
2010, the library of the future
"A very popular room is the library. There are no books. ...." [lees verder wat er in 2010 dan wel zou zijn ...].
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.
- 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]
donderdag 21 januari 2010
Het volgende Omega-decennium (4)
[aflevering 1]
[aflevering 2]
[aflevering 3]
In eerdere posts in deze serie kwamen aan de orde:
- ontwikkelingen rond "geïntegreerd zoeken"
- algemene voor- en nadelen van verdergaande integratie van materiaal in zoeksystemen, met het huidige Omega als uitgangspunt
- zoekproblemen die kunnen optreden bij integratie van artikelen (met uitgebreide inhoudelijke metadata) en catalogusrecords (met heel weinig en vaak nogal algemene metadata).
Op dit moment is er vrij veel verschil in geboden zoekfunctionaliteit tussen de huidige Omega en de Aleph-OPAC (en eigenlijk elke OPAC {!**!}). Belangrijke reden daarvoor is het verschil in de wijze van gebruik tussen catalogi en artikel-databases. In een catalogus wordt relatief vaak gezocht naar "known items", teneinde dat item te kunnen lenen of het in de kast te kunnen lokaliseren. Omdat een gebruiker niet altijd de exacte naam of voorletters van een auteur, of de exacte titel van een boek kent, bieden catalogi meestal een bladerfunctie om de alfabetische omgeving van een auteursnaam of van een boektitel te zien te krijgen, om zo uit een lijstje de juiste auteur of de gewenste titel te selecteren.
Dit is een functionaliteit die op dit moment niet in Omega zit. Het is ook een functionaliteit die daar niet makkelijk - maar vooral ook niet zinvol - is in te bouwen. De auteursnamen in een catalogus zijn - als het goed is - zorgvuldig gestandaardiseerd en zelfs gethesaureerd, zodat varianten van voorletters, voornamen en zelfs achternamen en pseudoniemen, toch (bijna) altijd aan de juiste standaard naam gekoppeld zijn. Zo is het in principe mogelijk alle publicaties van een auteur te vinden, op welke naamsvariant ook gezocht is. Bij de auteursnamen van de artikelen in Omega is dat niet het geval. De metadata in Omega zijn afkomstig van allerlei verschillende leveranciers die er voor hun auteursnamen uiteenlopende standaarden op na houden (zo ze die standaarden al hebben). Zelf die gegevens (geautomatiseerd) standaardiseren zal maar in zeer beperkte mate mogelijk zijn, evenals het koppelen van de van leveranciers ontvangen naamsvarianten. En ook de DAI, de Digital Author Identifier, is daar vooralsnog niet bruikbaar voor. Voor het overgrote merendeel van de inhoud van Omega - de full-text toegankelijke artikelen en andere publicaties - is het dus niet zinvol zo'n bladerfunctie voor auteursnamen te ontwikkelen.
Voor artikeltitels is zo'n bladerfunctie ook niet echt nuttig, omdat die manier van zoeken voor dat type materiaal nogal ongebruikelijk is. De enkele keer dat iemand een known-item-search voor een artikel(titel) doet, zal dat gedaan worden op basis van een combinatie van een paar kenmerkende titelwoorden. Die aanpak hebben onze gebruikers intussen wel geleerd van hun ervaring met webzoekmachines. Overigens is dat een techniek die voor boektitels even bruikbaar is, zodat het maar de vraag is of een titel-bladerfunctie voor cataloguszoekacties in de toekomst nodig blijft.
Behalve een beetje aan de zoekkant, vereist het fysieke materiaal vooral extra functionaliteit om de gebruiker aan gevonden materiaal te laten komen. Zo moeten gegevens getoond worden over beschikbaarheid (uitgeleend of niet, meer beschikbare exemplaren op verschillende locaties, ...) en over mogelijkheden tot reservering van gevonden items. Allemaal functionaliteit die voor de digitaal aanwezige artikelen overbodig is. En wat verder voor gebruikers nog van belang is aan een catalogus-systeem: controle op aflopen van uitleentermijnen, boetes e.d., dat is allemaal administratie die niets met zoekintegratie van doen heeft. In een meer digitale toekomst die ons te wachten staat (lees het nieuwe beleidsplan van de KB daar maar eens op na) zijn dat zaken die er al helemaal niet meer toe doen - of in elk geval heel anders moeten worden.
{!**!} Oeps, nu zie ik net dat zelfs Worldcat al geen auteursnamenbladerfunctie meer heeft. Eigenlijk ook niet zo gek, gezien het volslagen ratjetoe aan materiaal dat ze daar langzamerhand ingepompt hebben, en waar dus ook - net als bij Omega - geen enkele namenstandaardisatie of thesaurering meer wordt toegepast. Anderzijds zou zo'n kijkje in een auteursindex aan zorgvuldige gebruikers wel de kans bieden om zelf alle varianten bij elkaar te zoeken.
[wordt vervolgd]
woensdag 20 januari 2010
Mobile Design and Development , Voor U Gelezen
Voor U Gelezen in ca. 4 uur in een wiebelende auto
Titel: Mobile Design and Development: Practical Concepts and Techniques for Creating Mobile Sites and Web Apps
Auteur: Fling, Brian
Paperback: 336 pages
Publisher: O'Reilly Media; 1 edition (August 24, 2009)
Language: English
ISBN-10: 0596155441
ISBN-13: 978-0596155445
Table of contents: http://www.amazon.com/Mobile-Design-Development-Practical-Techniques/dp/0596155441
Dit boek schetst een uitgebreid beeld van het mobiele landschap. Dit landschap is zo snel in beweging dat de auteur beweert dat alles ouder dan 6 maanden al weer ongeldig is en vergeten kan worden. Anders dan de titel doet vermoeden komt coderen voor mobile web vrijwel niet aan bod. De doelgroep van dit boek is dan ook veel breder dan ontwikkelaars alleen en zeker ook aan te bevelen voor iedereen die in projecten stapt die raken aan het mobiele domein. Er komen veel verfrissende inzichten aan bod hoewel de auteur soms een beetje doordraaft.
Het boek geeft ook goed inzicht in wat je beslist niet moet doen en naar mijn mening is dan ook de allerbelangrijkste uitspraak: Don't convert, Create
Meest weerzinwekkende uitspraak: good mobile design will make the lifes of peoples better.
Ik heb zelf geen mobiel en heb niet het idee dat ik wat mis en zeker niet als ik naar mijn grommende en zwetende medemens kijk die zich op het Mobile 2.0 web durft te begeven.
In een vogelvlucht de inhoud van het boek
- Hoofdstukken 1 tm 3
Deze schetsen de historie van mobile devices en bijbehorende 'ecosystemen' zoals platforms en application frameworks (androïd, windows mobile, java etc.) De scope van mobile web wordt als enorm beschouwd en ook wel 'the seventh mass medium' genoemd
(print,recording,cinema,radio,tv,internet....mobile) welke spoedig het conventionele internet gebruik zal overstijgen. Dit omdat met mobile nu eenmaal veel geld kan worden verdiend.
Daarbij is mobile internet bij uitstek het platform voor personalisatie. Want wie geeft nu ooit zijn telefoon uit handen ?
- Hoofdstuk 4 - Designing for context
Behandelt het begrip 'Context' met een grote C en 'context' met een kleine c. Een beetje een zweverig hoofdstuk maar wel één met een belangrijke boodschap.
De context van de gebruiker speelt een cruciale rol in het gebruik en het soort informatie.
- Hoofdstuk 5
Een belangrijk hoofdstuk welke uit de doeken doet waarom een 'Mobile Stategy' noodzaak is waarbij geconstateerd wordt dat mobile design en development geen goedkope zaken zijn.
Opgesomd worden 7 (soms obligate) regels.
De belangrijkste
-Focus on context, goals and needs.
-You can't support everything
-Don't convert, Create
-Keep it simple
- Hoofdstuk 6
Hier worden diverse Mobile applicaties opgesomd waaronder Native Applications (specifiek compiled voor een platform) of Mobile Web Applications (plat gesteld een website gebaseerd op xhtml,css,javascript). Duidelijk mag zijn dat de laatste als nadeel heeft dat deze niet de optimale ervaring biedt van een native application die allerlei zaken van een device kan aanspreken.
- Hoofdstuk 7
Bevat veel rijke informatie omtrent de mobiele informatie architectuur en user experiences.
Na een verhelderend diagram op http://www.jjg.net/elements/pdf/elements.pdf komen diverse praktische zaken aan bod.
(Clickstreams, sitemaps, keep it simple, labels,wireframes,prototyping etc.)
Opvallende uitspraak: 'people don't respond to visual aesthetics as much as you might think'.
Kortom: een hoofdstuk wat het lezen waard is.
- Hoofdstuk 8
Over Mobile design met een wat meer praktisch gehalte.
Look and feel , Layout, color, graphics , typography, readability. Hier komen we ook te weten dat de kleur 'rood' staat voor passie, sex, kracht en huwelijk (India only) dus dat zit wel goed bij de UBU.
- Hoofdstuk 9
Mobile Web Application versus Native applications. Plat samengevat: maak een Mobile Web Application tenzij je echt functionaliliteit van het device nodig hebt zoals filesystem, offline gebruik, camera etc.
- Hoofdstuk 10
Allereerst een opsomming van wat Web 2.0 volgens de auteur is. Dan de constatering dat niemand goed weet wat Mobile 2.0 nu eigenlijk is. Wel enige handige weetjes:
-Wil je dat de batterij snel leeg is gebruik dan veel Javascript
-Idem voor data intensieve applicatie (er wordt voor veel AJAX gewaarschuwd)
-Mobile widgets are the next big thing
-De mobile community heeft een groot ego en staat haaks op de web community.
- Hoofdstuk 11
Over de ondersteuning van verschillende devices. Een 'device plan' op organisatie niveau is daarbij onontbeerlijk. Hierin ook een matrix waarbij de mobile browsers worden opgedeeld in classes lopend van 'A tm F' waarbij de ondersteuning voor markup, css en javascript inzichtelijk wordt gemaakt. Enkel Class A komt in de buurt van de bekende desktop browsers en javascript ondersteuning is uitermate pover bij overige classes.
Daarnaast is de ontwikkeling van DIAL als device onafhankelijke markup taal in opmars.
Het hoofdstuk sluit af met een stuk over de CSS ondersteuning aangeduid als Wireless CSS of WAP CSS.
Een W3C mobile validator http://ready.mobi/launch.jsp?locale=en_EN
- Hoofdstuk 12
Geheel gewijd aan iPhone en bijbehorende tools zoals webkit.
- Hoofdstuk 13
Een hoofdstuk van importantie over 'adapting to devices' via detect, adapt and deliver.
Er zijn verschillende opties
1) Do nothing. Dit stoelt op de W3C gedachte van 'One Web' en dat een device zelf in staat is te renderen o.a. op basis van bv. CSS3.
Een optimistische gedachte en weinig compatible momenteel.
2) Progressive enhancement. Gebaseerd op fallback techniek bijvoorbeeld varierend van 'geen stylesheet' tot een bijna volledige CSS2\CSS3 ondersteuning
3) Device targeting. Probeer zo goed mogelijk het device te detecteren. Op page 248 en verder zijn diverse voorbeelden gegeven om dit te doen. Niet enkel in Javascript of PHP maar ook bv. in .htaccess en zelfs in Apache \ IIS modules.
4) Full adaption. Ondersteuning van elke Class
Een zeer complete oplossing inclusief PHP API wordt aangeboden via opensource project WURFL
Andere opties o.a vanaf page 248-260
http://www.passani.it/switcher/ (niet gratis)
Voor de constructie van een mobile URL worden enkele mogelijkheden geschetsts
domain.com/mobile
domain.com/m
m.domain.com
of zelfs per device
iphone.domain.com
domain.com/iphone
Tips:
-lange URL's zijn lastig op een mobile dus het kan handig zijn om een tinyurl alias te gebruiken
-Popup windows: DON'T
- Hoofdstuk 14
Geheel gewijd aan 'making money in mobile' en wellicht interessant voor de mensen die een tweede huis willen kopen.
- Hoofdstuk 15
Omtrent 'supporting devices' en 'device plans'
Een rommelig en onvolledig stuk over de kosten en baten van device support en bijbehorende plans en testscenario's.
Een suggestie voor testen is 'guerilla testing' oftewel langsgaan bij diverse winkels en daar diverse modellen testen. Meer praktisch is het testen op een desktop o.a via een iframe of via webkit
Opera heeft de mini browser op http://www.opera.com/mini/demo/
iPhone http://www.testiphone.com/
Erg handig ook is de useragent switcher van de welbekende http://chrispederick.com/work/user-agent-switcher/
- Hoofdstuk 16
Dit laatste hoofdstuk schetst de toekomst van mobiel. Allereerst gelooft de auteur dat web 2.0 al enige tijd dood is. De uitdaging ligt in data portability en 'making content accesible to all people regardless of location,education,ability...'
Het boek staat meestal in de kast bij I&O ontwikkelaars.
vrijdag 15 januari 2010
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]
maandag 11 januari 2010
Het volgende Omega-decennium (2)
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]
Abonneren op:
Posts (Atom)
