7. Exploitatie van de onderwerpsontsluiting in Brocade

Auteur Richard Philips
Aanmaak 6 mei 2002
Oud BVV nr 2020

7.1. Abstract

Dit document behandelt de problematiek van het invoeren van onderwerpscodes bij bibliografische beschrijvingen en de exploitatie van deze codes in de software.

7.2. Invoeren van onderwerpscodes

Het invoeren van onderwerpscodes is wel heel eenvoudig: ongeacht de natuur van het onderwerp kan een a-loi geassocieerd worden met een c-loi. De exploitatie van het geven van onderwerpscodes is volledig ontkoppeld van de invoer.

Dit betekent nog dat de complexiteit van de onderwerpscodes volledig ten laste valt van enerzijds diegenen die de meta-informatie beschrijven en anderzijds de software ontwikkelaars.

7.3. Indexeren naar onderwerp

Een eerste problematiek is het indexeren naar onderwerp. Een c-loi wordt zoals elke loi geïndexeerd aan de hand van een indexgenerator. Dit is een stukje software die gegeven de loi, alle indexen, hoofdvormen en verwante vormen genereert die van toepassing zijn. De identifiers bij deze indexen hebben steeds de vorm cat.id.type. id is een vrij te kiezen naam die de set van indexen voor een catalogus onderscheidt. type identificeert dan weer de specifieke index binnen de catalogus.

Een voorbeeld uit het lvd-regelwerk om één en ander duidelijk te maken

cat.lvd.ti Titelindex
cat.lvd.tw Titelwoordindex
cat.lvd.pk Plaatskenmerkindex

Ten behoeve van de catalografen bestaat er slechts 1 onderwerpsindex: cat.lvd.ow. Het spreekt echter vanzelf dat dit niet volstaat voor de eindgebruikers. Zo hebben zij er geen behoefte aan om codes die enerzijds verwijzen naar UDC en anderzijds naar de maritieme thesaurus in een zelfde index terug te vinden. Hetzelfde verhaal vinden we terug in de openbare bibliotheken: het is niet zinvol in 1 index de trefwoorden jeugd en siso-codes te mengen.

Dit probleem wordt dan opgelost door een nieuwe macro te introduceren: m4_getAuthIndexSuffix(array,aloi) genereert, bij een gegeven a-loi een matrix met 2 subscripts:

  1. Een suffix: Deze suffix is de derde component in de index id.
  2. Een a-loi: Dit is ofwel de originele a-loi, ofwel een bredere term.

m4_getAuthIndexSuffix(array,aloi) zoekt, behalve de a-loi zelf, alle bredere termen van de a-loi op die aan de volgende voorwaarden voldoen:

  • Deze bredere term wordt geïndexeerd.
  • Deze bredere term bevat minstens 1 suffix die gemeenschappelijk is met een suffix van a-loi. De matrix ontstaat dan door precies deze suffixen te combineren met de gevonden bredere term.

Om de naamgeving te harmoniseren maken we twee afspraken over de suffix:

  1. De suffix begint steeds met de letters ow.
  2. Bij een bredere term, eindigt de suffix met de letters bt.

Het algoritme om de suffix te bepalen, maakt gebruik van meta-informatie die bijgehouden wordt in het type authority codes. In een apart veld staan de verschillende suffixen in volgorde genoteerd.

Voor alle duidelijkheid: het bestaan van een suffix betekent niet dat de corresponderende index automatisch wordt aangemaakt. Er is nog een extra test: de index identifier moet ook nog bestaan (m4_isIndex($xis,$Indexid)).

7.4. De authority file

De authority file wordt aangemaakt onafhankelijk van eventuele toepassingen in bijvoorbeeld de catalografie. Een belangrijk gegeven in verband met onze problematiek zijn de relaties: bredere termen, meer specifieke termen. Deze worden voor twee zaken gebruikt:

  1. Het genereren van de indexen.
  2. Het construeren van zoekbomen.

In de vorige paragraaf hebben we het al gehad over de impact op de index.

Zoekbomen worden door diverse elementen bepaald:

  • De root van de boom.
  • De geselecteerde meer specifieke termen van de root.
  • De collectie van bibliografische beschrijvingen die de authority code als onderwerp hebben.

Om specifieke zoekbomen te distilleren uit het authority bestand werken we met een tussenstap: de intermediare zoekboom.

7.5. Intermediare zoekbomen

De intermediare zoekboom is enkel afhankelijk van de authority file: van zodra een root gegeven is, worden gewoon alle authority codes die meer specifiek zijn, weerhouden. Er kunnen extra specificaties - gebaseerd op type en lidmaatschap - worden gegeven. Een gevolg hiervan is dat tussenliggende bredere termen kunnen verdwijnen: ze voldoen misschien niet aan deze extra voorwaarden. Daardoor schuiven meer specifieke termen op naar de root toe.

Toch nog even vermelden dat de intermediare zoekboom wordt opgebouwd onafhankelijk van catalografische beschrijvingen. Er kunnen ook diverse, onderling sterk verschillende zoekbomen worden opgesteld.

De intermediare zoekbomen worden niet dynamisch (= tijdens het onderhoud van de authority file) aangemaakt. Ze kunnen op vraag of via een batch proces worden opgesteld.

7.6. Index zoekbomen

De index zoekboom is het uiteindelijke doel van deze complexe structuur. In een specifieke OPAC kunnen diverse index zoekbomen worden aangeboden. De belangrijkste onderdelen van een index zoekboom zijn wel:

  • De geassocieerde intermediare zoekboom.
  • Een index (cat.xxx.owyyy) en zijn uitgebreide index (cat.xxx.owyyybt).

De constructie van de index zoekboom gebeurt in verschillende fasen:

  1. Het startpunt is de intermediare zoekboom.
  2. Hierin worden alle nodes geschrapt die geen beschrijvingen hebben binnen de gegeven index cat.xxx.owyyybt.
  3. De gewone relaties (releated terms) worden gelegd tussen de overblijvende nodes.
  4. Er wordt een index gemaakt op de overblijvende nodes.

Ook dit soort bomen worden of op vraag, of via een batch procedure geconstrueerd.

7.7. Index zoekbomen en de OPAC

Een OPAC kan verschillende zoekbomen tonen: de meta-informatie bij de OPAC vermeldt alle gewenste index zoekbomen. Het invoerprogramma van de meta-informatie van een OPAC test meteen of de aan de zoekbomen geassocieerde indexen wel behoren tot de indexen van de OPAC zijn catalogus.

7.8. Onderhoud van de indexen

Indexen veranderen enkel door het expliciet indexeren van de library object identifiers (LOI). Het is nu gewenst dat de indexen ook veranderen na aanpassing van de structuur van de authority codes:

Aanpassing van types authority codes
Indien de aanpassing van het type leidt tot een verandering van de set suffixen (volgorde mag wel worden aangepast) dan moeten alle bibliografische beschrijvingen van alle catalografische systemen doorlopen worden en moeten die opnieuw worden geïndexeerd indien ze een authority code in het onderwerp hebben dat van het betreffende type was.
Wijziging van het type van een authority code
In deze situatie moeten alle beschrijvingen van alle catalografische systemen doorlopen worden en die beschrijvingen die een authority code hebben in het nieuwe type of het oude type dienen te worden geïndexeerd.
Schrappen of toevoegen van een relatie (bredere term, meer specifieke term)
Men neemt dan de meest algemene term van de twee authority codes betrokken bij de operatie. Men neemt van deze code al de meer specifieke termen en verzamelt dan alle bibliografische records die minstens één van deze termen in het onderwerpsveld staan hebben. Deze verzameling records moet dan opnieuw geïndexeerd worden.

Het is duidelijk dat deze operaties niet online kunnen worden uitgevoerd. Er komen een aantal technieken ter beschikking waarmee een en ander kan worden gestroomlijnd. In het bijzonder zal in het regelwerk van een catalografisch systeem worden vermeld of records in dit systeem onderwerpsinformatie bevatten.