Datalandsbyen

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

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.

Helt enig at offentlig data bør/skal være offentlig.

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 😄

@oivind-langeland @sophus-aarnaes : Det er framleis analyse av Enhetsregisteret med Python, sjølv om det er utan Pandas, så eg tenker dette passar godt som ei fortsetting på denne tråden 🙂
Om du seinare tykkjer det passar betre, går det alltids an å lage ein ny tråd.

Kommentarfeltet tenker eg passar betre for kortare kommentarar, til dømes @oivind-langeland sitt innlegg med eit godt tips til andre brukarar på å vere obs på at XLSX-fila har fleire ark. Det er nokre tankar om kva ein kan bruke kommentar-feltet til i lanseringsposten frå tidlegare i år. Kommenter gjerne om du har tankar om kommentarfeltet.

Dersom ein har ein lengre diskusjonstråd som her, så passar det betre som ein vanleg tråd/emne i Datalandsbyen. Når ein legg inn ei lenke til datasettet i posten, dukkar det opp i datasett-oppføringa på data.norge.no, under avsnittet «Datalandsbyen»:
e36a61d5-678d-4dc4-890f-61323a5ea52c-image.png

@jon-tonnessen Takk for svar. Utfordringen med json er at filen er enormt stor (den er heller ikke komprimert) . Koden min laster ned excel filen, konverterer med Xlsx2csv og importerer csv direkte in i postgres database. Derfra gjør programmet sync og oppdateringer mot andre systemer (javascript/node) .

Så excel er bare plunder og heft for meg 😞

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.

@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

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

Mari Vestre sin presentasjon er ute i PDF på arrangementssida på Digdir

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

@steinar-skagemo Beklager at dette har tatt litt tid. Hvis du ser på beskrivelsen av datasettet, så finnes det en lenke til API-dokumentasjon herfra. API-et er åpent og tilgjengelig, men det er ikke registrert i API-katalogen på data.norge.no. Vi har tatt kontakt med Arkivverket og beskrevet noen forslag til hvordan de kan beskrive API-et i API-katalogen. Vi får håpe at det kommer noe der etter hvert.

Beklager at det tar tid å besvare denne! URLen er under endring, vi oppdaterer så snart vi har fått endelig info om hva som er riktig URL!