metasearch wat is het probleem bij de oplossing
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 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 Z 39. 50 intern api zoek index bestand http internet Z 39. 50 http xml Z 39. 50 zoek index bestand
meta-search oplossing metasearch software (zoals Metalib) kan communiceren met verschillende soorten zoeksystemen: – Z 39. 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 Z 39. 50 als voor http: url-syntax en screenscraping) © 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 (Ex. Libris) © 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 index Aleph biblo graf. omega zoekmach. zoek index ncc biblio graf. 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 index Aleph biblo graf. omega zoekmach. zoek index ncc biblio graf. full text
- Slides: 21