Utprøving av DCAT AP v1.1 for bruk i felles datakatalog for offentlig sektor

Transkript

1 Rapport: Utprøving av DCAT AP v1.1 for bruk i felles datakatalog for offentlig sektor Forfattere: David Skogan, Trond Smaavik Utarbeidet i perioden januar 2016 til mars 2016

2 Innhold Innledning Deltakere DCAT Referanser Datasett Hva er et datasett? Avgrensing av datasett Sensitivt innhold Store datasett Eksempel på oppdeling og beskrivelse av datasett Identifikasjon av et datasett Valg av identifikator Struktur på identifikator Anbefaling Tittel Beskrivelse Relasjoner mellom datasett og andre ressurser Endring av datasett Beste praksis fra W3C Eksempel på endring av datasett Anbefaling Knytte begreper til datasett Tilgangsrettigheter Anbefaling Datofelter Feltbeskrivelser i datasett Datakvalitet Enhet og kontaktpunkt Roller Utgiver Kontaktpunkt Anbefaling Organisasjonsnummer Distribusjon Type distribusjon Format og mediatype Anbefaling Tilgang til data Anbefaling

3

4 Innledning Denne rapporten dokumenterer diskusjoner og resultater fra en utprøving av standarden DCAT AP v1.1 i regi av Difi og SKATE. Formålet med utprøvingen har vært å avdekke offentlig sektor sine behov for å beskrive datasett i kontekst av en felles datakatalog for forvaltningen i Norge. I denne utprøvingen har det vært lagt vekt på å identifisere behov som vil gjøre det enklere for virksomheter i offentlig sektor å oppdage og gjenbruke data fra andre offentlige virksomheter. Representanter fra ulike statlige virksomheter er invitert til å delta. Arbeidet har vært gjennomført med basis i utarbeidelse av beskrivelser av datasett fra disse virksomhetene. Prosessen har avdekket behov og mangler eller uklarheter i standarden. Disse er blitt samlet inn, systematisert og diskutert i tre felles arbeidsmøter for deltakerne. Forslag til løsninger er hovedsakelig utarbeidet av en arbeidsgruppe bestående av to representanter fra henholdsvis Difi og Acando, som også har ledet prosessen. Forslagene til løsning er videre diskutert og validert i arbeidsmøter med alle deltakerne. Rapporten går gjennom utvalgte aspekter ved beskrivelse av datasett og vil være en hjelp til å forstå og bruke DCAT AP v1.1 standarden. En detaljert liste over prioriterte behov og tilhørende forslag til løsning blir presentert i et vedlegg til denne rapporten. Deltakere Følgende personer og organisasjoner har deltatt i arbeidet med utprøving av standarden. Navn David Norheim Joachim Mørk Eidem John Erik Ågotnes Tove Aasheim Anders Bryhni John Martin Furseth Geir Myrind Lars Inge Arnevik Harald Aanderaa Hilde Austlid Kristian Eide John Nonseid Organisasjon Brønnøysundregistrene Brønnøysundregistrene Fiskeridirektoratet Fiskeridirektoratet NAV NAV Skatteetaten Statens kartverk Statens pensjonskasse Statens vegvesen Difi Difi

5 Livar Bergheim Jim Yang Øystein Åsnes David Skogan Trond Smaavik Difi Difi Difi Acando Acando DCAT DCAT AP v1.1 er det gjeldende europeiske spesifikasjonen for beskrivelser av datasett. Formålet er å gjøre det enklere å søke etter datasett på tvers av dataportaler i EUs medlemsstater. Spesifikasjonen er basert på DCAT fra W3C. Videre er det laget en norsk versjon kalt DCAT AP NO 1.0, som igjen er basert på den europeiske. Denne finnes som anbefalt standard i referansekatalogen fra Difi. DCAT AP NO skal revideres i 2016, blant annet med utgangspunkt innspill fra denne rapporten. Referanser DCAT W3C Data Catalog Vocabulary (DCAT), Recommendation 16 January 2014 DCAT AP DCAT Application Profile for data portals in Europe, version 1.1, DCAT NO Standard for beskrivelse av datasett og datakataloger, versjon 1.01, W3C DWBP Data on the Web Best Practices Working Draft 12 January 2016 POD Project Open Data Metadata Schema v1.1, February 2015 Datasett Hva er et datasett? Det kan ofte være vanskelig å forstå hva som menes med datasett. For å klargjøre dette vil vi i dette dokumentet benytte de følgende begrepene som beskrevet under. Datasett skal forstås som data lagret i fil eller database, eller som kan gjøres tilgjengelig gjennom en tjeneste. Dette datasettet kan være tilgjengelig på flere formater. Hvert format angis som en dcat:distribution. Datasettbeskrivelse skal forstås som metadata som beskriver et datasett. Dette uttrykkes med DCAT klassen dcat:dataset. Datasettbeskrivelsen har rollen som en stedfortreder for datasettet og skal samsvare med dette. Datasettserie er en samling datasett som hører sammen, men som er delt opp med hensyn på geografi og/eller tid. I en tidsserie vil hvert enkelt datasett representerer data som er gyldig i en bestemt tidsperiode. I en geografisk serie vil hvert enkelt datasett representere data som er gyldig for en gitt geografisk region.

6 Et datasett kjennetegnes ved at det er er en samling av data som naturlig hører sammen. Eksempler på datasett er enhetsregisteret, bussrute for et fylke eller observasjoner av en fugleart. Hva som naturlig hører sammen vil variere fra virksomhet til virksomhet, og det er i stor grad gitt av hvordan datasettene faktisk finnes i dag. I DCAT har vi kun én type som kan brukes til å beskrive et datasett. Dette er dcat:dataset. Figuren under viser en konseptuell modell av de tre begrepene som er knyttet til datasett. DatasetSeries brukes til å gruppere DatasetDescription og DatasetVersion. Hvor DatasetDescription representerer metadata om datasettet og DatasetVersion representerer en gitt versjon av datasettet. I praksis kan man si at et dcat:dataset representerer både datasett serien, beskrivelsen og den faktiske versjonen. Datasett kan grovt deles inn i to grupper: Datasett som virksomheten samler inn eller produserer selv i en gitt kontekst. Datasett som virksomheten ønsker å dele med andre. Arbeid med å ta frem og beskrive datasett er en iterativ prosess. Selv om et datasett ikke er tilgjengelig for deling med alle, kan det være nyttig for andre å få vite at det finnes. Når man har identifisert et datasett, er det mye bedre å registrere dette i en datakatalog og tilkjennegi at datasettet finnes, enn å vente til man har en avansert løsning på plass for å gjøre det tilgjengelig. I datakatalogen må man registrere dette som en datasettbeskrivelse, men uten distribusjon. Datasett som kan deles, skal man registrere som datasettbeskrivelser og med de distribusjoner man kan levere. Det kan være vanskelig å vite hva andre har behov for, og det bør ikke legges ned mer arbeid enn nødvendig i en tidlig fase. Som et minimum skal alle datasett beskrives med følgende egenskaper: Tittel på datasett Beskrivelse Kontaktperson/fagansvarlig

7 Tittel på datasettet bør være selvforklarende, og så tydelig som mulig si hvilket datasett dette er. En beskrivelse av datasettet bør inneholde en kort oppsummering av hvordan datasettet er kommet i stand og hvilke data som er i datasettet. Det er naturlig å fokusere på å beskrive datasett som oppfattes å være knyttet til virksomhetens kjerneoppgaver. Disse vil trolig være av interesse for flere enn interne anliggender. Gjennom tilbakemeldinger og etterspørsel etter de databeskrivelsene man har publisert, har man grunnlag for prioritering av arbeid med å gjøre datasettene tilgjengelig. Det er også naturlig å beskrive data man allerede deler. Avgrensing av datasett Vi anbefaler som hovedregel at man beskriver og tilgjengeliggjør datasett slik de er. Dette krever minst arbeid, og fordi noen trolig har tenkt på hvordan data skal sammenstilles når datasettet ble laget. Andre ganger er det slik at du ikke er villig til eller kan dele alle data, blant annet på grunn av innholdet. Under følger ulike tilnærminger til avgrensing av datasett. Se også Difis veileder for åpne data: i tilgjengeliggjoring av offentlige data V2.pdf Sensitivt innhold Sensitivt innhold kan være personopplysninger, gradert informasjon, forretningshemmeligheter eller data som andre eier. Hvis datasettet inneholder slik informasjon, kan det være fornuftig å lage et avgrenset datasett med kun de dataene du kan dele med de fleste. Du bør likevel beskrive et datasett som inneholder den informasjonen du har, hvis den i noen tilfeller vil kunne deles med andre. Se også kapittel om tilgangsnivå. Store datasett Hvis datasettet ditt er veldig stort, i den forstand at det omhandler flere ulike tema, kan det være hensiktsmessig å se etter måter å dele det opp på. Slik kan det bli mer håndterbart og enklere å sette seg inn i for brukerne. Hvis, for eksempel, datasettet ditt omfatter kjøretøy, dets eiere og registrerte mangler, kan det vært bedre å dele dette opp i tre datasett. Når man deler opp datasett på denne måten bør man bruke relasjoner i DCAT til å angi sammenhengen mellom de ulike datasettene. Eksempel på oppdeling og beskrivelse av datasett Figuren under viser sammenhengene mellom datasett, beskrivelser av datasett, distribusjoner og beskrivelser av distribusjoner. En virksomhet har en stor mengde data, F0, som de forstår kan være til nytte for andre, og beskriver denne som et dcat:dataset, d0. Siden dataene ennå ikke er tilgjengelige for utenforstående, betyr det at det ikke finnes distribusjoner. På grunn av forespørsler om tilgang til dataene beskrevet i d0, velger virksomheten å lage en tjeneste, F1, tilpasset behovene. Dette beskrives som et nytt datasett, d1, med

8 d0 som kilde. I tillegg opprettes det en distribusjon, dis1, med informasjon om hvordan man får tilgang til dataene i F1. Det kommer nye forespørsler om tilgang til data basert på det som er beskrevet i d0. Virksomheten lager et nytt datauttrekk, F2. I datakatalogen beskrives dette som et nytt dcat:dataset, d2, med d0 som kilde. Siden d1 inneholder beslektede data, som kan kobles med d2, legges det til en referanse til d1. Det opprettes en distribusjon, dis2, med informasjon om hvordan man får tilgang til dataene i F2. Etter hvert som det kommer nye uttrekk av data fra F0 til F2, oppdateres d2 med informasjon som tidsstempel for siste oppdatering. Egenskapene tilgangsurl og nedlastingslenke i beskrivelsen av distribusjonen i dis2 holdes uendret. Dette gjør det enklere for brukerne av dataene, men egenskapene vil all alltid peke til siste utgave av F2. Identifikator for datasett For å kunne angi relasjoner mellom datasett på tvers av datakataloger, er det behov for å kunne referere til et gitt datasett på en entydig måte. Det er behov for en unik identifikator (hovedidentifikatoren) for et datasett eller en datasettserie. Identifikatoren må være bestandig og tilgjengelig. Den må altså være kunne følge datasettet og være obligatorisk. Valg av identifikator Det er angitt to egenskaper for å angi identifikatorer i DCAT AP. I tillegg har RDF sin innebygde ressursidentifikator som angis som en URI. De tre er:

9 1. identifikator (dct:identifier [0..n]) Hovedidentifikatoren for et datasett, f.eks. URIen eller annen identifikator som er unik i kontekst av katalogen 2. annen identifikator (adms:identifier [0..n]) Referanse til en sekundær identifikator av datasettet som MAST/ADS, DataCite, DOI, EZID eller W3ID 3. URI en til dcat:dataset. dcat:dataset er en ressurs, og alle ressurser i RDF skal ha en URI som identifiserer dem. I DCAT fra W3C defineres dct:identifier til å være A unique identifier of the dataset. Til denne definisjonen legger de til: The identifier might be used as part of the URI of the dataset, but still having it represented explicitly is useful. DCAT AP sier: This property contains the main identifier for the Dataset, e.g. the URI or other unique identifier in the context of the Catalogue. Det er upraktisk med mange identifikatorer. Siden RDF bruker URI til å identifisere ressurser og til å peke til andre ressurser (datasett), bør URI en til datasettet være hovedidentifikator og også ligge i dct:identifier. Hver gang et nytt datasett lages (nytt eller ny versjon) skal det ha en unik URI, enten som verktøyet genererer og/eller som kan angis av bruker. Etter at et datasett er publisert så bør man ikke få lov til å endre denne identifikatoren. Dette er også i henhold til W3Cs anbefaling for beste praksis, W3C DWBP, BP11 Use persistent URIs as identifiers of datasets. Struktur på identifikator Utover at hver enkelt datasettbeskrivelse skal ha en unik identifikator, bør det også være en identifikator for serien av beslektede datasett som alltid viser til siste versjon av datasett. W3C anbefaler som beste praksis i DWBP BP13 : Assign URIs to dataset versions and series. Måten W3C har gjort dette på er å la serien identifiseres med en base URI og ha versjonsidentifikatoren som ekstra ledd på denne. I det pågående arbeid med å etablere en forvaltningsstandard for persistente URI er, i regi av Standardiseringsrådet, foreslås blant annet å bruke tidsstempel som versjonsidentifikator og at man bør identifisere objekttypen til ressursen i URI en. Dessverre er det flere foreslåtte felter som ikke gir mening i oppbygningen av en URI, men som heller er spørrerelaterte, derfor kan vi ikke anbefale å følge denne. Vi foreslår følgende format på URI en til et datasett: <serie identifikator>/<versjonsidentifikator> Hvis vi har to datasett kan det se slik ut: Serieidentifikator: Versjon1: T10:31 Versjon2: T14:32

10 Serieidentifikatoren består da av som angir domenet, dataset som angir objekttypen, 42XY39 som er identifikator til objektet. Versjonsidentifikator er tidsstempelet T10:31 som er formatert i henhold til ISO Det betyr at hvis vi tar bort siste leddet i URI en får vi serie identifikatoren. Det bør da være funksjonalitet i datakatalogen som slår opp (resolverer) denne til gjeldende versjon. Dette er slik vi anbefaler å identifisere versjoner av samme datasett og serier av beslektede datasett. Det er opp til de enkelte virksomhetene å ha versjonsstyring på datasett. Se også kapittel om endringer. Anbefaling Oppsummert anbefaler vi følgende for identifikasjon av datasett. URI en til datasett skal være sammensatt av en serieidentifikator og et versjonsledd. Versjonsledd skal angis i form av et datostempel. URI en skal være globalt unik. URI en til datasettet og eneste identifikator i dct:identifier skal være like, og den skal være obligatorisk i DCAT AP NO 1.1. Kardinalitet Man bør kunne registrere ytterligere identifikatorer i adms:identifier uten at disse har begrensninger. adms/#identifier Tittel Tittel er en obligatorisk egenskap for datasett. Tittelen bør være selvforklarende, og så tydelig som mulig si hvilket datasett dette er. Husk at målgruppen er personer som ønsker å finne relevante datasett raskt, unngå derfor interne navn eller forkortelser i tittel. I det offentlige opererer man ofte med flere titler eller navn på ting. Et datasett kan ha et offisielt navn, et kortnavn og en forkortelse. For eksempel: Datasettet Administrative enheter i Norge har ABAS som forkortelse. Det er sjelden man bruker den fulle tittelen, så for å gjøre et datasett mest mulig søkbart er det behov for at man kan registrere kortnavn, forkortelser og/eller alternative titler. Vi anbefaler at et datasett har én tittel per språk. Man bør også angi en dct:title per målform, det vil si nynorsk, bokmål og samisk. Har man behov for kortnavn, forkortelser eller alternative titler så kan disse angis som nøkkelord (dcat:keyword). Da følger vi intensjonen i standarden og siden nøkkelordene bør være tilgjengelig for en søkemotor så vil man kunne finne datasettet slik. Dersom man har egne begreper og knytter disse til datasettbeskrivelsene innebærer dette også en mekanisme for å angi alternative termer og termer på ulike språk for begrepene.

11 Beskrivelse Beskrivelse er obligatorisk for datasett, men det ligger ingen føringer i standarden på hva en beskrivelse bør inneholde. Hensikten med egenskapen er å gi en oversikt over hva datasettet inneholder, og vil være noe av det første man leser. Mange egenskaper i datasettbeskrivelsen er beregnet for å gjøre den søkbar og maskinlesbar, mens beskrivelse er fritekst og retter seg mot mennesker. Informasjon som er nyttig å ta med er derfor slikt som hva datasettet inneholder, hvordan det kan brukes og hva som er grunnlag eller kilde for datasettet. Det kan også være aktuelt å beskrive hvordan datasettet bør, og ikke bør, brukes og hvordan det eventuelt kan kobles med andre datasett. Er det for eksempler mangler eller andre kvalitetsaspekter ved datasettet det er viktig å være oppmerksom på? Relasjoner mellom datasett og andre ressurser W3Cs DCAT har ikke relasjoner mellom datasett, men DCAT AP tillater oss å bruke dct:relation til å referere til andre ressurser. Dette betyr at man kan peke til alt som blir definert som en ressurs av RDF, herunder også datasettbeskrivelser som er av type dcat:dataset. De følgende relasjonene er spesifikt lagt til som en del av standarden. Egenskap Verdiområde Bruk Eksempel Kilde D Peker til ett eller flere datasett som helt eller delvis er en kilde for det aktuelle datasettet. Et datasett med personopplysninger kan være kilde til det datasett hvor disse er fjernet for at det skal kunne deles åpent. Er versjon av D Peker til et datasett som det aktuelle datasettet er en versjon av. Har versjon D Peker til en versjon av det aktuelle datasettet. I samsvar med S Peker til en standard eller spesifikasjon som det aktuelle datasettet eller distribusjonen er i samsvar med. Et datasett er i samsvar med SOSI 4.5 som innholdsstandard. Relasjon R En generell relasjon som peker til ressurser som er relatert til Se under.

12 datasettet. D datasett, S spesifikasjon/standard, R annen ressurs I tillegg til disse basisrelasjonene angitt av DCAT AP standarden, åpnes det for at egenskapen Relasjon kan spesifiseres ytterligere. Flere av relasjonstypene er ganske like, og det bør vurderes hvilken som er mest riktig å benytte i hvert tilfelle, eller om det er tilstrekkelig å benytte dct:relation. Følgende relasjonstyper er mulig. Egenskap Verdiområde Bruk Eksempel Kilde R Peker til ressurs, annet enn datasett, som helt eller delvis er en kilde for det aktuelle datasettet. Et datasett er opprettet basert på data som er hentet fra en nettside, uten at den er definert som et datasett. Er del av/ Har del D Peker til et datasett som det aktuelle datasettet er en delmengde av av, eller at det er brutt opp i mindre datasett. Datasettet Underenheter er del av datasettet Enheter i Enhetsregisteret. Har format/ Er format av Anbefales ikke benyttet siden distribusjoner uttrykker format. Erstatter/ Er erstattet av D Peker til et datasett som erstatter, eller er erstattet av, det aktuelle datasettet. Et kodeverk er fortsatt i bruk, men er erstattet av en nyere utgave. Krever/ Er krevet av R Peker til en ressurs som må være tilstede for at datasettet skal kunne produseres. Refererer til/ refereres fra D Referanse til andre datasett som kan være relevant for å forstå eller bruke det aktuelle datasettet. Datasett med kodeverk eller andre referansedata eller metadata. D datasett, R annen ressurs

13 Endring av datasett For at beskrivelser av datasett skal gi mest mulig verdi til de som søker etter datasett, er det viktig at beskrivelsene representerer de datasett som faktisk finnes. Dette medfører at når data endres, må beskrivelsen av det oppdateres eller det må lages en ny versjon av da den. Det bør være klare retningslinjer for hva som er kriteriene for å opprette en ny versjon av et datasett og for å opprette et nytt datasett. Dette gjelder også for tidsserier av datasett. Diskusjon Når man må endre et datasett, som er tidligere publisert, må man ta stilling til om det skal opprettes ny versjon, en ny tidsserie eller en ny urelatert datasettbeskrivelse. Man bør også tenke på om man bør slette tidligere datasettbeskrivelser hvis man ikke lengre vil tilby disse. I DCAT har man tre valg som er illustrert i figuren under. 1. Man kan angi i oppdateringsfrekvens for datasettet at det blir oppdatert kontinuerlig. Nye data medfører da ikke endringer på datasettbeskrivelsen. Brukere må undersøke om landingsiden eller accessurl gir et nytt datasett. 2. Man kan oppdatere datasettbeskrivelsen. For eksempel ved å endre modifisertdatoen (dct:modified). Man kan angi versjon og versjonsnote som beskriver den nye versjonen. Da kan brukere avgjøre om det er behov for å hente ut et nytt ved å se på modifisertdatoen og versjonsnoten. 3. Man kan utgi en nytt datasettbeskrivelse som representerer den nye versjonen av datasettet. Dette blir likt for tidsserier og versjoner som er vist som to ulike rader i figuren. Et datasett i en tidsserie har gyldighet for i en gitt periode og vil typisk bestå av data som er avledet og i hovedsak representerer nye objekter. En datasettbeskrivelse i en versjonsserie representerer datasett som blir oppdatert og hvor man kan forvente å finne igjen samme objekter i datasett over tid. Forskjellen mellom disse to kan avledes ved å bruke ulike relasjonstyper.

14 Det å lage en ny versjon av et datasett innebærer å lage en ny datasettbeskrivelse som må relateres til den gamle datasettbeskrivelsen den er en versjon av. For å gjøre dette må man holde styr på følgende egenskaper: identifikator (dct:identifier) som unikt identifiserer datasettet versjon (rdfs:literal), versjonsnote (rdfs:literal) som henholdsvis angir versjonsidentifikatoren og beskrivelse av hva som er nytt i denne versjonen Relasjonene erversjonav [0..n] (dct:isversionof) og harversjon [0..n] (dct:hasversion). Hvor vi antar at erversjonav skal peke på datasettet som blir versjonert som så skal peke tilbake til den nye versjonen via harversjon. frekvens [0..1] (dct:accrualperiodicity) som angir hvor ofte datasett blir oppdatert tidsperiode [0..n] (dct:temporal) som angir tidsperioden datasettet omfatter. dekningsområde [0..n] (dct:spatial) som angir hvilket geografisk område datasettet dekker. utgivelsesdato [0..1] (dct:issued) og modifisert [0..1] (dct:modified) som angir henholdsvis når datasettet er publisert og sist oppdatert. datasett distribusjon [0..n] (dcat:distribution) som peker på hvilke distribusjoner som er tilgjengelig for dette datasettet. Beste praksis fra W3C W3C DWBP anbefaler i BP8 Provide version information at man skal lage nye versjoner av et datasett hvis de fysiske dataene endres. For tidsserier og geografisk delte datasett så anbefaler de at man lager nye datasett (ikke versjon). Noen datasett blir oppdatert regelmessig, noen mer sporadisk. Et datasett blir oppdatert for eksempel fordi man endrer innsamlingsmetode eller fordi nye dataelementer blir oppdaget. For å håndtere disse

15 endringene så anbefaler W3C at man oppretter en ny versjon av datasettet. Dette selv for små endringer i dataene. De anbefaler videre at hvis man kan aksessere dataene gjennom et API, så bør det gi siste versjon av dataene, men at man i tillegg skal kunne angi en spesifikk versjon. W3C DWBP anbefaler i BP9 Provide version history at man skal angi versjonshistorikk når man versjonerer datasett. Dette for at brukerne skal kunne ta avgjørelser ut fra hva som er gjort med datasettene som er tilgjengelig. W3C DWBP anbefaler at ved tidsserier eller oppdeling av et datasett i ulike geografiske deler så skal man ikke lage en ny versjon av forrige datasett. I slike tilfeller bør det opprettes egne datasett, fordi de dekker ulike observasjoner av virkeligheten. Et eksempel på en tidsserie er ukentlige værvarsler for et gitt område. Hver uke så bør det opprettes et nytt datasett. Eksempel på endring av datasett Vi tenker oss et transportselskap som gjennom sin datakatalog har tilbudt et datasett (D1) som inneholder busstopp og rutetabell for Trondheim og et annet datasett (D2) for Steinkjer. Under følger noen scenarier over ulike endringer som kan skje med slike datasett, og forslag til hva disse vil kunne medføre for datasett og beskrivelser. Scenarier: 1. En ny busstopp er opprettet og skal legges til i D1. 2. En eksisterende busstopp er fjernet og må slettes fra D1. 3. En feil i rutetabellen er oppdaget og den må korrigeres i D1. 4. Transportselskapet utvider bussruten i D1 til å dekke hele Sør Trøndelag. 5. Selskapet ønsker å slå sammen D1 og D2 til ett datasett. 6. Selskapet vil ikke lengre tilby datasett D2 for Steinkjer. 7. Selskapet ønsker å utgi minuttbaserte datasett som angir sanntidsdata for hvor bussene er og når de ankommer neste holdeplasser. 8. Selskapet ønsker å endre metadataene (datasettbeskrivelsen), legge til noen nøkkelord og noen relasjoner til begreper og andre datasett. 9. Selskapet beslutter å legge ved nye objekter som viser bilder av holdeplassene. Løsninger: Scenario Beskrivelse 1, 2, 3 Endring av data: Legger til en ny holdeplass eller endre andre relaterte dataelementer. Naturlig å velge ny versjon. Bør beskrive versjonsnote. Oppdatere isversionof og hasversion relasjoner. 4 Endring i dekningsområde, utvidelse eller reduksjon av geografisk område. Om man velger ny versjon eller nytt datasett er nok noe avhengig av hvilke datasett som er gjort tilgjengelig før. Det bør være greit å utvide dekningsområde og lage

16 en ny versjon hvis man ikke tilbyr andre datasett som har overlappende område. Men det kan i praksis være enklere å lage et nytt datasett. 5 Endring av tjenestenivå. Brukerne må nå forholde seg til ett datasett. Det nye er summen av de to forrige. Da er det naturlig at det lages et nytt datasett D3. Det å flytte data fra ett datasett til det andre vil nok oppleves som merkelig av brukere. Man må også ta stilling til hva som skal skje med de gamle datasettene. Skal de slettes eller bli liggende med distribusjon merket med utgått gitt i adms:status. Hvis datasettet fortsatt skal tilbys bør det merkes med tidsperiode og/eller med relasjon til datasettbeskrivelse (replacedby) Tilsvarende hvis et datasett deles i to så bør en lage to nye datasett. 6 Endring i tjenestenivå. Virksomhet vil eller kan ikke lengre tilby datasettet. Her er det flere valg. Å slette datasetts distribusjoner, eller å sette distribusjonens status som utgått, eller å slette datasettet med sine distribusjoner. Dette handler mer om hva virksomheten ønsker å gjøre. Finnes det en datasettbeskrivelse i katalogen så forventer brukerne at de kan hente ut data for det. Det kan løses med å tilby historiske data. 7 Hvert minutt ønsker man å utgi et datasett som angir hvor bussen er og hvor lang tid det vil ta å nå neste holdeplass. Dette er en tidsserie der datasettene genereres på bakgrunn av nye målinger for hver gang. Forrige datasett kan ikke direkte relateres til neste datasett da tallene blir løpende produsert. Her er det naturlig med nye datasett i en serie eller ikke versjonere datasettet. 8 Endring i datasettbeskrivelsen. Dette vil ikke påvirke eksisterende brukere, så det er ikke nødvendig å lage et nytt datasett eller versjon. Modifisertdato skal ikke endres. 9 Endring i struktur i data. Dette vil oppleves som et endret tjenestenivå og kan ha stor betydning for brukerne av dataene. De må sannsynligvis bygge inn ny funksjonalitet i sine systemer. Av den grunn så bør dette være et nytt datasett. Her bør virksomheten vurdere om de skal fortsette å gi ut data i henhold til det gamle datasettet i en periode. Anbefaling Tidsserier og spesielt versjonering av datasett i DCAT er noe komplisert. Det er mange egenskaper som skal settes riktig og hvis vi skal følge anbefalingene fra W3C kan dette føre til at man får mange tilnærmet like datasettbeskrivelser i katalogen som relatert til hverandre. Dette må eventuelt tas hensyn til ved etablering av innsyns og søkefunksjonalitet. Antall datasett vil øke betraktelig hvis det skal opprettes ny versjon hver gang de fysiske dataene

17 endres. W3C anbefaler at når man versjonerer et datasett så skal man i prinsippet også tilby de forrige versjonene av datasettet til brukeren. Virksomheter har egentlig tre valg: 1) Ikke bruke versjoner eller tidsserier, men heller angi oppdateringsfrekvens. Brukere må selv finne ut om dataene er oppdatert ved å bruke API eller aksess url. Vi anbefaler å starte med denne fremgangsmåten. 2) Ved behov, bruke versjoneringsmekanismen der dataene er av en slik art og/eller bruken av dem er slik at det gir mening å tilby flere versjoner av samme datasett. Man bør vurdere behovet for hvor mange versjoner det kan bli behov for og for eksempel bruke en to nivå versjonshåndtering der kun hovedversjoner publiseres som egne versjoner i datakatalogen. 3) Ved behov, bruke tidsserier og relatere datasett til hverandre. Når man regelmessig produserer datasett på bakgrunn av beregninger eller nye innsamlinger bør man vurdere å opprette tidsserier av uavhengige datasett. Det anbefales at det følgende prinsipp følges: Når man lager et nytt datasett som har distribusjon så skal man kunne levere data på det. Derfor bør man også ha en strategi for å slette de datasettene som ikke lengre skal være tilgjengelig. Knytte begreper til datasett Noen virksomheter har egne kataloger over sine sentrale begreper. Flere ønsker å knytte begreper fra egen eller andres begrepskatalog til datasettet for å gjøre det lettere for andre å finne det og relaterte datasett. Det anbefales at for DCAT AP NO 1.1 innføres dct:subject som anbefalt egenskap på dcat:dataset med verdiområde skos:concept. Norsk navn på egenskapen blir begrep. I de tilfeller hvor det ikke finnes et begrep å peke til, benyttes egenskapen emneord (dcat:keyword) til å beskrive datasettet på tilsvarende måte. Se også Difis anbefaling omkring arbeid med begreper og terminologi: og definisjonsarbeid Autorativ kilde Det er identifisert et behov for å kunne uttrykke at et datasett er å anse som autorativt. Enkelte virksomheter i det offentlige har datasett som innen sitt område eller nasjonalt er å anse autorative kilder. Eksempler på slike datasett er enhetsregisteret og folkeregisteret. DCAT AP har ikke egen egenskaper som kan benyttes til å uttrykke dette. En slik egenskap vil være nyttig i forbindelse med søk i datakataloger. Det anbefales derfor at det innføres en valgfri, bolsk egenskap i DCAT AP NO 1.1 som får navnet dcatno:autorativt. Virksomheter som utgir

18 autorative datasett kan da gjennom selvdeklarering angi om et datasett er autorativt. Ved behov for detaljer utover dette henvises det til bruk av egenskapen beskrivelse, eller dokumentasjon for datasettet. Tilgangsrettigheter I arbeidet med å vurdere DCAT AP for bruk til felles datakatalog i offentlig sektor har flere pekt på behovet for å kunne knytte ulike hjemler til et datasett, herunder hjemmel for rett til innsamling av data i et datasett og hjemmel for å kunne skjerme et datasett for innsyn. Etter innspill fra jurister er det likevel valgt å ikke tilby en mekanisme for å eksplisitt kunne knytte hjemler til et datasett. Dette fordi det må gjøres en juridisk vurdering av hvert tilfelle hvor et datasett kan være aktuelt å ta i bruk. Det ansees derfor som uhensiktsmessig å på forhånd forsøke å uttrykke hvilke hjemler som vil være aktuelle. For å imøtekomme behovet for å kunne uttrykke hvilke juridiske forutsetninger som må være tilstede for at et datasett skal kunne benyttes av andre, anbefales det å benytte egenskapen tilgangsnivå (dct:accessrights). Denne er knyttet opp mot et vokabular som har verdiene offentlig, begrenset offentlighet og unntatt offentlighet. Dersom det oppstår behov for flere nivåer enn dette, kan det bli aktuelt å innføre dette på et senere tidspunkt. For en mer fleksibel mekanisme enn hjemler, anbefales det at egenskapen rights fra 1 metadataskjemaet til Project Open Data leges til i DCAT AP NO 1.1. Denne egenskapen benyttes til å gi kommentarer til det tilgangsnivået som er valgt. Datofelter DCAT AP inneholder en rekke datofelter. Datoer i DCAT AP skrives som xsd:date eller xsd:datetime. Dato kan uttrykkes slik Tidsstempel med tidssone kan uttrykkes slik T09:30:10Z eller T09:30:10 06:00. Egenskap Klasse Beskrivelse Utgivelsesdato Katalog Dato/tid katalogen først ble publisert. Modifisert Katalog Dato/tid sist katalogen ble endret. Dette kan være endring av en datasettbeskrivelse, eller andre metadata i katalogen. Utgivelsesdato Datasett Dato/tid datasettet ble gjort publisert som en del av katalogen. Modifisert Datasett Dato/tid sist datasettet sist endret seg. 1 open data.cio.gov/v1.1/schema/#rights

19 Tidsperiode Datasett Tidsperiode datasettet gjelder for. Minst startdato/starttid eller sluttdato/sluttid må angis. Egenskapen må sees som et tidsstempel for registreringen av første og siste dataelement i datasettet. Det kan angis flere tidsperioder per datasett. Det anbefales at periodene ikke er overlappende. Tidsperiode må ikke forveksles med tidsmessig gyldighet for informasjonselementene, da data kan ha gyldighet som strekker seg både før og etter dataelementene er registrert. Utgivelsesdato Distribusjon Dato/tid distribusjonen først ble publisert i tilknytning til et datasett. Modifisert Distribusjon Dato/tid sist distribusjonen sist endret seg. Feltbeskrivelser i datasett For å kunne avgjøre om et datasett kan anvendes kan det være nyttig å se beskrivelser av feltene som inngår i datasettet. DCAT AP inneholder flere valgfrie egenskaper som kan benyttes til å beskrive innhold i datasett på feltnivå. Det tillates at egenskapene gjentas flere ganger. Dersom det er behov for å tilby strukturerte beskrivelser av innhold, felter og kodeverk med mer som er relevant for det aktuelle datasettet, kan egenskapene i tabellen benyttes. Disse vil sammen kunne beskrive innhold i datasett slik at det vil være mulig for en person å vurdere om datasettet inneholder de tilstrekkelige opplysningene. Egenskap Type Verdiområde Beskrivelse I samsvar med Datasett dct:standard Kan benyttes til å angi at et datasett er i samsvar med en standard, spesifikasjon eller implementasjonsregel. Eksempel: Et datasett er i samsvar med SOSI 4.5 som innholdsstandard. Dokumentasjon Datasett foaf:document Kan benyttes til å peke til en side eller et dokument som beskriver og dokumenterer innhold og struktur i datasettet. Eksempeldata Datasett dcat:distribution Benyttes for å gi eksempeldata for et datasett, og hvordan en faktisk distribusjon ser ut. I samsvar med Distribusjon dct:standard Benyttes for å angi et etablert skjema som distribusjonen er i samsvar med, for eksempel

20 et XSD dokument. Dokumentasjon Distribusjon foaf:document Kan benyttes til å peke til en side eller et dokument som beskriver og dokumenterer innhold og struktur spesifikk for distribusjonen. Datakvalitet Formålet med å beskrive datasett på en strukturert måte er at det skal bli enklere å oppdage de og avgjøre om de kan gjenbrukes i en gitt sammenheng. DCAT AP inneholder i utgangspunktet ingen egne egenskaper eller mekanismer for å beskrive datakvalitet. Selv om det er behov for å kunne vite hvilken datakvalitet et datasett har, ansees dette for å være mer detaljer enn det standarden har som oppgave å omfatte. Dersom en datatilbyder har eller ønsker å dele informasjon om datakvalitet, kan dette likevel være til stor nytte for gjenbrukere av data. Datakvalitet anbefales beskevet i dokumentasjon om som legges ved en datasettetbeskrivelse. Se anbefaling om dokumentasjon av feltbeskrivelser i datasett, da de samme egenskapene for datasett er relevante i denne sammenhengen. I tillegg kan det være relevant å kort si noe om datakvalitet i beskrivelsen av datasettet. Enhet og kontaktpunkt Roller Det er behov for å kunne angi ulike roller på virksomheter, enheter og personer. For eksempel hvem som har produsert et datasett, hvem som eier, forvalter eller publiserer det, eller andre kontaktpersoner. I DCAT AP er det kun utgiver av datakataog og datasett som er definert som en egen rolle. Standarden åpner for å utvide med flere roller, men disse må være basert på konkrete behov. Utgiver Egenskapen utgiver (dct:publisher) finnes for både datakatalog og datasett. Henholdsvis som obligatorisk og anbefalt felt, med én verdi tillatt. Utgiver som er ansvarlig for å publisere katalogen eller datasettet. Det trenger ikke å være samme utgiver på datasett som det er på katalogen. For å representere en utgiver bruker man klassen enhet (foaf:agent), som har undertypene group, person og organization. Når standarden benyttes i offentlig sektor, vil det er være organisasjoner som er ansvarlige utgivere. Det anbefales at type organisasjon angis ved bruk av vokabularet

21 Kontaktpunkt Kontaktpunkt (dcat:contactpoint) for et datasett er et valgfritt felt som kan gjentas flere ganger. Det skal brukes til å angi kontaktinformasjon som kan brukes til å sende kommentarer om et datasett. I motsetning til dct:agent er dcat:contactpoint ikke ment til å peke på en organisasjon eller person, men kun kontaktinformasjon. Verdiområdet til kontaktpunkt er vcard:kind, som har disse undertypene: Type Individual Organization Group Location Beskrivelse For å representere personer For å representere organisasjoner, eller avdelinger av organisasjoner. For å representere grupper av vcard objekter For å representere lokasjonsobjekter Rolle kan angis på alle undertypene ved bruk av vcard:hasrole. Bruk av vcard:hastitle kan også være aktuelt. Forskjellen består i at rolle kan brukes mer i kontekst av datakatalogen, med verdier som faglig ansvarlig og teknisk ansvarlig, mens tittel er mer spesifikk med verdier som for eksempel leder for statistikkavdelingen eller it driftsingeniør. Anbefaling Rollen utgiver er obligatorisk for en datakatalog og skal peke på den organisasjonen som er eier og forvalter av datakatalogen. Type organisasjon bør angis. Rollen utgiver er obligatorisk for et datasett og skal peke på den organisasjonen som er eier og forvalter av datasettet. Type organisasjon bør angis. Dersom det er behov for å angi roller knyttet til et datasett bør dette gjøres ved bruk kontaktpunkt og det underliggende feltet rolle. Anbefalte verdier for rolle på kontaktpunkt er Teknisk kontakt, Faglig kontakt og Metadatakontakt. Organisasjonsnummer Det er uttrykt behov for å kunne angi organisasjonsnummer for en enhet. Dette er det ikke direkte støtte for i standarden nå. Dersom det skal være mulig å angi organisasjonsnummer på en strukturert måte, må standarden utvides ved å definere en egenskap som kan bære denne informasjonen. Denne egenskapen må videres tillates angitt på foaf:agent for utgiver og vcard:kind for kontaktpunkt.

22 Distribusjon En distribusjon er en beskrivelse av en måte å få tilgang til data i et gitt format. Et datasett kan i DCAT AP ha fra ingen til mange distribusjoner. Ulike formater av data skal ha ulike distribusjoner, så i teorien skal alle distribusjonene til et datasett inneholde de samme dataene. I praksis vil man ofte måtte gjøre noen unntak fra dette. Hvis data distribueres gjennom både en fil og et programmeringsgrensesnitt, kan det være at sistnevnte har en annen oppdateringsfrekvens, som egentlig gjør distribusjonen til et annet datasett. Dersom alt annet er likt, kan det likevel være mest hensiktsmessig å beskrive det som ulike distribusjoner av samme datasett. I slike tilfeller blir det viktig å opplyse om avvik i distribusjonens egenskap beskrivelse. Type distribusjon DCAT AP inneholder i utgangspunktet ikke informasjon om en distribusjons type, men det er 2 utviklet et vokabular for den europeiske dataportalen for dette. Verdiene i dette vokabularet er nedlastbar fil, infomasjonsstrøm og nettjeneste. Det er identifisert et behov for å kunne uttrykke om data fra en distribusjon blir levert via en fil eller en tjeneste. Det anbefales at dct:type innføres som valgfri egenskap for distribusjon. Gyldige verdier begrenses til vokabular for distribusjonstype. Format og mediatype Klassen distribusjon har egenskapene dct:format og dcat:mediatype som begge er ment til å angi informasjon om formatet på dataene i distribusjonen. DCAT AP er ikke helt klar når det gjelder bruk av «format» og «mediatype». En distribusjon kan ha kun ett format. Det betyr at klassen «Distribusjon» har enten «format» eller «mediatype» ikke begge. I henhold til DCAT AP er «format» anbefalt og «mediatype» er valgfri, men beskrivelsen av mediatype sier den at den skal brukes hvis formatet er fra IANA sin liste. Egenskap Uri Område Bruk Beskrivelse format dct:format dct:mediatypeorexten t 0..1 Anbefalt Referanse til distribusjonens filformat mediatype dcat:mediatyp dct:mediatypeorexten 0..1 Referer til 2 type/html/distribution types eng.html

23 e (undertype av dct:format) t Valgfri distribusjonens medietype dersom denne er definert i IANA. DCAT AP sier: Mediatype SKAL brukes når en distribusjons mediatype er definert i IANA, om ikke KAN format benyttes til andre verdier. types/media types.xhtml Anbefaling Vi anbefaler at hvis man vil tilby flere formater så må man enten lage flere distribusjoner, eller man kan man velge å ikke oppgi format og da angi dette gjennom tjenestegrensesnitt eller accessurl. kun egenskapen «format» brukes, og at verdier hentes fra IANA listen hvis mulig. mediatype ikke benyttes. dersom aktuelt filformat ikke finnes hos IANA, angis dette etter samme oppbygging. Dette for at håndteringen blir enklere for en bruker enn å bruke både «Format» og «Media Type», samt verktøy ikke trenger å vise hele IANA listen der de fleste av formatene ikke er relevante. Tilgang til data Det er ønskelig at standarden benyttes så likt som mulig for ulike måter å tilgjengeliggjøre datasett. Om data distribueres ved bruk av en fil eller et tjenesteendepunkt bør ikke ha påvirkning på hvilke egenskaper i standarden man benytter for å få tilgang til data. Distribusjoner har to egenskaper for å angi hvordan man får tilgang til data, tilgangsurl og nedlastingslenke. I tillegg er egenskapen landingsside for datasett relevant i denne sammenhengen. Egenskap Uri Område Bruk Beskrivelse tilgangsurl dcat:accessurl rdfs:resource 1..n En URL som gir

24 nedlastingslenk e Obligatoris k dcat:downloadurl rdfs:resource 0..n Valgfri tilgang til en distribusjon av datasettet. Ressursen det pekes til kan gi informasjon om hvordan en kan få tilgang til i datasettet Direktelenke (URL) til en nedlastbar fil i et gitt format landingsside dcat:landingpage foaf:documen t 0..n Valgfri Egenskap ved datasett som refererer til en nettside som gir tilgang til datasettet, distribusjoner og annen informasjon. Skal peke til en side hos den originale tilbyderen av data. Anbefaling Tilgangsurl bør i så stor grad som mulig peke direkte til en distribusjon av data. skal benyttes for tjenesteendepunkter eller lenke til filnedlasting. kan peke til en nettside med informasjon om hvordan man får tilgang til distribusjonen. Nedlastingslenke kan benyttes dersom alle data tilgjengelig via en tjeneste også er tilgjengelig for nedlasting som en fil. Landingsside kan benyttes for å peke til en samleside om et datasett og dets distribusjoner. bør peke til en side hos den originale tilbyderen av data.