Datalandsbyen

Jeg har brukt Go med kun standard-biblioteket en del de siste årene for første behandling av store CSV-filer (og sammenstillng av Excel gjennom excelize biblioteket). Go er minne-effektivt med utf-8 internt, og med litt parallell kjøring kan man iterere relativt hurtig på noen GB. I senere tid er Copilot tjenesten til github nyttig og gjør at man kan skrive kommentarer som "UFT-16 with BOM transformer encoding" fremfor å lete i dokumentasjonen (Men, det blir jo litt kodelinjer, så det er ikke noe man alltid ønsker å dra frem)

Dette er egentlig ikke noen erstatning for Pandas i python eller tidyverse i R.

Google BigQuery er ganske rimelig når datasettet blir stort.

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.

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.

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

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

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

Vi har behov for dette datasettet i utdanning.no. Vi har hittil løst det med å sammenstille flere historiske dumper av brreg-databasen til en forløpsdatabase, dvs. en datakilde med felt for år en org-enhet oppsto og når den eventuelt forsvant. Dermed kan vi finne ut geografisk sted for organisasjoner som ikke lenger er aktiv.

Spennende!
Dette er viktig. 🙂

hilsen
en utålmodig sjel som både arbeider med forskningsprosjekt rundt bruk av kontrakter og generell språkteknologi.

Espen Remman
97 55 70 21

@Jim-J-Yang 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.

@livar-bergheim

Ja, for at brukere skal ha ubegrensede muligheter til å redigere tidligere innlegg, er terskelen i dag at de trenger tre "upvotes" eller stemmer fra andre brukere. Tidsapspeket er derfor ikke like relevant, men omdømmet er.

Vi kommer til å ta i bruk Datex 3.1, den er dokumentert her: https://docs.datex2.eu/downloads/modelv31.html . Standarden har flere profiler, vi har ennå ikke valgt hvilken profil vi skal bruke. Det kommer til å bli dokumentert på https://www.vegvesen.no/om-oss/om-organisasjonen/apne-data/datex/ på forhånd.

Vi jobber også med en forbedring av vegmeldingene som kommer i løpet av året. Der har vi vurdert en tilpasning som tillater filtrering på fjelloverganger. Det er ennå ikke bestemt om den blir implementert (avhenger av hva vi har tid og penger til, sett opp mot andre ting vi vil gjøre), men det er nyttig å vite at dette er noe som folk har bruk for og etterlyser.

De skriftlige presentasjonene fra dagens møte er å finne her: https://www.digdir.no/informasjonsforvaltning/faglig-arena-informasjonsforvaltning/2846

Opptak finnes her: https://vimeo.com/595799014

Send en e-post til christiane.andrea.frohlich@digdir.no for å motta passord til opptaket.

@jim-j-yang
Flott - og takk for sist 😉
Jeg tar kontakt med det første

Ressurssenteret deltok på OffDig konferansen i Danmark 23. og 24. mars - danskenes store årlige digitaliseringskonferanse. Vi arrangerte en workshop om EUs Data Governance Act.

Her er presentasjonen vi brukte:
20220324 OffDig Nordic approach to EU data sharing.pdf

Et kort reisebrev ligger nå ute på bloggen vår. I tillegg finner dere en kort notis om en workshop kollegaer i Digdir var med å arrangere om nordisk samarbeid om sammenhengende tjenester her.

Hei, avtalen vi har med FINN.no innebærer pt. at vi ikke kan dele stillingsannonsene vi får fra dem videre i dette API-et. Vi er i dialog med FINN.no for å se om det er mulig å få delt flere data fra disse annonsene fremover, men per nå har vi altså ikke anledning til å dele dette videre.

@tom-1-2-3 Datasettet vert oppdatert kvar veke, vanlegvis på måndags morning/formiddag. Ser det manglar informasjon om oppdateringsfrekvens i oppføringa på data.norge.no.

Du kan hente ut ETag-verdien (ein HTTP-header) på datasettet for å sjekke når tid det vart sist oppdatert. Sjå detaljar på datahotellet si dokumentasjonsside, under overskrifta "ETag".

Det er eit nettlesar-innstikk (plugin som det heiter) som gir deg tidspunktet for sist oppdatering på eit datasett.
Med innstikket installert, så får ein opp tidspunktet når ein ser på datasettet i nettvisninga på hotell.difi.no:
03fb9b05-7fce-4983-b546-39da9d697a1d-image.png

Takk for svar!

@livar-bergheim Tusen takk for oppfølgingen! Jeg er glad jeg var ydmyk i min første post og antydet at feilen nok kunne ligge på min side. Ved nærmere testing, og etter noen tips fra @steinar-skagemo , viser det seg nemlig at feilen nettopp ligger på min side. Det viser seg altså at xlsx-filen man får ned fra APIet til Brreg inneholder to faner. Dersom Xlsx2csv-modulen kjøres uten parametere, tar den bare første fanen, og da mister man data. Jeg løste det ved å kjøre Xlsx2csv-modulen to ganger, en gang for hvert sheet, og deretter slå sammen resultatene fra disse to kjøringene, og droppe duplikatene. Da stemmer tallene overens fra xlsx og direktesøk i APIet til Brreg. Det er nok mangt man kan si om koden under, men den viser hvert fall hvordan det kan gjøres. Igjen tusen takk for at både du og Steinar fulgte opp, saken er løst 🙂

def lag_utvalg(): Xlsx2csv(ER_FULL_FIL, outputencoding="utf-8").convert("er1.csv", sheetid=1) Xlsx2csv(ER_FULL_FIL, outputencoding="utf-8").convert("er2.csv", sheetid=2) df_fane1 = pd.read_csv('er1.csv') df_fane2 = pd.read_csv('er2.csv') df_kombinert = pd.concat([df_fane1, df_fane2], ignore_index=True, sort=False) df_kombinert_trimmet = df_kombinert[["Organisasjonsnummer", "Navn", 'Organisasjonsform.kode', "Organisasjonsform.beskrivelse", "Næringskode 1", "Næringskode 1.beskrivelse", "Næringskode 2", "Næringskode 2.beskrivelse", "Næringskode 3", "Næringskode 3.beskrivelse", "Postadresse.adresse", "Postadresse.kommune", "Registreringsdato i Enhetsregisteret", "Antall ansatte"]] df_utvalg = df_kombinert_trimmet.astype(str) sok_etter = list(NACE_UTVALG.split(",")) nace_utvalg_1 = df_utvalg[df_utvalg['Næringskode 1'].str.contains('|'.join(sok_etter))] nace_utvalg_2 = df_utvalg[df_utvalg['Næringskode 2'].str.contains('|'.join(sok_etter))] nace_utvalg_3 = df_utvalg[df_utvalg['Næringskode 3'].str.contains('|'.join(sok_etter))] utvalg = pd.concat([nace_utvalg_1, nace_utvalg_2, nace_utvalg_3], ignore_index=True, sort=False).drop_duplicates(subset=['Organisasjonsnummer']) skriv_csv(utvalg, ER_UTVALG_FIL)