Community på Sveriges dataportal
Samarbete kring Roda (e-arkiv)
-
Hej,
LFV och Sjöfartsverket kommer att använda Roda för e-arkivering (projektledare för e-arkiv på LFV är @Anna_Bayard). Tullverket är redan igång och det verkar vara fler inom den offentliga sektorn som går samma väg, bl a har Polismyndigheten ett seminarium inom kort.
Det vore värdefullt för oss och användbart att få kontakt med andra som använder eller planerar att använda Roda.
Har en del idéer och tankar utveckling av verktyg för att underlätta arbetet för Arkivering och vi kan samarbeta kring dessa istället för att lösa sakerna var för sig?
Så ni får gärna svara här i tråden eller via DM.
Mvh Jimisola
-
@lfvjimisola sa i Samarbete kring Roda (e-arkiv):
Roda för e-arkivering
Har du en länk där man kan läsa mer om Roda?
-
@Ainali https://www.roda-community.org/
Polismyndigheten har som sagt ett seminarium inom kort. Jag har ingen länk men det kanske @Maria_Dalhage @Anna_Bayard
-
@lfvjimisola Tullverket verkar köra Roda enligt https://offentligkod.se
-
-
@Maria_Dalhage sa i Samarbete kring Roda (e-arkiv):
@lfvjimisola Tullverket verkar köra Roda enligt https://offentligkod.se
Ja, det stämmer. Anna har en kontakt med en person där. Ska be henne uppmärksamma honom på denna tråden.
-
@lfvjimisola Af har gjort en utvärdering av Roda. @MalinÅ kanske har mer info.
-
@lfvjimisola Halloj!
Arbetsförmedlingen har utvärderat RODA och genomfört praktiska tester av systemet. Resultatet av testerna var att systemet kunde uppfylla myndighetens krav för ett e-arkiv, däremot har det körts fast om det blir ett införande eller ej.
Men du får gärna höra av dig om ni vill bolla lite tankar och idéer
-
LFV har bestämt sig för att använda Roda och projektet är igång.
Vår arkiveringsavdelning (med @Anna_Bayard i spetsen) har ett behov av att kunna konvertera olika format till arkiv-vänliga sådana.
Det gäller primärt formaten (allt nedan är opensource):
- Office-format till PDF: unoserver (ersatte unoconv och använder LibreOffice för att konvertera dokument till PDF)
- PDF till PDF/A: Ghostscript (open source, stabilt och väl beprövat, skapades 1986 och senaste versionen kom i april i år)
- bilder: ImageMagick
- video: FFmpeg
Vår (lilla) utvecklingsavdelning vill göra det så enkelt för användarna som möjligt dvs det ska gå att göra batcher av konverteringar, se vilka som inte gick igenom (med ev felmeddelande) osv (vi ska sammanstråla för brainstorming krinv behov-/kravanalys nästa vecka). Samtidigt vill vi inte återuppfinna hjulet.
Min första tanke är att det borde finnas något sådant verktyg med Roda men så är kanske inte fallet?
Om det inte gör det så borde det finnas ett liknande behov hos andra Roda-användare och därmed andra inom offentliga sektorn utöver Tullverket som vi har kontakt med.
Om det finns ett gemensamt behov så kanske vi kan skapa en gemensam lösning?
Spontant ser jag några olika varianter (men tar gärna emot andra förslag):
- webbaserad där användaren ladda upp flera filer samtidigt som sedan konverteras och därefter laddas ner som t ex en zip-fil alternativ kopieras till en katalog
- filer läggs i en delad katalog t ex på R: (common) där en integration "skannar" katalogen, konverterar och därefter lägger i en annan katalog
Man kan också tänka sig att kombinera alternativ 1 och 2 dvs filerna läggs i en katalog, konvertering görs osv men att det även går att övervaka via webbgränssnitt.
I förlängningen kanske webbverktyget i sin tur går att integrera mot Roda så att användaren i webbverktyget "skickar" in dokument till Roda.
Webbapplikationen lägger i en Docker container och möjliggör därmed installation i olika miljöer.
Detta är tankarna hittills men vi tar som sagt gärna input från andra kring hur de gör filkonverteringar inför e-arkivering.
Mvh Jimisola
-
@lfvjimisola @Anna_Bayard Verkligen spännande! Många har rimligen samma behov. Kul att ni försöker angripa behovet på ett öppet sätt. Jag funderar på om det finns ett behov av att användaren mycket tidigare i processen kan få stöd med att själv välja ett "bra" format. Om användaren försöker lägga in något i ett e-diarium etc skulle en varningsflagga kunna börja blinka, varpå användaren erbjuds hjälp att lagra dokument i rätt format från början. Dvs att er batch-tjänst kan användas i ett online-scenario också.
-
@jonass Tack. Kul om vi kan samarbeta mer kring utveckling av mjukvara inom offentliga sektorn. Ja, idealiskt läggs så många dokument in rätt från början även om jag tror att en hel del dokument som läggs in i diarie-system är Office-format då det sker löpande editering.
-
@lfvjimisola RODA har kapacitet för plugins gällande konvertering. Osäker på om de plugins som leverantören KEEP erbjuder för konvertering var öppna eller propiertära. Grejen med RODA, vilket är en av sakerna som gör systemet bra, är ju möjligheten att koppla in och ersätta olika plugins för de olika stegen vid leverans och digitalt bevarande. Vi såg det som en stor fördel att över tid byta ut plugins när det kommer bättre eller ändra när vi vill ha en annan åtgärd genomförd.
Frågan om konverteringsverktyg har diskuterats rätt flitigt inom Arbetsförmedlingen då vi varit inne på samma sak som er om att kombinera olika verktyg för att kunna nå en viss helhet i hur vi konverterar. Vi har bland annat kollat på Finland, som har en myndighet för att hantera tjänster kopplat till myndigheters digitala bevarande. De presenterade på en konferens ca 2020/2021 om en tjänst de erbjöd sina myndigheter där beroende på filformat och konverteringsregel anropades ett specifikt konverteringsverktyg (många av dessa var öppen källkod-baserade). Länk till myndigheten i Finland: https://www.digitalpreservation.fi/en, de har inte längre information om konverteringsverktyget vad jag kan se, men det kan vara värt att höra med dom.
Skulle tro att alla myndigheter som försöker hantera bevarande av digital information skulle vara intresserade att vara delaktiga i att använda och förhoppningsvis uppdatera en framtagen funktion för konvertering av olika format. Det svåra här är ju vem eller vilka som har resurser att ta fram en första lösning som de kan dela öppet.
På Arbetsförmedlingen har vi tyvärr inte kommit längre än att vi skissat på en lösning och haft dialog med KEEP. Jag kommer gå över till Försäkringskassan i slutet av året och kan höra mig för där vad som finns och hur de planerar. Tycker det skulle vara av stor vikt att iaf få fram en light version 1.0 som kan byggas på av andra intressenter
-
@lfvjimisola Vad du efterfrågar är ett Pre-Ingestverktyg som väl inte bara konverterar filformat utan också skapar (och validerar) den SIP som e-arkivet ska ta emot, parsa och skapa arkivobjekt utifrån?
Med rätt Pre-Ingestverktyg kan man påbörja arbetet med att skapa SIP-paket utan att ens ha ett e-Arkiv på plats.
Jag tycker att det är genuint synd att Riksarkivets arbete med att ta fram FGS:er helt har avstannat och att ingen driver detta viktiga standardiseringsarbete längre.
För kontinuerliga flöden är det nog vettigt att involvera myndighetens integrationsplattform så att det går att monitorera, övervaka, arkiveringsflödet.
-
@jonass Hej! Det är en jätteintressant tankegång och något som vi har funderat tidigare på inom förvaltningen av LFVs dokumenthanteringssystem. Så arbetet med det här verktyget kan säkert gå hand i hand med kommande kravställning där.
För kännedom så jobbar jag även för Sjöfartsverket, som ingår i Roda-projektet tillsammans med LFV. Där har vi genom ett separat projekt infört begränsning i vilka filer som får läggas in i deras dokument- och ärendehanteringssystem (Public 360), vilket kommer att sparas oss en hel del jobb framöver. -
@Magnus-Sälgö Hos LFV har vi inga regelbundna leveranser till NAD så inget vi funderat på. Men jag tar det med mig!
-
@lfvjimisola Ja precis, vi har ju en automatisk konvertering till PDF/A (utan objektiv validering dock) av officeformat, men det kan nog finnas en hel del konstiga format inlagda iaf.
-
@PerAnd Roda har ett pre-ingest-verktyg som jag tycker är riktigt bra, Roda-In. Det är en separat programvara men man skapar SIP:arna där och sedan går man in i Roda och väljer transfer, hämtar sitt paket och gör resten där. Så det verktyg vi är intresserade av ska endast utföra formatkonverteringen (till en början iaf).
-
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.
