Tips og spørsmål

Vi i CKAN implementer DCAT v.3 nå (https://github.com/ckan/ckanext-dcat/issues/271) hvis du kan dele krav for Norge, det kan hjelpe oss.

@tony sa i Ny versjon av teknisk kjøretøyinfo: Hei, jeg la merke til at reg.år ikke finnes i versjon 2. Lette etter tekn_reg_f_g i json, men finner kun tekn_reg_f_g_n. Det stemmer. Her var det en feil som gjorde at akkurat det feltet («tekn_reg_f_g») ikke kom med på Datahotellet. Det ble rettet for et par timer siden. PS. Bruker du datasettet teknisk kjøretøyinfo eller andre datasett fra offentlig sektor, skriv gjerne kort om det i form av et innlegg i kategorien «Gode eksempel på bruk» (se tips).

@sven_bruun Bruker linken https://hotell.difi.no/download/vegvesen/kjoretoyinfo?download til å analysere bilparken, men det ser ikke ut til at denne informasjonen er vedlikeholdt lenger. Hvor kan jeg finne fila med alle biler?

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