Tips og spørsmål

Eit anna eksempel på frivilleg brukarregistrering på opne data frå offentleg sektor;
NAV sitt API for arbeidsplassen.no
https://arbeidsplassen.nav.no/vilkar-api

Der kan ein registrere seg med API-nøkkel. Det gir arbeidsplassen/NAV anledning til å kontakte brukarane ved endringar, driftsavbrot og liknande. Det står ikkje noko om at ein må (valfritt) fortelje om korleis dataene vert brukt, eller at NAV kan kontakte dei om det, sende ut brukarundersøkelse eller liknande. Eg mistenker at etter GDPR er ein nødt til å samle inn eksplisitt samtykke for dette formålet, slik at NAV kan få problem dersom ein seinare vil gjere dette.

@terje-bertelsen

Når skal Digidir implementere den nye begrepsstandarden i FDK? Jeg finner ingenting om dette i Digdirs roadmap. Vi i NAV har tenkt å berike våre 800 begreper i FDK med mer informasjon, men har ikke lyst til å gjøre det på to måter, altså først iht. utgående standard og deretter iht. ny standard.

Vennlig hilsen
Ida Solheim
Arbeids- og velferdsdirektoratet

@tine-kleivane Tusen takk! Se eget mail svar. Svært interessant med Vegvesen SLA-er.

Mitt navn er hans Löwe Larsen, og jeg har ansvaret for å utvikle informasjonsforvaltning innen helsesektoren på et nasjonalt nivå.

Ditt spørsmål er også interessant for oss i e-helse, hvor teknisk forvaltning av grunndata og ansvaret og eierskapet til selve grunndataene ofte er adskilt.

Jeg har altså ikke noe direkte svar til deg, men ved å sammenstille spørsmål og utfordringer kan vi kanskje bli litt klokere?

Laga eit PHP-script for å hente ut denne strukturen over staten, samt legg på alle organisasjonsnummer slik at ein kan koble dette med andre datasett.

Må endrast litt på for å kunne køyre, så det er mest til inspirasjon. Det er ikkje produksjonsklar kode.

To nivå
Kort fortalt, så hentast først ut toppnivået i staten (departement + andre toppnivå som t.d. domstolane), og deretter dei direkte underordna organa i nivå 2.

Eksempel på data (JSON) frå køyring av scriptet.
Informasjon om kvar enhet er den samme som ein får ut frå data.brrreg.no.
Det er organisert i eit hierarki med to nivå, samt lagt på ei liste med organisasjonsnummer på kvar enhet.

Underordna
Kvar enhet i toppnivået har eit felt («underordna») der underordna enhet er. For eksempel så er «ARBEIDS- OG VELFERDSETATEN» (kjent som NAV) under «ARBEIDS- OG INKLUDERINGSDEPARTEMENTET».

Organisasjonsnummer for å kunne koble med andre data
For kvar enhet i både nivå 1 og 2, blir det lagt på eit felt («orgNums») der alle organisasjonsnummer er med slik at ein kan krysskoble. For nivå 1 er det organisasjonsnummer til enheten, samt organisasjonsnummer for alle underenheter. For nivå 2 er det samme + rekursivt organisasjonsnummer for alle underordna enheter og alle underenheter.
NAV har for eksempel ei svært stor liste over organisasjonsnummer sidan dei har svært mange kontor.

Vi bruker nattlige importer av Brreg i tjenesteutvikling på Utdanning.no.

Noen kjente begrensninger i Brreg-dataene som fører til mye ekstraarbeid:

Vanskelig å få tak i datasett for opphørte organisasjoner. Så mange tjenester med org.nr som felt ender vi opp med "foreldreløse" data med manglende match fordi bedriften er lagt ned/fusjonert. Det er tungvindt at data for dette må spesialbestilles. Adressefelt kunne med fordel vært koblet til Kartverkets matrikkel i stedet for å være en fristekst full av feil og feilstavinger. Felt for bedriftens nettsted kunne vært koblet til NORID (hvis den har *.no-domene) siden NORID også har org.nr som nøkkelfelt. Det kunne økt datakvaliteten på dette feltet så mye at det faktisk vil kunne brukes (nå er feltet det bare skrot).

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

@leo-valen Takk for tipsa. Tenker konkret på kun korleis handtere rate-limiting. Å lage klientar som respektere cache-headerar (til dømes ETag) kan vi setje som premiss.

La oss seie at ein skal gjere 10 kall mot hotell.difi.no.
Dersom ein fyrer av alle kalla i eit jafs, går ein over grensa på 5 forespørslar i sekundet, og ein får feilmelding på halvparten og ein sit igjen med berre deler av dataene.
Ein (for) enkel måte å handtere dette er å automatisk prøve på nytt dersom ein får feilkode 429 (HTTP-statuskode «Too many requests») tilbake. Det fører til mange mislykka kall før ein kjem i mål med alle 10 kalla. For serveren er det langt mindre belastande å avvise for mange kall enn om serveren ikkje hadde hatt rate-limiting og måtte handtere mange kall i eit jafs. Det blir likevel ein del unødige kall med denne framgangsmåten.

Fann ein artikkel som går igjennom ulike strategiar for å handtere dette:
https://www.useanvil.com/blog/engineering/throttling-and-consuming-apis-with-429-rate-limits/

Grunnen til det opprinnelege spørsmålet er behovet for ein som utviklar å sleppe å forhalde seg til kompleksiteten med å handtere dette. Ideelt sett vil ein ha eit bibliotek som hjelper med dette slik at ein i koden berre kan oppgje kva kall som skal gjerast, og så handterer biblioteket rate-limiting og svar tilbake.

Alternativ: laste ned heile datasettet
I tilfellet med datahotellet, får ein ut data med 100 rader pr. API-kall (paginering). Dersom ein vil hente ein stor del av datasettet, og datasettet ikkje er så stort, bør ein vurdere å heller hente ned heile datasettet. Er det f.eks. under 20 MB, så kan det fungere fint å hente ned også i klientside-kode som køyrer i nettlesaren til sluttbrukaren. Å laste ned heile datasettet i eitt kall er kun tilgjengeleg i CSV-format.

Gjorde dette sjølv for eit par år sidan i eit hobbyprosjekt (søk på «$.csv»). Riktignok eit eldre programvarebibliotek (jQuery-plugin). Det fungerte svært bra. Nettlesaren handterte då cache-mekansimen (ETag) slik at datasettet (ca. 5 MB) ikkje vart lasta ned på nytt med mindre det var ein ny versjon av datasettet.

Hei Espen,
Ja, vi erfarer også at API tilbydere sliter med å dokumentere på en måte som gjør at brukeren både forstår hvilken data de får tilgang til og hvordan man rent teknisk skal implementere. Vi ser mange eksempler på at tilbydere prøver å gjøre begge deler i samme dokumentasjon, hvilket ofte fører til at hverken dataen(produktet) eller implementasjonen blir enkel å forstå. Jeg opplever nok ikke at våre brukere stiller like høye krav til dokumentasjon som det du beskriver over. Det er selvsagt behov for å forstå hvor dataen kommer fra, hva betingelsene for å bruke den er og hvordan man kan implementere mot den, men vi opplever at skoen trykker mest på det å enkelt kunne få en oversikt og forstå hva man får tilgang på, også for en person som ikke nødvendig vis er utvikler.

I Tadata fokuserer vi på at det skal bli enkelt for brukere å sette seg inn i hvilken data som ligger bak et gitt API og hva som skal til for å få tilgang til den. Vi har laget en testfunksjon som gjør at brukere kan kjøre spørringer direkte i nettleser med input fra enkelt forståelige felter, og opplever at dette blir mye brukt og er av stor verdi. En litt enklere og mer praktisk tilnærming til dokumentasjon kan man vel kanskje si. Kanskje er dette noe man kan benytte seg av på toppen av mer omstendelig dokumentasjon i det offentlige også?

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

Ja, jeg tenker meg et sted der vi kan ha kontoer som https://twitter.com/Regjeringen, https://twitter.com/datakatalogen, https://twitter.com/Trondheim, https://twitter.com/ssbnytt, https://twitter.com/Arkivverket, https://twitter.com/VegvesenMidt og https://twitter.com/VegvesenData.

...

(Sånn i parentes ser jeg også gjerne at noen av skattepengene mine brukes til støtte til sosiale medier for befolkningen, f.eks. ved å drifte egne tjenere eller noe lignende pressestøtte, men det er en mye større oppgave og en mye større diskusjon.)

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.