Buddy-projektet och tillgängliggörandets konst av Martin Olsson

När organisationer ska hitta sätt att hantera den digitala informationens livscykel är det förvisso intressant med abstrakta metoder och konceptuella modeller. Men den arkivarie som förväntas fixa saker behöver verktyg som hjälper till i det konkreta fallet. Här följer ett resonemang med exempel angående tillgängliggörandets konst. 

Vad menar jag då med ’i det konkreta fallet’? Låt mig ta ett exempel. Ett populärt format för det i begynnelsen analoga dokumentet är PDF, med PDF/A-specifikationerna för bevarandeändamål. VeraPDF har via Preforma – ett EU-projekt som riktade in sig på att ta fram open source som validerar filers följsamhet till formatspecifikationer – blivit den kod som validerar PDF/A och därmed anger hur specifikationerna ska tolkas så att det är möjligt att säga bu eller bä till en PDF-fil som utger sig för att vara PDF/A och därmed ha en inneboende tillgänglighet i det långa perspektivet. Enkelt!1 Vi har nått en konkret nivå där vi har ett verktyg som säger ja eller nej på input, och koden kan studeras av alla som har lite tålamod. Det är denna konkretion bevarandelösningar bör ha för att göra verklig nytta av digitaliseringens möjligheter. 

Detta ger några insikter: Organisationen behöver förstå lösningarna på ett konkret plan för att behålla den intellektuella kontrollen över informationen, och för att förstå lösningarna behöver de vara transparenta, det vill säga möjliga att begripa. 

Målet är tillgänglighet 

Jag föredrar att formulera målet med bevarande i termer av tillgänglighet. Om vi funderar en stund över själva processen och vad som krävs för att uppnå tillgänglighet, handlar det inte bara om att tillgängliggöra för konsument, utan även att tillgängliggöra lösningar. En flaskhals har länge varit ETL-biten (extract, transform, load) det vill säga konsten att få ut information från ett system och transformera den för att kunna få in informationen i ett annat system. När jag läste PAIMAS, standarden som beskriver hur lämnande och mottagande system interagerar,2 noterade jag att själva hantverket att ta fram det konkreta leveranspaketet (SIP enligt OAIS)3 lätt kunde gå förlorat i alla detaljerade beskrivningar av vad man generellt ska förhålla sig till. Vem eller vad ska fixa den biten? Hur kan vi samarbeta med ETL-funktionalitet för att få ner kostnaden och uppnå transparens och tillgänglighet? 

FGS buddy – en paketerare 

Dessa frågor har blivit vägledande för Buddy-projektet, som ägnar sig åt att konkret experimentera fram verktyg som underlättar för ETL-biten. Först ut var Viktor Lundbergs FGS Buddy, en paketerare som samlar filer till en SIP enligt FGS-standarden.4 Det är bara att ange paketmetadata i formulärfälten och peka ut filerna som ska ingå, så producerar Buddyn sip.xml-filen och spottar ut paketet på vald plats: 

Fig. 1: FGS Buddys grafiska gränssnitt.

FGS Buddysbuddy – skapa metadatafil 

FGS Buddy förutsätter att metadatafilen redan existerar som XML-fil, (samt förstås att den bevarandelösning man ska importera till har funktionalitet för import av SIP-paket). Därav idén att utveckla metadatatransformeraren FGS Buddysbuddy, som tar fram metadatafilen utifrån en textfil med tillräckligt strukturerad data: 

Fig. 2: FGS Buddysbuddys grafiska gränssnitt.

Som synes utgår Buddy från grafiska gränssnitt. Tanken med det är att fler ska kunna använda verktygen än om de vore textbaserade. Målsättningen är rentav att alla som förstår vilka utmaningar Buddy adresserar ska kunna använda verktygen. En annan målsättning är att fler ska bidra till utvecklingen och ge insikter om vilka behov som finns. 

Jag ska här kort gå in på några tekniska vägval för att  bidra till projektets transparens och förhoppningsvis väcka nyfikenhet. Utgångspunkten, input, är en XML- eller CSV-fil som innehåller det metadata som ska transformeras till en XML-fil som följer ett schema (.xsd).5 Detta görs med Python-bibliotek6 men själva ’hjärnan’ i det hela är den XSLT-fil som styr transformationen och skapar output-XML-filen. XSLT är ett språk för att hantera transformationer från en XML-struktur till en annan.7 I denna tillämpning handlar det om att en XML-fil transformeras med XSLT så att en ny XML-fil produceras. Buddybuddyn kan också validera outputfilen och rapportera eventuella valideringsfel, samt validera filer som är skapade med annat verktyg. 

En fråga jag fått är hur man ska få sin metadata tillräckligt strukturerad för att kunna hantera den på ett strukturerat sätt. Ja, var börjar resan?

Kvalitet 

Men att validera mot ett schema räcker ofta inte till för syftet att kvalitetssäkra sitt metadata. Dels kan du vilja titta på statistik som räknar olika antal och förekomster för att säkerställa att exempelvis antal objekt i input är lika med förväntat antal objekt i output, dels kan du vilja sätta ytterligare affärsregler som schemat inte tar hänsyn till. Kanske får ett värde inte vara ’0’ eller ett ID måste inledas med ett visst prefix. Buddysbuddy tillhandahåller embryonal funktionalitet för dessa scenarier. 8

Mappning 

Frågan blir då hur Buddysbuddy kan hjälpa till att skapa den XSLT-fil som är så central för funktionaliteten. I releasepaketet på Github finns en XSLT-fil i testdatat man kan utgå från som mall, men vore det inte bra om Buddysbuddy kan hjälpa dig att skapa XSLT-filen utifrån din input? Konceptet går ut på att skapa filen i samband med att man gör mappningen: 

Fig. 3: FGS Buddysbuddys grafiska gränssnitt, mappningen som resulterar i en XSLT-fil. Värdena i ’Mappa_från…’ kommer från inputfilen, de i ’Mappa_till…’ från XML-schemat. Du kan skriva in värden manuellt, exempelvis döpa om ’Leveransobjekt’ till ’Kanin’ eller ange ett fast värde att mappa från. Rader kan läggas till (’+Rad’) eller tas bort (’X’), (dock ej de översta raderna av lösningsbegränsande anledningar).

När filen är skapad kan du peka ut den i gränssnittet för att ta fram metadataoutput-filen. Och därefter gå till FGS Buddy för att ta fram SIP-paketet om du vill paketera inför import. 

Buddys framtid  

Utvecklingen är ännu i sin linda och det finns med säkerhet många fler behov att ta hänsyn till. En fråga jag fått är hur man ska få sin metadata tillräckligt strukturerad för att kunna hantera den på ett strukturerat sätt. Ja, var börjar resan? Var kommer metadata ifrån? En möjlig utveckling är att komplettera med anslutningar (”connectors”) för olika databashanterare för att kunna utvinna data direkt från databasen. Men i många fall finns ingen databas. Du har kanske en samling filer som legat på en filserver i 20 år. För ett sådant fall finns det olika metoder för att extrahera metadata från sådant som filer och mappstruktur. Du kan även använda XSLT-filen eller mappningsfunktionen till att ange fasta värden. 

Det finns även jobb att göra med den befintliga koden. FGS Buddy används idag ’på riktigt’ och har därmed nått en tillräckligt hög mognadsgrad för den befintliga funktionaliteten, medan dess spretigare lillebror som gapar efter mycket har en del kända begränsningar. Framför allt utgörs testdatat uteslutande av sådant anpassat för FGS 1.0 för ärendehantering och mappningsfunktionaliteten är ännu inte tillräckligt flexibel. Inte desto mindre erbjuder Buddysbuddy redan i denna tidiga livsform både på funktionalitet och idéer att bygga vidare på. Det är till exempel fullt görbart att ta fram en XSLT-fil i syfte att jobba vidare på den. 

Paketeraren FGS Buddy finns också i en version för Bagit9 och håller i skrivande stund på att utvecklas för att ta fram paket även enligt FGS 2.0. 

Självkritik 

Jag ger två tunga argument till den som vill avfärda Buddysbuddy. Det första handlar om att det grafiska gränssnittet riskerar att falla över sin egen ambition att vara användarvänligt. Att skapa ett grafiskt gränssnitt som tar hänsyn till alla möjliga varianter som kan finnas i ett schema innebär med detta sätt att designa en lång rad av fält för användarinput. Utvecklaren behöver på något sätt förklara vad de är bra för så att användaren kan inspireras till bra input. Exempelvis är det en enkel sak att ge möjlighet att välja sitt eget namespace.10 Men eftersom ambitionen är att någon utan kunskaper om namespace ska kunna ta fram sin egen mappningsfil, blir detta en pedagogisk utmaning. En kanske större utmaning är att ge möjlighet att hantera olika strukturella logiker för inputfilen. Det kan således finnas en punkt där det grafiska gränssnittet säger stopp, men vi är inte där än! Ett sätt att hantera dilemmat med det grafiska gränssnittets otillräcklighet kan vara att tydligt begränsa vilken funktionalitet i ett schema som ska stödjas. Detta kan liknas vid PDF/A-specifikationernas begränsning av PDF-formatet i syfte att stödja idén om långsiktigt bevarande. De scheman jag sett som är framtagna för import av metadata till e-arkiv (inte att förväxla med sådana som ingår i export från verksamhetssystem) är alla enklare än FGS-scheman, och det finns nog en poäng med att ha dem så. 

Det andra argumentet handlar om förvaltning. Även den allra öppnaste kod behöver någon eller något som håller den vid liv. I dagsläget är det inte något akut problem, men i det långa perspektivet behöver förvaltningsbarheten ses över. I den bästa av världar förmår vi kollektivt att samarbeta på ett sådant sätt att koden håller sig levande. I en något sämre värld är det kanske mer realistiskt att tänka sig att Buddy får nöja sig med att vara en kravställare och ett demoverktyg som berättar hur vi vill ha det. Som sådan tänker jag mig att Buddys ande kan transformeras till en tjusigt förpackad produkt med prislapp på. 

Arkivariens verktygslåda och drömmen om en bättre värld 

Vad dessa argument säger mig i förlängningen är att organisationer har allt att vinna på att lära sig det jag kallar för textlekens principer. Det som ligger under huven på Buddy-projektet är nämligen inga konstiga saker eller nya innovationer; de används redan i många av de köpeprodukter som finns på marknaden och av konsulter som anlitas för att hjälpa organisationer med ETL-utmaningar. Gemensamt för dessa är att det handlar om att leka med textbaserade strukturer och utnyttja att informationen inte är instängd eller ostrukturerad. Med andra ord handlar det om att skapa en kedja av tillgänglighet. Buddyn är – til syvende og sidst – bara ett sätt att paketera. Buddy-projektet vill lyfta fram att ett transparent förhållningssätt ger mer kontroll, bättre förutsättningar att välja kvalitet på output och därmed ett sannolikare utfall av tillgänglighet i slutet av kedjan. 

Slutligen, Buddy-projektet är inte de enda hemmasnickrarna därute. Organisationer med en omfattande e-arkivverksamhet har sannolikt tagit fram en del egna verktyg, och många kommunarkivarier har säkert saker i sin byrålåda. 

Låt oss därför öppna våra byrålådor, låt oss testa varandras grejer, låt oss utväxla och utveckla idéer tillsammans! 

Fotnoter

  1. Portable Document Format, PRONOM listar 42 varianter: https://www.nationalarchives.gov.uk/PRONOM/,  Preforma, PREservation FORMAts for culture information/e-archives, var ett av EU-kommissionen medfinansierat projekt som startade 2014 och koordinerades av svenska Riksarkivet. Projektet handlade om att ta kontroll över implementationen av filformatsstandarder genom att bland annat utveckla valideringsfunktionalitet som avgör hur en standard ska tolkas. Upplägget handlade om att para ihop kravställare från institutioner som jobbar med digital bevarande med professionella utvecklare som kan ta fram produkterna:”The overall intention of PREFORMA project is to research critical factors in the quality of standard implementation in order to establish a long-term sustainable ecosystem around developed tools with a variety of stakeholder groups. The tools should be innovative and provide a reference implementation of the most common file format standards for the assessment of the collections to be archived and for the correction of the collections.”,: https://cordis.europa.eu/project/id/619568, https://web.archive.org/web/20230407064555/http://www.preforma-project.eu/index.php VeraPDF: https://verapdf.org/ ↩︎
  2. PAIMAS, Producer-Archive Interface Methodology Abstract Standard:
    https://public.ccsds.org/Pubs/651x0m1.pdf ↩︎
  3. Submission Information Package, det informationspaket som importeras till ett OAIS-system, Open Archival Information System, se https://public.ccsds.org/pubs/650x0m2.pdf ↩︎
  4. Förvaltningsgemensamma specifikationer, ”gemensamma utbytesformat som förenklar en organisations överföringar av information mellan olika elektroniska verksamhetssystem, till e-arkiv och till andra organisationer”,  https://riksarkivet.se/intro-fgs ↩︎
  5. CSV: Comma separated values, även med andra avskiljare brukar det kallas CSV, exempelvis semikolon. Textfil som är strukturerad genom en avskiljare för varje värde och ny rad för varje ’record’.
    XML: Extensible Markup Language, https://www.w3.org/TR/xml/ ↩︎
  6. Python, programmeringsspråk som är ett populärt val bland annat för dataanalys,  https://www.python.org/ ↩︎
  7. XSLT: eXtensible Stylesheet Language, Transformation, https://www.w3.org/TR/xslt-10/ ↩︎
  8. Särskilt spännande i sammanhanget är hur Schematron kan användas, “a rule-based validation language for making assertions about the presence or absence of patterns in XML trees”, https://schematron.com/ ↩︎
  9. https://www.digitalpreservation.gov/documents/bagitspec.pdf ↩︎
  10. Se https://www.w3schools.com/xml/xml_namespaces.asp för förklaring och användning. ↩︎

Från vänster: Viktor Lundberg: Utvecklare FGS Buddy; Martin Olsson: Utvecklare FGS Buddysbuddy

Buddy-projektet på Github: 

Buddy: https://github.com/Viktor-Lundberg/FGSBuddy 

Buddysbuddy: https://github.com/s99mol/FGSBuddysbuddy 

Martin Olsson, projektledare för Buddy-projektet 

Till vardags jobbar Martin sedan tre år tillbaka på Danderyds kommun som IT-arkivarie. Han har varit i branschen i olika roller i drygt 20 år. På sin fritid gillar han att klappa katter, lapa sol och löpa. 

martin@anomali.se