Datalandsbyen

@datajegeren
Offentlig sektor besitter altså ikke Norges lover i en konsolidert utgave.
Jeg antar at du med konsolidert lov mener en oppdatert og gjeldende lov?

Kan man få tilgang til en ikke-konsolidert utgave?
Det er jo ikke optimalt, men bedre enn ingenting.

Hvis min forståelse er rett besitter ikke det offentlige gjeldende norsk lov.
Hvem besitter de gjeldende Norges lover?

Er det ingen som ser dette som en utfordring?i

Nå fikk jeg vite i neste tråd at jeg kan prøve Justisdepartementet.
Jeg vil prøve det.
Så langt har jeg prøvd Digitaliseringsdirektoratet, Stortinget og Datalandsbyen (Digitaliseringsdirektoratet pekte på begge). Jeg har også vært innom Lovdata som ikke er en offentlig aktør.

@robert-sasak sa i Nedlasting av data om kjøretøy:

Jeg kan ambefalle q (http://harelba.github.io/q/) 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.

@livar-bergheim 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'])

Hei @filip-hansen
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.

Kva skjer med enheter i kommunal sektor som er sletta?
Vil for eksempel Viken fylkeskommune (921693230) 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» (930580783). Er det tilsvarande konvensjon for foretaksnamn dersom Viken fylkeskommune verande i Enhetsregisteret etter 01.01.2024?

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 «vegvesen/kjoretoyinfo».
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: https://hotell.difi.no/api/json/vegvesen/kjoretoy?query=ABCDDF394058 Slå opp direkte ved filter på feltet — ?tekn_unr=<understellsnummer>
Eksempel: https://hotell.difi.no/api/json/vegvesen/kjoretoy?tekn_unr=ABCDDF394058

For forskjell på søk og filter, sjå API-dokumentasjon, under «Eksempel på oppslag i API-et».

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; https://hotell.difi.no/api/json/vegvesen/kjoretoy

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.

@andrea 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 😄

Takk for tilbakemelding @christiane-andrea-frohlich!

Da får vi krysse fingrene for at de ordner det en gang i den ikke altfor fjerne fremtid 🙂

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.

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

intressant utvikling @may-britt-prestoy!

Det ser ut som følgende to endepunkter er aktuelle:
https://app.swaggerhub.com/apis/skatteetaten/aksjonaer-i-virksomhet-api/1.0.0
https://app.swaggerhub.com/apis/skatteetaten/aksjebeholdning-api/1.0.0

Videre virker det som at man må ha en bedrift for å søke om tilgang til dataene. Men jeg finner ingen mekanisme for å søke om tilgangen for akkurat disse endepunktene. Klikker man seg til "hvordan du får tilgang til opplysninger fra Skatteetaten" og så "Eller trenger du data fra
Aksjonærregister" > så kommer man til gammelt søknadsskjema om uttrekk fra registeret

EDIT: Hvis man foretrekker markdown filene som er kilden til docsen:
https://github.com/Skatteetaten/api-dokumentasjon/blob/main/docs/api/aksjebeholdning.md
https://github.com/Skatteetaten/api-dokumentasjon/blob/main/docs/api/aksjonaerivirksomhet.md

@anette-skurdal Så hyggelig! Her er det bare å låne og dele i vei. 🙂

Hei @Aslak-Ø

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 :-).

Vi i DFØ har sett på DCAT og Purview, se kildekoden: https://github.com/dfo-no/ads-datakatalog. På toppen har vi laget en datakatalog, se https://data.dfo.no/.

Vi har gjenbrukt mye av arbeidet til Digdir, se https://github.com/Informasjonsforvaltning/atlasdcat.

Digdir jobber i dag med å lage en atlas-plugin som man kan bruke sammen med Purview-løsningen.

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 listeprodukt@brreg.no

Beste hilsen
Jon Carlstedt Tønnessen
Forskningsbibliotekar
Nasjonalbibliotekets nettarkiv

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.

Hei @erlend-stav,

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

@kodeverkstad Nei, dessverre.
Slik avtalen med Finn er pt. får vi ikke lov til å tilgjengeliggjøre deres annonser i APIet.

@georg 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 ein eigen tråd for å utveksle tips om korleis hente data frå API med rate-limiting. Vart sjølv nysgjerrig på kva støtte som finst i form av HTTP-klientbibliotek, rammeverk og liknande.