Vad nytt i Buddy-projektet? Att tillgängliggöra tillgängliggörandets konst av Martin Olsson

I förra numret av denna tidskrift skrev jag några rader om Buddy-projektet och dess mål att skapa världsfred i sinnet via ETL för e-arkiveringsändamål.1 Därpå blev jag engagerad i en miniturné runt Sverige som gav goda diskussioner och nya fräscha insikter i den problembild Buddyn verkar inom. Om ni hänger med bortom ingressen så ska jag förtälja några av de intressantaste epistlarna. 

Det mest glädjande är att buddysarna har blivit fler. Det är svårt att räkna oss men vi har definitivt gått från få till fler. Glädjande är också att Buddyn väcker känslor. Katarina Rivera Ahlin, mjukvaruutvecklare på Gislaveds kommun, höjer sin röst mot idén från förra artikeln om Buddyn som förpackad med prislapp: ”Det är väl bättre att vi på kommunerna fortsätter förvalta och utveckla och dela med oss.” Buddy-projektet ser att förutsättningarna för detta är betydligt större nu än förra året. Samtalet är viktigt. Tack alla! 

FGS Buddy 

Den kanske vassaste eggen i Buddyn är paketeraren FGS Buddy som tar fram SIP-paket enligt FGS 1 och BagIt.2 Det är allom bekant att Riksarkivet numera pekar på FGS 2.0 som efterträdare till ettan, varför ett naturligt mål för Buddy-projektet är att utveckla stöd för 2.0. Speciellt relevant har detta visat sig vara då ettan har stött på en del kritiska tungor angående dess tolkningsmöjligheter för hur en lösning kan se ut. Exempelvis finns det exportmoduler som menar att det ska finnas en underkatalog till .zip-paketet och därunder ligger Content-katalogen, Metadata-katalogen och System-katalogen. Metadata-katalogen kan också vara bortrationaliserad på så sätt att innehållet i den i stället ligger i Content. Vid turnéns diskussioner höjdes röster för att sådana tolkningsmöjligheter inte ska vara möjliga längre i och med 2.0 då denna har en bestämdare kravställning. 

Fig 1. visar två i praktiken förekommande varianter av katalogstruktur som enligt leverantören är i enlighet med FGS 1.0. 

Detta är högst välkommet. Det blir förstås mer komplext samt kräver mer resurser och mer av skattebetalarens pengar att ta fram ett verktyg som tar hänsyn till alla möjliga tolkningsmöjligheter hos en specifikation. FGS 2.0 är dessutom ingen nationell specifikation utan den förvaltas inom DILCIS-gemenskapen (se citatet nedan), vilket innebär att komplexitet och resurser bör kunna fördelas från en större kaka. 

På DILCIS webbplats står skrivet: 

“We are the Digital Information LifeCycle Interoperability Standards Board (DILCIS Board). 

We develop, publish and support standards which provide practical interoperability in digital archiving.”3 

Frågan är vilken “practical interoperability” [min kursiv] som DILCIS kan tillhandahålla utan att också utveckla eller låta utveckla ett Buddy-liknande verktyg som fungerar som referens för hur specifikationerna ska implementeras.  

I skrivande stund pågår i Sverige kommersiell utveckling av verktyg anpassade för FGS 2.0. Några har redan sett dagsljuset och fler har säkert gjort det när detta publiceras. I de samtal jag har haft är det tyvärr tydligt att leverantörerna fortsatt ställer sig frågor och har svårt att hitta någon att bolla med. Tydligt är att FGS 2.0 upplevs som en mer komplex specifikation än 1.0. Den som läser E-ARK CSIP ser att katalogstrukturen i SIP:en varierar beroende på hur omfattande paketen är sett till antal representationer och filer, och termerna som ska hjälpa till att balansera hur paketet ska se ut är hela fem stycken: MUST, MUST NOT, SHOULD, SHOULD NOT, MAY.4  

Den uppenbara risken är att de som jobbar på kammaren med lösningar för FGS 2.0 inte i önskvärd omfattning lyckas göra sina lösningar kompatibla med varandra. Detta leder till skräddarsydda lösningar som fungerar bäst utifrån specifik kontext med givna verktyg som ska ”prata” med varandra. 

Det hade således behövts en normerande FGS Buddy 2.0 redan när beslutet fattades. Kanske är RODA-In en sådan normerare, men den är inte tydligt utpekad.5 Den delen av Buddy-projektet som jobbar med paketeringsdelen står alltså inför det något paradoxala faktum att vi borde ha varit klara redan vid startskottet. Rapporten är att vi blir klara senare än så. 

Buddysbuddy då? 

Jo, tack, det går framåt! Lösningen syftar till att skapa den metadatafil som FGS Buddy paketerar. Vi har genomfört tämligen extensiva experiment angående konsten att mappa till mer eller mindre valfritt XML-schema. En insikt vi fick var att lösningen tjänar på att vara så pass flexibel att det är möjligt att knappa in input manuellt oberoende av inputfiler. Ett annat resultat är möjligheten att skapa förälderobjekt till objekt. När ni läser detta är en ny version av Buddysbuddy förhoppningsvis släppt. För den tekniskt intresserade kan jag berätta att utökad flexibilitet är uppnådd genom att en Jinja2-mall tar emot användarens inmatningar och trollar fram XSLT-mappningsfilen.6 

Fig 2. visar Buddsbuddys grafiska gränssnitt med mappningsfunktionalitet och möjligheten att ange förälder till ett objekt. Objekten förvaras i bibliotek i väntan på att användaren klickar på den blå knappen och precis som förut genererar den mappningsfil som sedan används i en annan del av Buddysbuddy för att ta fram metadatafilen. 

Generativ AI och den hemliga planen 

Under resan har generativ AI exploderat och kanske hypemässigt nått sin kulmen. Är det möjligt att ”prompta” fram användbar Buddy-kod? Ja, det är det. Måste man veta vad man håller på med? Ja, det måste man. Så kan mina experiment kort sammanfattas. Du kan alltså ha generativ AI som buddy och bollplank, men det är ”human in the loop”-principen som avgör din lycka.  

Buddy-projektet har en hemlig plan angående den framtida förvaltningen. Vi för diskussioner med sådana som har kommit längre i sin förvaltning av öppen källkod och har bland annat diskuterat vägar för granskning av koden. Att förvalta, utveckla och dela med oss är något vi behöver jobba aktivt med. I dessa tider då AI ofta aningen okritiskt ses som frälsaren för effektivisering och lösningen på det demografiska dilemmat, är det viktigt att framhålla de mänskliga samverkande operativa strukturerna som har potential att tillgängliggöra tillgängliggörandets konst och bygga transparens från grunden. 

Fotnoter

[1] ”Buddy-projektet och tillgängliggörandets konst”, https://arkivit.se/artiklar/buddy-projektet-och-tillgangliggorandets-konst-av-martin-olsson/

[2] FGS: https://riksarkivet.se/arkivera-och-forvalta/medium-och-format/forvaltningsgemensamma-specifikationer/faststallda-fgser,  BagIt: https://www.digitalpreservation.gov/documents/bagitspec.pdf (BagIt-lösningen är dock inte så genomtestad.)

[3] https://dilcis.eu/

[4]E-ARK CSIP, 2024-05-17, ver. 2.2.:  https://earkcsip.dilcis.eu/pdf/eark-csip.pdf s. 19, 28 ff. I brödtexten noterar jag även åtminstone ett ”ought to” (s. 27).

[5] https://rodain.roda-community.org/

[6] https://github.com/pallets/jinja/

Namn: Martin Olsson

Martin har varit i branschen i olika roller i drygt 20 år. På sin fritid gillar han att klappa katter, lapa sol och löpa.