digitaliseringsdirektoratet

Publisert: 2020-03-05
Oppdatert: 2021-07-01 (kun lagt til redaksjonell forklaring på forsiden)

Denne versjonen av veilederen var utarbeidet for DCAT-AP-NO v.1.1 som er under utfasing. Denne versjon av veilederen vil ikke bli oppdatert.
For DCAT-AP-NO v.2.x se den gjeldende versjon av veilederen.
Dette dokumentet kan også lastes ned som PDF.
For normative beskrivelser av feltene som er omtalt i dette dokumentet, se DCAT-AP-NO: Støtte til teknisk implementering av dcat-ap-no

Innledning

Bakgrunn

Digital Agenda og Digitaliseringsrundskrivet viser til målet om at brukeren (privatperson, offentlig og privat virksomhet og frivilligheten) ikke skal trenge å avgi informasjon som han allerede har avgitt. I Lov om Oppgaveregisteret § 5 stilles det krav til statlige virksomheter at informasjon fra næringslivet er samordnet slik at man ikke etterspør samme informasjon flere ganger. Det langsiktige målet er at gjenbruk er hovedregel.

Den enkelte offentlige virksomhet har etter Digitaliseringsrundskrivet (spesielt punkt 1.3) krav til å holde en oversikt over hvilke data de forvalter. Videre legger Regjeringens Retningslinjer ved tilgjengeliggjøring av offentlige data opp til at offentlige data skal dokumenteres og synliggjøres slik at de er enkle å oppdage, vurdere og eventuelt ta i bruk til nye formål.

Difi forvalter et felles offentlig rammeverk for informasjonsforvaltning som inneholder veiledere, spesifikasjoner og standarder som er relevante for informasjonsforvaltning i offentlig sektor. En Veileder for orden i eget hus er laget for å støtte arbeid med å etablere en praksis for dette i egen virksomhet og en faglig arena for informasjonsforvaltning etablert av Difi for å gi erfaringsutveksling mellom de offentlige virksomhetene.

Offentlige virksomheter forvalter store mengder opplysninger fordelt på mange registre. For at offentlige virksomheter skal utnytte informasjon fra andre ved utvikling av digitale brukerrettede tjenester, trenger de å vite hvilken informasjon som finnes og kan gjenbrukes. De behøver å kjenne til hvilke datasett som finnes, og evaluere om de er riktige til sitt formål. Til dette trengs egne oversikter å eksponeres utenfor virksomheten. Private virksomheter trenger en oversikt for å kunne finne, forstå og nyttiggjøre seg av åpne data til transparens, innovasjon og næringsutvikling, og få tilgang til opplysninger som kan bedre brukers prosess i private løsninger (myData) der deling skjer med brukers samtykke.

En felles oversikt etableres med Felles datakatalog. DCAT-AP v1.1 er den gjeldende europeiske spesifikasjonen for beskrivelser av datasett og datakataloger. Formålet er å gjøre det enklere å søke etter åpne datasett på tvers av dataportaler i EUs medlemsstater. En norsk versjon kalt DCAT-AP-NO 1.1 er basert på den europeiske. Den norske standarden inneholder utvidelser som er nyttig for også å beskrive datasett som ikke er åpne.

Veilederen

Mål og hensikt

Denne veilederen skal bidra til bedre beskrivelser av datasettene som virksomhetene i offentlig sektor forvalter, som en del av prosessene for å skape orden i eget hus, oppnå mer gjenbruk av data mellom offentlige virksomheter og å gjøre mer åpne offentlige data tilgjengelig for næringsliv og sivilsamfunn. Veilederen tar ikke stilling til hvordan du skal kartlegge hvilken informasjon din virksomhet forvalter. For kartlegging av informasjon i din virksomhet, kan bl.a. Difis veileder for Internkontroll i praksis - informasjonssikkerhet brukes.

Denne veilederen er laget for å gi en hjelp til at innholdet fra virksomhetene beskrives slik at de kan utnyttes godt av andre. Veilederen skal hjelpe de offentlige virksomhetene å beskrive sine data i henhold til forvaltningsstandarden DCAT-AP-NO.

Struktur

Digitaliseringsrundskrivet sier

Den enkelte virksomhet skal ha 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 (informasjonsforvaltning).
I samsvar med viderebruksbestemmelsene i offentleglova skal virksomheten gjøre egnet informasjon tilgjengelig i maskinlesbare formater, fortrinnsvis gjennom API’er.
— Digitaliseringsrundskrivet 2017

Strukturen på veilederen er bygget opp i henhold til dette. Veilederen skal bidra til å beskrive bedre bl.a.

  1. Hvilke datasett man har?

  2. Hvem forvalter datasettene?

  3. Hva er opphavet til dataene?

  4. Til hvilket formål er de samlet inn?

  5. Hvilke tjenester kan man benytte for å få tilgang til dataene?

  6. Er dataene autoritative?

Vedlegg A gir normative definisjoner av feltene.

Målgruppe

Målgruppen for denne veilederen er primært deg som skal bruke DCAT-AP-NO til å beskrive datasett og datakataloger i din virksomhet.

Sekundært kan også veilederen brukes av deg som skal utvikle/tilpasse verktøystøtte i virksomhetene for beskrivelser av datasett/datakataloger og/eller eksponering av slike beskrivelser i henhold til DCAT-AP-NO.

Hva er et datasett?

“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 Web-API (definert som en organisert samling av data).” Se forøvrig ordforklaringene til Standard for beskrivelse av datasett og datakataloger (DCAT-AP-NO).

Veilederen kan også benyttes til å beskrive ustrukturerte samlinger av data, men hovedhensikten og dermed eksemplene i denne veilederen er utelukkende basert på beskrivelser av strukturerte datasett.

Det kan være vanskelig å vurdere hva som er samling av data og dermed hvor stor eller liten samlingen skal være. Kriterier for å avgrense et datasett vil kunne variere mellom virksomheter og over tid. Se Brønnøysundregistrenes tanker rundt dette.

Eksempler på avgrensing av et datasett:

  • Enhetsregisteret: Med tanke på datadeling med andre, betrakter Brønnøysundregistrene ikke hele Enhetsregisteret som ett stort datasett, men deler videre Enhetsregisteret inn i datasettene Juridisk Person, Virksomhet/Bedrift, Roller. I tillegg kan tilgangsnivå skille Roller i to datasett; ett komplett, og et der sensitive data er fjernet.

  • I Matrikkelen er datasettene Eiendom, Adresse, Bygning. Datasettene distribueres i henhold til ulike applikasjonsskjema (informasjonsmodeller) og på ulike formater.

  • Aa-registeret inneholder datasettet Arbeidsforhold - kilde: A-ordningen, relasjon til Enhetsregisteret og DSF.

  • Det sentrale folkeregisteret (DSF) inneholder Innbyggere, andre personer med tilknytning til riket, bosted, samemantall osv.

  • Uføre (vedtak om uførestatus) fra NAV er en avgrensning av populasjonen og dermed et datasett.

  • Lovlig opphold fra UDI er et datasett

  • Vernepliktige er etter lov om verneplikt en del av Forsvarets verneplikts- og tjenesteregister.

Hvordan starte?

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 datasettbeskrivelsene man har publisert, har man grunnlag for prioritering av arbeid med å gjøre datasettene tilgjengelig. Det er også naturlig å beskrive data man allerede deler.

  • starte med hele registeret og få det beskrevet

  • avhengig av brukerbehov, tilgjengeliggjøring (distribusjon) og formål dele det inn i mindre datasett (subsett)

Hvor dypt skal man gå i nedbrytingen?

Hvis datasettet ditt er veldig stort og omfattende 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 datasettet ditt for eksempel 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.

Datasett

Hvordan beskrive et datasett?

Denne veilederen beskriver videre hvordan datasett beskrives i henhold til standarden DCAT-AP-NO v.1.1. For å ha med all nødvendig informasjon, er det en del felter som må fylles ut. I det følgende går vi gjennom de enkelte feltene og hvordan disse skal fylles ut.

Eksempel på en beskrivelse av et datasett:

Tittel: Partiregisteret
Datasetteier: Brønnøysundregistrene
Beskrivelse: Partiregisteret er et register over politiske parti i Norge. Hovedformålet med registeret er å gi parti anledning til å skaffe seg enerett på partinavn.
Sentrale opplysninger i datasettet: Organisasjonsnummer, Parti, Partinavn, Utøvende organ, Kontaktperson
Tema: Offentlig forvaltning
Geografisk omfang: Norge
Oppdateringsfrekvens: Daglig
Tilgangsrettigheter: Offentlig
Språk: Norsk
Kontaktpunkt: Brønnøysundregistrene, partiregisteret@brreg.no
Relatert til: Enhetsregisteret
Distribusjon:

Se felles datakatalog for flere eksempler (fellesdatakatalog.brreg.no).

Eier av datasettet

Sammendrag

Skal peke på en Enhet i Enhetsregisteret.

Anbefalinger

Identifisering av den enheten som er ansvarlig for at datasettet er tilgjengelig, ikke den som faktisk gjør datasettet tilgjengelig. Eier er et obligatorisk felt.

  • Skal peke på en Enhet (juridisk person, organisasjonsledd, underenhet)

  • Det offisielle navnet på virksomheten vil hentes fra Enhetsregisteret, men kortform (f.eks. Difi) kan legges inn av brukeren

  • Eieren av datasettet forvalter sammensetning av dataene, altså datasettet, og ikke nødvendigvis selve dataene.

Eksempler

  • Arbeids- og velferdsdirektoratet

<>  dct:publisher <http://data.brreg.no/enhetsregisteret/enhet/889640782> . #NAV

Skaper av datasettet

Sammendrag

Brukes unntaksvis der det er datasett som er satt sammen av data som andre er ansvarlige for

Anbefalinger

Egenskapen angir produsent(er) av datasettet der dette er en annen enn dataeier

  • Brukes unntaksvis der det er datasett som er satt sammen av data som andre er ansvarlige for

  • Skaper vil ikke angis med organisasjonsnummer siden det typisk vil være en sammensatt gruppe.

Eksempler

  • “Kommunene”

<>  <http://data.brreg.no/datakatalog/datasett/12>
    dct:creator “Kommunene” .

Tittel på datasett

Sammendrag

Tittelen skal være kortfattet, kunne stå alene og gi mening. Organisasjonens navn trenger ikke å være med. Tittelen skal gjenspeile avgrensninger dersom datasettet er avgrenset i populasjonen. Forkortelser skal skrives helt ut.

Anbefalinger

Datasettet har en tittel slik at det bl.a. kan vises i lister. Tittel er et obligatorisk felt.

  • Tittelen skal være kortfattet, kunne stå alene og gi mening.

  • Organisasjonens navn trenger ikke å være med, med mindre det er spesielt relevant for datasettets innholdsmessige utvalg.

  • Tittelen skal gjenspeile avgrensninger dersom datasettet er avgrenset i populasjonen - populasjonen er avgrenset av geografi eller formål, f.eks. “…​ med støtte i Lånekassen”, “…​ i Oslo”, “ Folketellingen av 1910”. Der populasjonen ikke er avgrenset angis IKKE dette (f.eks. valgkrets)

  • Forkortelser skal skrives helt ut (DTM10 erstattes av “Digital Terrengmodell 10m oppløsning (DTM10)” . Bruk eventuelt feltet for emneord til forkortelser. 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.

  • Lov- eller forskriftshjemlede navn bør brukes i tittel (f.eks. Jegerregisteret)

Eksempler

  • “Bomstasjoner i Norge”

  • “Statens vegvesens oversikt over Bomstasjoner i Norge”

  • “Digital Terreng Modell 10m oppløsning (DTM10)”

  • “DTM10”

Formål

Sammendrag

Beskrivelsen skal være kortfattet og ikke gjentas i Beskrivelsesfeltet.

Anbefalinger

En setnings-beskrivelse av formålet til datasettet.

  • Det er formålet for opprettelsen eller at datasettet i det hele tatt eksisterer som skal beskrives her

  • Beskrivelsen skal være kortfattet og ikke gjentas i Beskrivelsesfeltet.

  • Dersom datasettet inneholder personopplysninger skal dette feltet brukes for å gjengi det formålet i henhold til personopplysningsloven som ligger til grunn for datasettet.

Eksempler

  • Løsøreregisteret er etablert for å tinglyse heftelser (pant) i løsøre, uten tilknytning til fast eiendom

  • Kontakt- og reservasjonsregisteret er etablert for at det offentlige skal kunne kommunisere elektronisk med innbyggerne, og benyttes i forbindelse med saksbehandling og utføring av forvaltningsoppgaver for øvrig, og skal benyttes til varsling etter eforvaltningsforskriftens § 8 tredje ledd. Se eforvaltningsforskriften §§ 29-35

<>  dcatno:objective “Løsøreregisteret er etablert for å tinglyse heftelser (pant) i løsøre, uten tilknytning til fast eiendom”@no .

Beskrivelse av datasett

Sammendrag

Beskrivelsen skal være kortfattet. Hensikten med datasettet bør komme fram. Hvilke opplysninger som utgjør kjernen i datasettet bør angis. Bruk folkelige ord. Beskriv avgrensninger, hva datasettet ikke inneholder. Begrens lenker og markup.

Anbefalinger

En kort og presis beskrivelse av datasettet skal gjøre det lett for andre å se hva det inneholder. Beskrivelse er et obligatorisk felt.

  • Beskrivelsen skal være kortfattet slik at lister over datasett forståes ved å lese de første linjene.

  • Hensikten med datasettet bør komme fram (f.eks. “Løsøreregisteret inneholder tinglyste flyttbare eiendeler”).

  • Beskriv hva datasettet inneholder. Hvilke opplysninger som utgjør kjernen i datasettet bør angis.

  • Feltinnhold skal ikke listes, men listes i emneord eller begreper.

  • Beskrivelsen er ikke en gjentakelse av tittel

  • Bruk folkelige ord (f.eks.”Løsøre” må forklares. F.eks. “flyttbare eiendeler (Løsøre)”, ev. bare folkelige uttrykk mens faguttrykket tas med som stikkord slik at det gir treff i søk)

  • Beskriv avgrensninger, hva datasettet ikke inneholder, dersom dette kan misforstås ut fra tittelen.

  • Begrens lenker og markup (formatering) i teksten. Skal man angi språk må teksten formelt sett være fri for lenker og formatering (HTML).

  • Der målform er kjent skal "nb" eller "nn" brukes, "no" brukes ellers.

Eksempler

  • “Løsøreregisteret inneholder løsøre med unntak av skip og luftfartøy” Et lite folkelig ord (løsøre) er brukt. Avgrensningene her er greie

  • “Løsøreregisteret inneholder tinglyste flyttbare eiendeler som biler og båter”

Hva som inngår i datasettet er godt beskrevet, men unntakene her er utelatt.

  • “Løsøreregisteret inneholder tinglyste flyttbare eiendeler med unntak av skip og luftfartøy”

Dokumentasjon

Sammendrag

Referanse til en side som inneholder utdypende dokumentasjon om datasettet.

Anbefalinger

Utdypende dokumentasjon av datasettet angis ved å peke på en side der den finnes.

Eksempler
<> foaf:page
  <https://confluence.brreg.no/display/DBNPUB/Informasjonsmodell+for+Enhetsregisteret+og+Foretaksregisteret> .

Landingsside

Sammendrag

Referanse til en side som beskriver datasettetet.

Anbefalinger

Dokumentasjon om datasettet på en landingsside hos datasetteieren som kan beskrive datasettets innhold og struktur, og tilgang. Det anbefales at Dokumentasjon brukes der man refererer til utfyllende dokumentasjon, og Distribusjon benyttes f.eks. når man vil referere til en søkeside.

  • kan referere til datasettets hjemmeside

  • kan referere til en samleside som beskriver innhold og struktur

  • kan referere til en samleside om nedlasting/bruk/søk (tjenestene)

  • det kan refereres til flere sider

Eksempler
<> dcat:landingpage
  <https://confluence.brreg.no/display/DBNPUB/Informasjonsmodell+for+Enhetsregisteret+og+Foretaksregisteret>, <https://www.brreg.no/om-oss/samfunnsoppdraget-vart/registera-vare/einingsregisteret/> .

Tilgangsnivå

Sammendrag

Angi om datasettet offentlig åpne data, eller er helt eller delvis skjermet for innsyn.

Anbefalinger

Det er behov for å angi i hvilken grad datasettet kan bli gjort tilgjengelig for allmennheten, uten hensyn til om det er publisert eller ikke

  • Angi om datasettet er helt eller delvis skjermet for innsyn. Offentlig, begrenset offentlighet og unntatt offentlighet.

  • Skal gjenspeile det mest begrensede feltet/opplysningen i datasettet

  • “Offentlig” betyr at datasettet ikke inneholder begrensede opplysninger og kan legges ut som åpne data, selv om det ikke er laget en løsning for tilgang. Se Difis veileder for åpne data.

  • “Begrenset offentlighet” betyr at tilgangen til opplysningene avhenger av hvilket formål opplysningene er innsamlet til, og hvilket lovhjemmel den som skal bruke dataene har. Begrensningen kan skyldes innhold som personopplysninger. Når noen ønsker å benytte datasettet må man foreta en konkret vurdering av tilgangen.

  • “Unntatt offentlighet” betyr saksbehandler har med referanse til lov eller forskrift valgt at datasett (dokumenter eller saksopplysninger) kan unndras fra offentlighet. Typiske eksempler er interne dokumenter, styringsdialog, ansettelser, gradert informasjon, forretningshemmeligheter eller data som andre eier.

  • Varianter av datasettet kan være offentlig ved at det utelater de felt som gjør at det opprinnelige datasettet er begrenset teller unntatt offentlighet. (se relasjoner mellom datasett)

  • Ved bruk av verdiene "begrenset offentlighet" og "unntatt offentlighet" er egenskapen skjermingshjemmel anbefalt

Eksempler

Enhetsregisteret (hele):

  • begrenset offentlighet

Enhetsregisteret - Juridisk person (hovedenhet)

  • offentlig

<>  dcat:accessRights <http://publications.europa.eu/resource/authority/access-right/PUBLIC>.

Skjermingshjemmel

Sammendrag

Angi referanse til relevant lov eller forskrift.

Anbefalinger

Dersom datasettet har begrensninger på deling trenger vi å vite hva skjermingen gjelder. Det kan være hjemmel (kilde for påstand) i offentlighetsloven, sikkerhetsloven, beskyttelsesinstruksen eller annet lovverk som ligger til grunn for vurdering av tilgangsnivå.

  • Angi referanse til relevant lov eller forskrift. Helst til lovdata på paragraf-nivå.

  • Egenskapen er anbefalt dersom «tilgangsnivå» har verdiene «begrenset» eller «ikke-offentlig»

Eksempler

  • Forvaltningsloven, taushetsplikt §13

  • Offentleglova, Opplysningar som er underlagde teieplikt §13

<>   dcatno:legalBasisFor [ .
     skos:prefLabel “Forvaltningsloven, taushetsplikt §13” ;
     rdfs:seeAlso <https://lovdata.no/lov/1967-02-10/§13> .
   ], [
     skos:prefLabel “Offentliglova, taushetsplikt §13” ;
     rdfs:seeAlso <https://lovdata.no/lov/1967-02-10/§13> .
   ] .

Behandlingsgrunnlag

Sammendrag

Behandlingsgrunnlag knyttes enten til angitt lovhjemmel, samtykke eller nødvendighetsvurdering.

Anbefalinger

Etter personopplysningsloven skal det foreligge et grunnlag for behandling av personopplysninger.

  • Dersom et datasett inneholder personopplysninger skal det være et grunnlag for behandlingen.

  • Behandlingsgrunnlag knyttes til alternativene som finnes i forordningens artikkel 6, 9 eller 10. Angi dette i tekst.

  • Dersom behandlingsgrunnlaget forutsetter et supplerende rettslig grunnlag, se artikkel 6(3), skal det angis en referanse til dette rettslige grunnlaget. Helst til lovdata på paragraf-nivå.

Eksempler
<> dcatno:accessRightsComment [
       skos:prefLabel “Treffe vedtak om tjenestepensjon til i hovedsak statsansatte og (kommunale) lærere”@no ;
     rdfs:seeAlso <https://lovdata.no/dokument/NL/lov/1949-07-28-26/KAPITTEL_1#§1> .
] .

Utleveringshjemmel

Sammendrag

Henvisning til regelverk som begrunner en offentlig virksomhet sin rett eller plikt til å utlevere opplysninger til andre private personer eller juridiske personer.

Anbefalinger

Informasjon om utleveringshjemmel gjør det enklere for brukere av datasettet å se om det er nødvendig med egen hjemmel for innhenting eller om de kan få tillatelse til å bruke opplysninger etter søknad til dataeier.

  • Henvisning til regelverk som begrunner en offentlig virksomhet sin rett eller plikt til å utlevere opplysninger til andre private personer eller juridiske personer.

  • Henvisningen gjøres til lovdata på paragraf-nivå.

Eksempler
<>   dcatno:accessRightsComment [
       skos:prefLabel “behandling av helseopplysninger i nasjonal kjernejournal, personaljournalloven §13”@no ;
     rdfs:seeAlso <https://lovdata.no/lov/2014-06-20-42/§13> .
] .

Tema

Sammendrag

Ett eller flere temaer velges fra den kontrollerte listen av EU-temaer

Anbefalinger

For å kunne sortere datasettet inn under gitte kategorier er det behov for tema

Eksempler
<>  <http://data.brreg.no/datakatalog/datasett/12>
     dcat:theme <http://publications.europa.eu/mdr/authority/data-theme/HEAL> .

Type

Sammendrag

Referanse til en klassifisering av datasettets type innhold. Refererer til EU publication office sine datasett-typer

Anbefalinger

Referanse til en klassifisering av datasettets type innhold. Refererer til EU publication office sine datasett-typer.

  • Datasett som anses som å inneholde data angis med “Datasett”

  • Datasett som anses som metadata (f.eks. Kodelister, Taksonomier og Tesauri) skal angis tilsvarende

  • Datasett som anses som testdata angis som “Testdata”

Eksempler
<> dct:type <http://publications.europa.eu/resource/authority/dataset-type/CODE_LIST> .

<>  dct:type
<http://data.brreg.no/datasettype/Datasett> .

<> dct:type
<http://data.brreg.no/datasettype/TestDatasett> .

Begrep

Sammendrag

Innholdstyper i datasettet beskrives med referanse til begreper i begrepskatalog

Anbefalinger

For å beskrive viktigste typer innhold i datasettet refereres det til begreper i begrepskataloger som også gir mulighet til å utnytte synonymer

  • innholdstyper i datasettet beskrives med referanse til begreper i begrepskatalog

  • dersom det ikke kan benyttes en begrepskatalog brukes emneord.

Et datasett skal lenke til de aktuelle og sentrale begrepene i en begrepskatalog. Ved å henvise til gjennomarbeidede definisjoner som virksomheten selv er ansvarlig for å vedlikeholde, sikrer vi at det er tydelig hvordan et begrep brukt i datasettet skal forstås og at denne forståelsen til en hver tid er riktig og oppdatert. Vi ønsker at alle datasettene skal ha lenker til de aktuelle begrepene i virksomhetens katalog, slik at det er tydelig definert hva begrepene innebærer

I Referansekatalogen finner du relevante standarder for arbeidet med begrepsdefinisjoner: https://www.difi.no/artikkel/2015/10/begrepsanalyse-og-definisjonsarbeid

Eksempler

  • Løsøre, Pant, Tinglysing

<> <http://data.brreg.no/datakatalog/datasett/12>
    dct:subject <http://brreg.no/begrepskatalog/begep/løsøre>,
                <http://brreg.no/begrepskatalog/begep/pant>,
                <http://brreg.no/begrepskatalog/begep/tingslysning> .

Søkeord

Sammendrag

Angi synonymer og andre ord som kan hjelpe i søk. Sentralt innhold i datasettet som ikke ennå har begrepsdefinisjoner.

Anbefalinger

Ord og uttrykk som hjelper brukeren til å finne datasettet inkluderes (der det ikke er eksplisitt angitt referanser til begreper)

  • Angi synonymer til hjelp i søk

  • Angi sentralt innhold i datasettet som ikke finnes begrepsdefinisjoner for ennå

I noen tilfeller mangler noen av begrepsdefinisjonene som er sentrale for å beskrive datasettet, eller man har et ord som ikke formelt forbindes med datasettet men som man vet at mange likevel bruker. Da kan vi bruke dette feltet for å sørge for at disse søkeordene likevel gir treff i søkemotoren.

Eksempler

  • uførepensjon, uførepensjonister, uførereform

<http://data.brreg.no/datakatalog/datasett/12>
     dcat:keyword “uførepensjon”@no, “uførepensjonister”@no, “uførereformen”@no .

Geografisk avgrensing

Sammendrag

Angi geografisk avgrensning dersom datasett kun har innhold fra visse områder. Referer til geografiske områder angitt med URI fra Statens Kartverk eller GeoNames

Anbefalinger

Det er ønskelig å synliggjøre om datasettets utvalg er begrenset til bestemte geografiske områder.

  • Angi geografisk avgrensning dersom datasett kun har innhold fra visse områder. “Observert hekking av grågås i Oppdal” er datasettets geografiske omfang begrenset til kommunen Oppdal.

  • Benytt eksisterende avgrensninger som kommuner, fylker m.v.

  • Bør referere til geografiske områder angitt. Med URI-er (f.eks. Sentralt Stedsnavnsregister eller Administrative grenser fra Kartverket)

  • Flere områder kan angis om relevant

  • Dersom det finnes en tilsvarende landsdekkende oversikt, bør dette beskrives som et separat datasett, og disse relateres f.eks. "Observert hekking av grågås i Norge"

Eksempler
# eksempel på lenker til EU publication office (SKOS)
<> dct:spatial <http://publications.europa.eu/resource/authority/country/NOR>
             a dct:Location, skos:Concept ;
             skos:prefLabel “Norge”@no .

# eksempel på lenker til GeoNames
<> dct:spatial <http://sws.geonames.org/3144096/>
             a gn:Feature ;
             gn:officalName “Norge”@no .

# eksempel på lenker til Kartverket (kommer)

Tidsmessig avgrensing

Sammendrag

Angi tidsmessig avgrensning dersom datasett kun har innhold fra visse perioder. Dersom det finnes en tilsvarende komplett oversikt, bør også dette beskrives som et eget datasett

Anbefalinger

En tidsromangivelse er nødvendig for datasett hvor innholdet dekker et avgrenset tidsrom.

  • Angi tidsmessig avgrensning dersom datasett kun har innhold fra visse perioder. For mange datasett knyttet til registerfunksjoner vil tidsrom være direkte koblet mot oppdateringsfrekvens. For andre datasett vil tidsrom være vesentlig i forhold til forståelse av bruk av dataene, f.eks folketellinger.

  • Dersom det er angitt en periode med årstall, tolkes dette som fra og med 1. januar første år til og med 31. desember siste år.

  • Ved ett årstall på begynnelse, men ikke angitt slutt, tolkes det at datasettet har data også i en ubestemt fremtid og tilsvarende om startdatoen mangler antas det at det er ikke angitt om datasettet har en start.

  • Dersom det finnes en tilsvarende komplett oversikt, bør også dette beskrives som et eget datasett, og disse relateres.

  • Dersom datasettet er en av flere i en tidsserie anbefales det at det lages et overordnet datasett for tidsserien uten distribusjoner som peker på hver datasett.

  • Det benyttes tidsstempel for registreringen av første og siste dataelement i datasettet.

  • Det kan angis flere tidsperioder per datasett, men det anbefales at periodene ikke er overlappende.

  • Relativ avgrensning i tid fra tidspunkt for uttrekk (eksempelvis fra og med dato for forrige påbegynte semester og til og med avslutning av påfølgende semester)

Eksempler

  • “1901”

<> <http://data.brreg.no/datakatalog/datasett/12>
    dct:temporal  [
        a dct:PeriodOfTime ;
        ot:hasBeginning  [
            a ot:Instant ;
            ot:inXSDDateTime "1901-01-01T00:00:00Z"^^xsd:dateTime
        ] ;
        owl:hasEnd [
            a ot:Instant ;
           ot:inXSDDateTime  "1901-12-31T00:00:00Z"^^xsd:dateTime
       ]
   ] .

Utgivelse

Sammendrag

Tidspunktet angir når innholdet i datasettet gjøres tilgjengelig.

Anbefalinger

For å forstå når datasettet er operativt og tilgjengelig angis tidspunkt for utgivelse.

  • Angis som tidspunkt (dato alene tolkes som kl. 00:00)

  • Tidspunktet angir når innholdet i datasettet gjøres tilgjengelig. Dette er ikke alltid samsvarende med når den enkelte distribusjonen er tilgjengelig. Og heller ikke når beskrivelsen om datasettet utgis (katalogpostens utgivelse).

  • Tidspunkt angis med xsd:dateTime. Dette inkluderer utvidelser av kapittel 5.4 i ISO 8601 med tidssoner) [-]CCYY-MM-DDThh:mm:ss[Z|(+|-)hh:mm]

Eksempler

  • 01.01.2017 00:00

<> <http://data.brreg.no/datakatalog/datasett/12>
     dct:issued “2017-01-01T00:00:00+01:00”^xsd:DateTime .

Språk

Sammendrag

Hovedspråket benyttet i datasettets innhold angis

Anbefalinger

For å forstå hvilket språk innholdet til datasettet har angis dette

  • Det er hovedspråket benyttet i datasettets innhold som skal angis

  • Er datasettet uten språklige tekster angis ikke språk

  • Inneholder datasett tekster på flere språk, og det ikke er tydelig hva som er hovedspråket, angis ikke språk

  • Språk angis fra en liste av gyldige språk fra EUs autoritetsliste.

Eksempler

  • Norsk

<> <http://data.brreg.no/datakatalog/datasett/12>
     dct:language <http://publications.europa.eu/resource/authority/language/NOR> .

Opphav

Sammendrag

Angi om opplysningene i datasettet er resultat av vedtak eller innsamlet fra bruker eller tredjepart

Anbefalinger

Det er behov for en sortering om innholdet er basert på avgjørelse truffet under utøvelse av offentlig myndighet (vedtak) eller er kommer fra andre kilder (bruker eller tredjepart). Vedtak anses å være autoritative kilder for hele forvaltningen.

  • Angi om opplysningene i datasettet er resultat av vedtak eller innsamlet fra bruker eller tredjepart

  • Det skal velges en verdi fra et kontrollert vokabular med verdiene Vedtak, Bruker og Tredjepart

Enkelte offentlige virksomheter har datasett som innen sitt område eller nasjonalt er å anse autoritative kilder. Eksempler på slike datasett er Enhetsregisteret (ER), Folkeregisteret (DSF), Matrikkelen og Aa-registeret. Per i dag er de tre første formelle grunndataregistre, men det er flere andre datasett som i større eller mindre grad blir gjenbrukt innenfor sektorer eller generelt innenfor offentlig sektor og resten av samfunnet.

Eksempler

  • Vedtak

<> dct:provenance <http://data.brreg.no/opphav/vedtak>

Oppdateringsfrekvens

Sammendrag

Beskriv hvor ofte datasettet har nytt innhold

Anbefalinger

En angivelse hvor ofte datasettet blir oppdatert.

  • Beskriv hvor ofte datasettet har nytt innhold. For eksempel oppdateres Enhetsregisteret med nye enheter og sletting av enheter kontinuerlig, mens Inntektsdata fra likningen (Skattemelding) er årlig og Folketelling fra 1910 oppdateres aldri.

  • Begreper (og tilhørende URIer) fra Frequency Name Authority List skal benyttes

Eksempler
<> dct:accruralPeriodicity  <http://publications.europa.eu/resource/authority/frequency/MONTHLY>

Sist oppdatert

Sammendrag

Tidspunktet angir når innholdet i datasettet sist er endret.

Anbefalinger

For å forstå når datasettet sist ble oppdatert angis tidspunkt for siste endring

  • Tidspunktet angir når innholdet i datasettet sist er endret.

  • Angis som tidspunkt (dato alene tolkes som kl. 00:00:00 norsk tid)

  • Tidspunkt angis med xsd:dateTime etter kapittel 5.4 i ISO 8601 utvidet med tidssoner [-]CCYY-MM-DDThh:mm:ss[Z|(+|-)hh:mm]

Eksempler

  • 01.01.2017 00:00

<> <http://data.brreg.no/datakatalog/datasett/12>+

Aktualitet

Sammendrag

Avvik eller tilleggsopplysninger om “oppdateringsfrekvens” og “sist oppdatert”

Anbefalinger

Avvik eller tilleggsopplysninger om “oppdateringsfrekvens” og “sist oppdatert”

  • Er opplysninger om “oppdateringsfrekvens” og “sist oppdatert” alltid gyldig? Er det opplysninger i datasettet som har annen oppdateringsfrekvens?

Eksempler
<> dqv:hasQualityAnnotation [
    a dqv:QualityAnnotation ;  # kvalitetsnote
    dqv:inDimension iso:Currentness ;
    oa:hasBody [
       rdf:value=”Enhetsregisteret er kontinuerlig oppdatert, men egenskapen antall ansatte oppdateres månedlig fra Aa-registeret”@no;
    ] .
  ] .

I samsvar med standard

Sammendrag

Angi at et datasett er i samsvar med en standard, spesifikasjon eller implementasjonsregel.

Anbefalinger

Det er behov for å vite om et datasett er i henhold til gitt(e) standard(er).

  • 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.

  • For referanser til maskinlesbare informasjonsmodeller, skal egenskapen “informasjonsmodell benyttes”

Eksempler
<> dcat:conformsTo [
  skos:prefLabel “Produktspesifikasjon NVE flomsoner 1.0”@no
  rdfs:seeAlso <http://sosi.geonorge.no/Produktspesifikasjoner/Produktspesifikasjon_NVE_Flomsoner_1%200.pdf>
] .

Relevans

Sammendrag

Avvik eller tilleggsopplysninger knyttet til datasettes relevans i ulike brukskontekster

Anbefalinger

Avvik eller tilleggsopplysninger knyttet til datasettes relevans i ulike brukskontekster * En vurdering om det er bruksområder datasettet er spesielt velegnet eller ikke bør brukes.

Eksempler
<> dcatno:hasQualityAnnotation [
    a dqv:QualityAnnotation ;
    dqv:inDimension iso:Relevance ;
    oa:hasBody [
       rdf:value=”Enhetsregisterets Næringskode viser enhetenes hovedaktivitet og skal primært dekke statistiske behov for Statistisk sentralbyrå (SSB). Næringskoden er satt ved opprettelse av selskapet, og reflekterer ikke alltid selskapets endrede forretningsmodell.”@no;
    ] .
  ] .

Kompletthet

Sammendrag

I hvilken grad inneholder datasettet alle objekter som nevnt i formålet.

Anbefalinger

I hvilken grad inneholder datasettet forventede opplysninger

  • Kompletthet tolkes i forhold til formålet (utvalget)

  • Inneholder datasettet de objekter som nevnt i formålet?

Eksempler

Enhetsregisteret - formålet er effektiv utnyttelse og samordning av offentlige opplysninger om juridiske personer, enkeltpersonforetak og andre registreringsenheter

  • Enhetsregisteret inneholder ikke slettede selskaper før 1994.

<> dqv:hasQualityAnnotation [
    a dqv:QualityAnnotation ;
    dqv:inDimension iso:Completeness ;
    oa:hasBody [
       rdf:value=”Enhetsregisteret inneholder ikke slettede selskaper før 1994.”@no;
    ] .
  ] .

Kontakt og reservasjonsregisteret - formål benyttes til varsling og kan benyttes i forbindelse med saksbehandling og utføring av forvaltningsoppgaver for øvrig

  • Alle innbygger er ikke representert/registrert

<> dqv:hasQualityAnnotation [
    a dqv:QualityAnnotation ;
    dqv:inDimension iso:Completeness ;
    oa:hasBody [
       rdf:value=”Alle innbygger er ikke representert/registrert.”@no;
    ] .
  ] .

Nøyaktighet

Sammendrag

I hvilken grad er innholdet i samsvar med formålet

Anbefalinger

I hvilken grad representerer datasettet korrekt intensjonen som er angitt av dataeier i formålet

  • Nøyaktighet skal tolkes i forhold til formålet.

  • Angi om det er begrensninger i forhold til formålet

Eksempler

Regnskapsregisteret - Formålet med ordningen er å sikre økonomisk trygghet og effektivitet – mellom selskapene og myndighetene, mellom selskapene og publikum, og ikke minst, selskapene imellom.

  • Enhetens regnskap blir ikke kontrollert av Regnskapsregisteret.

<> dqv:hasQualityAnnotation [
    a dqv:QualityAnnotation ;
    dqv:inDimension iso:Accuracy ;
    oa:motivatedBy dqv:qualityAssessment ;
    oa:hasBody [
       rdf:value=”Enhetens regnskap blir ikke kontrollert av Regskapsregistert.”@no;
    ] .
    ] .

Kontakt og reservasjonsregisteret - formål benyttes til varsling og kan benyttes i forbindelse med saksbehandling og utføring av forvaltningsoppgaver for øvrig

  • Brukere har selv oppgitt informasjon, sjekkes med SMS.

<> dqv:hasQualityAnnotation [
    a dqv:QualityAnnotation ;
    dqv:inDimension iso:Accuracy ;
    oa:motivatedBy dqv:qualityAssessment ;
    oa:hasBody [
       rdf:value=”Brukere har selv oppgitt informasjon, sjekkes med SMS.”@no;
    ] .
  ] .

Askeladden - Riksantikvarens offisielle database over fredete kulturminner og kulturmiljøer i Norge

  • Arkeologiske funn som er registrert før år 2005 har feilmargin på stedfesting på opptil 10 meter. Funn registrert etter 2005 har feilmargin på opptil 0,5 meter

<> dqv:hasQualityAnnotation [
    a dqv:QualityAnnotation ;
    dqv:inDimension iso:Accuracy ;
    oa:motivatedBy dqv:qualityAssessment ;
    oa:hasBody [
       rdf:value=”Arkeologiske funn som er registrert før år 2005 har feilmargin på stedfesting på opptil 10 meter. Funn registrert etter 2005 har feilmargin på opptil 0,5 meter”@no;
    ] .
  ] .

Tilgjengelighet

Sammendrag

Avvik eller tilleggsopplysninger knyttet til datasettes tilgjengelighet

Anbefalinger

Avvik eller tilleggsopplysninger knyttet til datasettets tilgjengelighet

  • Tilgjengelighet tolkes i forhold til tilgangsnivå og ev. begrensninger utover det som er angitt i behandlingsgrunnlag, skjermings- og utleveringshjemmel.

  • Dersom datasettet er åpent men mangler distribusjoner bør årsaken angis her.

Eksempler
<> dqv:hasQualityAnnotation [
    a dqv:QualityAnnotation ;
    dqv:inDimension iso:Availability ;
    oa:hasBody [
       rdf:value=”Regnskapsregisteret kan kun hentes ut på forespørsel”@no;
    ] .
    ] .

Informasjonsmodell

Sammendrag

Refereranse til datasettets informasjonsmodell

Anbefalinger

En eksplisitt referanse til informasjonsmodell

  • Benyttes til å angi en maskinlesbar referanse til informasjonsmodell.

Eksempler
<> dcatno:informationModel [
   skos:prefLabel “Informasjonsmodell Flomsoner 1.0”@no ;
   rdfs:seeAlso <https://objektkatalog.geonorge.no/Pakke/Index/EAPK_C8C565A7_B07B_41ec_80B0_1A2EEEBA0C15> ] .

Kilde datasett (avledet fra)

Sammendrag

Peker til ressurs (datasett eller annet) som helt eller delvis er en kilde for det aktuelle datasettet.

Anbefalinger

Peker til en ressurs som er kilde til datasettet

  • Peker til ressurs (datasett eller annet) som helt eller delvis er en kilde for det aktuelle datasettet. F.eks. kan et datasett er opprettet basert på data som er hentet fra en nettside, uten at den er definert som et datasett.

  • Dersom et åpent datasett er basert på et annet hvor personopplysninger er fjernet, kan relasjonen brukes.

  • Et datasett som er avledet fra et annet skal ha en referanse til kilde for det aktuelle datasettet.

  • Dersom det er et utvalg fra et annet datasett bør heller relasjonen del av brukes

Eksempler
<> dcat:source [
   skos:prefLabel “Det sentrale folkeregisteret”@no ;
   rdfs:seeAlso <http://brreg.no/catalogs/974761076/datasets/e3fc94e4-cc7e-4290-b479-4e0c99dc6caa> ] .

Del av datasett

Sammendrag

Der registre oppdeles i mindre datasett skal relasjonen brukes.

Anbefalinger

Peker til et datasett som det aktuelle datasettet er en delmengde av av, eller at det er brutt opp i mindre datasett.

  • Der registre oppdeles i mindre datasett skal relasjonen brukes. F.eks. er datasettet Underenheter er del av datasettet Enhetsregisteret.

Eksempler
<> dct:isPartOf [
   skos:prefLabel “Det sentrale folkeregisteret”@no ;
   rdfs:seeAlso <http://brreg.no/catalogs/974761076/datasets/e3fc94e4-cc7e-4290-b479-4e0c99dc6caa> ] .

Erstattet av datasett

Sammendrag

Peker til et datasett som erstatter et aktuelt datasettet

Anbefalinger

Peker til et datasett som erstatter et aktuelt datasettet.

  • F.eks. kan et kodeverk bli erstattet av en nyere utgave.

Eksempler
<> dct:isReplacedBy [
   skos:prefLabel “Bydeler fra 1.1.2004”@no ;
   rdfs:seeAlso <https://data.norge.no/node/1115> ] .

Påkrevd av datasett

Sammendrag

Peker til en ressurs som må være tilstede for at datasettet skal kunne produseres

Anbefalinger

Peker til en ressurs som må være tilstede for at datasettet skal kunne produseres.

  • Peker til ressurs (datasett eller annet) som aktuelt datasett er avhengig av

Eksempler
<> dct:isPartOf [
   skos:prefLabel “Postnummer i Norge”@no ;
   rdfs:seeAlso <https://data.norge.no/node/1252> ] .

Refererer til

Sammendrag

Referanse til andre datasett som det kan være nyttig for brukere å være oppmerksom på.

Anbefalinger

Referanse til andre datasett som det kan være nyttig for brukere å være oppmerksom på

  • Peker til datasett som kan være aktuelt å se i sammenheng med det aktuelle datasettet, f.eks. for Enhetsregisteret supplerende informasjon om Enheter, men ikke direkte relatert.

Eksempler
<> dct:references [
   skos:prefLabel “Register over offentlig støtte”@no ;
   rdfs:seeAlso <http://brreg.no/catalogs/974760673/datasets/ca04abdd-6327-4833-bd05-7a3dca20e6a5> ] .

Relatert

Sammendrag

Referanse til andre datasett som gir supplerende informasjon om innholdet.

Anbefalinger

En generell relasjon som peker til ressurser som er relatert til datasettet.

  • Angi referanser til andre datasett som gir supplerende informasjon om innholdet. Kan f.eks. være å relatere til et annet register.

Eksempler
<> dct:relation [
    skos:prefLabel “Det sentrale folkeregisteret”@no ;
   rdfs:seeAlso <http://brreg.no/catalogs/974761076/datasets/e3fc94e4-cc7e-4290-b479-4e0c99dc6caa> ] .

Versjon av

Sammendrag

Referanse til et datasett som i prinsippet er det samme, men hvor innholdet er blitt oppdatert på bakgrunn av bedret datakvalitet e.l.

Anbefalinger

Peker til et datasett som det aktuelle datasettet er en versjon av.

  • I prinsippet det samme datasettet, men hvor innholdet er blitt oppdatert på bakgrunn av bedret datakvalitet e.l.

  • Peker til en versjon av det aktuelle datasettet kan avledes (har versjon).

Eksempler
<> dct:isVersionOf [
   skos:prefLabel “Bydeler fra 1.1.2004”@no ;
   rdfs:seeAlso <https://data.norge.no/node/1115> ] .

Testdatasett

Sammendrag

For å angi at et register eller datasett foreligger som testdata, typisk syntetiske eller anonymiserte, angis dette med relasjonen testdatasett til et annet datasett.

Anbefalinger

For å angi at et register eller datasett foreligger som testdata, typisk syntetiske eller anonymiserte, angis dette med relasjonen testdatasett til et annet datasett.

  • Peker til datasett som er består av testdata til det aktuelle datasettet

Eksempler
<> dct:isVersionOf [
   skos:prefLabel “Syntetiske folkeregisteredata”@no ;
   rdfs:seeAlso <http://brreg.no/catalogs/974761076/datasets/e3fc94e4-cc7e-4290-b479-4e0c99dc6caa/> ] .

Kontaktpunkt

Sammendrag

Angi kontaktinformasjonen som kan brukes ved henvendelser om et datasett.

Anbefalinger

Egenskapen kontaktpunkt angis for å komme i dialog med eieren av datasettet.

  • Angi kontaktinformasjonen som kan brukes ved henvendelser om et datasett.

  • Vcard https://www.w3.org/TR/vcard-rdf benyttes for å beskrive kontaktpunktet (se anbefaling under hvert Kontaktpunkt-felt)

Eksempler

  • Avdeling Digitalisering

<> <http://data.brreg.no/datakatalog/datasett/12>
    dcat:contactPoint <http://data.brreg.no/datakatalog/kontaktpunkt/a-7> .

Datasettdistribusjon

Sammendrag

For å angi hvor man kan få tilgang til datasettet skal det angis ulike distribusjoner.

Anbefalinger

For å angi hvor man kan få tilgang til datasettet skal det angis ulike distribusjoner.

  • Det angis i utgangspunktet en distribusjon per fil, feed eller API

  • Dersom det er ett API som leverer flere filformater angis det som en distribusjon

Eksempler
 <> <http://brreg.no/catalogs/974760673/datasets/63086dda-9b72-43f0-bbc2-3ced4bc2edd6>
    dcat:distribution <http://data.brreg.no/datakatalog/distribusjon/12>
. # til et beskrivelse av et API

Eksempeldata

Sammendrag

Benyttes for å gi eksempeldata for et datasett, og hvordan en faktisk distribusjon ser ut.

Anbefalinger

Benyttes for å gi eksempeldata for et datasett, og hvordan en faktisk distribusjon ser ut. * Dersom datasettet inneholder personopplysninger vil det være nyttig for bruker å se en eksempedata som viser en anonymisert rad i datasettet.

Eksempler
<> <http://brreg.no/catalogs/974761076/datasets/e3fc94e4-cc7e-4290-b479-4e0c99dc6caa>
    dcat:distribution <http://data.brreg.no/datakatalog/distribusjon/124312>
. # til et beskrivelse av en eksempel-distribusjon av folkeregisteret

Enhet

Relasjonen eier og skaper fra datasettbeskrivelsen peker på en klasse Enhet. Offentlig sektors datasett skal ha organisasjoner som ansvarlige eiere.

  • Det anbefales å referere direkte til Enhetsregisteret, som vil hente opplysningene direkte derfra

  • Sekundært benytte egenskapene under med eller uten en sameas lenke.

Enhetsnavn

Sammendrag

Navnet på enheten benyttes i visninger

Anbefalinger

Navnet på enheten benyttes i visninger

Eksempler
<> a foaf:Agent ;
   foaf:name “Brønnøysundregistrene”@no .

Organisasjonsnummer

Sammendrag

Enheter skal oppgis med organisasjonsnummer.

Anbefalinger

Enheter skal oppgis med organisasjonsnummer.

Eksempler
<> a foaf:Agent ;
   dct:identifier “974760673” .

Utgivertype

Sammendrag

Enheter angis med organisasjonstype for å skille mellom offentlige og private datasetteiere.

Anbefalinger

Enheter angis med organisasjonstype for å skille mellom offentlige og private datasetteiere * Brukes organisasjonsnummer hentes dette fra Enhetsregisteret

Eksempler

<> a foaf:Agent ;
   er:orgform [
       skos:prefLabel "ORGL";
       dct:description "Organisasjonsledd";
   ]  .

Kontaktpunkt

Relasjonen kontaktpunkt fra datasettbeskrivelsen peker på en klasse Organisasjonsenhet

Organisasjonsenhet

Sammendrag

Kontaktpunkt angis med organisasjonsenhet. Dette kan være navnet til en gruppe, avdeling, seksjon eller liknende i organisasjonen

Anbefalinger

Kontaktpunkt angis med organisasjonsenhet * Dette kan være navnet til en avdeling, seksjon, kontor, gruppe eller liknende i organisasjonen. * Kontaktinformasjon på person frarådes.

Eksempler
<> <http://data.brreg.no/datakatalog/kontaktpunkt/a-7>
      a vcard:Organization ;
      vcard:organization-unit  "Difi ID porten" .

E-post

Sammendrag

Angi e-postadresse for kontaktpunktet dersom dette er en ønsket kontaktform

Anbefalinger

Angi e-postadresse for kontaktpunktet dersom dette er en ønsket kontaktform

Eksempler
<> <http://data.brreg.no/datakatalog/kontaktpunkt/a-7>
      vcard:hasEmail     <mailto:idporten@difi.no> .

Telefon

Sammendrag

Angi telefonnummer for kontaktpunktet dersom dette er en ønsket kontaktform

Anbefalinger

Angi telefonnummer for kontaktpunktet dersom dette er en ønsket kontaktform

Eksempler
<> <http://data.brreg.no/datakatalog/kontaktpunkt/a-7>
      vcard:hasTelephone <tel:80030300> .

Kontaktskjema

Sammendrag

Angi referanse til kontaktskjema på web dersom dette er en ønsket kontaktform

Anbefalinger

Angi referanse til kontaktskjema på web dersom dette er en ønsket kontaktform * Hvis det finnes et web-basert kontaktskjema bør dette benyttes

Eksempler
<> <http://data.brreg.no/datakatalog/kontaktpunkt/a-7>
      vcard:hasURL <http://eid.difi.no/en/contact-support> .

Distribusjon

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.

Dersom datasettet allerede har en distribusjon og kan deles, registrerer du det som datasettbeskrivelser og opplyser om de distribusjoner man kan levere.

Det er imidlertid ikke alle datasett som blir distribuert. Hvis datasettet ikke har en distribusjon, registrerer du dette som en datasettbeskrivelse uten distribusjon. Det er bedre å registrere disse datasettene i en katalog og dermed informere andre om at de faktisk finnes, enn å vente på å få en avansert løsning for distribusjon.

Hver distribusjon skal kun ha ett format av data. I teorien skal alle distribusjonene av et datasett inneholde de samme dataene, men i praksis vil man ofte måtte gjøre noen unntak fra dette. Hvis data distribueres både gjennom en fil og et programmeringsgrensesnitt, kan det være at sistnevnte har en annen oppdateringsfrekvens. Dette betyr at det kan være innholdsmessige forskjeller, noe som gjør at distribusjonen egentlig er 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.

Distribusjonen bør så nært som mulig følge datasettets beskrivelse innholdsmessig.

Beskrivelse

Sammendrag

Kort beskrivelse av distribusjonen som skiller dem fra hverandre dersom der er flere.

Anbefalinger

Beskrivelse skal beskrive egenskaper ved de ulike distribusjonene

  • Er det kun en distribusjon kan beskrivelsen utelates

  • Ved flere distribusjoner bør beskrivelsen benyttes for å skille dem

  • Dersom det er et utsnitt spesifikt for distribusjonen/formål til distribusjonen benyttes beskrivelse

Eksempler

Eksempler to distributører:

  • “Enhetsregisteret via Datahotellet”

  • “Enhetsregisteret i sanntid”

Eksempel to ulike variasjoner av innhold:

  • “Mottakere med tilhørende profiler”

  • “Mottakere med tilhørende evner”

Distribusjonstype

Sammendrag

En distribusjon kan bli levert på ulike vis. Angi distribusjonens type (Nedlastbar fil, API, Feed, Søkeside)

Anbefalinger

En distribusjon kan bli levert på ulike vis

  • Det skal angis distribusjonens type

  • Bruk Nedlastbar fil dersom hele distribusjonen kan hentes ned i maskinlesbart format

  • Bruk API dersom deler av datasettet lastes ned gjennom et programmeringsgrensesnitt, typisk REST-API

  • Bruk Feed dersom det i prinsippet er endringer som hentes gjennom f.eks. RSS, Atom eller meldingsformidling

  • Bruk Søkeside når det refereres til en landingsside som er ment for mennesker.

  • Se EU publication office (http://publications.europa.eu/mdr/resource/authority/distribution-type/html/distribution-types-eng.html)

Eksempler
<> <http://data.brreg.no/datakatalog/distribution/124>
      dct:type <http://data.brreg.no/datakatalog/distribusjonstype/API> .

Format

Sammendrag

Hver distribusjon har format for utveksling. Format er et obligatorisk felt for en distribusjon.

Anbefalinger

Hver distribusjon har format for utveksling. Format er et obligatorisk felt for en distribusjon.

  • Det skal angis mediatype (e.g. application/json) fra IANAs liste over offisielle medietyper

  • Det kan angis mediatyper utover denne listen ved å bruke mønsteret x.+{filakronym}, f.eks. “application/x.sosi”

  • Flere formater skal kun brukes når et og samme API eller sluttbrukerapplikasjoner som tilbyr flere formater

Eksempler
<> <http://data.brreg.no/datakatalog/distribution/124>
      dct:format "application/json" .

Tilgangslenke

Sammendrag

Lenke til distribusjonen.

Anbefalinger

Lenke til eller sekundært informasjon om distribusjonen av datasettet. Tilgangslenke er et obligatorisk felt.

  • bør primært 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.

<> <http://data.brreg.no/datakatalog/distribution/124>
      dcat:accessURL <http://hotell.difi.no/?dataset=brreg/partiregisteret> .

Nedlastingslenke

Sammendrag

Direktelenke til en nedlastbar fil i et gitt format

Anbefalinger

Direktelenke til en nedlastbar fil i et gitt format. Det anbefales heller å benytte Tilgangslenke.

  • kan benyttes dersom alle data tilgjengelig via en tjeneste også er tilgjengelig for nedlasting som en fil.

  • En nedlastingslenke er en direktelenke (URL) til en nedlastbar fil i et gitt format. Dersom nedlastingslenken er den eneste tilgjengelige lenken til datasettet må denne dupliseres i feltet for TilgangsURL

Eksempler
<> <http://data.brreg.no/datakatalog/distribution/124>
     dcat:downloadURL <http://hotell.difi.no/?dataset=brreg/partiregisteret> .

I samsvar med

Sammendrag

Benyttes for å angi et etablert skjema som distribusjonen er i samsvar med, for eksempel et XSD-dokument.

Anbefalinger

Benyttes for å angi et etablert skjema som distribusjonen er i samsvar med, for eksempel et XSD-dokument.

Eksempler
<> <http://data.brreg.no/datakatalog/distribution/12>
    dcat:conformsTo <https://confluence.brreg.no/display/DBNPUB/Informasjonsmodell+for+Enhetsregisteret+og+Foretaksregisteret> .

Dokumentasjon

Sammendrag

Referanse til en side eller et dokument som beskriver og dokumenterer innhold og struktur spesifikk for distribusjonen.

Anbefalinger

Referanse til en side eller et dokument som beskriver og dokumenterer innhold og struktur spesifikk for distribusjonen.

Eksempler
<> <http://data.brreg.no/datakatalog/distribution/12>
    foaf:page <https://confluence.brreg.no/display/DBNPUB/API> .

Utgivelse

Sammendrag

Dato/tid når distribusjonen (f.eks. api) først ble publisert i tilknytning til et datasett.

Anbefalinger

Dato/tid når distribusjonen (f.eks. api) først ble publisert i tilknytning til et datasett. Når innholdet i datasettene ble gjort tilgjengelige.

Eksempler

  • 01.01.2017 00:00

<> <http://data.brreg.no/datakatalog/distribution/12>
     dct:issued “2017-01-01T00:00:00+01:00”^xsd:DateTime .

Sist oppdatert

Sammendrag

Dato/tid sist distribusjonen (API-et, filen eller feeden) sist ble endret.

Anbefalinger

Dato/tid sist distribusjonen (API-et, filen eller feeden) sist ble endret.

Eksempler

  • 01.01.2017 00:00

<> <http://data.brreg.no/datakatalog/distribution/12>
     dct:modified “2017-01-01T00:00:00+01:00”^xsd:DateTime .

Lisens

Sammendrag

Referanse til lisensen som datasettet gjøres tilgjengelig under. Lisens er påkrevd for alle åpne offentlige data.

Anbefalinger

Referanse til lisensen som datasettet gjøres tilgjengelig under. Lisens er påkrevd for alle åpne offentlige data.

Eksempler
<> <http://data.brreg.no/datakatalog/distribution/12>
      dct:license: "http://data.norge.no/nlod/" .

Datakatalog

Hva er en datakatalog?

Datasett fra en virksomhet eller flere virksomheter samles i en datakatalog.

Tittel

Sammendrag

Kortfattet om katalogen. Angi, uten å liste, hvilke datasett den omfatter.

Anbefalinger

Kortfattet om katalogen

  • Angi, uten å liste, hvilke datasett den omfatter,

  • f.eks. datasettene til Brønnøysundregistrene.

Eksempler
<> <http://brreg.no/catalogs/974760673>
    	a dcat:Catalog ;
    	dct:title "Datakatalog for REGISTERENHETEN I BRØNNØYSUND"@nb ;

Beskrivelse av katalog

Sammendrag

En kort og presis beskrivelse av datasettet skal gjøre det lett for andre å se hva det inneholder. Beskrivelse er et obligatorisk felt.

Anbefalinger

En kort og presis beskrivelse av datasettet skal gjøre det lett for andre å se hva det inneholder. Beskrivelse er et obligatorisk felt.

Eksempler
<> <http://brreg.no/catalogs/974760673>
    	a          	dcat:Catalog ;
    	dct:description "Katalog over alle data i Brønnøysundregistrene"@nb ;

Datasett

Sammendrag

Beskriver datasettene i katalogen. Minst ett datasett er påkrevd.

Anbefalinger

Beskriver datasettene i katalogen. Minst ett datasett er påkrevd.

  • Lenke til alle datasettene

Eksempler
<> <http://brreg.no/catalogs/974760673>
    	 dcat:dataset   <http://brreg.no/catalogs/974760673/datasets/b97e7db3-8e46-4bc4-857e-77d7280b0e9e> , <http://brreg.no/catalogs/974760673/datasets/1ffcb9e4-008b-4333-a372-268f50d01482> , <http://brreg.no/catalogs/974760673/datasets/9922b7df-4fb8-4e1e-8da9-85736e37195f> .

Eier av katalog

Sammendrag

Identifisering av den enheten som er ansvarlig for katalogen

Anbefalinger

Identifisering av den enheten som er ansvarlig for katalogen. Eier er et obligatorisk felt.

  • Skal peke på en Enhet (juridisk person, organisasjonsledd, underenhet)

  • Det offisielle navnet på virksomheten vil hentes fra Enhetsregisteret, men kortform (f.eks. Difi) kan legges inn av brukeren

Eksempler

  • Brønnøysundregistrene

<> <http://brreg.no/catalogs/974760673>
     dct:publisher <http://data.brreg.no/enhetsregisteret/enhet/974760673> .
# brreg

Utgivelse

Sammendrag

Dato/tid katalogen først ble publisert.

Anbefalinger

Dato/tid katalogen først ble publisert.

Eksempler

  • 01.01.2017 00:00

<> <http://brreg.no/catalogs/974760673>
     dct:issued “2017-01-01T00:00:00+01:00”^xsd:DateTime .

Sist oppdatert

Sammendrag

Dato/tid sist katalogen ble endret,. Dette kan være endring av en datasettbeskrivelse, eller andre metadata i katalogen.

Anbefalinger

Dato/tid sist katalogen ble endret,. Dette kan være endring av en datasettbeskrivelse, eller andre metadata i katalogen.

Eksempler

  • 01.01.2017 00:00

<> <http://brreg.no/catalogs/974760673>
     dct:modified “2017-01-01T00:00:00+01:00”^xsd:DateTime .

Referanser

DCAT-W3C: Data Catalog Vocabulary (DCAT), Recommendation 16 January 2014
DCAT-AP: DCAT Application Profile for data portals in Europe, version 1.1, 2015-10-23
DCAT-AP-NO: Standard for beskrivelse av datasett og datakataloger, versjon 1.1, 2016-10-11
W3C-DWBP: Data on the Web Best Practices- Working Draft 12 January 2016 POD: Project Open Data Metadata Schema v1.1, February 2015