door  Marcel de Rooy

Inleiding
In een vorig artikel schreven we over de eerste tien jaar werken met Koha. Een van de redenen om in 2010 deze open source software bij de Rijksmuseum Research Library in gebruik te nemen was een efficiëntieslag op het vlak van catalogisering. Koha laat immers toe om via copy-cataloging bestaande bibliografische records over te nemen uit andere databases, sommigen gratis (zoals de Library of Congress of de Getty), anderen tegen betaling (zoals Worldcat van OCLC).

In 2011 begonnen we in de Rijksmuseum Research Library met het exporteren van bibliografische gegevens vanuit ons bibliotheeksysteem Koha naar het GGC (Gemeenschappelijk Geautomatiseerd Catalogiseersysteem). Vanuit deze Nederlandse gemeenschappelijke catalogus vond op zijn beurt weer synchronisatie plaats met Worldcat, de wereldwijde catalogus van OCLC. Begin 2021 bevatte Worldcat meer dan 500 miljoen bibliografische records en 3 miljard holdings (exemplaargegevens).

Tegen de achtergrond van de plannen van OCLC om de GGC uit te faseren en onze wens om de kwaliteit van onze records in Worldcat te verbeteren, begonnen wij eind 2020 in samenwerking met OCLC met een project om een directe export vanuit Koha naar Worldcat te realiseren. Wij hadden daarbij nog een belangrijk ontwerpcriterium in gedachten: de oplossing voor deze export moest aansluiten bij het lopende project om een integratielaag tussen verschillende bronsystemen in het Rijksmuseum te bouwen, waaronder Adlib voor de museumcollectie en Koha voor de bibliotheekdata. Deze blogpost vertelt hoe de gekozen oplossing er binnen die architectuur uitziet.

PPN of OCN
Eerst kort even iets over de verschillende identifiers die voor GGC en Worldcat relevant zijn. Records in het GGC hebben een unieke id, die PPN wordt genoemd; dat staat voor Pica Productie Nummer. In Worldcat hebben records ook een uniek nummer; dit wordt OCN genoemd of OCLC Control Number. De synchronisatie van onze records met het GGC was mogelijk door dit PPN op te slaan in onze bibliotheekrecords (voor de liefhebbers: in MARC21 veld 029). Het OCN wordt in MARC21 in veld 035 gezet. Hiermee wordt meteen duidelijk dat de export naar GGC of Worldcat geen eenrichtingsverkeer was of is, maar dat er vanuit OCLC terugkoppeling naar het bronsysteem (Koha) nodig is om de OCLC identifier voor toekomstige synchronisatie in het bronrecord op te nemen. Een stap die wij dus ook moesten zetten om van GGC naar Worldcat te gaan, was een conversie van de PPNs in onze records naar de corresponderende OCNs. Belangrijk om hier nog bij te vermelden is dat records in zowel GGC als Worldcat in principe door bibliotheken worden gedeeld. Een nieuw record van ons kan dus aan een bestaand Worldcat record worden gehangen, waarbij alleen onze exemplaargegevens worden toegevoegd.

Aansluiting op de integratielaag
Het onderstaande schema illustreert in vereenvoudigde vorm hoe Koha als bronsysteem met de nieuwe integratielaag moet communiceren.

Tussen Koha en de componenten van de integratielaag staat een applicatie-adapter. Deze adapter is specifiek voor het bronsysteem en verzorgt alle communicatie. Hierbij wordt gebruik gemaakt van een message queue. Dit is een component die te vergelijken is met een postkantoor. Hij biedt meerdere queues of brievenbussen aan, waar je ofwel een bericht kan achterlaten, ofwel een bericht kan ophalen. Om bijvoorbeeld een OCN in een Koha record te laten wegschrijven, moet er een berichtje met een identifier van een bibliotheekrecord (biblionumber) en een OCLC nummer in een van die queues (brievenbussen) worden geplaatst. De adapter haalt dit bericht op zijn beurt op en verwerkt het.

Wat is het voordeel van zulke adapters? Stel je voor dat wij uiteindelijk een bronsysteem vervangen. Er komt bijvoorbeeld een ander bibliotheeksysteem. Om de aansluiting met de integratielaag te herstellen, hoeven wij er ‘alleen’ voor te zorgen dat het nieuwe bronsysteem berichten aan de message queue kan doorspelen en dat de adapter verzoeken om bronrecords te wijzigen correct aan het bronsysteem doorgeeft. De rest van de integratielaag blijft gewoon op de geëigende manier met de adapter praten en hoeft (in principe) niet te worden aangepast.

Van twee scripts naar 10+ stappen
Het volgende diagram schetst hoe wij de export naar Worldcat uitgewerkt hebben met de bovenstaande aansluiting op de integratielaag in gedachten:

Je ziet nu drie componenten tussen Koha en Worldcat; de pijlen zijn in de belangrijkste richting getrokken, maar voor het terugkoppelen van het OCN naar Koha volgen wij dezelfde weg terug. Wij zien de Koha adapter, een message queue (SMQ) en een derde component (Exchanger).
Terwijl wij vroeger eigenlijk maar twee stappen hadden: 1) export naar GGC met bijbehorend script/programma en 2) import van PPN met een tweede script, onderscheiden wij nu elf stappen: acht stappen in de ene richting en drie stappen in de andere. Wij zouden daarbij aan een pijpleiding kunnen denken waar data doorheen stroomt. Wij geven straks een kort overzicht van die stappen en noemen enkele highlights.
Waar zit het verschil tussen de Koha adapter en Exchanger? De Koha adapter voert algemene stappen uit en zorgt ervoor dat te exporteren data beschikbaar komt via de message queue. De Exchanger zou je feitelijk met een component in de integratielaag kunnen vergelijken. Hij praat met Koha via de adapter en message queue. Hij voert specifiekere stappen uit om data voor Worldcat aanvaardbaar aan te bieden. En hij communiceert dus met Worldcat; dat doet de Koha adapter niet. Technische noot: de communicatie met de GGC liep via het FTP protocol; voor Worldcat gebruiken wij het veiligere SFTP protocol. 

Met zevenmijlslaarzen naar Worldcat
Nadat Koha voor iedere wijziging van een bibliografisch record of een exemplaar (item) record met behulp van een Koha plugin een bericht in de export queue van de adapter heeft geplaatst, volgen er nog acht stappen: vier stappen in de adapter en vier in de exchanger.
Eerst kopieert de adapter het bericht naar een backup queue (voor incidentele recovery) en verplaatst het naar de queue van stap 2; in die stap wordt het aantal berichten dat op hetzelfde record betrekking heeft tot één teruggebracht (meerdere wijzigingen zijn voor dit proces feitelijk één grote wijziging). Daarna wordt het MARC record met alle items uit Koha gedownload en in een bericht gezet. In de vierde stap vindt opnieuw distributie plaats: het bericht wordt gekopieerd naar de integratielaag queue én naar de exchanger queue.

Welke stappen kent de Exchanger? Kort gezegd: [1] validatie, [2] cleanup, [3] build en [4] upload. Tijdens de validatie worden records die nog niet aan de export criteria voldoen uit de queue verwijderd; bijvoorbeeld bestelrecords gaan nog niet naar Worldcat. Afhankelijk van de reden wordt een waarschuwing gemaild. Bij cleanup worden alleen kleine cosmetische ingrepen op het record uitgevoerd; eventuele GGC identifiers worden bijvoorbeeld verwijderd. De build stap produceert drie bestanden: een bestand met alle verwijderde records, een bestand met gewijzigde records (d.w.z. records met een OCN) en een bestand met nieuwe records (die geen OCN bevatten). De bestanden zijn momenteel in MARC of ISO2709 formaat; OCLC werkt aan ondersteuning van MARCXML formaat. Tenslotte vindt de SFTP upload naar een OCLC server plaats.

De reis van een OCN terug naar Koha
Nadat wij een record aan Worldcat hebben aangeboden, krijgen wij binnen 1 of 2 dagen een automatische response van de OCLC server. In de vorm van verschillende reports die wij via STFP kunnen downloaden. De Exchanger kijkt iedere dag op de OCLC server of er nieuwe te verwerken reports zijn. In de tweede stap worden sommige reports naar medewerkers van de Bibliotheek gemaild. Een van die reports vermeldt bijvoorbeeld de eventuele fouten die in onze records zijn geconstateerd en nog handmatige aandacht behoeven. Vanzelfsprekend is dat een uiterst gering aantal. Voor synchronisatie interessanter zijn de reports die de koppeling tussen het Koha record en Worldcat bevatten. Deze bestanden worden automatisch door de Exchanger ingelezen; voor iedere combinatie van Koha identifier en OCN wordt een berichtje in de adapter import queue geschreven.
De derde en laatste stap wordt nu weer in de Koha adapter gezet. Deze leest de import queue in en verwerkt berichten met OCN updates door voor iedere OCN automatisch een webrequest naar de Koha server te sturen. Dit service-script in Koha past de OCN aan, als die niet al in het record voorkomt, en retourneert de uitkomst van die actie aan de adapter. En daarmee is de cirkel rond.
Nog een kleine wetenswaardigheid over deze laatste actie: conform het bovenstaande betekent het wegschrijven van een OCN in een Koha record dat het record weer wijzigt en dat er dus opnieuw een berichtje in de export queue wordt gezet. Dit is natuurlijk niet nodig; als dit de enige wijziging is, dan hoeft er geen export plaats te vinden. Om een dubbele export te voorkomen, schrijft de adapter een extra berichtje in de export queue. Een zogenoemde unmodify message vertelt de adapter om de laatste modificatie van dat specifieke biblotheekrecord tijdens de volgende export te negeren (en ook alleen de laatste).

Lessons learned
Het vervangen van twee grotere scripts voor import en export door code die meer dan 10 stappen ondersteunt verspreid over verschillende componenten, heeft voor- en nadelen.
Na de eerste volledige upload en incrementele update waren er de nodige foutmeldingen uit Worldcat. Ze brachten kleine(re) datafoutjes in het bronsysteem aan het licht. Gedurende dit project was er de gelegenheid om meer aandacht te geven aan de reports dan voorheen aan de GGC terugmeldingen. Dat betekent uiteraard wat meer werk maar de data wordt zo tegelijkertijd wel op een hoger niveau gebracht.

De code voor synchronisatie met het GGC werd in 2011 geschreven en van tijd tot tijd aan veranderingen in de omgeving aangepast. De tijd om dergelijke code te onderhouden neemt daardoor langzaam af. De complete refactoring zoals hier beschreven is een kwaliteitsimpuls waarbij de onderhoudbaarheid weer aanmerkelijk is toegenomen.
Omdat het proces nu in veel kleine stappen is opgebroken, kunnen individuele stappen nu getest en gemonitord worden; dat is een voordeel. Aan de andere kant is de totale constructie hierdoor wel complexer geworden; wij hebben nu drie extra componenten met elk hun eigen parameters. Wil je in het proces ingrijpen, dan is het wel noodzakelijk om een goed beeld van het totaalplaatje te hebben, hetgeen het belang van documentatie uiteraard onderstreept.

De belangrijkste voordelen liggen mijns inziens in het losweken van hele proces van het bronsysteem (Koha) en de onmiddellijke mogelijkheden om de data in de integratielaag te gebruiken. De afgenomen afhankelijkheid van het bronsysteem maakt een migratie naar een ander systeem mogelijk zonder dat het hele proces moet worden herschreven. De componenten dienen nu niet alleen in de dataflow naar Worldcat maar zijn multifunctioneel, inzetbaar in de koppeling naar de integratielaag. Een voorschot op de toekomst!