6. Index aanmaak in Brocade

Auteur Richard Philips
Aanmaak 15 okt 2001
Oud BVV nr 2003

6.1. Library Object Identifiers (LOI)

Objecten binnen Brocade worden doorgaans gekarakteriseerd door middel van een absolute referentie. Gebaseerd op hetzelfde principe als URLs, begint de referentie met een aanduiding van het type object, het tweede veld geeft dan een eerste specificatie binnen dit type, de volgende velden geven dan opnieuw verdere detaillering binnen de voorgaande velden.

Als delimiter wordt : gebruikt. De enige restrictie die is opgelegd aan de deelvelden, is dat deze velden geen spaties of : mogen bevatten.

Een voorbeeld om dit principe van de LOI toe te lichten

c:lvd:1263577 Dit gaat om een catalografische beschrijving (c). Ze behoort tot het regelwerk lvd en heeft als volgnummer binnen dit regelwerk 1263577.

Deze eenvoudige afspraak heeft verregaande consequenties: het wordt mogelijk eigenschappen op een abstracte wijze te gaan beheren en op basis van deze eigenschappen wordt het dan mogelijk software te gaan samenstellen die grotendeels onafhankelijk is van het gegeven object type.

6.2. Indices

Zoals steeds in Brocade zijn indices abstracte objecten. Ze worden gekarakteriseerd door een identifier (in het vervolg duiden we deze aan met INDEX). Om de index structuur goed te kunnen begrijpen, is het belangrijk een inzicht te hebben in wat een hoofdvorm en wat een zoekvorm is.

Indices zorgen ervoor dat een gebruiker (menselijk of een proces) in staat zijn LOIs terug te vinden. De objecten, gerepresenteerd door deze LOIs, hebben diverse eigenschappen. Deze eigenschappen nemen de gedaante aan van karakterrijen en het is precies via deze strings dat de LOI kan worden teruggevonden.

Deze karakterrij wordt gerepresenteerd door een hoofdvorm: dit is meestal een vereenvoudiging van de originele string.

Voorbeeld

  • Kleine letters vervangen door hoofdletters.
  • Opkuisen van overtollige whitespace.
  • Aanpassen van diacritische tekens.

De hoofdvorm laat toe dat diverse kleine verschillen bij data entry weggevlakt worden bij de terugzoekbaarheid. De hoofdvorm lijkt meestal sterk op de ingebrachte zoekterm. Toch hoeft dit niet altijd zo te zijn: vooral het gebruik van authority controle kan tot grote visuele verschillen leiden. Het kan zelfs zijn dat een basisstring verschillende hoofdvormen produceert: dit kan zijn bijvoorbeeld voorkomen bij vertalingen. Essentieel is echter dat de LOI geassocieerd wordt met de hoofdvorm(en).

Het is niet realistisch te veronderstellen dat de gebruiker deze string exact kan reproduceren: veelal kent hij de schrijfwijze en de afspraken niet die gehanteerd worden op het moment van data entry. Daarom bestaan de zoekvormen (soms ook ‘verwante vorm’ genaamd). Deze worden opgesteld vanuit het standpunt van de gebruiker.

Het transformatieproces begonnen bij de hoofdvorm gaat nog verder: eventuele dicacritische tekens worden verdubbeld.

Voorbeeld

Müller heeft als hoofdvorm MUELLER en als zoekvormen MUELLER en MULLER.

De verdubbeling kan verder gaan dan een eenvoudige lexicale transformatie. Soms worden zoekvormen geproduceerd vanuit een databankopzoeking. Dit doet zich onder andere voor bij authority controle.

Het indexeerproces associeert enerzijds zoekvormen met hoofdvormen en anderzijds hoofdvormen met LOIs. Het is precies deze realiteit die de globalstructuur van een index vastlegt.

Met een index object worden diverse eigenschappen geassocieerd:

Identifier
Een unieke roepnaam voor het indexobject.
Verwoording
Een titel voor deze index.
Zoekvorm-naar-Hoofdvorm-global

Een global referentie die de associatie maakt van zoekvorm naar hoofdvorm. Deze globals hebben de volgende structuur:

@ZV2HV@(VV,SORTHV,HVN) = ACDATA
ZV2HV Zoekvorm-naar-Hoofdvorm-global
VV Verwante vorm of zoekvorm (andere benaming)
HVN Hoofdvorm numeriek
SORTHV Sorteervorm van de hoofdvorm binnen de index
ACDATA Deze string is meestal leeg. Is VV echter een authority code, dan staat hier de verwoording van de hoofdvorm (in de taal van de verwante vorm).
Hoofdvorm-naar-LOI-global

Een global referentie die de associatie maakt van hoofdvorm naar LOI. Deze globals hebben de volgende structuur:

@HV2LOI@(HVN) = NUMBER^HV
@HV2LOI@(HVN,SORTLOI,LOI) = DATALOI
HV2LOI Hoofdvorm-naar-LOI-global
HVN Hoofvorm numeriek
HV Hoofdvorm string
SORTLOI Sorteercode bij de LOI (numeriek)
DATALOI Datawaarde bij de LOI
NUMBER Het aantal LOIs bij deze HVN
Sorteervlag
Moeten de hoofdvormen - binnen een zoekvorm - gesorteerd worden?
Stopwoordenvlag
Moeten zoekvormen die stopwoord zijn, gemeden worden?
Lijst met nieuwe indices
Verzamelt de LOIs die nieuwe zoekvormen genereren. Indien de lijstnaam leeg is, worden de LOIs niet verzameld.

6.3. Indexeren van LOIs

Een LOI kan eventueel geïndexeerd worden. De meta informatie voorziet daartoe in 5 velden.

De sorteersleutel generator

Dit is M-code. Na het laden van de juiste variabelen en na uitvoering wordt de sorteerwaarde van de LOI berekend. De sorteerwaarde van een LOI is een string.

Een voorbeeld hiervan bij catalografische beschrijvingen

De sorteerwaarde is de naar hoofletters getransformeerde waarde van de eerste titel van deze beschrijving.

Deze sorteerwaarde wordt steeds omgezet naar een numerieke waarde. Dit getal gaan we in het vervolg steeds aanduiden door SORTLOI.

Een algemene initialisatiestring
Dit is M-code. Telkens een indexeeractiviteit wordt gestart, wordt deze initialisatiestring getriggered. Deze string beschikt over de waarde van de LOI. Dit is een handig mechanisme om neveneffecten te creëeren die dan weer nuttig kunnen zijn. Zo kan hierdoor het indexreservoir meer specifiek gemaakt worden.
De datagenerator

Dit is opnieuw M-code. Na het laden van de juiste variabelen en na uitvoering wordt het dataelement van de LOI berekend. Het dataelement kan om het even welke waarde aannemen. Deze waarde is vooral van belang bij het gebruik van de index. Hij laat toe, om zonder verdere gegevens bij de LOI op te vragen, selecties uit te voeren. Meestal is deze waarde de lege string. Toch kan men, bijvoorbeeld bij bibliografische beschrijvingen, hiervoor beter het jaar van uitgave nemen. De gebruiker van de index kan dan een restrictie formuleren op het jaar van uitgave en de applicatie software kan dan die restrictie uitvoeren zonder verdere data op te vragen.

Een verandering in dit dataelement impliceert wel een aanpassing van alle indices. In het vervolg duiden we deze string steeds aan met LOIDATA.

De indexgenerator

Dit is M-code. Deze routine werkt met de volgende impliciete variabelen:

RDigloi de LOI
RDigact init | next
RDighv index hoofdvorm
RDigvv index zoekvorm
RDiginx index identifier

De indexgenerator werkt in twee fasen:

In de eerste fase RDigact = "init" wordt de indexgenerator geïnitialiseerd. Van dan af genereert hij met RDigact = "next" telkens een nieuw tripel (RDighv, RDigvv, RDiginx) totdat dan de waarden van dit tripel leeg worden.

De indexgenerator is een abstractie van alle indices die relevant zijn voor een LOI. De termen ‘hoofdvorm’, ‘zoekvorm’ en ‘indexidentifier’ worden elders verklaard.

Het reservoir

Dit is een M globalstructuur die de indices bevat die op dit ogenblik geassocieerd zijn met een Brocade beschrijving.

Het reservoir (RSV) heeft de volgende structuur:

@RSV@(LOI,"set") = SORTLOI^DATALOI^INFO
@RSV@(LOI,"set",INDEX,HVN) = SORTHV^HV
@RSV@(LOI,"set",INDEX,HVN,VV) = ""
LOI Library Object Identifier
SORTLOI Sorteercode bij de LOI (numeriek)
DATALOI Datawaarde bij de LOI
INFO Tijdstip ($H) van laatste aanpassing
INDEX Indexidentifier
HVN Hoofdvorm numeriek
HV Hoofdvorm string
SORTHV Sorteervorm van de hoofdvorm binnen de index
VV Verwante vorm van de hoofdvorm

6.4. Aanpassen van een index

Voor de ontwikkelaar bestaat er een eenvoudige interface om een LOI te indexeren: m4\_updIndexLoi(LOI,MODE) past de indices aan bij een gegeven LOI.

De MODE (optioneel, de default waarde is 0) dient om extra aanpassingen mogelijk te maken.

Is deze waarde gelijk aan 2,
dan worden eerst alle oude indices geschrapt (of ze nu moeten blijven of niet) en alle indices terug aangemaakt.
Is deze waarde gelijk aan 1,
dan worden enkel de verouderde indices geschrapt en alle indices aangemaakt.

De werkzaamheden verlopen als volgt:

  1. Het reservoir wordt geupdated: zowel alle te schrappen indices als de nieuwe aangemaakte indices worden gemarkeerd. In deze fase worden de indices zelf niet geraakt.
  2. Alle te schrappen indices worden effectief gewist. Merk op: is de sorteerwaarde van de LOI veranderd of is de datawaarde van de LOI anders, dan worden ALLE indices geschrapt.
  3. Alle nieuw aan te maken indices worden effectief geplaatst in de juiste globals.

6.5. Authority records

Authority records hebben een speciale invloed op de aanmaak van de index. Het principe is dat in het indexupdatingsproces wel de link tussen hoofvorm en LOI wordt gezet, maar dat de link tussen zoekvorm en hoofdvorm door de authority software zelf wordt geregeld. Het is precies deze software die aanpassingen aan de authoritycodes waarneemt en dan de indices kan aanpassen. De authority software beheert ook een geheel van locks (authority code naar LOI naar indexidentifier).

De verwante vormen van een authority code worden berekend tot op het niveu hoofdvormen (terminologie bij authority controle !). Dit betekent dat de authority codes genormaliseerd worden tot de hoofdvormen.

Een paar voorbeelden

a::086:1:E wordt geïndexeerd als a::086:1
a::086:1.1 wordt geïndexeerd als a::086:1

Merk wel op dat er hoofdvormen worden gemaakt voor alle talen.