De OvidSP lay-out is ongetwijfeld handig en mooi, maar het gebruik ervan is echt wennen. Inmiddels heb ik begrepen hoe dat nou zit met het feit dat de ene keer het toevoegen van Related terms minder hits oplevert, en een andere keer meer. Dat is echt zo en het meest verbluffende is, dat het niet geeft 😉 .

Wat is namelijk het geval: je moet anders leren denken.
Je bent gewend een zoekactie te doen, al dan niet sets te combineren en dan te verwachten dat het resultaat alles oplevert ‘wat er is’ in deze database althans. Op zich is dat eigenlijk ook een schijnzekerheid, want je hangt ook in de beste database af van de accuratesse van de indexeerders en de mate waarin je in staat bent een goede zoekactie te doen (hoe moeilijk is het intikken van een paar termen immers? 🙂 ).
Daarnaast: met Google bekijk je zelden alle hits, omdat de meest relevante tamelijk vooraan zitten. Dus eigenlijk vind je nooit echt alles, of je bekijkt niet alles, en meestal wil je dat ook eigenlijk niet echt.
Ovid heeft daar vorm aan gegeven in hun nieuwe zoeksysteem dat nu ook ook aan relevance raking doet en gaat o.a. uit van deze zaken:

1. de zoekactie wordt in een keer ingevoerd in de natuurlijke taal, geen/nauwelijks postcoordinatie, hooguit toevoegen van wat limits. Het opdelen in concepten en die later samenvoegen moet je niet in deze Basic search doen
2. niemand wil meer dan 500 hits wil hebben, daarom hebben ze hun ‘cut-off point’ op 500 gezet.

Achter de schermen worden de zoekresultaten nl. al tijdens het zoeken opgedeeld in sets per soort relevantie (waarschijnlijk de velden waar de zoekvraag in gevonden wordt), die sets worden bij elkaar opgeteld in volgorde van belang voor die relevantie. De eerste optelling van sets die boven de 500 komt is de winnaar: die bepaalt wat het getal is van het aantal ‘hits’ dat wordt gepresenteerd en de hoogte daarvan is min of meer toeval en totaal niet van belang. Dat is iets wat we los moeten laten. Ovid legt uit:

Each search result is assigned a score based on its relevancy to the search query and all results with the same score are grouped together. The number of groups (let’s call them “Scoring Groups”) varies depending on the number of results that are assigned the same score. We stop after the first group that brings the total result count past 500.If that group is large, the ending count may be a lot higher than 500.

Example:
The query “computed tomography {No Related Terms}” returns 900 equally-relevant results in MEDLINE. The query doesn’t provide much information, so the system can’t whittle the result down to the 500 or so that it prefers to return; all 900 results are equally-relevant, so they’re all returned.

Here is another hypothetical example. Suppose that for a particular search, the scoring of the results returns the following:

Scoring group Number of results with the same score Total number of results showing
7 367 805
6 289 438
5 79 149
4 14 70
3 37 56
2 14 19
1 5 5
Five of the results for this query were assigned a score of “1”; 14 a score of “2”; 37 a score of “3”; and so forth. We can see that the “Scoring Group” that brings the total over 500, Scoring Group “7”, contains 367 results, bringing the total number of results OvidSP shows to 805. If the last group, the one with a score of “7” had returned only 200 results, the total number of results shown would have been 638 (438 + 200). If Scoring Group “6” had included enough results to bring the total to over 500, say 359 for example, the total would have been 508 (149 + 359). No results from Scoring Group “7” would have been included.

Dat verklaart waarom je dit maffe resultaat krijgt in PsycInfo:

1. stress library personnel 5469
2. stress library personnel (incl related terms) 504

Achter de schermen worden de ‘zoekgroepjes’ gevormd en bij elkaar opgeteld. Stel dat in beide gevallen de ‘zoekgroepjes’ in het proces ergens uitkomen op 499: als je zoekt zonder de related terms is de volgende set (bijv) 4970 groot, en zoek je met related terms is die maar 5 groot: in beide gevallen wordt dat met de reeds gevonden set van 499 hits opgeteld, en in beide gevallen kom je boven de 500 uit en wordt de zoekactie gestopt. Met als gevolg dat je in situatie nummer 1 een veel groter resultaat hebt dan 2. Maar in beide situaties verwacht niemand van je dat je meer dan de eerste 100 of zo gaat bekijken, dus de totale hoeveelheid doet er helemaal niet toe.

Het vergt een ander denkpatroon, het vergt ook vertrouwen in het zoekalgoritme van Ovid: weten ze echt de belangrijkste velden / records te lokaliseren om hun resultaat goed te ‘ranken’.
Een probleem zie ik wel met downloaden naar locale bestanden: daar zit die relevance ranking niet in, en stop je gewoon bij het aantal gevonden hits: dan tellen aantallen wel 😉 .

Ikzelf kan alle consequenties nog niet overzien en ben van plan om de komende tijd beide systemen naast elkaar te gebruiken. Maar ik ben in elk geval wel blij dat ik nou een beetje begrijp waarom de resultaten zijn zoals ze zijn.