Skip to content

Velkommen til Datalandsbyen!

Her kan du stille spørsmål om data, delta i diskusjoner, dele prosjekter, knytte kontakter og finne samarbeid. Forumet er åpent for alle, men du må registrere deg for å poste. Bli med og bidra til kunnskap, åpenhet og innovasjon!

  • I denne gruppen kan du dele tips og spørre om alt du måtte lure på.

    85 Emner
    265 Innlegg
    S

    Hei, Livar og takk for svar!
    Godt innspill å snevre inn definisjonene - det er jeg enig i.

    Du har et godt poeng med 1 aksje eksemplet ditt. Kanskje om man tar utgangspunkt i Daglig leder og personer med signaturrett?

    Jeg har mens jeg venter på svar her funnet et midlertidig alternativ; Ved å sende en OTP til mobilnummeret oppgitt i virksomhetens Brreg data.

    Minusen med løsningen over er at det er veldig få som har lagt inn mobilnummer og at det tildels er slitsomt å endre disse opplysningene.

    Ser frem til svar!

  • Brukt data eller API-er til noe spennende? Del her!

    23 Emner
    33 Innlegg
    J

    Jeg har begynt å oppdatere mine Jupyter notebooks som viser hvordan bruke Python for å hente data fra SSBs APIer.
    Du finner eksemplene her:
    📂 GitHub-repoet mitt

    Samtidig har også R-pakken PxWebApiData, som gjør det enkelt å hente data fra ulike statistikkbankers APIer (inkl. Eurostat), nylig nådd versjon 1.0
    Mer om dette her:
    📦 CRAN-siden til PxWebApiData

    Disse verktøyene kan være nyttige for datadrevne prosjekter og analyser – uansett om du foretrekker Python eller R.

    Jan Bruusgaard
    Pensjonist (tidl. SSB)

  • Diskuter og tips om møter, arrangementer og konkurranser.

    247 Emner
    325 Innlegg
    T
    Oppsummering av informasjonsmøtet Opptak

    🎞 Video av informasjonsdelen finner du på Vimeo: https://vimeo.com/1053674448/94a89c918b?share=copy 📽

    Ressurser

    Relevante lenker til sider og ressurser som nevnes i møtet:

    Standarden DCAT-AP-NO: https://data.norge.no/specification/dcat-ap-no GitHub (hvor du kan opprette issue): https://github.com/Informasjonsforvaltning/dcat-ap-no Standarden HVD-DCAT-AP-NO: https://data.norge.no/specification/hvd-dcat-ap-no GitHub (hvor du kan opprette issue): https://github.com/Informasjonsforvaltning/hvd-dcat-ap-no Veileder for Orden i eget hus: https://www.digdir.no/informasjonsforvaltning/veileder-orden-i-eget-hus/2716 Kræsjkurs i RDF: https://data.norge.no/nb/docs/sharing-data/rdf Hvordan lage og publisere en datasettbeskrivelse fra A-Å: https://data.norge.no/nb/docs/sharing-data/how-to-dataset Kontakt oss Tekniske spørsmål knyttet til data.norge.no: fellesdatakatalog@digdir.no Andre spørsmål: informasjonsforvaltning@digdir.no Spørsmål og svar

    Spørsmål: Hva er relasjonen mellom en dataleverandør og en katalog. Er det meningen at hver organisasjon skal ha en katalog?

    Svar: Et datasett må være del av en katalog, og katalogen med datasettene må være beskrevet i en fil for at data.norge.no skal kunne høste hele katalogen. Hver virksomhet bør ha en egen katalog. Hver virksomhet kan lage flere kataloger om de ønsker.

    Spørsmål: Er det tilstrekkelig at virksomhets datakatalog høstes til GeoNorge eller annen sektorspesifikk katalog?

    Svar: Om virksomhetens datakatalog høstes til GeoNorge vil det også automatisk høstes til data.norge.no, så man vil da oppfylle Digitaliseringsrundskrivets krav til publisering av beskrivelser. Per nå kjenner vi ikke til tilsvarende løsninger som GeoNorge, og høster vi ikke fra andre sektorkataloger.

    Spørsmål: Selv virksomheter med små IT-avdelinger er pålagt å dele data, og for disse kan det være vanskelig å vite hvor man skal begynne. Virksomheten sitter gjerne på data, men må finne en avgrensning på hva som skal deles og hva som kan deles. Hvor begynner man?

    Svar: Her kommer vi inn på Orden i Eget Hus-konseptet som handler om hvordan få oversikt over egne data. Vi anbefaler at man ikke er for ambisiøs på hvor detaljert man skal være i starten, og at man jobber iterativt. Begynn med de feltene som er obligatorisk, gjerne med utgangspunkt i hvilke oppgaver eller tjenester man har. Hvilke datasett man beskriver kan basere seg på det andre har behov for, eller det man tror andre har behov for, enten i næringsliv, offentlig sektor eller sivilsamfunnet for øvrig.

    Samtidig er det vanskelig å vite hva andre har behov for og som er verdt å beskrive, før man har publisert en oversikt over egne data til data.norge.no og fått tilbakemeldinger på det. Så publiserer først enkle beskrivelser for å avdekke hvilke datasett det er interesse for, og utvid deretter til mer detaljerte beskrivelser der hvor det er interesse for datasettet. På Datalandsbyen kan du få tilbakemeldinger på de datasettene du har beskrevet.

    Spørsmål: Kan dere si litt mer om RDF? Er det vanlig å begynne i Excel/regneark? Hvor er et naturlig sted å starte?

    Svar: Excel/regneark er helt fint å begynne med for å få oversikt over sine data. Et spørsmål da er hvordan komme seg fra regnearket til et RDF-format som data.norge.no kan høste. Vi undersøker muligheter for å oversette fra regneark til RDF slik at data.norge.no kan høste beskrivelser i regneark eller andre lett tilgjengelige formater. Kom gjerne med innspill om dere har erfaring med hvordan gjøre dette. I tillegg har data.norge.no et mini-kurs i RDF og en steg-for-steg-veileder i hvordan beskrive sine datasett i RDF.

    En annen snarvei inn er Registreringsløsningen på data.norge.no, hvor du kan beskrive datasettene dine i en skjemaløsning. Men for virksomheter som har anledning til å forvalte beskrivelsene i egne systemer anbefaler vi heller det enn Registreringsløsningen; vi tror det enklere å holde beskrivelsene oppdatert når de forvaltes nært der selve datasettet befinner seg, nemlig i virksomhetens egne systemer.

    Spørsmål: Fins det støtte for konvertering av metadata fra åpne standarder som OpenAPI til DCAT-AP-NO? For oss som har en del metadata i dette formatet hadde det vært praktisk å konvertere det automatisk til RDF og DCAT-AP-NO.

    Svar: Vi har fra tidligere et Python-bibliotek, oastodcat, som oversetter fra OpenAPI til DCAT-AP-NO, men det er ikke oppdatert, noe som må gjøres for å kunne tas i bruk. Kildekoden er åpen og vi håper at de som har mulighet og kan dra nytte av biblioteket bidrar inn i koden. I tillegg undersøker vi gjerne alternative tilnærminger for å oversette fra OpenAPI til DCAT-AP-NO.

    Ellers dekker DCAT-AP-NO ganske lite når det kommer til beskrivelser av API-er, og disse beskrivelsene vil være på et svært overordnet nivå og av mye mindre omfang enn det OpenAPI tilbyr.

    Spørsmål: For en del er RDF et hinder til adopsjon. Det er en stor terskel å sette seg inn i en såpass stor spesifikasjon/standard som DCAT-AP-NO, i tillegg til å sette seg inn i RDF, når det fins såpass lite verktøystøtte som det gjør. Må virksomhetene ha en RDF-ekspert og dyptgående kompetanse på DCAT-AP-NO for å komme i mål?

    Svar: Vi ønsker gjerne å gjøre dette så enkelt som mulig, og virksomhetene skal ikke trenge å ha en egen RDF-ekspert eller inngående detaljkunnskap om DCAT-AP-NO for å komme i mål. Vi ønsker gjerne tilbakemeldinger på hvilke hindre dere møter på og hva som er vanskelig å forstå når dere lager beskrivelser i henhold til DCAT-AP-NO, det er verdifullt for oss å få vite om slik at vi kan tilpasse vår støtte og veiledning. En av grunnene til at vi baserer oss på RDF er at DCAT-AP-NO er basert på W3C-standarden DCAT som er RDF-basert, noe som øker samhandlingsevnen på tvers av virksomheter og landegrenser.

    Vi tilbyr noen verktøy for å forenkle det å lage beskrivelser i RDF, og ønsker gjerne flere verktøy som støtter en oversettelse fra kjente formater til DCAT-AP-NO, f.eks. fra OpenAPI. Vi ser absolutt at det mangler verktøy og støtte for å enkelt få til dette i praksis. Her tar vi gjerne imot innspill på hva som er nyttig for dere som skal beskrive datasettene deres. I tillegg er både data.norge.no og standardene åpen kildekode som dere gjerne kan bidra med kode til om det er noe dere savner.

    Om RDF er en terskel å begynne med kan man begynne med JSON-LD. Det er et RDF-format i JSON, som kan senke terskelen litt for de som har kjennskap til JSON.

    Det er også viktig å understreke at når man skal lage en minimal beskrivelse av sine datasett, så er det ikke meningen at man skal lese hele standarden. Det skal kun være nødvendig å lese de relevante delene av den. Denne type standard er blant annet rettet mot verktøyleverandører, slik at de lager gode verktøy som lar en utveksle informasjon om datakataloger på tvers av virksomheter. Da slipper dere som enkeltvirksomheter å forholde dere til alle detaljer i standarden. Samtidig er det viktig at virksomhetene passer på at de verktøyene og de går til anskaffelse av, f.eks. datakataloger og dataplattformer, støtter standarden.

    Spørsmål: Er det en oversikt over navnerom/prefikser (som f.eks. “dcat”) som brukes i standarden?

    Svar: Dette har blitt flyttet fra tidlig i dokumentet til slutten av dokumentet under Vedlegg A.

    Spørsmål: Hvilke andre land har sin egen DCAT-profil?

    Svar: Mange av de europeiske landene har sine egne profiler, blant annet Sverige, Nederland, Italia, Tyskland. Noen av disse har hatt en litt annen tilnærming med hovedvekt på åpne data. En oversikt over kjente DCAT-profiler finner du her: https://www.w3.org/TR/vocab-dcat-3/#profiles

    Annet som er greit å vite om:

    For at et datasett skal regnes som åpne data må det ikke bare beskrivelsen publiseres til data.norge.no, men datasettet må også gjøres tilgjengelig med en åpen lisens, som f.eks. CC0 (Creative Commons – No Copyright Reserved).

    De som skal gjøre anskaffelse av datakataloger eller dataplattformer bør etterspørre at verktøyene man anskaffer støtter standardene. Standardene dekker kanskje ikke alle behov virksomheten har internt, men det forenkler utvekslingen av datasettbeskrivelser og API-beskrivelser mellom virksomheter i Norge og i andre land. Hyllevare-katalogene er veldig god på virksomhetens interne behov, men det kan være vanskelig å utveksle beskrivelsene med andre systemer, og standarden adresserer dette.

    Når virksomheten har beskrevet sin datakatalog i henhold til DCAT-AP-NO og publisert den på internett er det ikke eksklusivt til nytte for data.norge.no, informasjonen kan da utveksles mellom alle systemer som støtter DCAT. Katalogen til data.norge.no er også koblet på EU sin portal data.europa.eu.

  • Post om datasett og API-er du ønsker å få tilgang til eller har spørsmål om.

    56 Emner
    265 Innlegg
    nav.team.arbeidsplassenN

    Hei. Takk for henvendelsen. Nei, vi har ikke kommet noe lenger med å få med stillingsannonser fra Finn. For det andre du lurer på, må jeg vise deg videre til finn.no for mer informasjon.

    mvh Team arbeidsplassen.no

  • Her kan du finne arenaer hvor du kan diskutere bestemte problemstillinger, eller se hvilke prosjekter andre holder på med.

    32 Emner
    85 Innlegg
    jens.andresen.osbergJ

    @maritbre Hei! Denne skulle du naturligvis fått svar på for veldig, veldig lenge siden. Så her er det all grunn til å beklage fra vår side.

    Vi kjenner ikke til at det finnes helt generelle retningslinjer for merking av KI-generert tekst. I KI-forordningens artikkel 50 stilles det krav til åpenhet for at brukeren av et KI-system må kunne forstå at de samhandler med et KI-system. I tilknytning til denne vil det nok komme standarder eller praksis for hvordan man merker KI-generert innhold.

    På et generelt grunnlag er dette med merking likevel krevende. En aktør kan oppgi at det er KI-generert, men det finnes ingen garanti for at denne informasjonen følger innholdet dersom det brukes videre i andre sammenhenger. På lengre sikt trenger man en annen tilnærming til denne problematikken. Vi kjenner til to ulike tilnærminger:

    Automatisert deteksjon av KI-materiale: Dette innebærer bruk av en KI-modell trent til å identifisere KI-generert materiale. Vi registrerer at det finnes ulike selskaper som tilbyr slike løsninger. Det er imidlertid utfordringer knyttet til nøyaktigheten av modellene, og hvordan de kan påvirke ulike grupper på en uheldig måte. I tillegg krever endringer i de store generative KI-systemer at deteksjonsverktøyene kontinuerlig oppdateres for å holde tritt. Til dette kommer også mulige teknikker for å omgå slike systemer. Dette kan du lese mer om hos Faktisk her: Kan vi stole på KI-detektorer? Vannmerking: Dette innebærer at det legges inn et usynlig vannmerke i det KI-genererte innholdet ved å påvirke sannsynlighetsfordelingen i genereringen av innholdet slik at det kan identifiseres senere. Denne artikkelen fra forskere ved universitetet i Maryland går inn på dette og jeg ser den er mye sitert: A Watermark for Large Language Models Artikkelen forklares ganske godt i denne videoen fra Universitetet i Nottingham: Ch(e)at GPT? - Computerphile
    Vi ser at Google Deepmind har kommet nokså langt med en slik tilnærming med sin Synth-ID som gjelder for flere modaliteter, inkludert bilder. Ser at dette arbeidet også henviser til artikkelen nevnt fra forskerne ved universitetet i Maryland.
    Selv om vannmerking høres ut som en god løsning, er det også noen utfordringer. Vannmerkingen må implementeres i de generative KI-modellene. Dette krever at alle leverandører av følger standarden, noe som skaper håndhevelses-utfordringer. For eksempel: Hvordan sikrer man at alle implementerer vannmerking, og hvordan gjør man dette med open-source-modeller?

    I dagens situasjon er det altså en del usikkerhet rundt merking av KI-innhold. I påvente av noen tekniske løsninger må vi da basere oss på en variant hvor vi med «good faith» opplyser om hva som er KI-generert. Spørsmålet da blir imidlertid når vi mener at vi bør opplyse om dette.

    Tekst: Vi har ikke gitt et generelt råd for merking av KI-generert tekst. Dette skyldes at vi er usikre på om et slikt generelt råd har noen verdi. Vi tror behovet for åpenhet varierer mellom ulike områder og kontekster. For eksempel har vi inntrykket av at visse grupper, slik som journalister og mediehus, har interne retningslinjer for hvordan dette skal gjøres. Vi tenker også at for enkelte offentlige virksomheter i visse sammenhenger vil det være viktig å opplyse om at innholdet er generert av KI. Fordi mer og mer tekst vil være helt eller delvis bearbeidet med et KI-verktøy, tror vi ikke det er så mye poeng å gi et generelt råd om dette, og så kan det heller være opp til de spesifikke områdene og kontekstene å vurdere dette.

    Kode: I den forrige utgaven av veiledningen fra 2023 ga vi et råd om å opplyse dersom kode var KI-generert. På dette tidspunktet var bruk av verktøy for KI-kodegenerering nokså nytt. Dette rådet er nå fjernet fordi det har blitt veldig vanlig og det mange som har innarbeidet dette i arbeidsflyten, eller som arbeider med det nå. På samme måte som med tekst, og kanskje i en enda større grad, er det usikkert hvor mye nytte brukerne har av å vite at kode er KI-generert.

    Bilder: For bilder har vi valgt å beholde rådet om merking. I tråd med tankene bak artikkel 50 i KI-forordningen, er det viktig at ingen blir forledet av innhold fra offentlige myndigheter. Med bilder fra en offentlig myndighet, er konteksten av å gi informasjon som offentlig myndighet i seg selv viktig. Derfor har dette verdi, selv om bildet kan bli flyttet og gjenbrukt uten at forbeholdet blir med videre.

  • Kommentarer på innhold i data.norge.no

    31 Emner
    118 Innlegg
    L

    Svar fra Mattilsynet: «Mattilsynet har ikke planer om noe API for Husdyrregisteret med det første.»

  • Kom med tilbakemeldinger på Datalandsbyen, Felles datakatalog og Transportportal.

    32 Emner
    64 Innlegg
    kjersti.stenerud.steienK
    Endringslogg uke 6 2025 Støtte for EU sin kodeliste "Currency" i reference data (https://github.com/Informasjonsforvaltning/fdk-reference-data/issues/258) Lagt til lenke til mer informasjon om utforming av URI-er på https://data.norge.no/nb/docs/sharing-data/how-to-dataset/2-dataset-description. Forbedret lenketekst på https://data.norge.no/nb/docs/sharing-data/how-to-dataset/2-dataset-description, for å være i henhold til wcag-krav. Sikkerhetsoppdateringer