37. Systematisch consolideren in Brocade

Auteur Richard Philips
Aanmaak 07 nov 2009
Aangepast door Jef Tegenbos
Aangepast op 16 december 2015
Oud BVV nr 2240

37.1. Abstract

Dit document beschrijft hoe systematische consolidatie in Brocade werd geïmplementeerd. “Consolidatie” is het samenvoegen van twee gelijkaardige records. Met systematische consolidatie wordt bedoeld: de procedure om systematisch mogelijke dubbele records op te sporen, en om die mogelijke dubbels paarsgewijs aan de catalograaf aan te bieden ter consolidatie, op basis van een lijst.

37.2. Inleiding

Deze inleiding beschrijft de krachtlijnen van de uitgewerkte procedures.

Recordtypes
De uitgewerkte procedure is inzetbare op elk recordtype dat overeenkomt met een LOI. De meta-informatie bij de LOI zijn bepalend voor een correct uitvoeren van de consolidatie. Het samensmelten van twee records kan enkel indien de records van hetzelfde recordtype zijn. In de voorbeelden wordt er vooral aandacht geschonken aan de consolidatie van catalografische records. Dit is enkel omdat daarvoor de specifieke software verder is gevorderd. Dezelfde procedures kunnen ook worden gevolgd door om a-lois, e-lois, isad-lois, poster-lois, ... te consolideren.
Visuele consolidatie
Deze BVV behandelt niet het specifieke algoritme om de consolidatie uit te voeren: dit is LOI specifiek. In deze BVV worden de procedures beschreven die visueel ondersteunde consolidatie mogelijk maken en ondersteunen.
Sleutelverzamelingen
Het geprefereerde werkpaard van Brocade operaties zijn lijsten. Lijsten zijn echter sequentiële opsommingen van singletons. Voor consolidaties hebben we echter koppels nodig. Om deze zorgvuldig te kunnen beheren gebruiken we sleutelverzamelingen. Dit zijn verzamelingen (van sleutels) die een naam (een identifier) toegewezen krijgen. Met deze naam worden dan verschillende eigenschappen gekoppeld die het consolidatieproces stroomlijnen.
Sleutels
Het centerpunt van alle consolidatiebewerkingen zijn de sleutels. Dit zijn de elementen van een sleutelverzameling. Met deze sleutels worden dan records geassocieerd. Deze records zijn dan kandidaten om te worden geconsolideerd. Deze consolidatie geschiedt pas na visuele bevestiging. Vanzelfsprekend kan deze visuele confirmatie worden overgeslagen. Daarvoor bestaat er reeds software (zie het manueel proces: %UcoLst^bcascon) en valt buiten de scope van deze BVV.

37.3. Sleutels

Sleutels worden toegevoegd aan sleutelverzamelingen. De fysieke opslag van deze sleutels wordt geregeld via de macro addConsKeysetRecord (beschreven in /catalografie/consolidate/merge.d) en is gebaseerd op de meta-informatie van de LOI horende bij de record.

Een sleutel bestaat uit 2 componenten:

Vaste component
Dit is het belangrijkste onderdeel: enkel LOIs met dezelfde vaste component komen in aanmerking om te worden geconsolideerd. Hoe groter het onderscheidend vermogen hoe minder LOIs er zullen zijn met deze sleutel en hoe minder koppels er moeten worden bekeken (denk aan het kwadratisch effect !). Een goed voorbeeld bij bibliografische beschrijvingen is een ISBN
Dynamische component
Soms zijn er attributen van een record die een uitstekend onderscheidend vermogen hebben maar ook erg foutgevoelig zijn. Een goed voorbeeld bij bibliografische beschrijvingen is het aantal pagina’s van een boek. Afhankelijk van de catalografische regels kan hier wel wat speling opzitten. In de Brocade consolidatie kan dit worden behandeld door dit attribuut los te maken van de vaste component. Bij de meta-informatie van de sleutelverzameling wordt dan omschreven hoe met variaties op deze waarde om te gaan. In het gegeven voorbeeld kunnen we zeggen: indien de paginering slechts 10 pagina’s verschilt, wordt het koppel toch aangeboden ter consolidatie. Ten overvloede wordt hier benadrukt, dat de consolidatie pas wordt uitgevoerd na VISUELE controle en EXPLICIETE goedkeuring. Zou men deze dynamische component NIET opnemen, dan zou er geen rekening worden gehouden met de paginering en stijgt het aantal aangeboden koppels kwadratisch!

Het algoritme om sleutels te produceren valt buiten de scope van deze BVV. Ze zijn niet alleen LOI afhankelijk maar ook de context kan bepalen welke sleutels effectief zijn. In /catalografie/consolidate/bccsisbn.m werd een voorbeeld uitgewerkt dat alle elementen toont om een sleutelverzameling te vullen.

37.4. Sleutelverzamelingen

In de vorige paragraaf werd voldoende benadrukt hoe belangrijk het is om de sleutel zo onderscheidend mogelijk te maken. Er zijn echter situaties waarbij dit zeer moeilijk is. Een goed voorbeeld is het opladen van een collectie beschrijvingen in een bibliografische catalogus waarbij de nieuwe beschrijvingen substandaard werden beschreven. Deze paragraaf beschrijft welke instrumenten er zijn in een sleutelverzameling om toch te kunnen werken met weinig selectieve sleutels.

Beperk de verzameling LOIs
Dit is een vrij triviale opmerking maar desalniettemin belangrijk: het heeft geen zin om bij een consolidatie van boeken ook sleutels te genereren voor artikels.
Meta-element max
Sleutels die meer koppels opleveren dan deze waarde worden geschrapt uit de sleutelverzameling. Steeds invullen! Sommige sleutels geven nu eenmaal dramatisch veel LOIs. Voorbeeld: stel een sleutel gebaseerd op auteur die de (authority)waarde n.a. oplevert.
Meta-element dist
Dit is een algoritme die de ‘afstand’ berekent tussen de dynamische componenten van de sleutels. Hoe strenger dit algoritme is, hoe minder koppels er zijn.
Meta-element filtera en filterb
Deze voorwaarden leggen beperkingen op aan de LOIs die worden gekoppeld (de volgorde speelt geen belang). Bij een upload van een externe catalogus kan de eerste filter enkel de ‘oude’ records weerhouden en de tweede filter enkel de ‘nieuwe’ records. Op deze wijze worden enkel de externe records vergeleken met de bestaande records
Het geheugen van verschillende records
Hoewel dit geheugen onafhankelijk opereert van de sleutelverzameling is het een belangrijk hulpmiddel om maar 1 keer met een koppel te worden geconfronteerd
Catalografische beschrijvingen: verschillende record

Speciaal voor catalografische beschrijvingen kan men ook passende meta-informatie invullen op het niveau van het regelwerk: men kan daar een algoritme invullen dat aangeeft wanneer een koppel verschillend is. Dit kan bijvoorbeeld worden gebruikt in een VLACC context: 2 beschrijvingen zijn verschillend indien ze een verschillend VLACC nummer hebben.

Hoewel dit systeem specifiek is voor catalografische beschrijvingen kan dit vanzelfsprekend worden uitgebouwd voor andere LOI types

Sleutelverzamelingen hebben nog andere meta-informatie. Deze dienen om het effectieve werk mogelijk te maken en te controleren:

Meta-element loi
Dit element bevat het LOI type. vandaar wordt het mogelijk om de passende meta-informatie op te sporen op LOI niveau
Meta-element master
Dit is een algoritme die een ‘master’ kan kiezen uit een koppel. Naargelang de interface (LOI specifiek) kan de rol van master en ‘slave’ nog worden gewisseld.
Meta-element acckey
De toegangssloten bepalen die toegang hebben tot een sleutelverzameling. Deze toegangssloten geven enkel consolidatierechten binnen deze sleutelverzameling, en niet elders in catalografie.
Meta-element list
Een template voor de lijst waarin de masters worden genoteerd
Statistieken
Deze geven allerlei informatie over de sleutelverzameling. Deze statistieken worden NIET aangepast gedurende de werkzaamheden: de herberekening moet expliciet worden aangevraagd door het aanstippen van de checkbox
Gebuikerstatistieken
Deze geven allerlei informatie over de werkzaamheden van het personeel. Deze statistieken worden WEL aangepast gedurende de werkzaamheden. Stel dat de sleutelverzameling wordt hergebruikt dan worden deze statistieken NIET geschrapt. Ook dit moet expliciet gebeuren door aanstippen van de passende checkbox

37.5. Procedures

Een aantal sleutelverzamelingen dienen te worden gedefinieerd en te worden gevuld met passende sleutels en dit in samenwerking met het automatiseringsteam. De algoritmes om deze sleutels te beheren kunnen het best worden bewaard onder de vorm van manuele procedures.

Het uitvoerend personeel krijgt een overzicht te zien van de hem toegewezen sleutelverzamelingen. Na selectie van een passende sleutelverzameling wordt er achter de schermen een random sleutel uit deze verzameling gegenereerd en ALLE koppels worden dan op visuele wijze aangeboden aan het personeelslid. Deze specifieke interface moet dan toelaten om te consolideren, dit koppel te markeren als verschillend, of niets te doen.