REFERANSE: DATO: VERSJON: ANSVARLIG: [Skriv inn referanse] 14.04.2016 1.0 Marte Brekke Rapport
Innhold 1 Innledning... 3 1.1 Bakgrunn... 3 1.2 Dagens OEP-løsning... 3 1.3 Mål for POC... 3 1.4 Rapportens struktur... 3 2 Konsept... 5 2.1 Arkitektur benyttet i POC... 5 2.1.1 Publish-subscribe modellen... 5 2.1.2 SDShare... 5 3 Løsning... 6 3.1 Informasjonsarkitektur... 6 3.2 Validering av data... 6 3.3 Dataflyt... 7 3.4 Skjerming... 9 4 Funn... 11 4.1 Testbeskrivelse... 11 4.2 Funn... 11 4.2.1 Økt datamengde... 11 4.2.2 Bedre kontekstforståelse... 12 4.2.3 Validering... 13 4.2.4 Noark 4 vs. Noark 5... 13 4.3 Konflikterende journalposter... 14 5 Gevinster... 16 5.1 Gevinster ved løsningen... 16 5.2 Gevinster ved videreutvikling av OEP... 17 6 Konklusjon... 19 7 Referanser... 20 Rapport 27.01.2014 Side 2 av 20
1 Innledning 1.1 Bakgrunn Høsten 2015 startet Riksarkivet en pilot med Sesam-plattform, som er basert på W3C sin RDFstandard og semantisk teknologi, til løpende overføring av arkivmateriale mellom Riksantikvaren og Riksarkivet. Denne piloten settes i produksjon april 2016. Difi ønsker i denne POC en å teste Sesam som plattform for innsamling av arkivjournaldata til Offentlig Elektronisk Postjournal (OEP). Testinstallasjonen baseres på løsningen som Bouvet har tilpasset for løpende overføring av arkivdata fra Riksantikvaren til Riksarkivet. Løsningen skal benytte data fra Riksantikvaren. 1.2 Dagens OEP-løsning Dagens løsning går ut på at innholdsleverandørene/arkivskaperene laster opp en journalpostrapport over forrige ukes journalposter i xml-format, i OEPs publiseringsløsning. Formatet på filen skal støtte krav til filformatet som beskrevet i Noark 4.1, kapittel 15 1. De ulike postjournalene blir samlet i en felles database som er gjort søkbar for brukerne. Brukerne kan søke etter informasjon gjennom OEP og bestille innsyn i den informasjonen de finner interessant. Denne bestillingen blir sendt til den virksomheten som er ansvarlig for journaloppføringen. Deretter blir bestillingen behandlet av virksomheten som et innsynskrav, og brukeren får svar direkte fra virksomheten. 1.3 Mål for POC Dagens løsning med overføring av journaldata til OEP krever flere manuelle operasjoner. Det er satt i gang et arbeid med å erstatte dagens løsning med ny infrastruktur, for å oppnå mer automatisering og effektivisering. Ny løsning skal produksjonsettes i årsskriftet 2017/2018. Denne POC en er et ledd i dette arbeidet. Målet for ny OEP-løsning (heretter kalt einnsyn), er for det første å få på plass en sikker og effektiv infrastruktur, som automatisk samler inn arkivdata fra 120 statlige virksomheter. I dag er det årlig snakk om omkring 3 millioner journalposter. Det andre sentrale området er å åpne for publisering av dokumentfiler. I dag er det få dokumenter som blir publisert som del av OEP. Målet er at brukere av einnsyn selv kan laste ned dokumenter som er publisert åpent tilgjengelig. Dette vil gi innbyggerne bedre tjenester, og forvaltningen vil bli avlastet i arbeidet med håndtering av innsynskrav. Et tredje mål er å teste en ny datamodell (RDF 2 ) for å lenke sammen data fra forskjellige arkivskapere og flere datakilder. 1.4 Rapportens struktur Rapporten inneholder en generell beskrivelse av Sesam-arkitekturen og de tekniske komponentene som er benyttet for å løse dataflyt mellom to virksomheter. Deretter beskrives hvordan komponentene er implementert i POC. I kapittel 4 beskrives testen som er gjennomført og hvilke funn som ble gjort. 1 https://arkivverket.no/arkivverket/offentleg-forvalting/noark/noark-4/standarden 2 http://www.w3.org/tr/2014/rec-rdf11-concepts-20140225/ Rapport 27.01.2014 Side 3 av 20
Rapporten inneholder tilslutt en liste over gevinster ved bruk av denne typen teknologi generelt, og for OEP spesielt. Rapport 27.01.2014 Side 4 av 20
2 Konsept 2.1 Arkitektur benyttet i POC Sesam-arkitekturen inneholder komponenten Datanav, for å skille masterdatakilden fra klientene som trenger dataene. Datanavet abonnerer på data som er publisert fra masterdatasystemet og gjør deretter dataene tilgjengelige for de klientene som måtte være interessert. Dette fjerner alle avhengighetene mellom masterdatasystemet og klientene som benytter seg av dataene. Dette betyr at hvis masterdatasystemet er nede vil masterdataene fremdeles være tilgjengelig for alle klientene. Det betyr også at hvis man bytter ut et system med et annet, trenger man ikke å gjøre endringer mot de eksisterende systemene fordi disse er integrert mot datanavet og ikke direkte mot systemet som byttes ut. System B (Masterdata klient) Lokal kopi Hente endringer Datanav Hente endringer Publiserte data System A (Masterdata kilde) Figur 1: dataflyt mellom kilde og klient 2.1.1 Publish-subscribe modellen For å hente data fra masterdatasystemet og frakte dataene til kildesystemene, benytter Sesam åpne standarder (SDShare og RDF). Disse baserer seg på det som kalles publish-subscribe modellen, for å eksponere og hente data mellom ulike systemer. Modellen fungerer slik at dataene blir publisert av masterdatasystemet og abonnert på av datanavet. Deretter publiserer datanavet dataene videre slik at klientene kan abonnere på disse. Ved å benytte denne tilnærmingen oppnår man at: Hvert system vil kun trenge å «snakke ett språk» og være avhengig av kun én integrasjon, uavhengig av hvilke data systemet skal hente. Hvis masterdatasystemet forandrer seg vil ikke dette påvirke klientsystemene. Hvis det er mer enn ett system som publiserer masterdata, vil fremdeles ikke klientsystemene bli påvirket. Hvis det legges til et nytt klientsystem kan det benytte seg av eksisterende masterdata som er publisert av datanavet, uten at dette krever noe av masterdatasystemet eller datanavet. Med denne modellen på plass, vil endringer som skjer i masterdatasystemet automatisk bli synkronisert fortløpende inn i datanavet, og på samme måte vil endringer i datanavet bli publisert og synkronisert videre til alle klientsystemene. 2.1.2 SDShare For å publisere og hente dataene sine benytter Sesam seg av den åpne protokollen SDShare (http://www.sdshare.org/), standarden baserer seg på Atom og RDF. RDF har en fleksibel datamodell som kan representere data i alle ulike former. De eksisterende RDF standardene definerer hvordan man kan lagre modellen, hvordan man kan spørre mot modellen (SPARQL), samt hvordan man kan oppdatere modellen (SPARQL Update). SDShare protokollen beskriver hvordan maskiner kan kommunisere seg i mellom ved å publisere og hente RDF, og på den måten synkronisere dataene på tvers av systemer. Denne er benyttet mellom alle Sesam-komponenter i POC, som utveksler RDF data ved hjelp av publish/subscribe modellen. Rapport 27.01.2014 Side 5 av 20
3 Løsning 3.1 Informasjonsarkitektur I POC overføres validerte og journalførte Journalposter og tilhørende arkivdata, fra Riksantikvaren løpende til einnsyn. Løsningen er en videreføring av arkitekturen som er etablert for løpende overføring av arkivmateriale til Riksarkivet. Denne løsningen går ut på at data fra Riksantikvarens sakog arkivsystem (Public 360) blir overført til et datanav, (heretter kalt earkiv). Her blir dataene mappet til Noark 5 format. Dataene eksisterer nå i to format, med forskjellige name space, URI er og de er lagret i forskjellige grafer. I earkiv blir dataen lagret i RDF-format. RDF-datamodell består av tripler av subjekt predikat - objekt. For eksempel: Journalpost - har tittel Vikavollan hyttefelt 41/3 Uttrykt i RDF: <https://data.kulturminne.no/p360/dokument/249565> <http://www.arkivverket.no/standarder/noark5/arkivstruktur/tittel> <"Vikavollan hyttefelt 41/3 - Id 118376 - Regulering - Søknad om dispensasjon - KML 8, 4. ledd"> I RDF-formatet blir semantikken fra kildesystemet beholdt, samtidig som dataene får en løsere kobling. 3.2 Validering av data Sesam-arkitekturen består av en valideringskomponent som beskriver og utfører definerte regler. Noark 5 regler blir beskrevet i RMIL 3 der alle Noark 5 klasser beskrives gjennom hvilke egenskaper de har og hvilken relasjon de har. For eksempel vil en én til én (1 1) relasjon bety at klassen må ha denne egenskapen for å bli validert korrekt. RMIL beskriver også forholdet mellom klasser gjennom arv og oppbygning av klassehierarkiet i arkivet. Figur 2 : eksempel fra klasse Journalpost i RMIL Fra RMIL genereres RDF-tripler som inneholder regelstrukturen, i RDF Constraint Language 4 (RDFCL). 3 RDF Modelling and Instance Language, RMIL, https://github.com/sesamresearch/rmil 4 RDFCL, https://github.com/sesamresearch/rdfcl/blob/master/rdfcl.md Rapport 27.01.2014 Side 6 av 20
<http://arkivverket.no/noark5/record> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://data.bouvet.no/rmil/class>. <http://arkivverket.no/noark5/record> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2000/01/rdf-schema#class>. <http://data.bouvet.no/rmil/1b6ecaa997d84181ae39d3d399ab3825> <http://www.w3.org/1999/02/22- rdf-syntax-ns#type> <http://data.bouvet.no/rmil/classpropertyconstraint>. <http://data.bouvet.no/rmil/1b6ecaa997d84181ae39d3d399ab3825> <http://data.bouvet.no/rmil/applies-to-type> <http://arkivverket.no/noark5/record>. <http://data.bouvet.no/rmil/1b6ecaa997d84181ae39d3d399ab3825> <http://data.bouvet.no/rmil/applies-to-propertytype> <http://arkivverket.no/noark5/recordtype>. <http://data.bouvet.no/rmil/1b6ecaa997d84181ae39d3d399ab3825> <http://data.bouvet.no/rmil/valuetype> <http://www.w3.org/2001/xmlschema#string>. <http://data.bouvet.no/rmil/1b6ecaa997d84181ae39d3d399ab3825> <http://data.bouvet.no/rmil/mincard> "0". <http://data.bouvet.no/rmil/1b6ecaa997d84181ae39d3d399ab3825> <http://data.bouvet.no/rmil/maxcard> "1". <http://arkivverket.no/noark5/recordtype> <http://www.w3.org/2000/01/rdf-schema#domain> <http://arkivverket.no/noark5/record>. <http://arkivverket.no/noark5/recordtype> <http://www.w3.org/2000/01/rdf-schema#range> <http://www.w3.org/2001/xmlschema#string>. Figur 3: RDF tripler uttrykket i RDFCL Resultatet av valideringen skrives tilbake til datanavet som boolsk verdi, ja eller nei, og data som blir validert uten feil er klare til overføring til Riksarkivet og einnsyn. Både modell og regler (contstraints), og resultatet av valideringen, er på denne måten beskrevet i data og lagres som RDF i datanavet sammen med resten av dataene. Dette gjør det enkelt å synkronisere modell/regler fra Riksarkivet til arkivskaper, slik at validering av NOARK 5 RDF hos arkivskaper skjer med best mulig forutsetninger. Dersom resultatet av validering hos arkivskaper er vellykket, sendes dataene videre til Riksarkivet og einnsyn der dataene valideres på nytt. 3.3 Dataflyt Når dataene er validert i Riksantikvarens earkiv er det klart for overføring til einnsyn, etter følgende krav: 1. Dataene må være validert uten feil. 2. Journalposter må ha status Journalført. 3. Journalpost, Dokumentbeskrivelse og Dokumentobjekt må ha en parent som er validert uten feil. Det betyr at ingen dokumentfiler og metadata om dokumentfiler kan overføres til einnsyn før Journalposten er journalført. Det betyr også at klasser høyere i hierarkiet enn Journalposter, f.eks. Saksmapper og Klasser, kan være overført til einnsyn uten at de har tilhørende Journalposter. Denne løsningen er valgt for å få en effektiv løsning som flyter godt, og samtidig for å komme i mål innenfor prosjektets rammer. Klasser uten tilhørende Journalposter kan eventuelt skjules i databrowser for å ikke skape støy i løsningen. De dataene som ikke validerer blir ikke overført til einnsyn, og arkivansvarlig bli varslet med en e- post. Når dataene er rettet opp blir valideringen kjørt på nytt. Arkivskaper vil på denne måten få en Rapport 27.01.2014 Side 7 av 20
kontinuerlig kvalitetstest av dataene, og få mulighet til å oppdatere dataene kort tid etter at de ble skapt. Dagens rutiner for publisering på OEP er 48 timer etter journalføring og utsendelse av brev. Dette er ikke implementert i POC, men det er ingen hindringer for at dette kan løses enten i overføringen til einnsyns datanav eller i publisering av data i databrowser, eller et annet tilpasset brukergrensesnitt. Skissen beskriver dataflyten og hvilke komponenter som er tatt i bruk. Alle komponenter benytter RDF-basert teknologi, enten i form av Sparql spørringer eller ved bruk av den RDF-baserte datautvekslingsprotokollen SDShare. I POC er samtlige komponenter, inkludert datanavet, installert på én fysisk maskin. De fleste komponenter er uavhengig av både teknisk plattform og operativsystem, så lenge de implementerer de korrekte standardiserte kommunikasjonsprotokollene. Rapport 27.01.2014 Side 8 av 20
Figur 4: dataflyt fra Riksantikvaren earkiv til Riksarkivet earkiv og Difi einnsyn 3.4 Skjerming I tillegg til de generelle reglene for overføring av data til einnsyn, er det innført regler for skjermet informasjon: Sakstittel og Journalposttittel skal skjermes dersom det er skjermingsinformasjon knyttet til saken eller journalposten. Teksten etter @-tegnet skal da erstattes med "Avskjermet" i overføringen til einnsyn. Avsender/mottaker (Korrespondanseparttype) skal skjermes dersom det er skjermingsinformasjon knyttet til Journalposten. Avsender eller mottaker skal da erstattes med "Avskjermet" i overføringen til einnsyn. Rapport 27.01.2014 Side 9 av 20
Den binære filen skal ikke overføres til einnsyn dersom det er skjermingsinformasjon knyttet til Dokumentbeskrivelsen. Metadata på Dokumentbeskrivelse og Dokumentobjekt blir overført til einnsyn selv om den binære filen ikke overføres. Figur 5: eksempel på skjermet tittel og korrespondansepart under Journalpost Rapport 27.01.2014 Side 10 av 20
4 Funn 4.1 Testbeskrivelse Følgende forberedelser til testen ble gjennomført: 1. Data ble overført løpende fra Riksantikvaren til einnsyn i én uke. 2. I slutten av uken genererte Riksantikvaren Journalpostrapport til OEP (Noark 4 xml), etter etablerte rutiner. 3. Denne rapporten ble importert til einnsyn, mappet til Noark 5 og lagret i en egen graf. 4. Det ble satt opp to databrowsere; en som eksponerte data som var løpende overført, og en annen for data fra journalpostrapporten. Følgende testscenario ble gjennomført: Test 1: sammenligning av data publisert på oep.no og data overført løpende til einnsyn. Test 2: sammenligning mellom data som var løpende overført til einnsyn og data importert fra journalrapporten. Begge testene var en manuell sammenligning av data publisert i de to forskjellige databrowserene og oep.no. 4.2 Funn Journalpostrapporten inneholder totalt 611 Journalposter. Disse er overført til einnsyn datanav, mappet til Noark 5 og publisert i en egen databrowser. Journalposter som er journalført i samme periode, er overført løpende til einnsyn sammen med relaterte data i Noark hierarkiet. I denne perioden er det overført 478 journalposter løpende til einnsyn. Avviket på 133 Journalposter skyldes valideringsfeil hos Riksantikvaren. Tilsammen er det funnet 143 feil i datasettet. Disse feilene fordeler seg på: Manglende administrativenhet i Saksmappen Manglende saksansvarlig i Saksmappen For mange Klasser knyttet til Saksmappen Manglende Korrespondansepart i Journalposten Manglende dokumentfil knyttet til Dokumentobjekt 4.2.1 Økt datamengde Det er overført en betydelig større datamengde i løsningen til løpende overføring til einnsyn. I tillegg til data om journalposten er hele Noark-hierarkiet 5 overført. Dette er den samme datamengden som blir overført til Riksarkivet for langtidslagring. Dette gir noen klare fordeler ved at einnsyn nå inneholder et helhetlig datasett, heller enn en liste over Journalposter slik dagens OEP-løsning fremstår. At hele Noark-hierarkiet er overført betyr også at man kan navigere oppover og nedover i hierarkiet, samt til side-klasser som for eksempel Journalposttype og Korrespondansepart. I tillegg til metadata blir også binære filer overført til einnsyn. Det betyr at brukere av einnsyn kan laste ned filer de er interessert i direkte. Alle dokumenter som ikke har registrert skjermingsinformasjon, kan lastes ned direkte. Etter dagens regelverk skal ikke arkivene 5 Noark 5 hierarkiet består av: Arkiv ArkivDel Klassifikasjonssystem Klasse Saksmappe Journalpost Dokumentbeskrivelse - Dokumentobjekt Rapport 27.01.2014 Side 11 av 20
forhåndsklassifisere dokumenter, men gjøre dette på det tidspunktet det begjæres innsyn. Om alle binærfiler som er overført til einnsyn i denne POC en kan offentliggjøres direkte, må derfor tas opp til vurdering. Figur 6: eksempel på tilgjengelige dokumentfiler 4.2.2 Bedre kontekstforståelse Med et bredere datasett vil brukere av OEP få mer informasjon om journalpostens kontekst enn ved overføring av én og én journalpost slik som i dagens OEP-løsning. For eksempel blir det overført mer informasjon om tilknyttet sak, hvordan den er klassifisert og hvilken arkivdel den tilhører. Det blir også overført mer informasjon om selve dokumentfilen, og den binære filen blir også overført til einnsyn, så lenge det ikke er lagret noen skjermingsinformasjon. I tillegg til hvem som er registrert som korrespondansepart på dokumentene, overføres det informasjon om selve korrespondanseparten, som for eksempel kontaktinformasjon. Figur 7: eksempel på informasjon om korrespondansepart I tillegg til mer data, viser også einnsyn flere sammenhenger i dataene. I einnsyn får man få oversikt over alle journalposter som er knyttet til samme sak, alle saker knyttet til samme klassifikasjonskode, alle dokumentfiler knyttet til samme journalpost etc. I tillegg vises kryssreferanser mellom saker og journalposter som har en relasjon. Rapport 27.01.2014 Side 12 av 20
Figur 8: eksempel på journaldata overført løpende til einnsyn 4.2.3 Validering Det er funnet et avvik mellom data i journalrapporten og einnsyn, som skyldes valideringsfeil hos Riksantikvaren. Som beskrevet innledningsvis er det 133 færre Journalposter som er overført løpende til einnsyn enn det finnes i Journalpostrapporten. Det betyr at noen av dataene som einnsyn abonnerer på ikke er registrert i henhold til Noark 5 regelverket. Validering av data hos arkivskaper er i utgangspunktet en bra ting ved at man får kvalitetssikret dataene og holdt et høyt sikkerhetsnivå, men samtidig kan det også forårsake forsinkelse i overføringsprosessen til einnsyn. Valideringsrutinen krever at arkivskaper agerer raskt på melding om valideringsfeil og får rettet dem opp innen 48 timer etter journalføring. 4.2.4 Noark 4 vs. Noark 5 Data overført fra journalpostrapporten i Noark 4 format, vises svært fragmentert. For eksempel er ikke saksnummer vist slik det normalt blir vist med saksår og saksnummer (06/00137). Saksansvarlig vises kun som kode/initialer og ikke hele verdien, slik det gjør i dataene som er løpende overført til einnsyn. Figur 9: eksempel på saksinformasjon fra journalpostrapporten i Noark 4 format Korrespondanseparter som er overført via journalpostrapporten i Noark 4 format, er vist som et relatert objekt og ikke som en del av journalpostinformasjonen. Det er ingen informasjon om korrespondanseparten som blir overført. Rapport 27.01.2014 Side 13 av 20
Figur 10 : eksempel på korrespondansepart relatert til journalpost fra journalpostrapporten i Noark 4 format Om journalpostrapporten i Noark 4 format skal være en alternativ vei for overføring av data til einnsyn, må det gjøres endel tilpasninger for å få data til å vises likt som data som blir løpende overført fra earkiv. Journalpostrapporten i Noark 4 format har metadata om korrespondanseparten er en person. Denne metadataen benyttes til å identifisere personnavn som ikke skal være søkbare ett år etter publisering. Når dataene blir mappet to Noark 5 forsvinner denne muligheten, siden Noark 5 ikke skiller mellom personer og organisasjoner. Dette er en nødvendig funksjonalitet i OEP som det må lages en løsning for når data blir overført i Noark 5 format. Riksarkivet er informert om funnet. 4.3 Konflikterende journalposter Konflikterende journalposter er en utfordring i den nåværende OEP-løsningen og som oppstår når en journalpost som allerede er overført til OEP flyttes til en ny sak i kildesystemet. Følgende beskrivelse ble gitt av Difi: 1. En journalpost opprettes i kildesystemet. Saks- og dok-nummer: 2010/12345-4 Løpenummer: 96543/10 Journaldato: 20.03.10 Journalposten er den nyeste på saken og har derfor det høyeste dokumentnummeret (4). 2. Journalposten overføres til OEP. 3. Journalposten flyttes til en annen sak som følge av oppsplitting eller sammenslåing. Saks- og dok-nummer: 2010/12555-2 Løpenummer: 96543/10 4. Det opprettes en ny journalpost på den opprinnelige saken. Dokumentnummer 4 er nå ledig pga. flyttingen, og den nye posten får derfor dette nummeret. Saks- og dok-nummer: 2010/12345-4 Løpenummer: 99777/10 Journaldato: 18.04.10 Denne journalposten har nå samme saks- og dokumentnummer som journalposten i pkt. 1 hadde. 5. Den nye journalposten overføres til OEP. OEP gjenkjenner saks- og dokumentnummeret som en eksisterende post, mens løpenummeret sier at det er en ny post. OEP kan da ikke avgjøre hva som skal skje med posten. Samme fremgangsmåte ble testet i den nye løsningen med følgende resultat: Rapport 27.01.2014 Side 14 av 20
1. Under sak 05/00004 ble det opprettet et nytt dokument - 05/00004-97 - i P360 Test hos Riksantikvaren a. Sak-/dokumentnr: 05/00004-97 b. RegistreringsID: 416324 (dette er journalpostens unike nr i Noark. I tillegg til år tilsvarer det løpenr) 2. Sak og dokument ble overført til earkiv Riksantikvaren og deretter til einnsyn. 3. Dokument 05/00004-97 ble flyttet til ny sak 06/00001 i P360 Test. a. Nytt Sak-/dokumentnr: 06/00001-9 b. Samme RegistreringsID: 416324 4. earkiv Riksantikvaren og deretter einnsyn fanger opp endringene i kildesystemet og oppdateres. Dokument 05/00004-97 er nå borte fra både earkiv og einnsyn. 5. Nytt dokument opprettes på sak 05/00004 a. Sak-/dokumentnr: 05/00004-97 b. RegistreringsID: 416325 6. earkiv og einnsyn oppdateres på nytt og det ligger nå to dokument i de to datanavene - 05/00004-97 (regid 416325) og 06/00001-9 (regid 416324) Konklusjonen fra denne testen er at konflikterende journalposter ikke lenger vil være en utfordring i løsningen med løpende overføring av arkivmateriale til einnsyn. earkiv og einnsyn vil til enhver tid være en speiling av kildesystemet, dvs. at alle endringer overskriver tidligere verdier. Endringshistorikken lagres i kildesystemet. Rapport 27.01.2014 Side 15 av 20
5 Gevinster Dette prosjektet benytter de samme Sesam-konseptene som i Riksarkivets POC. Løpende overføring av arkivmateriale til einnsyn gir et verdifullt tilskudd til Riksarkivets prosjekt, ved å kunne tilby de samme dataene (bortsett fra de som etter reglene skal skjermes), åpent tilgjengelig. Med utgangspunkt i det samme datasettet (Riksantikvarens earkiv) er det realisert flere use cases. I tillegg til løpende overføring til Riksarkivet og einnsyn, utvikler Riksantikvaren også her egne brukertjenester. 5.1 Gevinster ved løsningen 1. Alle Sesam-komponenter er løst koblet Sesam-arkitekturen legger opp til at alle kilder (earkiv eller Noark 4 xml) publiserer sine data uten å ha noe forhold til mottakerkomponenten (einnsyn) som abonnerer på dataene, gjennom bruk av «publish-subscribe» modellen. Det er ingen direkte avhengigheter mellom arkivskaper og Difi, og om flere hundre statlig og kommunale virksomheter (arkivskapere) i fremtiden skal koble seg på en slik modell, er denne uavhengigheten viktig. Kildesystemet vil ikke være avhengig av at einnsyn til enhver tid er tilgjengelig (100% oppetid på mottaksservere), og einnsyn vil ikke være avhengig av at alle statlige etaters kildesystemer er tilgjengelige til enhver tid for å utveksle data. 100% tilgjengelighet er svært kostnadsdrivende og heller ikke nødvendig i denne sammenheng. 2. Datadrevet arkitektur Data flyter mellom komponenter ved bruk av åpne standarder og det defineres ingen faste grensesnitt mellom kilde og mottaker, slik som i en tjenesteorientert arkitektur. I einnsyn POC er det overført data fra den samme kilden (Riksantikvarens earkiv) som overfører data løpende til Riksarkivet. Det er implementert litt andre regler for overføring av data til einnsyn, men datagrunnlaget er det samme. Data og behov er stadig i endring, og det er vanskelig å definere en modell for hvilke data som skal overføres i all fremtid. Lagring av arkivmateriale har et langt perspektiv, og det er stor fordel at tjenesten for løpende overføring har en fleksibel og utskiftbar modell, i motsetning til et sett med statiske grensesnitt (for eksempel web services), som må vedlikeholdes og endres etter behov. I et slik tilfelle hadde Difi og Riksarkivet samarbeidet om å støtte svært mange ulike versjoner, eller krevd at statlige etater endret sine systemer til å overføre arkivdata mot siste oppdatert versjon. 3. Fleksibel og skjemaløs datamodell (RDF) Bruken av en skjemaløs datamodell betyr at i motsetning til mange datavarehusprosjekter, trenger man ikke å bruke tiden på å bestemme, lage og vedlikeholde en felles datamodell for hele virksomheten. Sesam gjør det mulig å lagre og sammenkoble data i fra forskjellige kilder uten å måtte endre på deres opprinnelige modell. I POC blir data fra P360 mappet til Noark 5 standarden før validering og overføring til Riksarkivet og einnsyn. Noark 5 standarden representerer en felles datamodell for all arkivdata, men overføring til einnsyn er ikke avgrenset av denne standarden. Det betyr at man kan hente data fra mange forskjellige typer systemer, ikke bare sak- og arkivsystemer, men også andre fagsystemer som lagrer data om saksbehandlig og korrespondanse, eller konteksten til sak- og arkivsystemer. 4. Publiser endringer løpende Istedenfor å publisere data på OEP en gang i uken, oppdateres alle data løpende. Datanavet abonnerer på endringer fra kildesystemet og det vil derfor kun overføres små mengder data om gangen. Valideringsfeil i henhold til kravene, blir varslet løpende og det vil være lav terskel for å rette opp nye feil. Den løpende overføringen vil også gi mindre last på den tekniske infrastrukturen. Rapport 27.01.2014 Side 16 av 20
Kravet om at journaldata skal publiseres 48 timer etter brevutsendelse, kan implementeres som et nytt funksjonelt krav i den løpende overføringen. 5. Lagre alle metadata i et sentralt Datanav Alle metadata som blir overført fra kildesystemet, blir lagret i et sentralt Datanav (RDF database). Dette betyr at dataene enkelt kan eksponeres i en søkemotor. Dette gir svært gode muligheter for gjenfinning, både av arkivert materiale i seg selv, men også om data rundt arkiveringsprosessen, som valideringsfeil eller andre operasjonelle data. Dataene kan også brukes til rapportering, eksport til ulike formater eller integrasjon mot andre systemer. 5.2 Gevinster ved videreutvikling av OEP Flere av disse temaene er behandlet i rapporten Idénotat beriking av journaldata i OEP / Marte Brekke (Bouvet). 19.11.2015. 1. Utvidet datasett og kvalitetssikrede data Det er overført betydelig mer data til einnsyn enn det blir til OEP i dag. I POC ble det vist eksempel på hvordan journaldata kan berikes med mer arkivdata for å sette det inn i en videre kontekst. For eksempel er det hentet mer informasjon om Saker og korrepondanseparter. I tillegg til metadata blir også binære filer overført til einnsyn. Det betyr at brukere av einnsyn kan laste ned filer de er interessert i innsyn i direkte. Dette er et flott tilbud for brukere av einnsyn, samtidig som det ligger store gevinster for offentlig sektor i å bruke tid på å saksbehandle og håndtere innsynsbegjæringer. Alle arkivdata som blir overført til OEP er kvalitetssikret gjennom validering og oppdatering. Dataene blir validert etter Noark 5 regelverket hos arkivskaper før de blir overført til einnsyn. På den måten vil man alltid være sikker på at dataene har en høy kvalitet og at data med skjermingsinformasjon ikke blir overført. 2. Flere integrasjoner I POC ble det kun overført data fra Riksantikvarens sak-/arkivsystem. Planen på sikt er å koble til flere arkivskapere slik at man kan søke og navigere i korrespondanser og øvrig arkivmateriale på tvers av arkivskapere. I POC ble datainnsamlingen avgrenset kun til å gjelde data definert i Noark 5, men på sikt vil man også åpne for å integrere mer virksomhetsspesifikk og domenespesifikk data. Ved å berike journaldata på denne måten vil man kunne gi einnsyn et større bruksområde enn OEP er i dag, både når det gjelder innsyn og gjenbruk av offentlig data. OEP er i dag avgrenset til korrespondanse registrert av statlig sektor, men det er ingen ting i veien for at einnsyn skal kunne tilgjengeliggjøre data fra kommunale og fylkeskommunal sektor i tillegg. På denne måten vil man kunne få følge saksbehandling og kommunikasjon på tvers av offentlig sektor på en mer helhetlig måte. 3. Gjenfinning og navigering Løpende overføring av arkivmateriale til einnsyn på basis av Noark 5, gir et helhetlig datasett som er brukervennlig å navigere i og som viser sammenhenger i materialet. Noark 5 standarden er bygget opp som et hierarki man kan navigere oppover og nedover i og man kan for eksempel se alle saker registrert på en konkret klasse, alle journalposter i en sak, alle dokumentfiler knyttet til en journalpost etc. Noark 5 består også av flere klasser som er relatert til hierarkiet, for eksempel kan alle saker eller journalposter knyttet til en konkret korrespondansepart vises samlet. Gjennom å filtrere og navigere seg gjennom arkivmaterialet, kan man se nye sammenhenger og få et videre blikk på materialet enn om det kun ligger i en kronologisk liste. Navigeringen kan gjøres innenfor datasettet til en arkivskaper eller mellom arkivskapere. Når einnsyn fylles med data fra Rapport 27.01.2014 Side 17 av 20
mange arkivskapere, kan man virkelig få verdiskapning gjennom å kunne følge saker mellom arkivskapere, se sammenhenger mellom saker på tvers av arkivskapere, eller analysere dataene for å få ny kunnskap om offentlig sektor som kan benyttes til styringsdata. 4. Beriking av journaldata I POC ble det importert data fra Riksantikvaren sak- og arkivsystem. I offentlig sektor finnes det også flere andre fagsystemer som lagrer informasjon om saksbehandling og korrespondanse. Mange av disse har en Noark 5 kjerne som tar var på arkivinformasjonen, men mye informasjon som setter arkivmaterialet inn i en større kontekst, vil ikke være tilgjengelig via arkivsystemene. I tillegg til fagsystemer vil offentlig sektor inneha en rekke registre. For eksempel har Riksantikvaren et register/fagsystem, Askeladden, som inneholder informasjon om alle kulturminner i Norge og som er gjenstand for saksbehandling. Å ha mulighet til å se dataene i en større sammenheng, vil gi stor gevinst for offentlig sektor. 5. Gjenbruk av data Det finnes allerede en rekke åpne data som kan være interessante for einnsyn å integrere mot; som for eksempel enhetsregisteret, matrikkelen, wikipedia og flere kilder 6. Det er stor fokus på forvaltning og gjenbruk av åpne data i det offentlige. Gjennom å benytte en teknologi som er godt egnet til å gjenbruke åpne data, vil terskelen for å utnytte disse mulighetene være mye lavere. Dessuten kan også den samme teknologien benyttes til å åpne egne data, og eksponere disse for både samarbeidspartnere og andre interessenter. 6. Tjenestebygging RDF har en standardisert måte å tilby integrasjon, gjennom et API/SPARQL endpoint. Gjennom dette kan offentlige data deles videre. Difi kan selv utvikle nye brukertjenester, eller andre interessenter kan utvikle nye apps/applikasjoner, på basis av åpne og tilgjengelige data, som ingen klarer å forestille seg på forhånd. 6 Eksempel på integrasjon med blant annet OEP-data, Enhetsregisteret og Matrikkelen er viste på https://open.sesam.io/ Rapport 27.01.2014 Side 18 av 20
6 Konklusjon POC en viser at løpende overføring til einnsyn har mange gevinster både i forhold til brukervennlighet og arkitekturmessig. Dataene blir presentert i en videre kontekst og har mange muligheter for navigering i Noark hierarkiet, og på tvers av materialet. Arkitekturmessig viser POC at einnsyn vil ha mange muligheter til å løse flere use cases i fremtiden. Validering av data i henhold til Noark 5 regelsettet gir noen rutinemessige utfordringer for arkivskaper, men alt i alt vil kvalitetskontroll av data gi verdi for einnsyn. Dersom journalpostrapporten skal benyttes som et alternativ til leveranse av data til einnsyn, i tillegg til earkiv, må dataene behandles ytterligere før de blir publisert. Mapping til Noark 5 gir en utfordring siden det ikke er mulighet for å skille mellom personer og organisasjoner i Korrespondansepart. Rapport 27.01.2014 Side 19 av 20
7 Referanser 1. Idénotat beriking av journaldata i OEP / Marte Brekke (Bouvet). 19.11.2015 2. RDF 1.1 Concepts and Abstract Syntax, http://www.w3.org/tr/2014/rec-rdf11-concepts- 20140225/ 3. RDFS 1.1, http://www.w3.org/tr/rdf-schema/ 4. SPARQL 1.1, http://www.w3.org/tr/sparql11-overview/ 5. RDF 1.1. Primer, http://www.w3.org/tr/rdf11-primer/ 6. RDFCL, https://github.com/sesamresearch/rdfcl/blob/master/rdfcl.md 7. RDF Modelling and Instance Language, RMIL, https://github.com/sesamresearch/rmil 8. SDShare, http://www.sdshare.org Rapport 27.01.2014 Side 20 av 20