Upload
vincent-pieters
View
219
Download
2
Embed Size (px)
Citation preview
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
© 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
• het is dan gebruikersonvriendelijk dat die systemen vaak allemaal verschillende zoekinterfaces hebben
© eric sieverts, UB Utrecht / HvA - MIM
integratie van meer bronnen / zoeksystemen
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
© eric sieverts, UB Utrecht / HvA - MIM
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)
© eric sieverts, UB Utrecht / HvA - MIM
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
© eric sieverts, UB Utrecht / HvA - MIM
indexer
internet
tekstbestanden(volledige documenten) tekstbestanden
centrale index
zoekengeïntegreerd systeemvia lokale centrale index
indexeer-regels voor
targets
full-text links
eigen centrale index
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
© eric sieverts, UB Utrecht / HvA - MIM
eigen centrale index
ook dat kan (technisch) 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
© eric sieverts, UB Utrecht / HvA - MIM
indexer
internet
tekstbestandentekstbestanden
centrale index
zoekengeïntegreerd systeemvia lokale centrale index
indexeer-regels voor
targets
full-text links
eigen centrale index
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
© eric sieverts, UB Utrecht / HvA - MIM
eigen centrale index
ook dat kan (technisch) 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
© eric sieverts, UB Utrecht / HvA - MIM
indexer
internet
tekstbestanden(metadata) tekstbestanden
centrale index
zoekengeïntegreerd systeemvia lokale centrale index
indexeer-regels voor
targets
full-text links
eigen centrale index
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
© eric sieverts, UB Utrecht / HvA - MIM
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
© eric sieverts, UB Utrecht / HvA - MIM
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– ....
© eric sieverts, UB Utrecht / HvA - MIM
problemen bij centrale index
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
© eric sieverts, UB Utrecht / HvA - MIM
problemen bij centrale index
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)
© eric sieverts, UB Utrecht / HvA - MIM
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
© eric sieverts, UB Utrecht / HvA - MIM
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
meta-search oplossing
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)• ....
© eric sieverts, UB Utrecht / HvA - MIM
meta-search oplossing
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)
© eric sieverts, UB Utrecht / HvA - MIM
meta-search oplossing
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"
© eric sieverts, UB Utrecht / HvA - MIM
meta-search oplossing
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)
© eric sieverts, UB Utrecht / HvA - MIM
meta-search oplossing
voorbeelden voor alleen webzoeken:
– web-metasearchers:ixquick, clusty, mamma, search.com, kartoo, goshme, … <vb goshme>
– desktop metasearchers (op eigen pc te installeren):
copernic
© eric sieverts, UB Utrecht / HvA - MIM
meta-search oplossing
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>
© eric sieverts, UB Utrecht / HvA - MIM
meta-search oplossing
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
© eric sieverts, UB Utrecht / HvA - MIM
meta-search oplossing
© eric sieverts, UB Utrecht / HvA - MIM
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
meta-search oplossing
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)
© eric sieverts, UB Utrecht / HvA - MIM
meta-search 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)
© eric sieverts, UB Utrecht / HvA - MIM
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)
© eric sieverts, UB Utrecht / HvA - MIM