Geïntegreerde zoeksystemen verbeterde toegankelijkheid door meer verschillende bronnen in één...

geïntegreerde zoeksystemen

verbeterde toegankelijkheid door meer verschillende bronnen in

één keer doorzoekbaar te maken

© eric sieverts, UB Utrecht / HvA - MIM

integratie van meer bronnen / zoeksystemen

waarom wil je dat?

veel organisaties hebben (heel) veel verschillende bronnen ter beschikking

• het is dan onhandig dezelfde zoekvraag aan elk afzonderlijk systeem telkens weer opnieuw te moeten stellen<vb utrecht>

• het is dan gebruikersonvriendelijk dat die systemen vaak allemaal verschillende zoekinterfaces hebben


http://ir.library.uu.nl/cgi-bin/mus212/dialogserver?DB=ubuweb&B=CAAlles&HEAD=Digitale%20bestanden%20-%20Alfabetische%20lijst&ORGANISE_CODED=W:url0text


waarom wil je dat?

veel organisaties hebben (heel) veel verschillende bronnen ter beschikking

• het is dan onhandig dezelfde zoekvraag aan elk afzonderlijk systeem telkens weer opnieuw te moeten stellen

• het is dan gebruikersonvriendelijk dat die systemen vaak allemaal verschillende zoekinterfaces hebben



waarom wil je dat?

bovendien nog algemene randvoorwaarde:

• google lijkt altijd eenvoudiger

• als zoeksystemen niet op zijn minst bijna net zo eenvoudig lijken als google , worden ze niet gebruikt


hoe kun je dat integreren?

globaal twee soorten aanpak voor zogenaamde “content-integratie”:

– alle bronnen in je eigen centrale systeem (zoekmachine) indexeren

– meta-zoeksysteem dat de externe zoeksystemen van de verschillende bronnen in één keer parallel bevraagt (gedistribueerde zoekactie)


eigen centrale index

dat kan (technisch) ook nog weer op verschillende manieren, zoals:

– de van verschillende leveranciers verkregen (“gekochte”) informatie volledig op de eigen server laden en daar indexeren

– toegang verkrijgen (kopen) tot informatie die op servers van leveranciers staat en die door je eigen “robot” of "spider" laten indexeren (zoals webzoekmachines)

– zogenaamde “metadata” (in deze context meestal ook abstracts van artikelen) van verschillende leveranciers op eigen server laden en indexeren; daarin hyperlinks naar volledige documenten op servers van leveranciers


indexer

internet

tekstbestanden(volledige documenten) tekstbestanden

centrale index

zoekengeïntegreerd systeemvia lokale centrale index

indexeer-regels voor

targets

full-text links


voorbeeld:

koninklijke bibliotheek had dat tot 2 jaar geleden(en gaat daar in nieuwe architectuur weer naar terug)• een aantal al lokaal beschikbare bestanden in

verschillende systemen (incl. gewone catalogus) geconverteerd naar XML

• samen geïndexeerd• standaard in die bestanden tezamen gezocht



ook dat kan (technisch) nog weer op verschillende manieren, zoals:





indexer

internet

tekstbestandentekstbestanden

centrale index



targets

full-text links


voorbeeld:

scirus zoekmachine (Elsevier: www.scirus.com)• enerzijds: bijna 6 miljoen full-text artikelen uit circa

1800 (eigen) wetenschappelijke tijdschriften

• daarnaast: meer dan 160 miljoen wetenschappelijke webpagina's op allerlei sites

• ook: 15 miljoen bibliografische Pubmed-records

• en: inhoud uit wetenschappelijke “repositories”

• standaard in die collecties tezamen gezocht


http://www.scirus.com/


ook dat kan (technisch) nog weer op verschillende manieren, zoals:





indexer

internet

tekstbestanden(metadata) tekstbestanden

centrale index



targets

full-text links


voorbeelden (waar dus alleen metadata doorzoekbaar; niet de full-text)

OAIster <link>

• volgens Open Archive protocol “ge-harveste” metadata (volgens Dublin Core), uit allerlei “archieven” met wetenschappelijke publikaties

UB Utrecht - Omega-systeem <link>

• metadata van artikelen uit groot aantal tijdschriften van diverse leveranciers


http://www.oaister.org/

http://omega.library.uu.nl/

voordelen eigen centrale index

• garantie van uniforme zoekmogelijkheden• geavanceerde zoekfunctionaliteit mogelijk

(dus concurrentie met Google aan te gaan), want de "aanbieder" heeft zelf in de hand – welke zoekmachine software te installeren, – hoe die te configureren, – welke functionaliteit aan te bieden, – hoe het gebruikersinterface te ontwerpen


problemen bij centrale index

problemen met leverancier van de “content”:

• mogelijkheid staat niet in contract / licentie• leverancier begrijpt niet precies wat de klant wil• technische problemen

– format van geleverde content inconsistent (velden, tags, ...)– spider van zoekmachine wordt “toch” toegang geweigerd– ....

• “logistieke” problemen– ontbrekende / incomplete / dubbele gegevens– metadata ontvangen waarvoor geen full-text toegang is– ....



problemen met "inhoud":

• interne consistentie van geleverde format– velden (aanwezigheid, veldtags)

– bijzondere tekens (diacrieten)

• verschil tussen leveranciers in hoeveelheid digitale tekst in de metadata

• veldconcordantie tussen bronnen / leveranciers– content laten zoals die is ontvangen:

apart indexeerscript per bron

– content converteren naar eigen format in "data-repository" (bijv. in xml en volgens DC): apart import-filter per bron



problemen met techniek:

• benodigde schijfruimte voor de content + de index(en)• beheer en configuratie van eigen zoekmachine• beheer en configuratie van conversiefilters en/of

indexeer-scripts

problemen met zoekfunctionaliteit:

• geen thesaurus zoekfunctie (zonder grote investering)


meta-search oplossing

moet kunnen communiceren met allerlei verschillende soorten zoeksystemen(o.a. vraag- en antwoord-syntax daarvan kennen)

– Z39.50 protocol

(vooral voor bibliografische databases)– xml-gebaseerde systemen

(SRU: vooral voor bibliografische databases, OpenSearch: vooral voor "gewone" zoekmachines)

– http-protocol / web-formulieren

("screen-scraping" van gewone webinterfaces)

vereist database met configuratie-gegevens van de te doorzoeken systemen


internet

zoekengeïntegreerd systeemvia meta-zoekmethode

index

be-stand

zoek

query-generator / antwoord-inzamelaar

index

be-stand

zoek

index

be-stand

zoek

index

be-stand

zoek

index

be-stand

zoek

index

be-stand

zoek

Z39.50

Z39.50 Z39.50

internapi

http http xml

Z39.50 http

configuratiegegevens

van targets


Z39.50 standaard protocol voor communicatie tussen lokale client-software en server voor:

– opsturen query (en andere opdrachten) in juiste syntax• gewenste actie (browsen / zoeken / tonen / …)• veldnamen• booleaanse operatoren• ....

– interpretatie van ontvangen antwoorden / gegevens• stuk uit index • aantal hits• resultatenlijst (velden)• detailpresentatie van resultaten (velden, structuur)• ....



Z39.50 protocol

voordeel: • in de tijd stabiele interfaces• velden “in principe” gestandaardiseerd

nadeel: • inflexibel• lastige implementatie• velden in praktijk vaak niet echt gestandaardiseerd• weinig geavanceerde zoekfunctionaliteit

(bijv. geen relevance ranking)



http-protocol / webformulieren

– queries (ingevoerd via zoekregel of meer complex webformulier) worden doorgegeven via een URL, volgens door zoeksysteem gespecificeerde syntax

http://www.google.com/search?hl=en&ie=UTF-8&q=mim+idm

– antwoorden (zoekresultaten) moeten worden geïnterpreteerd; er is geen standaard structuur: elementen uit antwoordscherm moeten worden herkend op basis van schermopmaak - toevallig aanwezige kenmerkende stukjes html-code - z.g.n. "screen-scraping"



http-protocol / webformulieren

voordeel: • alle functionaliteit van betreffende zoekfunctie

nadeel: • url-based query-syntax moet geanalyseerd worden

• lastige filter-scripts schrijven voor “screen-scraping” t.b.v. verwerken gegevens uit antwoordschermen (zoekresultaten)

• interfaces van zoeksystemen niet erg stabiel in de tijd (telkens opnieuw "screen-scraping" filters aanpassen)



voorbeelden voor alleen webzoeken:

– web-metasearchers:ixquick, clusty, mamma, search.com, kartoo, goshme, … <vb goshme>

– desktop metasearchers (op eigen pc te installeren):

copernic


http://www.goshme.com/


xml-gebaseerde standaarden

– SRU/SRW (ook wel ZING - Z39.50 next-generation; xml-variant op Z39.50)

• SRU-protocol (search & retrieval by url) – queries in url verpakken (volgens standaard syntax) – antwoorden van systemen komen standaard in xml terug,

zodat elementen daarin eenduidig herkenbaar zijn

• SRW-protocol (search & retrieval by the web)– gebruikt daarvoor SOAP-protocol

– openSearch (XML protocol voor -gewone- zoekmachines)

<zie voor uitleg de serie “De Standaard” in Informatie Professional>



voorbeeld van SRU-gebaseerd systeem• TEL - The European Library <link>

project van Europese Nationale Bibliotheken, waarbij al hun uiteenlopende catalogi in één keer doorzocht kunnen worden

prototype ontwikkeld door KB

zie ook artikel van Theo van Veen in:

Informatie Professional - maart 2004

• wordt nu intern al in veel meer systemen toegepast


http://www.theeuropeanlibrary.org/portal/index.html



enkele algemene voorbeelden van producten:• metalib (van bibliotheekautomatiseerder ExLibris)• museglobal• fretwell-downing portal• ihs portal suite• v-spaces (van bibliotheekautomatiseerder Infor)• webfeat (webservice)

bij vrijwel allemaal (nog) nadruk op Z39.50 targets

zie kritisch artikel van Marten Hofstede: “Portals op de pijnbank” in: Informatie Professional - oktober 2002


enkele voordelen:

– lokale software stelt geen heel hoge eisen aan server– geen (nauwelijks) problemen met leveranciers– geen problemen met indexeer- of filter-scripts

(vergeleken met eigen indexerings-oplossing)



nadelen van huidige generatie metazoekers:

– geen uniformiteit in beschikbare zoekfunctionaliteit

– grootste gemene veelvoud van functionaliteit

– geen geavanceerde zoekfuncties [relevance ranking, thesaurus, …] (al biedt SRU in principe wel mogelijkheden)

– onvergelijkbare aantallen resultaten / incomplete antwoorden

– vaak slechte responsetijden (van achterliggende systemen)

– beperking van aantal gelijktijdig te doorzoeken systemen

– slechte "usability" [onduidelijk interface, hoe voorselectie van bestanden? …]

– database met configuratiegegevens bijhouden/updaten (al zorgt leverancier daar meestal voor)


wat nieuwe ontwikkelingen

• expertsysteem voor bestandskeuze inbouwen in metasearch ("Livetrix" bij UB Groningen)

• user experience van metasearch verbeteren, o.a. door response "schijnbaar" te versnellen door toepassing van bijvoorbeeld AJAX-technologie (scherm wordt geleidelijk opgebouwd en veranderd, zonder hele reloads zoals bij klassieke HTML)

• combinatie van zoeken via centrale index met metasearch voor niet lokaal te indexeren gegevens ("Primo" van ExLibris, "Summa" van Deense bibliotheken)


Geïntegreerde zoeksystemen verbeterde toegankelijkheid door meer verschillende bronnen in één...

Documents

Transcript of Geïntegreerde zoeksystemen verbeterde toegankelijkheid door meer verschillende bronnen in één...