Samarbete kring Roda (e-arkiv)
-
Hej, nu är jag också här. Jag är IT-arkivarie på Tullverket. Det är ju vi som är igång med RODA. Jag ska titta på inläggen och se om det är något jag kan bidra med.
/Sven Jonsson -
Jättekul att intresset för RODA växer! Bara några inledande kommentarer som kanske reder ut några funderingar. Kanske en del självklarheter, men ändå:
De verktyg i RODA-familjen som är centrala är
RODA - ett e-arkiv som bl a kan- ta emot och validera SIP i några olika internationella paketstandarder E-ARK och BagIt. E-ARK som vi använder, bygger på metadatastandarder EAD, EAC, METS, PREMIS. Ett självklart val tycker vi, särskilt som EU-medlemsland och i synnerhet som statlig myndighet.
- validera paketen bl a utifrån kontrollsumma, metadatainnehåll, struktur mm utifrån standard (och ev egen konfiguration)
- lagra, söka, visa, förvalta, gallra,
- skapa och hantera flera behörighetsnivåer ner till paketnivå
- möjliggör uppdatering av paket och paketmetadata (för den med rätt behörighet)
- viruskontroll vid Ingest är konfigurerbart
Det och mycket annat är vad RODA gör i grunden.
Observera att valet av RODA också innebär ett val av paketstandard (metadata och paketstruktur) för e-arkiverad information. Vilket ju är en bonus!
Valet av RODA är i sig ganska enkelt. Men Pre-Ingest är (som vanligt) den stora tröskeln när det gäller e-arkivering. Man behöver börja titta på hur man vill att e-arkivering ska gå till. Vad ska e-arkiveras? Vem ska göra det? Hur ska det gå till? När man har behoven och den önskade processen klar för sig kan man börja titta på Pre-Ingest-verktyg.
Till RODA behövs Pre-Ingestverktyg för att skapa SIP med önskade metadata. I RODA-familjen finns ett Pre-Ingestverktyg för det - RODA-In - som är en klientprogramvara för "manuell" e-arkivering där man kan berika SIP med metadata. Dvs skapa arkivpaket av filer/filkataloger/filstrukturer. Om det är arkivering av "dokumentfiler" som är behovet så uppfyller RODA-In i princip behovet av Pre-Ingest.
Om behovet är att e-arkivera uppgifter ur tabeller i databaser som "ärenden" (paketeras som t ex E-ARK), så behöver man skaffa eller bygga en pre-ingestfunktion med någon variant av ETL-programvara (särskilt Extract och Transformation). Detta ligger alltså helt utanför RODA. Här finns hur många vägar som helst att ta.
Open source, kanske Talend eller liknande.
Prioprietär programvara som MS SSIS, kanske i kombination med MS Power BI, kanske Informatica etc. Vilken väg man tar avgörs bl a av- Hur man vill arbeta och vilka behov man har (t ex grafisk dataanalys eller inte)
- Vad det får kosta
- Vad som ev redan finns i organisationen som går att använda
- Den tekniska miljön och vad som fungerar ur det perspektivet.
- Kunskap och resurser i organisationen
Vi använder MS SSIS och en serie egenutvecklade script som kör hela ETL-processen från hämtning ur datakällan till inlastning av färdiga SIP i RODA. Vi hade hellre använt open source här också, men det var så det blev av bl a tids- och ekonomiska skäl och vad som fanns i organisationen.
Om behovet är att e-arkivera uppgifter ur databaser i tabellform så kommer vi in på andra standarder och andra verktyg i RODA-familjen:
Format för databasarkivering: SIARD-formatet som bygger på sql
DBPTK Developer för att skapa avgränsade databasuttag i SIARD-format (text)
DBPTK Desktop för att visa, söka och validera arkiverade tabeller
DBPTK Enterprise för att visa, söka och hantera olika databaser, behörigheter mmSå, vi har alltså i fallet databasarkivering två möjligheter:
- e-arkivera som tabeller (databas som SIARD-fil) eller
- e-arkivera som ärenden (E-ARK).
Vi använder båda, utifrån sökbehoven i varje enskilt fall.
Båda varianterna e-arkiveras i RODA (som E-ARK-paket). DBPTK används för visning av SIARD-paket. (Uppdatering av RODA/DBPTK lär möjliggöra visning av SIARD-filer i DBPTK direkt ur RODA. )
Filkonverteringsverktyg hanteras också helt utanför RODA. Välj själv bland verktyg som funkar för dina behov bland verktyg som går att köra som plug-in i RODA. De som anges i ett inlägg av @lfvjimisola ovan är de som vi har valt för våra behov.
Sist men inte minst tänker jag nämna att man bör ha en generell informationsmodell för de paket som e-arkiveras. Det är ju långsiktig sökning som är kärnan i ett e-arkiv. Utan en generell och långsiktig sökmöjlighet (samma metadatauppsättning till alla paket) så har man bara ett antal stuprör som blir svåra att använda. Så en rekommendation är - oavsett vilken e-arkivlösning man har - att definiera en metadatakatalog som alltid tillämpas när man skapar SIP. Och att man konfigurerar RODA (och RODA-In om man vill använda den) med motsvarande metadataformulär.
Långt inlägg :-). Sorry. -
@lfvjimisola Nej, RODA kommer inte med något färdigt konverteringsgränssnitt.
Jag är inte tekniker, så jag borde kanske hålla mun. Men de alternativ du skissar på pekar i mina ögon mot någon form av arkiveringsbehov där olika roller (handläggare mm) manuellt ska välja ut filer för konvertering och arkivering.
Tänker du att det är ett försteg för att skapa filer/kataloger som man sedan kan köra RODA-In mot? Så kan det vara.
Men det förutsätter nog i de flesta fall att man tar omhand/skapar någon form av metadata redan i försteget som gör att man ser vad en fil har för sammanhang (t ex ett ärende eller en filkatalog strukturerad utifrån t ex tidsomfång). Gränssnittet skulle behöva ett tvingande metadataformulär (e-arkivets metadatamodell) som styr lagringsstrukturen, tillsammans med kunniga användare, så att det inte bara blir en hög blandade filer.
Vilken informationsstruktur ska filerna in i?- En SIP per tidsomfång med alla filer i tidsomfånget?
- En fil per SIP?
- Ärende-SIP med vissa tillhörande filer per SIP?
- Annat?
- Olika beroende på? Hur?
Den snåriga delen är hur man skapar "rätt" datastruktur och sökbarhet (metadata). Där behöver både den informationsskapande verksamheten och arkivet säga hur det ska vara. En generell informationsmodell bör ligga till grund för det, som alla leveranser kan mappas mot.
Konverteringsbehoven och målen är ju väldigt olika, även om det övergripande målet är detsamma...
-
Hej alla!
Jag jobbar med införande av e-arkiv i en väldigt liten verksamhet som jobbar mot enskilda arkiv. Väldigt värdefullt för mig att kunna ta del av den här tråden.I dagsläget har jag demo-versionen av Roda och Roda-in för att testa och förbereda. Har inte någon egen IT-avdelning utan driftar hela vår IT-infrastruktur med hjälp av ett konsultföretag. De har varit toppen att jobba med och jag har en modern hantering av hela vår infrastruktur i molntjänster vilket har många fördelar för vår verksamhet.
Toppen så långt och här kommer nu min fråga: Vi har haft svårigheter med att ladda ner och installera Roda i vår miljö (Azure). Keep kan vara behjälplig men säljer såklart den tjänsten men med ett minimum av 40 timmar. Det blir ganska mycket pengar för oss. Är det er bedömning att man behöver köpa den hjälpen från Keep för att klara installationen av Roda?mvh Carina
-
@svenTV sa i Samarbete kring Roda (e-arkiv):
@lfvjimisola Nej, RODA kommer inte med något färdigt konverteringsgränssnitt.
Jag är inte tekniker, så jag borde kanske hålla mun. Men de alternativ du skissar på pekar i mina ögon mot någon form av arkiveringsbehov där olika roller (handläggare mm) manuellt ska välja ut filer för konvertering och arkivering.
Tänker du att det är ett försteg för att skapa filer/kataloger som man sedan kan köra RODA-In mot? Så kan det vara.
Men det förutsätter nog i de flesta fall att man tar omhand/skapar någon form av metadata redan i försteget som gör att man ser vad en fil har för sammanhang (t ex ett ärende eller en filkatalog strukturerad utifrån t ex tidsomfång). Gränssnittet skulle behöva ett tvingande metadataformulär (e-arkivets metadatamodell) som styr lagringsstrukturen, tillsammans med kunniga användare, så att det inte bara blir en hög blandade filer.
Vilken informationsstruktur ska filerna in i?- En SIP per tidsomfång med alla filer i tidsomfånget?
- En fil per SIP?
- Ärende-SIP med vissa tillhörande filer per SIP?
- Annat?
- Olika beroende på? Hur?
Den snåriga delen är hur man skapar "rätt" datastruktur och sökbarhet (metadata). Där behöver både den informationsskapande verksamheten och arkivet säga hur det ska vara. En generell informationsmodell bör ligga till grund för det, som alla leveranser kan mappas mot.
Konverteringsbehoven och målen är ju väldigt olika, även om det övergripande målet är detsamma...
Ja, vi tänker oss ett konverteringsverktyg av diverse format (initialt Office och PDF till PDF/A).
Har kommit en bit på vägen nu och skriver om det i nästa post. -
Nu har vi tagit fram en Docker image med konvertingsverktyg för
- Office-format till PDF: unoserver (LibreOffice)
- PDF till PDF/A: Ghostscript
- bilder: ImageMagick
- video: FFmpeg
samt valideringsverktyget veraPDF (båda implementationerna dvs Greenfield och PDFBox).
Härnäst är tanken att implementera en Java-backend som mikrotjänst som styrs av användaren genom en webbaserad frontend.
För att spara tid och undvika att återuppfinna hjulet så undrar jag om någon har kommandorad(er) samt eventuellt tillhörande definitionsfil för Ghostscript för konvertingar av PDF till PDF/A-1A samt PDF/A-1B? I så fall mottages den tacksamt.
Mvh Jimisola
-
@lfvjimisola Den här tråden på stackoverflow kanske är till hjälp: https://stackoverflow.com/questions/1659147/how-to-use-ghostscript-to-convert-pdf-to-pdf-a-or-pdf-x
-
@Linus sa i Samarbete kring Roda (e-arkiv):
@lfvjimisola Den här tråden på stackoverflow kanske är till hjälp: https://stackoverflow.com/questions/1659147/how-to-use-ghostscript-to-convert-pdf-to-pdf-a-or-pdf-x
Tack men jag har koll på den tråden men den har några år på nacken och fanns det något som garanterat fungerar och går igenom validering så hade det besparat mig lite tid.
-
@lfvjimisola Hallå där, ni måste så klart arkivera i arkivbeständiga format men jag undrar om ni också kommer spara i originalformatet? Man dödar mycket användning om man byter till pdf till exempel.
-
@Björn-Hagström sa i Samarbete kring Roda (e-arkiv):
@lfvjimisola Hallå där, ni måste så klart arkivera i arkivbeständiga format men jag undrar om ni också kommer spara i originalformatet? Man dödar mycket användning om man byter till pdf till exempel.
Vet ej. Det är inte mitt ansvarsområde utan arkiverings.
-
@lfvjimisola Hej, vi på SIS analyserar nu förutsättningar för Roda e-arkiv och vi tar gärna en fortsatt kontakt med er om detta.
-
Vi på Tillväxtverket arbetar med att utvärdera lösningar för e-arkiv. Vi har ett beslut om att välja lösning baserad på öppen källkod. RODA är en stark kandidat.
Vi är nyfikna på hur långt andra myndigheter har kommit i sitt arbete med RODA. Kan ni hjälpa mig att sammanställa:
- vilka myndigheter utvärderar RODA inför ett beslut om införande?
- vilka myndigheter inför just nu RODA?
- vilka myndigheter använder RODA i produktion?
Om det är känt – är det RODA4 eller RODA5?
Hälsningar
Alf Persson, Tillväxtverket, projektdeltagare e-arkiv -
@alfp Arbetsförmedlingen utvärderar i skrivande stund RODA. Och har publicerat följande: Strategiska vägval för e-arkiv och digital informationshantering | Arbetsförmedlingen (Denna hittar du under https://nosad.se/tips).
Fler och fler myndigheter använder offentligkod.se för att visa vilka öppna programvaror man använder och på så sätt hjälpa andra organisationer med att välja det öppna alternativet. Söker du på Roda finner du Tullverket, LFV, Sjöfartsverket. Men som framgår av denna tråd bubblar SIS och Arbetsförmedlingen också.
-
@Maria_Dalhage Tack för svar!
Jag gör ett taffligt (?) försök att själv sammanställa:
Jag har lagt till Försäkringskassan som vi vet arbetar med RODA, Kronofogden som vi "hört" gör det och så förstås oss själva
För oss är det bra info att ha inför beslut. Våra ingångsvärden är bl a öppen källkod och att flera andra myndigheter använder produkten.
Så vi tar tacksamt emot korrigeringar/kompletteringar av tabellen ovan.
