Vi gjør det enklere å skape verdier med data som ressurs

Datajegeren

Juridisk veiviser

Søk etter data

Still spørsmål, se eksempler på hvordan deling og bruk av data kan skape verdier for deg og samfunnet.

Delta i Datalandsbyens diskusjoner

Bygg din kompetanse i deling og bruk av data med våre kurs.

Nyttige kurs

Veilederne gir deg hjelp med å dele og bruke data til nye formål.

Gode veiledere

- Ser muligheter i data
- Trenger data til utvikling av nye løsninger
- Ser at dine data kan ha verdi for andre

Datafabrikken er for deg som:

Ny forside Datafabrikken

Datafabrikken gir deg tilgang på en mengde offentlig data, samt hjelp til å skape verdi fra disse.

Dette kan Datafabrikken hjelpe deg med – og slik kommer du i gang

Rozemarijn van der Hilst-Ytreland, leder for Nasjonalt ressurssenter for deling og bruk av data

Usikkerhet rundt regelverk er en «akilleshæl» for deling av data. Med sin nye juridiske veiviser for deling av data ønsker Datafabrikken å redusere denne barrieren – uten kostnad.

Ny juridisk veiviser for deling av data: Trekker ut essensen – i klartekst 

Bilde av Livar Bergheim. Foto: May-Britt Drage Bakke

Ny tjeneste fra Datafabrikken hjelper deg å finne offentlige data.

Nå lanseres Datajegeren – skal jakte datasett for norske bedrifter

<a class="plugin-mentions-user plugin-mentions-a" href="https://datalandsbyen.norge.no/uid/305">@espen-remman</a> sa i <a href="/post/793">Tilgjengeliggjøring av norges lover og forskrifter</a>:
<blockquote>
<a class="plugin-mentions-user plugin-mentions-a" href="https://datalandsbyen.norge.no/uid/52">@livar-bergheim</a> Takk for det. 
Burde jeg sende et brev til Justisdepartementet for eksempel?
</blockquote>
Beklager seint svar. Justisdepartementet er relevante å kontakte om desse dataene ja.

Tilgjengeliggjøring av norges lover og forskrifter

<a class="plugin-mentions-user plugin-mentions-a" href="https://datalandsbyen.norge.no/uid/60">@robert-sasak</a> sa i <a href="/post/264">Nedlasting av data om kjøretøy</a>:
<blockquote>
Jeg kan ambefalle q (<a href="http://harelba.github.io/q/" rel="nofollow ugc">http://harelba.github.io/q/</a>) som en enkelt SQL databasen direkte mot CSV filen. Som sagt vi jobber mye med kjøretøy databasen og har flere interne API. Kanskje vi kan hjelpe med.
</blockquote>

Nedlasting av data om kjøretøy

<a class="plugin-mentions-user plugin-mentions-a" href="https://datalandsbyen.norge.no/uid/52">@livar-bergheim</a> Var det jeg mistenkte, men det er ikke noe problem. Vasking og fjerning av ikke-relevante nøkler kan gjøres enkelt i python med pandas dataframes med df.drop:
# Fjerne kolonner for næringskode:

df.drop(columns=['naeringskode1', 'naeringskode1_beskrivelse', 'naeringskode2', 'naeringskode2_beskrivelse', 'naeringskode3', 'naeringskode3_beskrivelse'])

Analyse av Enhetsregisteret med Python og Pandas

Hei <a class="plugin-mentions-user plugin-mentions-a" href="https://datalandsbyen.norge.no/uid/80">@filip-hansen</a> 
Takk for svar. Det er fint å finne noen som deler interessen for tema. Felles forståelse er viktig, og for oss er det nøkkel til alt. 
Så en liten generell kommentar. 
Vi mennesker ser alltid etter mønster rundt oss for å strukturere vår forståelse av virkeligheten. Vi lager "data" ut av våre observasjoner i den grad det er mulig. 
Og til eksemplene du viser til i din tekst er min påstand: Det er kun når vi analyserer, omformer og drar statistikk ut av det ustrukturerte at det blir data av det, altså noe som kan settes opp i tabeller og dermed representere mønstere som igjen gir forståelse, altså merverdi. Årringer er grunnlag for tabelldata, DNA er ekstremt strukturert kode. Og disse representasjonene er uten unntak det jeg kaller datasett. 
PDFene i min etats arkivsystem er informasjon inntil noen skraper disse for ord og lager møsterdata og logiske statistiske analyser ut av mengden av naturlig språk inklusive tall og symboler i disse. 
Så til forståelse av data som noe som kan settes opp i tabell med kolonner med definert innhold - helst fylt med det vi kaller verdilister/kodeverk. Disse kodeverkene er våre informasjonsmessige representasjoner: for språk er primærkodeverket våre lydbærende skrifttegn (tegnesett) og tallsymboler samt andre meningsbærende eller logiske symboler. Så er å er disse satt sammen til ord som kan være ett ords- eller flerordsbegreper - altså mening. Begge disse kan vi regne som kodeverk, og ved analyse setter vi disse opp i tabeller som gir oss innsikt av det ene eller andre slaget - vi har data. Og disse dataene kan sammenstilles med andre datasett som er satt opp med tilsvarende kriterier. 
Så svaret mitt til ditt første spørsmål er at begrepet data forteller alle at det er snakk om strukturerte representasjoner av "virkeligheten", ikke bare våre intuitive observasjoner eller beskrivelser av disse med språk, lyd eller bilde. Og da gir begrepet merverdi i forhold til det bredere informasjon.

Hva er et datasett?

Kva skjer med enheter i kommunal sektor som er sletta? 
Vil for eksempel Viken fylkeskommune (<a href="https://data.brreg.no/enhetsregisteret/api/enheter/921693230" rel="nofollow ugc">921693230</a>) bli liggande ei stund i Enhetsregisteret etter 01.01.2024? 
Ser at førehandsregistreringar i kommunal sektor har som konvensjon at foretaksnamnet er for eksempel «NYE AKERSHUS FYLKESKOMMUNE FRA 01012024 UNDER FORHÅNDSREGISTRERING» (<a href="https://data.brreg.no/enhetsregisteret/api/enheter/930580783" rel="nofollow ugc">930580783</a>). Er det tilsvarande konvensjon for foretaksnamn dersom Viken fylkeskommune verande i Enhetsregisteret etter 01.01.2024?

Datasett Enhetsregisteret, REGISTERENHETEN I BRØNNØYSUND

Understellsnummer fjerna i Datahotellet 
No er understellsnummer (kolonna «tekn_unr» fjerna i Datahotellet). 
Endringa vart gjort kl. 16 i dag.
OBS! Nytt namn/id på datasettet 
For at alle som slår opp på understellsnummer skal få med seg at datasettet er endra, så byter vi også namn på datasettet. Alle integrasjonar vil slutte å virke og API-kall gir statuskode 404 («Not found») tilbake.
Id'en var «vegvesen/kjoretoy», og blir no «<a href="https://hotell.difi.no/?dataset=vegvesen/kjoretoyinfo" rel="nofollow ugc">vegvesen/kjoretoyinfo</a>». 
Endringa vart aktiv 17:01.
Grunnen til dette er at no som understellsnummer er fjerna, kan ein få feil svar tilbake. For nokre integrasjonar som gjer oppslag mot understellsnummer, vil ein ikkje få tomt resultat tilbake når ein no slår opp på understellsnummer. I staden for får ein tilbake dei 100 første radene i datasettet. For å unngå mulege problem hos dei som har sett opp integrasjonar som ikkje er robuste, så endrar vi identifikator på datasettet slik at alle integrasjonar stoppar å virke. På denne måten får også alle som nyttar datasettet med seg endringar. Det er antagelegvis fleire som ikkje har fått med seg annonsering av denne endringa.
Meir tekniske detaljar 
Det er to måtar ein kunne slå opp på understellsnummer. Det er kun den eine av desse måtane som gir feil svar tilbake.

Slå opp ved hjelp av søk — bruke query-parameteret. Eksempel 
Eksempel: <a href="https://hotell.difi.no/api/json/vegvesen/kjoretoy?query=ABCDDF394058" rel="nofollow ugc">https://hotell.difi.no/api/json/vegvesen/kjoretoy?query=ABCDDF394058</a>
Slå opp direkte ved filter på feltet — ?tekn_unr=&lt;understellsnummer&gt; 
Eksempel: <a href="https://hotell.difi.no/api/json/vegvesen/kjoretoy?tekn_unr=ABCDDF394058" rel="nofollow ugc">https://hotell.difi.no/api/json/vegvesen/kjoretoy?tekn_unr=ABCDDF394058</a>

For forskjell på søk og filter, sjå <a href="https://hotell.difi.no/api" rel="nofollow ugc">API-dokumentasjon, under «Eksempel på oppslag i API-et»</a>.
Det er nr. 2) som gir 100 første radene i datasettet. Når feltet «tekn_unr» ikkje lenger eksisterer i Datahotellet, blir forespørselen behandla på samme måte som om parameteret ikkje var med; <a href="https://hotell.difi.no/api/json/vegvesen/kjoretoy" rel="nofollow ugc">https://hotell.difi.no/api/json/vegvesen/kjoretoy</a>
Det er dessverre slik Datahotellet fungerer. Ein får ingen feilmelding dersom ein gjer API-kall med parameter som er ugyldige.
For oversikt; eg jobbar i Digdir med blant anna Datahotellet, og bistår Statens vegvesen i publisering på Datahotellet når det gjeld dette datasettet.

Endring i datasett Teknisk kjøretøyinformasjon på datahotellet

<a class="plugin-mentions-user plugin-mentions-a" href="https://datalandsbyen.norge.no/uid/528">@andrea</a> Vi har dessverre ikke noe åpen kildekode, men det er bare å komme med ønsker, så skal vi absolutt vurdere det i den videre utviklingen!
Angående å hente ut mer data i ett kall og gjennomsnittspris, er dette noe som flere har kommet med forslag om, så det står allerede på todo-listen 😄

Gratis og åpent API for strømpriser

Som nevnt i første post bruker jeg ENTSO-E sitt api i dag, og ja, veldig fint at noen lager enklere variant for hvermansen, men dette vil jo ha samme problem som i topicen når ENTSO-E sitt api detter ned.
Hvorfor Nord Pool er så grådige for tilgang på data fra dem skal ikke jeg spekulere i, men det var derfor jeg tenkte at staten burde ta ansvar her, og si at det burde være en folkerett å ha god tilgang på pris på det vi kjøper.
Jeg har også laget et lite api for å hente ut priser på strøm, nettleie, dag/nattsater, vinter/sommerpriser, enovaavgift, elavgift, strømstøtte beregninger, etc. Det gir et meget omfattende bilde av faktisk strømpris. api-et henter data fra mange kilder, inkludert både ENTSO-E og Nord pool Jeg har dog ikke vært tøff nok til å gi public tilgang til dette. Så for min del, så har jeg nå stålkontroll over strømprisene. Men, jeg syns dette er urettferdig! Man må sitte med dyp kunnskap og utvikle dette selv, som jo ekskulderer de aller fleste som faktisk sliter med både teknisk forståelse og det å få krone-kabalen til å gå opp. Med et lovlig, stabilt offentlig api, vil det kunne motivere tjenesteutviklere til å lage løsninger som kan hjelpe dem som trenger det mest.
Jeg tror ikke dere vil få noen problemer med å ha api-et som dere har laget offentlig, og takk som er villige til å gjøre det! Men, å utvikle en tjenete som faktisk nytter seg av dette for å hjelpe hvermansen med presentasjon av data i etterkant er nok like risky da sluttproduktet fremdeles ikke har lov å distribuere denne prisinformasjonen.

Norske strømpriser

Takk for svar. Jeg ser at tjenesten leverte oppdaterte data på mandag, men i dag (tirsdag 22. august) er det ingen nye data.

Datatjeneste Kjøretøyopplysninger (tekniske data enkeltoppslag), STATENS VEGVESEN

<a class="plugin-mentions-user plugin-mentions-a" href="https://datalandsbyen.norge.no/uid/367">@anette-skurdal</a> Så hyggelig! Her er det bare å låne og dele i vei. 🙂

Hva er egentlig et API?

Hei <a class="plugin-mentions-user plugin-mentions-a" href="https://datalandsbyen.norge.no/uid/201">@Aslak-Ø</a>
Så bra at dere kjører seriøs prosess med å skaffe verktøy for intern datakatalog. 
Mattilsynet som jeg jobber i, bestemte seg ikke for å legge midler i tilsvarende behov. Vi konkluderte da etter noe tid med å satse på FDK som vår interne og eksterne datakatalog. Vi er i ferd med å ta den i bruk som intern katalog for begreper, og vil også gå igang med å registrere datasett denne veien. Vi har allerede engasjert mange av dataeierne i å føre GDPR protokoller i løsningen, så vi er igang med desentral bruk av FDK. 
Jeg har en filosofi om at det er dataeierne i huset som må ha ansvaret for å definere sine begreper og beskrive sine datasett - "holde orden på sitt rom". Så får jeg og noen informasjonsforvaltningsmennesker hos oss være tilretteleggere for våre dataeiere - "leie dem i handa". 
FDK har jo relativt greie skjema for dette. Styrken i FDK er at den følger standarder som vi alle er pålagt å følge. Og at det til slutt er et klikk fra ansvarlig eier for å gjøre metadatene offentlig tilgjengelig. 
Vi er jo søsteretater, og jeg ser fram til at vi begge kan henvise til FDK for våre metadata :-).

Erfaringer med innkjøp av applikasjoner for interne datakataloger

Vi i DFØ har sett på DCAT og Purview, se kildekoden: <a href="https://github.com/dfo-no/ads-datakatalog" rel="nofollow ugc">https://github.com/dfo-no/ads-datakatalog</a>. På toppen har vi laget en datakatalog, se <a href="https://data.dfo.no/" rel="nofollow ugc">https://data.dfo.no/</a>.
Vi har gjenbrukt mye av arbeidet til Digdir, se <a href="https://github.com/Informasjonsforvaltning/atlasdcat" rel="nofollow ugc">https://github.com/Informasjonsforvaltning/atlasdcat</a>.
Digdir jobber i dag med å lage en atlas-plugin som man kan bruke sammen med Purview-løsningen.

DCAT fra Azure Purview

<a class="plugin-mentions-user plugin-mentions-a" href="https://datalandsbyen.norge.no/uid/615">@hermonmelles</a> Tusen takk for god og grundig tilbakemelding, Hermon!
Forstår jeg deg rett, understreker tilbakemeldingen din kompleksiteten og usikkerheten rundt rettighetssituasjonen til både inputen og outputen, men i hovedsak outputen.
Vi har også fått et annet innspill (i en annen kanal) om at vi i vår fremstilling bør fokusere på rettighetene til det genererte materialet/outputen (både tekst, bilder og kode mm.) og hvordan dette blir brukt. Bakgrunnen for dette er følgende:


Fokus på "outputen" treffer de aktuelle rettighetene bedre: Det er ingen tvil om at det er usikkerhet knyttet til trening av de store maskinlæringsmodellene med immaterielt vernet materiale. Her er det mange viktige spørsmål og diskusjoner. De synes imidlertid ikke å treffe norske virksomheter i så stor grad, all den tid disse modellene trenes av utenlandske teknologiselskaper. For norske virksomheter er det outputen som i praksis får betydning, og da skal ikke vi bruke for mye tid på detaljspørsmål knyttet til inputen.


Det er en praktisk nyttig tilnærming: Det er lite sannsynlig at virksomheter vil klare å kontrollere rettighetssituasjonen til inputen. En ansatt vil eksempelvis kunne bruke tekst i ChatGPT e.l. som har opphavsrettslig vern og det vil være vanskelig for en virksomhet å kontrollere dette. Virksomheten bør i stedet ha tydelige retningslinjer for hvordan det genererte materialet benyttes. I dette ligger at virksomheten må sikre at det genererte materialet ikke er plagiat. På denne måten blir tilnærmingen litt det samme som uten generativ KI. I dag vil jo en ansatt fritt kunne lese og la seg inspirere av opphavsrettslig beskyttet materiale, så fremt dette ikke plagieres eller på en annen måte benyttes i strid med immaterielle rettigheter. Jo mer praktisk nyttig vår veiledning, jo større er sannsynligheten for at vi får regelverksetterlevelse i praksis. Og det er jo helt klart målet.


Slik jeg forstår deg, er dine tilbakemeldinger forenelig med dette innspillet vi har fått. Du peker på at det er bruken av det bearbeidede verket etter åndsverkslovens § 6 som kan forutsette samtykke, og ikke selve bearbeidelsen. Det er altså en konkret vurdering av om det genererte materialet og hvorvidt kravene til verkshøyde tilsier "bearbeidet verk" eller "selvstendig verk". Også etter markedsføringslovens § 25 vil vel dette bero på en konkret vurdering hvor en ser på det genererte materialet opp mot det opprinnelige materialet. Vi vil altså kunne ta med dine innspill i arbeidet fremover hvor vi særlig ser på "outputen".
Gi meg gjerne tilbakemelding dersom jeg har misforstått noe i innspillet ditt.
TLDR; Vi tenker fremover å fokusere på outputen. I en veiledning som dette vil det blant annet kunne være aktuelt å peke på tiltak/rutiner osv. for å bidra til å sikre at det genererte materialet ikke er plagiat eller på en annen måte brukes i strid med immaterielle rettigheter.

[Diskusjonstråd] Spesifikke retningslinjer for bruk av generativ kunstig intelligens i offentlig sektor

Vi har nylig bestilt uttrekk fra historiske versjoner av Enhetsregisteret for perioden 2009-21, to datasett per år (hovedenheter og underenheter).
Vårt formål var å dokumentere endringer av domenenavn over tid, men du bør fint kunne bruke dette til å spore endringer i hvilke enheter som har vært oppført.
Bestillingen ble gjort per e-post til <a href="mailto:listeprodukt@brreg.no" rel="nofollow ugc">listeprodukt@brreg.no</a>
Beste hilsen 
Jon Carlstedt Tønnessen 
Forskningsbibliotekar 
Nasjonalbibliotekets nettarkiv

Historisk enheter fra enhetsregisteret?

Har fått kontakt rett stad i departementet, KDD — tidlegare KMD, og fått svar: 
«Vi har ikke umiddelbare planer om dette. Lønnstabellen inneholder begrenset med data, og vi ser ikke et stort behov for digitalisering grunnet den begrensede mengden med data.»
Avventar meir informasjon om behovet før eg følgjer opp vidare.

Lønn for ansatte i staten

Hei <a class="plugin-mentions-user plugin-mentions-a" href="https://datalandsbyen.norge.no/uid/147">@erlend-stav</a>,
Takk for oppdatering. Sjekker og kommer tilbake med eventuelle spørsmål.
Bra at man samskaper på tvers med tematikken. Ingen vits at flere aktører finner opp det samme hjulet.
Mvh 
Johnny Alexander

Guide til åpne data - Hvordan kan byer og kommuner komme enkelt i gang

<a class="plugin-mentions-user plugin-mentions-a" href="https://datalandsbyen.norge.no/uid/389">@georg</a> PEPPOL Directory er ein måte å sjekke på, men det beste er som Frode (@kons-fbj) seier, å gjere eit SML+SMP-oppslag. Det er fleire grunnar til det. Då eg sist var meir inne i PEPPOL-domenet for snart eit år sidan, så var det ikkje eit absolutt krav at alle SMP-ar må legge inn sine mottakarar i PEPPOL Directory. I så fall vil ikkje PEPPOL Directory ha ein komplett oversikt. Eg veit ikkje om det er blitt eit krav nyleg. Sjølv om det er blitt eit krav, så vert det eit ekstra ledd til den faktiske registreringa i PEPPOL (oppslag via SML+SMP), og dermed ei ekstra feilkilde. Nokre SMP-ar har kanskje problem med oppdatering til PEPPOL Directory osv.
Dersom du får 429-feil på oppslag i PEPPOL Directory, så var det mogeleg å laste ned heile PEPPOL Directory som ei stor fil og så gjere sjekk lokalt. Om det er ein batch-jobb som ikkje køyrer veldig ofte, så kan det vere ein meir farbar veg.
Laga forresten <a href="https://datalandsbyen.norge.no/topic/184/bruke-api-med-rate-limiting">ein eigen tråd for å utveksle tips om korleis hente data frå API med rate-limiting</a>. Vart sjølv nysgjerrig på kva støtte som finst i form av HTTP-klientbibliotek, rammeverk og liknande.

ELMA for alle norske bedrifter

Mari Vestre sin presentasjon er ute i <a href="https://www.digdir.no/datadeling/fagleg-arena-datadeling-og-informasjonsforvaltning/4026" rel="nofollow ugc">PDF på arrangementssida på Digdir</a>

Faglig arena 09.11.2022

<a class="plugin-mentions-user plugin-mentions-a" href="https://datalandsbyen.norge.no/uid/37">@steinar-skagemo</a> Jeg tenker at forholdet mellom personvern og konkurranseregelverket har et enda videre perspektiv. Introduksjon av nye systemer/tjenester eksploderer i markedet i dag. Mange av disse har ikke innebygd personvern og personvern som standardinnstilling som har vært et krav siden 2016. I beslutningsprosesser trumfer dessverre design og funksjonalitet sikkerhet og personvern som gjør at 'useriøse' aktører (og deres investorer) som ikke tar seg tid til å bygge robust teknologi vinner mens de som tar dette på alvor ofte er de som ikke vinner frem. Det lønner seg derfor ikke å bruke tid og penger på sikkerhet og personvern. Så lenge myndighetene ikke håndhever regelverket vil dette være konkurransevridende.

Åpne innspill og diskusjon

<a class="plugin-mentions-user plugin-mentions-a" href="https://datalandsbyen.norge.no/uid/36">@Jim-J-Yang</a> Dere har ikke laget en slik mal for Tjenester-beskrivelse også vel? Hmmm. Det er vel den CPSV-AP-NO det ja. Jeg har en i mitt hus som gjerne vil se på denne, så en oversendelse er helt ok.