Domenespesifikke metadata for et bestemt fagfelt - f.eks. byggesak, oppvekst e.l.

[lvbachmann]

Beskrivelse av behov

En standard struktur for bruk på arkiv innenfor et fagfelt, slik at det kan gjenbrukes på tvers og dermed forenkle samhandling (og senere gjenfinning). Begynne på et fagfelt først for å etter hvert utvide med andre fagfelt.

1. Avklare om dette er en fornuftig tilnærming - og om dette er noe Arkivverket skal eie
2. Avklare hvilke(t) domene(r) det vil gi mest verdi at standardiseres
3. Avklare form på domenespesifikk standardisering av metadata for et utvalgt område - vise til eksisterende vs. utvikle nytt

Eventuelle andre domenespesifikke standarder registreres som egne behov

Mål/motivasjon

Nyttig for fagfeltet og nyttig som erfaring på å lage mer spissede standarder.

Suksesskriterier/måling

Område/prosess

Målgrupper

Hastegrad

Lav hastegrad (fordi det i sin natur er spisset mot et smalere felt - og dermed ikke gir gevinst utenfor dette feltet)

Hastegrad vil kunne variere mellom ulike domener - siden noen domener er tilfredsstillende(?) dekket i dag, mens andre ikke er det

Forslag til løsning

[yonyonson]

Dette er et nydelig mulighet for å vurdere gjenbruk av eksisterende standarder.

[magnehg]

Jeg lagde et utkast til noe lignende i 2008, jeg skal se om jeg finner det igjen.

Grovt sett så vil arkivstruktur i seg selv kunne standardiseres, men det er vesentlige muligheter for effektivisering ved å forhåndsdefinere og regelbinde hele saksbehandlingsprosessen knyttet til en sakstype:

"Saksmal":

• Arkivstruktur
• Saksbehandlingsprosess(er)
• Dokumenttyper, titler og -innhold (den faktiske teksten)
• Tagging, klassering, datatyper (koblinger til andre systemer)
• Vedtakstyper / status for saksbehandlingen
• knytninger til andre systemer (innhenting / utsending av dokumentasjon)

Ved at "alt" er forhåndsdefinert vil saksbehandler i stedet for å skrive inn manuelle titler / tekst kunne ha et skjema-/fagsystembasert skjermbilde der vedkommende foretar den faktiske saksbehandlingen, i stedet for å forholde seg til fritekst / ikke maskinlesbar tekst i word:

[Foreta saksbehandling] -> [Vedtak: Innvilget (med vilkår)] -> skriv inn/velg vilkår -> Forhåndsvis dokument -> Ekspeder dokument

Dette gir "smarte" data, i stedet for ikke maskinlesbar fritekst i word- og sak/arkiv- eller fagsystemer. Samtidig kan journalføring, vurdering av dokumentinnhold etc skje automatisk. Saksbehandlingen kan også automatiseres ved at regler / betingelser for en regelmotor ligger innebygd i saksmalene, og hver enkelt etat kan da velge å bruke verktøy for automatisering i stedet for manuell behandling.

Alt dette, inkludert innholdet i tekstdokumenter, kan defineres i én XML-fil og importeres / eksporteres til/fra et NOARK- eller fagsystem. Dette muliggjør at f.eks. KS eller private aktører kan forhåndsdefinere maler basert på standarder som kommunene kjøper, eller at etater kan dele maler seg imellom. Vi snakker teknisk og semantisk interoperabilitet.

Selve malsystemet må defineres som en standard som saksbehandlings- og/eller arkivsystemer kan velge å støtte. Standarden bør også fungere for / støttes av fagsystemer.

[sturtzel]

Akkurat for byggesak er naturlig å ta utgangspunkt i datamodellene for eByggesøknad, samt ArkivLett. Der finnes det også regler i regi av DiBK.

For plansaker (f.eks. reguleringsplan) er det også datastrukturer å ta utgangspunkt i, f.eks. SOSI.

Deler av disse passer inn i Noark/arkivmeldingen (ref. oppdateringer i Fiks Arkiv), deler er en utvidelse.

[lvbachmann]

Jeg lagde et utkast til noe lignende i 2008, jeg skal se om jeg finner det igjen.

Hei, @magnehg.

Hvis/når dette er et behov vi skal begynne å vurdere løsninger på, tar vi kontakt for å høre mer om det du har gjort og tenkt.

[TerjePD]

I Sverige opererer man med FGS'er. Der blir det definert en spesifikk FGS for hvert fagfelt. Kan være en ide å undersøke hvor vellykket innføringen av FGS'er er blitt.
(Tror dog ikke det finnes en FGS for byggesak.)

[yonyonson]

Begrunnelse for prioritering av behovet etter sesjon den 6. oktober 2022. Lenke til alle prioriteringer: github.com/arkivverket/standardlab/blob/master/styrende/veikart.md

Gjennomførbarhet

• Vi kan ikke standardisere for hele offentlig sektor på dette nivået - trekker betydelig ned
• Vi må bygge en generisk standard før vi kan standardisere for spesifikke områder/gjøre en spesialisering - trekker betydelig ned

Verdi

• Treffer smalt - trekker ned
• Det finnes allerede de fakto standarder som virker, vi kommer antegelig ikke å forbedre noe - trekker ned
• Det blir lite innovasjon og nytenking

Hastegrad

• Det er mulig at andre aktører opplevere at hastegrad her er betydelig høyere enn oss. Det er viktig for kommuner
• Det foregår mye uhjemlet kassasjon i kommunesektor - det trekker sterkt opp
• Vi kan ikke begynne på hvilken som helst fagfelt, det er kun utvalg av fagfelt som vi kan begynne på - trekker ned

Risko

Redusjon av eksisterende risiko

• Reduserer risiko for uhjemlet kassasjon - trekker i riktig retning
• Dekker kun 1 smal segment av gangen - trekker i feil retning
• Samtidig kan stadnardisering være for omfattende - trekker i feil retning

[sturtzel]

Hvis man skal lage noe generisk uten å ha konkrete systemer å verifisere mot risikerer man å lage en akademisk standard som ikke egner seg til noe og derfor heller ikke blir brukt.

Starter man med noen fagsystemer (byggesak, plansak, barnehagesøknad - systemer der det er gjort standardiseringsarbeid tidligere) har man et langt bedre grunnlag for å plukke ut det generiske.