metasearch

metasearch
• wat is het probleem bij de oplossing?
• welke oplossing bij welk probleem?
behoefte aan integreren van
meer bronnen / zoeksystemen
waarom wil je dat voor je gebruikers?
• het is onhandig als ze dezelfde zoekvraag
aan elk afzonderlijk systeem telkens weer
opnieuw moeten stellen
• het is gebruikersonvriendelijk dat die
systemen vaak allemaal verschillende
zoekinterfaces hebben
© eric sieverts, UB Utrecht
behoefte aan integreren van
meer bronnen / zoeksystemen
waarom wil je dat voor je gebruikers?
• het is onhandig als ze dezelfde zoekvraag
aan elk afzonderlijk systeem telkens weer
opnieuw moeten stellen
• het is gebruikersonvriendelijk dat die
systemen vaak allemaal verschillende
zoekinterfaces hebben
© eric sieverts, UB Utrecht
integreren van meer
bronnen / zoeksystemen
globaal twee soorten aanpak:
• alle bronnen in je eigen centrale systeem
(zoekmachine) indexeren
de OMEGA-aanpak
• meta-zoeksysteem dat de eigen zoeksystemen
van de verschillende bronnen in één keer
parallel bevraagt (gedistribueerde zoekactie)
de METALIB-aanpak
© eric sieverts, UB Utrecht
geïntegreerd systeem
via lokale centrale index
zoeken
mega
centrale index
indexeerregels voor
targets
indexer
internet
full-text links
tekstbestanden
(metadata)
tekstbestanden
eigen centrale index
voorbeelden:
UB Utrecht - Omega-systeem
• metadata van artikelen uit groot aantal
tijdschriften van diverse leveranciers
OAIster
• volgens Open Archive protocol “ge-harveste”
metadata (volgens Dublin Core), uit allerlei
“archieven” met wetenschappelijke publikaties
© eric sieverts, UB Utrecht
eigen centrale index
voordelen:
• garantie van uniforme zoekmogelijkheden
• geavanceerde zoekfunctionaliteit mogelijk, want
wij hebben zelf in de hand welke zoekmachine
we kiezen en hoe we die configureren
nadelen:
• zwaar systeem (eigen zoekmachine) te hosten
en beheren
• kan niet voor alle “content”
© eric sieverts, UB Utrecht
wanneer eigen index ?
als je zelf beheer kunt krijgen over te
doorzoeken “content”
– wel bij materiaal van (sommige / grote)
uitgevers (zoals Elsevier, JStor, etc)
– niet bij materiaal van uitgevers die dat (nog)
niet willen / kunnen / begrijpen
– niet bij databases waar bijbehorend zoeksysteem al verweven is met (de ontsluiting van)
de gegevens (zoals Ovid/ERL, CSA, etc)
© eric sieverts, UB Utrecht
meta-search oplossing
daarvoor is nodig:
• het betreffende materiaal / content moet al een
eigen zoeksysteem hebben
• dat zoeksysteem moet extern (via internet) te
benaderen zijn
• met dat zoeksysteem moet via gestructureerde
interactie gecommuniceerd kunnen worden
(opdrachten versturen, antwoorden binnenhalen)
© eric sieverts, UB Utrecht
geïntegreerd systeem
via meta-zoekmethode
zoeken
configuratie
gegevens
van targets
query-generator / antwoord-inzamelaar
Z39.50
Z39.50
intern
api
zoek
zoek
index
index
bestand
bestand
http
internet
Z39.50
http
http xml
Z39.50
zoek
zoek
zoek
zoek
index
index
index
index
bestand
bestand
bestand
bestand
meta-search oplossing
metasearch software (zoals Metalib) kan
communiceren met verschillende soorten
zoeksystemen:
– Z39.50 protocol (vooral bibliografische databases)
redelijk gestandaardiseerd, maar weinig geavanceerd
– interactie op basis van xml (o.a. nieuw SRU-protocol)
redelijk flexibel, maar nog geen ruime ondersteuning
– http-protocol / web-formulieren ("screen-scraping")
wijd verbreid, maar niet gestructureerd / weinig stabiel
– lokale “legacy”-systemen
© eric sieverts, UB Utrecht
meta-search oplossing
voordelen:
– geen zwaar eigen systeem te beheren
– ook geschikt voor niet zelf indexeerbare content
nadelen:
– grootste gemene deler van zoekfunctionaliteit
– geen geavanceerde zoekfuncties beschikbaar
– soms ingewikkeld configuratie-werk
(zowel voor Z39.50 als voor http:url-syntax en
screen-scraping)
© eric sieverts, UB Utrecht
meta-search toepassingen UBU
wat we zelf niet makkelijk kunnen indexeren
en wel een eigen zoeksysteem heeft
– full-text tijdschriften die we (nog) niet in
Omega-zoekmachine hebben kunnen krijgen
– bibliografische databases, catalogi etc.
die we niet zelf kunnen indexeren
én niet tot de eigen full-text collectie behoort
(dus eigenlijk niet in Omega-zoeksysteem thuishoort)
© eric sieverts, UB Utrecht
meta-search bij Omega
uitgevers die (nog) geen metadata leveren
mogelijke problemen:
– meestal web-interfaces die configuratie met
screen-scraping nodig maken
– meeste waarschijnlijk (nog) niet standaard
ondersteund door Metalib (ExLibris)
© eric sieverts, UB Utrecht
bibliografische meta-search
al die verschillende niet-fulltext zoeksystemen
mogelijke problemen bij Metalib:
– veel “native” interfaces bieden veel betere /
geavanceerder zoekmogelijkheden
– niet meer dan ca. 10 tegelijk doorzoekbaar te
maken
– mergen van zoekresultaten met relevance
ranking geeft problemen
– nog niet allemaal standaard ondersteund
– …..
© eric sieverts, UB Utrecht
mogelijk scenario voor toepassen
van meta-search
scenario 1:
– een systeem dat alle bibliografische bronnen
tegelijk doorzoekbaar maakt via metasearch
(in groepjes van maximaal 10)
– Omega-systeem dat alle full-text beschikbaar
materiaal tegelijk doorzoekbaar maakt via
Omega-zoekmachine + metasearch van
“overige” uitgevers
© eric sieverts, UB Utrecht
scenario 1
bibliografisch zoeken
“biblio”
metasearch
omega zoeken
“full-text”
metasearch
omega
index
internet
zoek
zoek
index
index
Aleph
biblo
graf.
omega
zoekmach.
zoek
zoek
zoek
zoek
index
index
index
index
ncc
biblio
graf.
full
text
full
text
mogelijk scenario voor toepassen
van meta-search
scenario 2:
– één systeem dat “alles” tegelijk doorzoekbaar
maakt via metasearch (in groepjes van
maximaal 10)
daarónder native interfaces van alle
individuele systemen (pubmed, psycinfo, ...),
waarbij ook Omega dat alle full-text materiaal
tegelijk doorzoekbaar maakt
© eric sieverts, UB Utrecht
scenario 2
alles zoeken
omega zoeken
“alles”
metasearch
“full-text”
metasearch
omega
index
internet
zoek
zoek
index
index
Aleph
biblo
graf.
omega
zoekmach.
zoek
zoek
zoek
zoek
index
index
index
index
ncc
biblio
graf.
full
text
full
text