Utredning og vurderinger - Revisjon av "Standard for beskrivelse av datasett og datakataloger (DCAT-AP-NO)"

Om dokumentet Dokumentet inneholder diskusjon og vurdering av å revidere nåværende versjon av "Standard for beskrivelse av datasett og datakataloger" (DCAT-AP-NO), og skal være en kilde til mer informasjon og begrunnelse for de valgene som er tatt, samt en vurdering av om den reviderte «Standard for beskrivelse av datasett og datakataloger» bør fortsatt bli en forvaltningsstandard for åpne data spesielt, men også for datasett i offentlig sektor generelt. Utredningsdokumentet er ikke selve standarden.

Innhold Om dokumentet ...................................................................................................................................... 1

Sammendrag ........................................................................................................................................... 2

1 Innledning ........................................................................................................................................ 3

1.1 Formål med utredningen ......................................................................................................... 3

1.2 Omfang og avgrensning ........................................................................................................... 4

1.3 Tidligere utredninger på området ........................................................................................... 4

1.4 Metode for informasjonsinnhenting ....................................................................................... 4

1.5 Dokumentstruktur ................................................................. Feil! Bokmerke er ikke definert.

1.6 Informasjon om standardiseringsarbeidet i Difi ...................................................................... 5

2 Introduksjon til bruksområdet ........................................................................................................ 5

2.1 Ord, uttrykk og forkortelser .................................................................................................... 5

2.1.1 Datasett ........................................................................................................................... 5

2.1.2 Datakatalog ..................................................................................................................... 6

2.1.3 Åpne data ........................................................................................................................ 6

2.1.4 Offentlige data ................................................................................................................. 7

2.1.5 Maskinlesbare data ......................................................................................................... 7

2.1.6 Applikasjonsprofil (AP) .................................................................................................... 7

2.1.7 Application Programming Interface (API)........................................................................ 7

2.1.8 W3C ................................................................................................................................. 7

3 Offentlige virksomheters behov på området .................................................................................. 7

3.1 Behov som ligger til grunn for oppdatering av standarden .................................................... 8

3.1.1 EUs revisjon av DCAT-AP ................................................................................................. 8

3.1.2 Behov identifisert i piloten «Stresstest av DCAT-standarden» ....................................... 8

3.1.3 Behov identifisert i prosjektet «Felles datakatalog» ..................................................... 10

3.2 Behov som ikke er løst........................................................................................................... 15

4 Kartlegging av standarder på bruksområdet ................................................................................. 11

5 Evaluering av standarder ............................................................................................................... 12

6 Vurdering av alternativer .............................................................................................................. 12

7 Enkel vurdering av økonomiske og administrative konsekvenser ................................................ 16

8 Forvaltningsregime ........................................................................................................................ 16

9 Konklusjon ..................................................................................................................................... 17

1 Oppsummering av endringene fra v.1.0 til den foreslåtte v.1.1 ................................................... 18

2 Den foreslåtte DCAT-AP-NO v.1.1 ................................................................................................. 18

3 Oversikt over behov identifisert i piloten «Stresstest av DCAT» .................................................. 18

4 Utkast til veileder .......................................................................................................................... 18

Sammendrag Informasjon er en av de viktigste ressursene i offentlig sektor, og det har lenge vært et krav om at offentlig sektor må utnytte informasjonen sin på en bedre måte for å bli mer effektiv, gi bedre tjenester til innbyggere og næringsliv, og bidra til økt rettssikkerhet. Digitaliseringsrundskrivet1 konkretiserer dette ved bl.a. å si at offentlige virksomheter i størst mulig grad bør gjenbruke informasjon som allerede finnes. I samsvar med viderebruksbestemmelsene i offentleglova skal samtidig offentlige virksomheter gjøre egnet informasjon tilgjengelig for bruk også utenfor offentlig sektor (åpne data). Tilgjengliggjøring av offentlige data som åpne data er et virkemiddel for å utløse innovasjon, effektivisering og større demokratisk deltagelse. Selv om vilkårene for bruk kan være ulike i og utenfor offentlig sektor, så er behovet grunnleggende det samme: å oppdage, vurdere og bruke offentlige data. En stadig mer datadrevet forvaltning medfører at offentlig informasjon blir brukt til nye formål og ved hjelp av nye metoder. En forutsetning for å oppnå mer bruk av offentlige data er at virksomhetene har oversikt over egne datasett og at disse oversiktene er publiserte og mulig å utveksle. En større grad av gjenbruk og viderebruk krever imidlertid en helhetlig forvaltning av informasjon, både internt i virksomheten og på tvers av virksomheter. Mange offentlige virksomheter har nå en felles forståelse av at manglende oversikt over egen informasjon er et av de viktigste hindrene for elektronisk informasjonsutveksling Formålet med "Standard for beskrivelse av datasett og datakataloger" er å etablere en felles måte å beskrive offentlige datasett på, slik at beskrivelsene lettere kan utveksles mellom datakataloger og dataportaler.

1 Digitaliseringsrundskrivet er en sammenstilling av pålegg og anbefalinger vedrørende digitalisering i offentlig

sektor, og gir et helhetlig bilde av hvilke føringer som gjelder.

Ønsket effekt er å utløse innovasjon, effektivisering og større demokratisk deltagelse ved at andre (andre offentlige virksomheter, privat næringsliv eller sivilsamfunnet for øvrig) lettere kan oppdage, vurdere og (eventuelt) bruke offentlige data til nye formål. Standarden vil gjelde datasett som forvaltes av offentlig sektor, og som beskrives med tanke på oppføring i en katalog/"inventarliste" (intern eller ekstern). En slik felles standard vil støtte søking i og deling av datasett på tvers av offentlig sektor (gjenbruk) og legge til rette for viderebruk i privat sektor. Standarden er således nyttig både for offentlig sektor selv og for næringsliv og sivilsamfunn for øvrig. DCAT-AP-NO bygger på den internasjonale standarden Data Catalog Vocabulary (DCAT)2 som ble anbefalt av W3C i 2014 for beskrivelse av datasett og datakataloger. EU-kommisjonen har utarbeidet en applikasjonsprofil (DCAT-AP)3 basert på DCAT ut fra behovene knyttet til en felles europeisk dataportal for åpne data. DCAT-AP ble revidert i 2015, og foreligger nå i versjon 1.1. Den standarden som foreslås i denne utredningen, anbefales også brukt for beskrivelse av datasett som ikke er åpne. Arbeidet med informasjonsforvaltning i offentlig sektor har vist at det er behov for beskrivelser av alle datasett i forvaltningen, og det vil være hensiktsmessig at disse datasettene beskrives på en helhetlig måte. Standarden vil således være nyttig for etatens forvaltning av egen informasjon, og for andre etater, næringsliv og sivilsamfunn som har behov for å vite hvilke data etaten forvalter.

1 Innledning Denne utredningen handler om revisjon av en eksisterende standard, "Standard for beskrivelse av datasett og datakataloger" (DCAT-AP-NO v.1.0)4. Standardiseringsrådet fastsatte DCAT-AP-NO v.1.0 som en anbefalt forvaltningsstandard, gjeldende fra 21.07.2015. DCAT-AP-NO er basert på EU sin profil (DCAT-AP v.1.0) av DCAT-standarden (Data Catalog Vocabulary)2 som W3C i 2014 anbefalte som standard for beskrivelse av datasett og datakataloger. EU sin profil som den norske profilen var basert på, ble oktober 2015 revidert fra v.1.0 til nåværende v.1.13. I tillegg har Difi gjennomført et pilotprosjekt hvor standarden var prøvd ut med tanke på å avdekke eventuelle behov i offentlig sektor som ennå ikke er dekket av standarden. Ved fastsetting av DCAT-AP-NO v.1.0 som anbefalt forvaltningsstandard var det allerede planlagt en revisjon av standarden, bl.a. pga. den planlagte revisjon av EU sin profilen som den norske var basert på.

1.1 Formål med utredningen [Redaksjonelt redigert sammenlignet med forrige utredning5] Formålet med "Standard for beskrivelse av datasett og datakataloger" er å gjøre det enklere å oppdage, vurdere og å ta i bruk data som det offentlige forvalter. Standarden vil legge til rette for utveksling av datasettbeskrivelser mellom ulike datakataloger og dataportaler, og å lette søk etter datasett.

2 W3C: Data Catalog Vocabulary (DCAT), http://www.w3.org/TR/vocab-dcat/ 3 EU: DCAT application profile for data portals in Europe, https://joinup.ec.europa.eu/asset/dcat_application_profile/asset_release/dcat-ap-v11 4 Standard for beskrivelse av datasett og datakataloger (DCAT-AP-NO), http://difi.github.io/dcat-ap-no/ 5 Utredning og vurderinger – standard for beskrivelse av datasett og datakataloger, https://data.norge.no/sites/datanorge/files/2015-02-04-utredning-dcat.PDF

1.2 Omfang og avgrensning [Redaksjonelt redigert sammenlignet med forrige utredning5] Standarden omfatter beskrivelse av datasett og datakataloger i offentlig sektor. Den vil gjelde for alle datasett i offentlig sektor (inkludert åpne data) som beskrives med tanke på oppføring i en katalog/"inventarliste" (intern eller ekstern). En oversikt (katalog) over alle datasett i virksomheten vil være nyttig både internt i virksomheten, for offentlig sektor, og for privat sektor. I Difis Veileder i tilgjengeliggjøring av åpne data6 sies det at grønne data er data som åpenbart kan publiseres som åpne data. Gule data omfatter datasett som ikke kan åpnes grunnet sikkerhet, personvern eller immaterielle rettigheter, men som likevel kan deles innenfor offentlig sektor. Røde data er datasett som på grunn av sikkerhet, personvern eller immaterielle rettigheter må holdes internt, eller potensielt deles med dem det gjelder. Standarden omfatter altså alle disse tre kategoriene av data. En kategorisering i disse tre kategoriene understøttes nå også i EUs DCAT-AP versjon 1.1. Standarden dekker ikke tekniske spørsmål som mekanismer for utveksling av data eller funksjonalitet i systemer som skal implementere DCAT-AP. Det er ingen krav om at systemer skal være implementert i spesifikke tekniske miljø for å kunne kommunisere. Standarden definerer hvilke felter som skal med i beskrivelsen av hhv. datasett og datakataloger samt hvilke vokabularer som skal brukes for å beskrive disse. Anbefalte publiseringsformater for datakataloger er RDF/XML og JSON-LD.

1.3 Tidligere utredninger på området Denne utredningen handler om revisjon av en eksisterende standard, dvs. av DCAT-AP-NO v1.04. Det henvises derfor også til forrige utredning5 som ble gjennomført før DCAT-AP-NO v.1.0 ble fastsatt som en forvaltningsstandard.

1.4 Metode for informasjonsinnhenting Difi etablerte en intern arbeidsgruppe som sammenstilte endringsbehov med forslag til løsning. Behovene som ble sammenstilt kom fra følgende kilder:

Endringer av EU sin profil, fra DCAT-AP v.1.0 til DCAT-AP v.1.1

Behovene identifisert i pilotprosjektet som Difi gjennomførte

Behovene identifisert i forbindelse med funksjonell og teknisk spesifikasjon av en felles datakatalog

Behovene som fremkom fra forrige utredningsrunde som ikke ble med på DCAT-AP-NO v.1.0.

Det ble avholdt en åpen arbeidssamling med leverandører og referansegruppen den 7. juni 2016. Revisjonsarbeidet forholder seg til følgende overordnede prinsipper:

6 Originaltittel til denne veilederen er "Veileder i tilgjengeliggjøring av offentlige data". Vi har her i dette dokumentet kalt veilederen "Veileder i tilgjengeliggjøring av åpne data" siden veilederen primært handler om åpne data og ikke offentlige data generelt. Vi gjør også oppmerksom på at veilederen er planlagt revidert i løpet av 2016. http://data.norge.no/document/del-og-skap-verdier-veileder-i-tilgjengeliggj%C3%B8ring-av-offentlige-data

Endringer skal:

1. forbedre oppdagelsen av datasett 2. ivareta etterlevelse av DCAT 3. ivareta enkelhet: et smalt omfang 4. ivareta domenenøytralitet 5. sikre at særnorske utvidelser er basert på konkrete behov

1.5 Informasjon om standardiseringsarbeidet i Difi Difi har fått ansvaret for å forvalte referansekatalogen over anbefalte og obligatoriske IT-standarder i forvaltningen. Difi utreder og hører behovet for anbefalte og obligatoriske forvaltningsstandarder på ulike bruksområder. Difi beslutter de anbefalte standardene og spiller inn ferdig hørte forslag om obligatoriske standarder til KMD, som fremmer de obligatoriske kravene for regjeringen i forskrifts form. Det er etablert et bredt sammensatt Standardiseringsråd med virksomheter fra både statlige og kommunale virksomheter, for å gi råd til Difi. I tillegg opprettes det referansegrupper med spesialist- kompetanse innen de ulike bruksområdene som utredes. Det er utarbeidet en arbeidsmetodikk for å sikre forutsigbarhet og kvalitet i de vurderingene som gjøres. I tillegg gjennomføres det kommentarrunder på utredninger før Standaradiseringsrådsmøter, høring av nye anbefalte krav før de blir tatt inn i referansekatalogen og høring av obligatoriske krav før de tas inn i referansekatalogen/ Forskrift om IT-standarder i forvaltningen. Det er mulig å se eksisterende krav og følge arbeidet med nye krav på http://standard.difi.no.

2 Introduksjon til bruksområdet [Uendret sammenlignet med forrige utredning5] Bruksområdet "Beskrivelse av datasett og datakataloger" gjelder både åpne og begrensede data. Med begrensede data menes data som kun skal deles med en avgrenset brukergruppe med hjemmel til å bruke informasjonen. Bruksområdet handler om hvordan man skal beskrive og utforme datasett og datakataloger.

2.1 Ord, uttrykk og forkortelser

2.1.1 Datasett Et datasett er en samling av data, utgitt eller satt sammen av en enkelt aktør, som er tilgjengelig eller kan lastes ned i et eller flere formater. [Kilde: DCAT Application Profile for data portals in Europe3] (oversatt av Difi) Helt enkelt kan en si at et datasett er en samling med data, for eksempel i form av en tabell, liste eller en database som kan gjøres tilgjengelig som en nedlastbar fil, og/eller nåes via et programmeringsgrensesnitt (API). Begrepet datasett er oftest brukt om innholdet i en enkelt databasetabell, eller statistikkmatrise hvor hver kolonne i tabellen representerer en bestemt variabel, og hver rekke representerer verdier knyttet til hver variabel.

Ofte er informasjonen i fagsystemet strukturert på komplekse måter og vi må dermed av og til dele den opp i flere datasett for å kunne distribuere den slik at dataene kan konsumeres utenfor selve løsningen den er produsert i. Her er noen eksempler på hva et datasett kan være: 1. Rådata fra et system. Her snakker vi om en dump eller kopi av databasen slik den foreligger i et

fagsystem. Ettersom et system ofte inneholder flere databasetabeller, er det hensiktsmessig å distribuere disse som separate datasett.

2. Uttrekk fra et system. Ofte kan delmengder av informasjonen som finnes i et system hentes ut ved å fremstille rapporter. Uttrekk kan enten utføres som en manuell oppgave eller være automatisert som en forhåndsdefinert prosess.

3. Regneark og tabeller. Dette er informasjon som er strukturert i tabeller i for eksempel i Word eller som regneark i Excel.

4. Endepunkt/API. Data som er tilgjengelig gjennom et API (også kalt programmeringsgrensesnitt, applikasjonsgrensesnitt, endepunkt og webservice). Denne typen distribusjon egner seg godt til data som oppdateres ofte.

Felles for alle disse er at beskrivelsene av hva dataelementene representerer, hvordan informasjonen henger sammen og verktøy for å lese gjeldende formater, ofte er avgjørende for å kunne bruke datasettene. Ettersom informasjonen gjerne er delt opp i flere datasett enn den i utgangspunktet var i systemet dataene kom fra, er det viktig å bruke nøkler som gjør det mulig å sette sammen informasjonen igjen. Datasett kan videre deles inn etter tidsaspektet. Dette gir samtidig en indikasjon på hvor de største utfordringene vil ligge i arbeidet med å tilby åpne data:

Historiske datasett: Dette er data som gjør det mulig å se på historiske trender, men sier ikke nødvendigvis noe om situasjonen i dag. Historiske datasett oppdateres ikke.

Periodiske datasett: Datasett som oppdateres ved jevne mellomrom kaller vi periodiske data. Oppdaterte data er dermed tilgjengelige ved faste intervaller. For mange formål er periodiske data tilstrekkelig for å kunne gjøre analyser eller lage tjenester.

Levende data: Levende data, eller sanntidsdata, er data som til enhver tid er oppdatert. Levende data er nødvendig for en del tjenester. Det har f.eks. ingen hensikt å gi reisende som venter på bussen data fra i går.

Historiske data er de enkleste å tilgjengeliggjøre, mens levende data er mer krevende. [Kilde: Difis veileder for tilgjengeliggjøring av åpne dataFeil! Bokmerke er ikke definert.]

2.1.2 Datakatalog En datakatalog er en organisert samling av beskrivelser av datasett. [Kilde: W3C sin Data Catalog Vocabulary (DCAT)] (oversatt av Difi)

2.1.3 Åpne data Data som er fritt tilgjengelig for bruk og viderebruk av alle, både mennesker og maskiner. Dataeiere kan ikke kreve mer enn at man navngir og/eller deler videre på samme vilkår. [Kilde: Open Knowledge Foundation7] (oversatt av Difi)

7 http://opendatahandbook.org/guide/en/what-is-open-data/

2.1.4 Offentlige data Offentlige data er alle data som er organisert, forvaltet og arkivert i offentlig sektor. Offentlige data er data som enten er samlet inn utenfra eller blir utarbeidet av de ansatte i en enhet i offentlig sektor. [Kilde: Difis veileder for tilgjengeliggjøring av åpne dataFeil! Bokmerke er ikke definert.]

2.1.5 Maskinlesbare data Maskinlesbare data er data i et format som kan leses og bearbeides av en dataapplikasjon og dermed lett kan deles på tvers av IT -systemer. Maskinlesbare dataformater, som XML, JSON og CSV egner seg derfor godt som maskinlesbare data. Bildefiler (skannet informasjon) og PDF-dokumenter er eksempler på formater som er krevende for dataapplikasjoner å hente strukturert informasjon fra. [Kilde: Difis veileder for tilgjengeliggjøring av åpne dataFeil! Bokmerke er ikke definert., noe redaksjonelt

redigert]

2.1.6 Applikasjonsprofil (AP) En applikasjonsprofil er en spesifikasjon som gjenbruker termer fra en eller flere basisstandarder, og gjør disse mer spesifikke ved å identifisere obligatoriske, anbefalte og valgfrie elementer som skal brukes i en spesiell anvendelse, samtidig som den anbefaler hvilke kodelister (kontrollerte vokabularer) som skal brukes. [Kilde: DCAT Application Profile for data portals in Europe]

2.1.7 Application Programming Interface (API) API betegner et grensesnitt i en programvare slik at spesifikke deler av denne kan aktiviseres (kjøres) fra en annen programvare. [Kilde: Wikipedia8] API er gjerne også kalt programmeringsgrensesnitt, applikasjonsgrensesnitt, endepunkt, webservice og (data)tjeneste.

2.1.8 W3C The World Wide Web Consortium (W3C) er en internasjonal gruppe som utvikler åpne standarder for å sikre internetts vekst i et langsiktig perspektiv. [Kilde: W3Cs nettside; http://www.w3.org/]

3 Offentlige virksomheters behov på området "Regjeringen ønsker å stimulere til at mest mulig offentlige data blir gjort tilgjengelig for viderebruk. Det må gjøres på en slik måte at det blir enkelt å ta dataene i bruk. Det kan etatene eksempelvis gjøre ved å dokumentere datasettet, kvalitetssikre dataene, strukturere dem på en logisk måte og legge ut datasettet i kjente og tilgjengelige filformater."9 Meld. St. 27 (2015-2016) Digital agenda for Norge10 slår fast at "Informasjon til forvaltningen skal leveres kun én gang […] Forvaltningen skal gjenbruke informasjon i stedet for å spørre brukerne på nytt om forhold de allerede har opplyst", og at "Regjeringen vil: At den enkelte virksomhet har oversikt over hvilke data den håndterer, hva dataene betyr, hva de kan brukes til, hvilke prosesser de inngår i og hvem som kan bruke dem."

8 http://no.wikipedia.org/wiki/API_(programmering) 9 http://www.regjeringen.no/nb/dokumentarkiv/stoltenberg-ii/fad/Nyheter-og-pressemeldinger/pressemeldinger/2013/vil-apne-for-okt-bruk-av-offentlige-data.html?id=720467 10 https://www.regjeringen.no/no/dokumenter/meld.-st.-27-20152016/id2483795/?q=&ch=2#KAP7

Difi-rapport 2013:10 om informasjonsforvaltning har som krav til god informasjonsforvaltning at "verksemda har oversikt over data ho handsamar". En slik oversikt krever dokumentasjon av datasett, og en katalog/"inventarliste" som samler disse beskrivelsene også internt i etatene. Vi vil derfor ikke begrense oss kun til åpne data i dette arbeidet, men identifisere en standard som kan brukes til å beskrive alle datasett i offentlig sektor, i tråd med kravene til god informasjonsforvaltning. En slik oversikt skal inneholde nødvendige beskrivelser av datasett som gir brukerne tilstrekkelig informasjon, og som gjør det enkelt å søke i datasettene. For å lette søket på tvers av offentlig sektor, bør også beskrivelsen være gjenkjennbar fra etat til etat, noe som krever en standardisering. Internasjonalt har en også sett behovet for en slik standard, og W3C anbefalte i 2014 standarden DCAT (Data Catalog Vocabulary) til dette formålet. EU-kommisjonen har laget en applikasjonsprofil for denne (DCAT-AP) som skal brukes på datasett og datakataloger i Europa. Formålet med DCAT er å legge til rette for samhandling (interoperabilitet) mellom datakataloger som er publisert på internett. EUs applikasjonsprofil (DCAT-AP) er utviklet mer spesifikt for åpne data-portaler, særlig EUs portal for åpne data (http://open-data.europa.eu/). Kommisjonen sier som en begrunnelse at mye av informasjonen som er nyttig å utveksle, finnes som datasett i dataportaler, og et felles format for datautveksling vil støtte deling, søk og gjenbruk. Behovskartleggingen som ble gjennomført i forbindelse med forrige utredning5 viste en unison enighet om at det er behov for en standard. Argumentene som ble brukt var at offentlig sektor trengte en felles framgangsmåte for beskrivelse av datasett og datakataloger, og at dette var viktig for å kunne sammenlikne på tvers av etater og kilder, og gjenbruke/viderebruke data. En standard vil spare brukerne for arbeid og gi en felles forståelse av elementene som beskrives. En overordnet standard på katalog- og datasettnivå vil også gi grunnlag for datadefinisjoner (variabler) på neste nivå. Standardiseringsarbeidet passer sammen med, og må ses i sammenheng med, arbeidet som nå er i gang rundt informasjonsforvaltning i offentlig sektor (ledet at Brønnøysundregistrene og Difi – del av Veikartarbeidet). En standard vil i tillegg bidra til å gi etatene et bevisst forhold til dataene de forvalter. Det ble også sagt at det ville være nyttig med en nasjonal standard som en "kjerne", og så kan ulike fagmiljø eventuelt utvide med informasjon som er nødvendig for deres fagområde.

3.1 Behov som ligger til grunn for oppdatering av standarden

3.1.1 EUs revisjon av DCAT-AP Allerede i forbindelse med forrige runde i Standardiseringsrådet var det varslet en rask revisjon av standarden for å oppnå samsvar mellom EUs DCAT-AP og DCAT-AP-NO. EUs DCAT-AP versjon 1.1 ble publisert i august 2015 og inneholdt totalt 32 endringer i forhold til versjon 1.0. Endringene er implementert i høringsforslaget for DCAT-AP-NO v. 1.1

3.1.2 Behov identifisert i piloten «Stresstest av DCAT-standarden» I løpet av første kvartal 2016 ble det gjennomført en pilot, «Stresstest av DCAT-standarden», i regi av Difi som på ulike måter testet ut EUs DCAT-AP v. 1.1 i et utvalg av offentlige virksomheter. Formålet med piloten var å teste ut EUs DCAT-AP v. 1.1 i et utvalg virksomheter med vekt på offentlig sektors behov knyttet til en felles datakatalog på tvers av forvaltningen. Her deltok Skatteetaten, Nav, Statens vegvesen, Kartverket, Statens pensjonskasse, Brønnøysundregistrene og Fiskeridirektoratet.

I piloten ble det utarbeidet en prioritert liste over identifiserte behov. Behovene som angår standarden direkte og som er i tråd med kriteriene for revisjon er lagt til grunn i revisjonsarbeidet (se http://bit.ly/p1behov for en mer komplett oversikt).

Tittel Beskrivelse

Identifikator Behov for å kunne ha en id som er lik på tvers av kataloger, slik at man kan kjenne igjen et datasett. Denne må derfor være globalt unik, typisk i form av en URI.

Flere formater på en distribusjon11

En distribusjon må kunne ha flere formater. Det virker ulogisk at det er én distribusjon per format, spesielt for API'er ettersom de gjerne leverer data i flere formater og muligheter for å forhandle om format. Gjelder også for sluttbrukertjenester der brukeren (et menneske) først må gjøre et utvalg for deretter å eksportere resultatet (spørringen) i foretrukket format.

Ikke mulig å registrere hjemmel

Behov for å registrere hjemler12 for datasett. Trenger to nye attributter på for datasett. Skjermingshjemmel og innsamlingshjemmel.

Dokumentasjon på variabelnivå

Behov for å legge inn dokumentasjon på variabelnivå – altså en utlisting av elementene i datasettene (med definsjoner) utover sentrale begreper

Datakvalitet Behov for struktur for å registrere datakvalitet.

Ulike typer titler Behov for å registrere ulike typer titler. Lang, kort, forkortelse. Eks. Arbeidsgiver-arbeidstakerregisteret, AA-registeret, AAREG

Tidsserier Behov for anbefaling for hvordan man skal registrere tidsserier. Mangler relasjon for å evt peke til neste og forrige datasett.

Enhet i datasettet Behov for å beskrive hvilken enhet(er) som datasettet omhandler. (Hva er det man kan telle?)

Autoritativ kilde Behov for å angi at et datasett er å betrakte som autoritativt/masterdata. Noen datasett samles inn av virksomheten og den er en autoritativ kilde for dette. Datasettet kan også distribueres av andre virksomheter, men da er de ikke en autoritativ kilde.

Bruk av felter Behov for å oppklare hva som er forskjellen på landingsside og accessURL.

Unntak fra conformsTo Behov for å beskrive unntak fra dct:standard.

Begreper Vi må ha en mulighet til å peke på begreper fra et dataset. Egenskap dct:subject og med område skos:Concept.

Rullerende periode på datasett

Behov for å angi periode på rullerende datasett. Eksempelperiode: siste fem år

Skille mellom api og fil Behov for å skille mellom en nedlastbar fil med xml-format pakket med zip, og et api-endepunkt som tilbyr de samme dataene i xml og JSON.

11 En distribusjon er en spesifikk måte å gjøre et datasettet tilgjengelig på. Hvert datasett kan være tilgjengelig på flere måter, for eksempel i ulike format eller fra ulike nettadresser. Eksempel på distribusjoner kan være nedlastbar CSV-fil, et API eller en RSS-strøm. 12 Forvaltningen må ofte ha lovhjemmel for å samle inn opplysninger. For eksempel er Enhetsregisteret hjemlet i «Lov om Enhetsregisteret» https://lovdata.no/dokument/NL/lov/1994-06-03-15. Skjermingshjemmel refererer til hjemmel (kilde for påstand) i offentlighetsloven, sikkerhetsloven, beskyttelsesinstruksen eller annet lovverk som ligger til grunn for vurdering av tilgangsnivå - altså skjerming av datasettet.

Organisasjoner/aktører på tvers av kataloger

Behov for å entydig kunne identifisere en organisasjon når det skal høstes datasett på tvers av kataloger. Spesielt siden domenekataloger, som Geonorge, inneholder datasett fra ulike utgivere.13

Bruksbegrensning for datasett

Behov for mulighet til å angi hva data kan brukes til og ikke. "Ikke bruk data til navigasjon"

Beskrivelse av datasett Behov for å kunne beskrive at noe man kunne forvente finnes, ikke gjør det.

Datofelt er vanskelige å forstå

Behov for å klargjøre hvordan datofelter skal brukes. Gjelder de datasett eller beskrivelsen?

Distribusjonsmetoder med flere formater.

Tungvint å utrykke at én distribusjonsmetode har flere formater. For eksempel at api’er tilbyr ulike formater. Det skjer også at accessURL er den samme for ulike formater, når man benytter accept-headers for REST-api.

Eier av datasett Behov for å kunne angi eier av datasett, ulik fra creator og publisher.

Flere roller mot Enhet Behov for å angi hvem som har produsert, eier, forvalter eller publiserer et datasett

Uklart hva utgivelsesdato skal brukes til

Behov for å avklare bruk. Er det hver gang datasettet utgis, første gang, eller når datasettet ble opprettet?

Tilgangsnivå, kommentar Behov for å kunne beskrive hvorfor et datasett et begrenset

Uklarhet om identifikator og landingsside

"Identifikator og Landingsside blir ofte den samme siden."

3.1.3 Behov identifisert i prosjektet «Felles datakatalog» Brønnøysundregistrene sitt prosjekt "Felles datakatalog" omhandler etablering av en felles nasjonal løsning for å holde oversikt over data det offentlige besitter. En funksjonell spesifikasjon er utviklet i tett samarbeid med 13 offentlige virksomheter: Brønnøysundregistrene, Difi, Skattetaten, NAV, Kartverket, SSB, Helsedirektoratet, Lånekassen, KS KommIT ved Oslo Kommune, Arkivverket, Politiet, Statens Pensjonskasse og Veivesenet. Spesifikasjonen inneholder et sett med behov som er uttrykt i form av brukerhistorier. Følgende behov har relevans for standarden og er ikke tilstrekkelig dekket i DCAT-AP-NO versjon 1.0:

FDK-10: Som forretningsutvikler/funksjonelt ansvarlig ønsker jeg å se begreper (betydning og definisjon) som benyttes i datasettet slik at jeg kan vurdere om datasettet er egnet for mitt formål

FDK-11: Som forretningsutvikler/funksjonelt ansvarlig ønsker jeg å se datasettets populasjon/dekning slik at jeg kan vurdere om datainstansene jeg trenger er med i utvalget

FDK-15: Som forretningsutvikler/funksjonelt ansvarlig ønsker jeg å se beskrivelser av datasettets avgivere/opphav slik at jeg kan vurdere kvalitet i mitt bruk

FDK-17: Som forretningsutvikler/funksjonelt ansvarlig ønsker jeg å se hvilke restriksjoner det ligger på dataene slik at jeg må ta hensyn til disse

13 Behovet oppstår både fordi utgiver ikke er obligatorisk egenskap i versjon 1.0 og fordi angivelsen ikke alltid er entydig (jf «Difi» og «Direktoratet for forvaltning og IKT»). Når datakataloger høster fra andre kilder/kataloger (eller virksomheter publiserer datasett på vegne av andre) er det ikke et 1:1 forhold mellom utgiver av katalogen og utgiver av datasettene.

FDK-18: Som forretningsutvikler/funksjonelt ansvarlig ønsker jeg å se hvilket formål som ligger til grunn for innhenting av opplysningene i datasettet slik at jeg kan vurdere om jeg har det samme formålet

FDK-19: Som forretningsutvikler/funksjonelt ansvarlig ønsker jeg å se hvilken hjemmel som behandlingen bruker for innhenting av opplysningene i datasettet slik at jeg kan vurdere om jeg har hjemmel for å gjenbruke dem med samme grunnlag

FDK-20: Som forretningsutvikler/funksjonelt ansvarlig ønsker jeg å se hvilken hjemmel andre benytter for bruk av dette datasettet slik at jeg kan vurdere om jeg kan bruke samme hjemmel

FDK-21: Som forretningsutvikler/funksjonelt ansvarlig som har valgt å utvikle en tjeneste ønsker jeg å registrere hjemmel for mitt bruk av datasettet slik at andre kan vurdere om de kan også benytte denne hjemmelen

FDK-26: Som forretningsutvikler/funksjonelt ansvarlig ønsker jeg å se på datasettets presisjon slik at jeg kan vurdere om det er tilstrekkelig presist for mitt formål

FDK-27 Som forretningsutvikler/funksjonelt ansvarlig ønsker jeg å se om dataene i datasettet har riktig nøyaktighet (sannhet/autoritativitet) slik at jeg kan vurdere å bruke det i mine prosesser.

FDK-29: Som forretningsutvikler/funksjonelt ansvarlig ønsker jeg å se hvem som bruker datasettet slik at jeg kan se brukere og kontakte andre brukere for å få deres erfaring på kvalitet

FDK-43: Som forvalter av en (sektor-) datakatalog ønsker vi at det benyttes felles måte å identifisere datasett slik at anvendeligheten øker og man kan sammenstille datasett på tvers av datakataloger

FDK-51: Som saksbehandler med ansvar for regelverksutvikling ønsker jeg å analysere innhold i ulike registre utfra definerte begreper og lovreferanser slik at jeg kan se på dette i forbindelse med regelverksutvikling.

LDK-1: Som forvalter av en lokal datakatalog ønsker vi at alle datasett har unike identifikatorer slik at vi enkelt kan identifisere dubletter i felles datakatalogen om flere datakataloger aggregerer like beskrivelser

LDK-7 Som forvalter av en lokal datakatalog ønsker vi å finne kodeverk i vår datakatalog slik at vi kan gjenbruke/viderebruke disse.

LDK-14: Som forvalter av en lokal datakatalog ønsker vi å knytte hjemmel til datasettene slik at man kan avklare viderebruk og gjenbruk

4 Kartlegging av standarder på bruksområdet Denne utredningen handler om revisjon av en nylig vedtatt standard. I forrige utredningsrunde ble flere aktuelle standarder vurdert. Siden denne utredningen handler om revisjon relativt kort tid etter at forrige utredningsarbeid ble gjennomført, ser vi ikke behov for å foreta en ny kartlegging og vurdering av aktuelle standarder for dette bruksområdet. Siden forrige utredningsrunde har imidlertid EU utviklet GeoDCAT-AP som er en applikasjonsprofil med utvidelser beregnet på geodata. En egen profil for statistiske data, StatDCAT-AP, er også under arbeid og planlagt ferdigstilt innen utgangen av september 2016. Begge bygger på DCAT-AP og er ikke konkurrerende standarder eller applikasjonsprofiler. I arbeidet med revisjon må vi derfor sikre at særnorske tillegg til DCAT-AP ikke bryter med egenskaper i GeoDCAT-AP eller StatDCAT-AP. En oversikt

Figur 1: Slektskapet mellom standarder for å beskrive geodata, statiske data og EUs DCAT-AP

I tillegg til Norge, har Nederland, Italia og Sverige utviklet egne nasjonale applikasjonsprofiler basert på DCAT-AP. En uoffisiell sammenstilling av de ulike utvidelsene i DCAT-AP-NL og DCAT-AP_IT er vedlagt, samt et dokument som beskriver den svenske applikasjonsprofilen. Det henvises ellers til forrige utredning5 for aktuelle standarder som ble kartlagt og vurdert.

5 Evaluering av standarder Som forklart i kapittel 4, ser vi ikke behov for å kartlegge og vurdere aktuelle standarder for dette bruksområdet, når denne utredningen handler om revisjon av en relativt nylig vedtatt standard. Det henvises til forrige utredning5 for evaluering av aktuelle standarder.

6 Vurdering av alternativer Som forklart i kapittel 4, ser vi ikke behov for å kartlegge og vurdere aktuelle standarder for dette bruksområdet, når denne utredningen handler om revisjon av en relativt nylig vedtatt standard. Det henvises til forrige utredning5 for evaluering av andre aktuelle standarder. Arbeidet med revisjon har derfor handlet om hvordan vi skal tette gapet mellom identifiserte behov og gjeldende standard (DCAT-AP-NO v.1.0). Som nevnt i kapittel 3 er det tre drivere for en revisjon nå:

Behov for samsvar med siste versjon av EUs DCAT-AP

Behov som er identifisert i forbindelse med piloten «Stresstest av DCAT-standarden»

Behov som er identifisert i forbindelse med forprosjektet for «Felles datakatalog» Revisjonsarbeidet har forholdt seg til følgende overordnede prinsipper i vurderinger av behov og forslag til løsning: Endringer skal…

1. forbedre oppdagelsen av datasett 2. ivareta etterlevelse av DCAT 3. ivareta enkelhet 4. ivareta domenenøytralitet 5. sikre at særnorske utvidelser er basert på konkrete behov

For å oppnå samsvar med DCAT er mulighetsrommet for endringer i en norsk profil avgrenset til følgende endringer:

- Legge til nye egenskaper - Snevre inn praksis (ved å endre beskrivelse) for bruk av egenskaper - Endre status for egenskaper fra anbefalt eller valgfritt til obligatorisk - Endre status for egenskaper fra valgfritt til anbefalt

Ved innføring av nye egenskaper er det lagt vekt på å gjenbruke URIer for etablerte vokabularer (som for eksempel Dublin Core) der disse finnes. Der det ikke har vert mulig å gjenbruke eksisterende vokabularer, er det i forslaget til standard lagt opp til at Difi publiserer og forvalter URIer for disse. I forslaget er denne tilnærmingen valgt for egenskapene skjermingshjemmel 14 og organisasjonsidentifikator15.

6.1 Vurderinger av de særnorske endringene Alle endringer i EUs DCAT-AP er vurdert som viktige for å oppnå samhandlingsevne med andre land. Med noen få unntak er derfor alle endringer tatt inn som en del av DCAT-AP-NO v. 1.1. Avvikene fra DCAT-AP versjon 1.1 og DCAT-AP-NO er følgende: For klassen Datasett: Utgiver er endret fra anbefalt til obligatorisk egenskap. Anbefaling om bruk av URI eller org.nummer er lagt til i beskrivelsen.

- Endringen er vurdert som viktig for å unngå «foreldreløse» datasett i kataloger som er sammensatt av innhold fra andre kataloger. Anbefaling om URI for enhet eller org.nummer gir en mer entydig identifisering.

Tema er endret fra anbefalt til obligatorisk og LOS er er lagt til som anbefalt vokabular

- Endringen er vurdert som viktig for å unngå «foreldreløse» datasett i sluttbrukertjenester som tilbyr tematisk navigering. Vokabularet som pekes på (MDR Dataset theme) er svært overordnet og dermed lett å bruke eller mappe til. Kostnadene er dermed vurdert som lave.

- LOS er lagt til som anbefalt vokabular, ettersom dette er det eneste domenenøytrale vokabularet som finnes for norsk offentlig sektor. Vokabularets egnethet for klassifisering av datasett må vurderes på grunnlag reell bruk. LOS er nå publisert som et SKOS-vokabular: http://psi.norge.no/los/struktur (legg til .html for html-visning)

- Identifikator er endret fra valgfri til obligatorisk egenskap og er i tillegg endret fra å være unik i kontekst av katalogen til en globalt unik identifikator

- Endringene er vurdert som viktige for å sikre entydig identifisering av datasett (og dermed også dubletter) i tjenester som aggregerer datasettbeskrivelser fra flere kataloger.

- For egenskapen dekningsområde er anbefalingen om bruk av vokabularene MDR Continents Named Authority List, MDR Countries Named Authority List og MDR Places Named Authority List fjernet. Bruk av Geonames er påkrevd

- Ifølge DCAP-AP bør MDR vokabularene brukes når det er mulig, og Geonames der MDR ikke er dekkende. Denne delingen er ikke bare problematisk fra et teknisk perspektiv. Den er også

14 https://doc.difi.no/dcat-ap-no/#datasett-skjermingshjemmel 15 https://doc.difi.no/dcat-ap-no/#enhet-organisasjonsidentifikator

vanskelig å opprettholde over tid. Fra et teknisk perspektiv er det svært upraktisk å slå sammen alle fire lister i en stor liste og sortere ut duplikater. MDR Places er dessuten svært lite dekkende og i praksis ikke relevant i norsk kontekst.

Tilgangsnivå er endret fra valgfri til anbefalt egenskap

- Egenskapen er vurdert som nyttig for å unngå at åpne data og data som krever hjemmel for bruk ikke blir underlagt ulike rutiner og prosesser for forvaltning av metadata. Tjenester som retter seg for bestemte brukergrupper (for eksempel Felles datakatalog og data.norge.no), vil ha stor nytte av egenskapen for å indikere det juridiske grunnlaget for deling på en enkel måte til sluttbruker uavhengig av om det foreligger en distribusjon (dataleveranse) eller ikke. Egenskapen var også en del av DCAT-AP-NO versjon 1.0, men ble en del av EUs DCAT-AP versjon 1.1. som valgfri egenskap.

Skjermingshjemmel har fått ny URI og endret område fra dct:RightsStatement til skos:Concept

- Egenskapen er vurdert som nyttig i kombinasjon med «Tilgangsnivå» for å indikere det juridiske grunnlaget for skjerming av datasettet dersom datasettet inneholder opplysninger som skal skjermes for allmenheten. Egenskapen var også en del av DCAT-AP-NO versjon 1.0, men valgt URI for egenskapen ble brukt til egenskapen «Tilgangsnivå» i DCAT-AP v 1.1. Ny URI er satt til dcatno:accessRightsComment og vil bli forvaltet av Difi

- Område(range) er endret til skos:Concept for å oppnå bedre struktur - Et kontrollert SKOS-vokabular skal publiseres og forvaltes av Difi.

Begrep er lagt til som ny anbefalt egenskap

- Egenskapen er vurdert som svært viktig for å sikre at opplysningene i datasettet blir forstått og brukt riktig. Ettersom begrep som for eksempel «lønn», «inntekt» og «samboer» har ulik betydning i ulike virksomheter og i ulike kontekster, bør sentrale begreper som inngår i datasettet refereres til med URIer for å sikre entydighet. Tilnærmingen fordrer revisjon av «Standard for begrepsbeskrivelser». dct:subject er valgt som URI for selve egenskapen i høringsforslaget. Alternativt ble det vurdert å definere «concept» som en egen subklasse til dct:subject. Dct:subject ble vurdert til å dekke behovet.

Skaper er lagt til som ny valgfri egenskap

- Egenskapen er vurdert som nyttig i de tilfellene hvor utgiver og skaper/opphavsmann (opphavsorganisasjon) er ulike virksomheter.

Relasjonene er del av/ har del er lagt til som nye valgfrie egenskaper

- Egenskapene er vurdert som nyttige for å angi at et datasett er en del av et annet. For eksempel når sensitive opplysninger blir vasket og resultatet blir publisert som et nytt datasett med tilgang for alle. Egenskapen kan også være nyttig om det oppstår behov for geografiske eller tematiske «subsett» av et større datasett

Relasjonene krever / er påkrevd av er lagt til som nye valgfrie egenskaper

- Egenskapene er vurdert som nyttige for å angi avhengigheter mellom ulike datasett. For eksempel som relasjon mellom et datasett i form av en kodeliste og selve datasettet der kodelisten er brukt

Relasjonene erstatter / erstattes av er lagt til som nye valgfrie egenskaper

- Egenskapene er vurdert som nyttige for å angi at et datasett ikke lenger er gyldig (og å referer til gyldig versjon) – uten å fjerne det utgåtte datasettet. Eksempel: Offisielle navn og kommunenummer i Norge

relasjonene refererer til / er referert av er lagt til som nye valgfrie egenskaper

- Egenskapene er vurdert som nyttige når datasett inneholder referanse til andre datasett.

For klassen Distribusjon: Egenskapen format er endret fra anbefalt til obligatorisk

- Når et datasett har en distribusjon (altså at datasettet er tilgjengelig), har det nødvendigvis også et format. Vi kan dermed anta at denne opplysningen alltid finnes og er svært lett tilgjengelig. Opplysninge gir økt verdi for sluttbrukerne og for datakatalogen som maskinlesbar ressurs

Egenskapen format er endret til å tillate flere verdier (kardinaliteten endret fra 0..1 til 1..n)

- DCAT-AP tillater kun ett format per distribusjon. Tjenester som leverer samme datasett i flere ulike formater må dermed beskrives som egne distribusjoner selv om dette i praksis blir løst ved hjelp av innholdsforhandling av tjenesten. Dette gjelder også for sluttbrukertjenester der brukeren (et menneske) først må gjøre et utvalg for deretter å eksportere resultatet (spørringen) i foretrukket format.

- Selv om dette bryter med DCAT-AP er ikke endringen et brudd med prinsippet «ivareta etterlevelse av DCAT» ettersom DCAT ikke forholder seg til kardinalitet.

- Ved eksponering til andre dataportaler som benytter DCAT-AP (for eksempel den europeiske opne dataportalen) må data konverteres enten ved å duplisere distribusjoner (en pr format) eller bare oppgi en verdi

Egenskapen mediatype er fjernet fordi egenskapen format dekker behovet

- Egenskapen er utelatt for å unngå to egenskaper med overlappende formål. I følge DCAT-AP skal dcat:mediaType brukes for formater anerkjent av IANA, og dct:format for øvrige formater. Ettersom IANAs vokabular ikke har URIer som gir svar (de-referencable) og ikke er dekkende for behovet, er denne tilnærmingen vurdert som lite nyttig.

Andre endringer:

JSON-LD er lagt til som anbefalt publiseringsformat i tillegg til RDF/XML Egenskapene er gitt norske navn (URIer skal brukes - ikke navnet på egenskapene)

- Begge endringene gjelder også versjon 1.0 og er dermed ikke vurdert på nytt.

6.2 Behov som ikke er løst En del behov er ikke løst i forslaget til ny versjon ettersom områdene er potensielt kompliserte og henger sammen med prosesser både knyttet til arbeidet med felles datakatalog for forvaltningen og signaler gitt av EUs arbeidsgruppe for DCAT-AP knyttet til tjenestebeskrivelser. I tråd med referansegruppens anbefalinger er derfor følgende behov ikke løst i forslaget til versjon 1.1:

Behov for å ha en mer komplett oversikt over dataelementene som et datasett består av utover referanser til sentrale begreper

Behov for å ha oversikt over lovhjemmel for innsamling informasjonen

Behov for å ha oversikt over formål med innsamling av informasjonen

Behov for å ha oversikt over datakvalitet for datasettene

Behov for mer utfyllende beskrivelser av tjenester som leverer data (API-distribusjoner) Selv om høringsforslaget ikke dekker disse behovene på en entydig, strukturert og maskinlesbar måte, er det likevel mulig å oppgi disse opplysningene som en del av beskrivelsen og dokumentasjonen for et datasett. Fremtidige versjoner av standarden bør etterstrebe en mer strukturert og maskinlesbar tilnærming.

7 Enkel vurdering av økonomiske og administrative konsekvenser

Denne utredningen handler om revisjon av en eksisterende standard relativt kort tid etter at den ble vedtatt som en anbefalt forvaltningsstandard. Forrige utredning5 foretok ingen kostnytte-vurdering når det gjelder å innføre DCAT-AP-NO som en anbefalt forvaltningsstandard. Forrige utredning gjorde noen generelle betraktninger og konkluderte med at det er effektiviseringsgevinster å hente ved å ha en slik standard. På oppdrag fra Brønnøysundregistrene og Difi gjennomførte DNV GL en samfunnsøkonomisk analyse for informasjonsforvaltning i offentlig sektor16. For en analyseperiode på 15 år, estimerte DNV GL at det offentlige kan ha et innsparingspotensial på 13 mrd kroner ved at det finnes felles standarder og metoder for arbeid med informasjonsforvaltning på tvers av offentlig sektor, vel å merke er DCAT-AP-NO bare en av mange standarder og veiledere som inngikk i beregningsgrunnlaget for DNV GL. I høringsforslaget er det lagt vekt på en restriktiv bruk av obligatoriske egenskaper. Sammenlignet med forrige versjon er identifikator, utgiver, tema og format gjort til obligatoriske. Det er ikke forventet at dette skal medføre økonomiske eller administrative konsekvenser for forvaltningen.

8 Forvaltningsregime [Uendret sammenlignet med forrige utredning5] Utarbeidelse av nye versjoner av «Standard for beskrivelse av datasett og datakataloger» initieres av Difi, og den primære kilden til nye versjoner vil være endringer i DCAT-AP. Difi vil derfor ha ansvar for å følge med på EUs bruk av, og endringsarbeid knyttet til, DCAT-AP. Arbeidet med en ny versjon av den nasjonale standarden skal som vanlig forankres i relevante organer via høring og behandling i Standardiseringsrådet. Difi vil i forbindelse med nye versjoner av DCAT-AP avgjøre om endringene er så store at det bør nedsettes en egen arbeidsgruppe bestående av relevante aktører, eller om revisjonen kan utføres av Difi selv. Forslaget til ny versjon sendes uansett på høring. De innkomne høringskommentarene behandles hos Difi, og resulterer i et forslag som oversendes Standardiseringsrådet. Difi ønsker å gi brukerne mulighet til å gi tilbakemeldinger og innspill til standarden via Difis nettsider. Slike innspill vil tas med inn i arbeidet med revisjoner initiert av nye DCAT-AP-versjoner,

16 DNV GL: Gevinstpotensialet i et felles konsept for informasjonsforvaltning i offentlig sektor, v.1.1, 22. oktober 2015, https://www.brreg.no/wp-content/uploads/2015/12/Rapport_informasjonsforvaltning_v1.1_sent-_a.pdf

men Difi vil også vurdere tilbakemeldingene en gang i året, for å se om noen av dem bør føre til oppdateringer utenom disse større revisjonene. Dette kan være aktuelt bl.a. fordi den nasjonale standard har noen tillegg til DCAT-AP som f.eks. kan vurderes. Dersom det oppdages mindre feil i standarden (stavefeil etc.), vil ikke korrigering av disse utløse en ny versjon. Disse korrigeringene skal imidlertid dokumenteres i et vedlegg som følger den aktuelle standarden. Gjeldende og eventuelle tidligere versjoner av standarden skal være tilgjengelige på Difis nettsider, slik at det er enkelt å finne ut når tidligere versjoner var gyldige, og hvilke endringer som er foretatt mellom to versjoner.

9 Konklusjon Vi mener den norske profilen av DCAT bør revideres, både for å følge med revisjonen som er gjort i den europeiske profilen av DCAT, men også for å ivareta behov som er identifisert men som ikke var godt nok dekket av forrige versjon av den norske profilen.

Vi anbefaler at den reviderte versjonen av standarden gjøres til en anbefalt standard.

Vedlegg Av praktiske årsaker foreligger ikke vedleggene som vedlagte dokumenter, kun som lenker:

1 Den foreslåtte DCAT-AP-NO v.1.1 https://doc.difi.no/dcat-ap-no/

2 Oppsummering av endringene fra v.1.0 til den foreslåtte v.1.1 https://docs.google.com/spreadsheets/d/13TFSaI3YSnp-1gnaHNrA2svN9thGtaAL61sJ7d-mzI0/edit?usp=sharing

3 Oversikt over prioriterte behov identifisert i piloten «Stresstest av DCAT»

https://docs.google.com/spreadsheets/d/1SDXlx6h5Mxlm2OJ-eUf7le3_Wkl_Nj1qLcXONBWAvw4/edit?usp=sharing

4 Utkast til veileder https://docs.google.com/document/d/1garJn3Ve4UU8YUU0i__zjJRdHigHeFVYAKBzCDrxNjQ/edit?usp=sharing (Dokumentet er åpent for kommentering)

5 Funksjonell spesifikasjon felles datakatalog https://docs.google.com/document/d/1CKnnbObTxdlojGRlAbEAdCiagSxZ-UeejQsYWP-L7jY/edit?usp=sharing

6 Samstilling av endringer gjort i den italienske og nederlandske DCAT-profilen

https://docs.google.com/spreadsheets/d/1LINEhAzn-YRnb8yCCKCyW4v25bp1KL66tZAWWV4jo0w/edit?usp=sharing

7 Forslag til svensk DCAT-applikasjonsprofil https://docs.google.com/document/d/17-vEfZXlu9kykcmjXZo1_Z8QKkr7-Prgwd6YUKLRrjk/edit?usp=sharing