SegmentArchitecture_Informasjonsforvaltning

(Kapabilitetsoversikt - API-beskrivelse (OAS))

(OASIS SMP protokoll - API-spesifikasjon)

(API-tilbyder - 13. Som API-forvalter ønsker jeg å kunne påvirke utformingen av felles nasjonale oppskrifter for API-beskrivelser slik at de dekker mine behov.)

(API-beskrivelsen - EPOS 4: Som API-konsument ønsker jeg oversikt over endepunkter slik at jeg kan ta API-et i bruk)

(BA13. Som API-konsument ønsker jeg at Tableau/R/etc kan hente inn data for meg slik at jeg kan lage visualiseringer uten å måtte vite noe om API-er. - Studenter, gründere og app-utviklere)

(Tjenesteeier (Applikasjons-/tjenesteutvikler/API-konsument) - virksomhetssertifikat )

(Maskin-porten - Delegering)

(BA16. Som API-konsument ønsker jeg at API-et tåler stor trafikk slik at jeg kan bruke API-et direkte i applikasjon - Studenter, gründere og app-utviklere)

(Open Accounting API - xbrl:AnnualAccount)

(Som administrator ønsker jeg enkelt å administrere tilganger til datasettbeskrivelser slik at jeg kan utøve god tilgangsstyring - 3-1 Som leder ønsker jeg å administrere tilganger til registreringsløsning for Lokal datakatalog slik at jeg ivaretar tilgangsrettighetersikkerhet og personvern)

(Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted. - BAM01 - Som ansvarlig for API-management ønsker jeg å publisere mine API i en API-katalog slik at utviklere raskt kan finne frem til mitt API/økt synlighet )

(Som API-forvalter ønsker jeg en å samle beskrivelser av API-ene våre og andres slik at det er enkelt å få oversikt over API-er og bruk - 28. Som API-katalogeier ønsker jeg å, slik at jeg kan ha en total oversikt over API-ene våre kunne vite hvilke API-er min virksomhet tilbyr (og forvalte de på felles måte, vite hvem som bruker hvilke API-er osv.). )

(210. Som tjenesteutvikler ønsker jeg at tjenestens modell også blir oppdatert når jeg fjerner et felt i skjemaklienten, slik at modellen og brukergrensesnittet hele tiden er gjensidig oppdatert. - 5 = gir nødvendig funksjonalitet til produktet)

(Veiledning - Beste praksis - API/mikrotjeneste - BFP033: Som API-konsument ønsker jeg at API-et er avledet av en informasjonsmodell og Masterdata, som både sikrer konsistens mellom API og informasjonsmodell og gir mer og bedre dokumentasjon for API-et. )

(Datamottak - Tjenesteleverandør)

(API-beskrivelsen - BFP032: Som API-konsument ønsker jeg klar informasjon rundt lisensen på dataene APIet tilbyr for å raskt se om dette er forenlig med min bruk av dataene. )

(Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted. - BAM07 - Som leverandør av API-management-verktøy ønsker jeg å kunne publisere dokumentasjon om API fra mitt API management verktøy til en felles offentlig API katalog )

(REST GET Begrepskatalog - Søk og oppslag begreper)

(Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API - BFDK02 - Som forretningsutvikler ønsker jeg å søke etter API, slik at jeg raskt kan finne ut om det finnes data jeg kan gjenbruke)

(211. Som tjenesteutvikler ønsker jeg at modellen til tjenesten automatisk blir opprettet når jeg starter med å lage brukergrensesnittet til tjenesten i skjemaklienten slik at jeg slipper å manuelt modellere modellen i etterkant og så koble denne til grensesnittet til tjenesten. - 5 = gir nødvendig funksjonalitet til produktet)

(API-beskrivelsen - BFP008: Som API-konsument ønsker jeg å vite oppdateringsfrekvens slik at jeg kan bestemme egen oppdatering. )

(Som API-konsument ønsker jeg referanser til dokumentasjon som ikke beskrives i API-beskrivelsen slik at jeg kan nøste meg videre - BA3. Som API-konsument ønsker jeg at det pekes til gode landingssider for API-et slik at jeg raskt settes i stand til å ta det i bruk.)

( BB26. Som API-konsument ønsker jeg at API-ene jeg har tilgang til er de samme som API-forvalteren selv benytter til sin tjenesteutvikling, slik at jeg kan ha tillit til at forvaltning og videreutviklingen av API-ene gis prioritet og er verdt å bruke tid på å lære, gjøre bruk av [tjenestenivå/sla] - Åpne data statistikk, datajournalistikk og stordata)

(Som API-forvalter ønsker jeg at det med API-beskrivelsen følger en veileder slik at jeg kan følge beste praksis - 6. Som API-forvalter ønsker jeg at de aktivitetene jeg må gjøre og de standardene jeg må forholde meg til for å gjøre API-dokumentasjonen tilgjengelig i en nasjonal API-katalog, også gir verdi for andre, kommersielle, internasjonale API-kataloger, f.eks. synliggjøring på søkemotorer, ref Schema.orgs arbeid med vokabular for WebAPI http://pending.webschemas.org/WebAPI )

(34. Som API-katalogeier som ikke har en katalog, så ønsker jeg enkel måte å eksponere API-er på, ikke egen katalog med maskinlesbar beskrivelse, slik at jeg slipper å lage et eget verktøy med egne beskrivelser. - API-forvalter og API katalogeier)

( BAM06 - Som ansvarlig for API-management ønsker jeg å kunne fordele eierskap og ansvar for de enkelte API-ene til det forretningsområdet som er dataforvalter/dataeier, slik at de kan være mest mulig selvbetjente og redusere flaskehalser (“publisher portal”)/sikre nærhet og dermed kvalitet (ansvarliggjøring av den rette aktøren) - API-management)

(API-beskrivelse (OAS) - )

(API-katalog - Scope)

(Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier. - BAM13 - Som ansvarlig for API-management ønsker jeg at brukerne av mine API-er skal kunne gi innspill til endringer av mine API-er, slik at jeg gjøre API-ene mine mer brukervennlige. )

(Sluttbruker - En tjeneste)

(API-katalogen - BFDK07 - Som datasetteier (og som beskriver datasett i datakatalogen) ønsker jeg å kunne kople beskrivelser av APIer (i flertall) til et gitt datasett, slik at jeg kan vise hvilke distribusjoner som finnes av et datasett )

(Som API-forvalter ønsker jeg eierskapet og ansvaret til API-eier kommer tydlig frem slik at man unngår uklarheter - 27. Som API-katalogeier ønsker jeg å koordinere beskrivelsene av API-ene som inngår i min katalog, slik at beskrivelsene fremstår som ensartet for de som skal benytte API-ene.)

(API-beskrivelse - Åpent Regnskapsdata API (maskinlesbart))

(Som forretningsutvikler ønsker jeg å se filtrere på datasett som tilbyr API slik at jeg kan benytte det i mine tjenester - BFDK04 - Som forretningsutvikler ønsker jeg å filtrere på datasett som har API, slik at jeg bedre treff på mine søk i katalogen. )

(API-konsument (design time) - BFP003: Som API-konsument ønsker jeg å kunne se eventuelt tilknyttede informasjonsmodeller der det finnes, slik at jeg også kan finne og kvalitetssikre data og informasjon. )

(API-katalogen - BB20. Som API-konsument ønsker jeg eksempel på bruk av dataene som en del av dokumentasjonen av API-et, slik at de er enklere å fortså og ta i bruk [dokumentasjon] )

(BB3. Som API-konsument ønsker jeg å gjøre spørringer som gir meg dataene jeg har rettighet til å få (og ikke blir blokkert tilgang fordi API-et bare gir tilgang til mer data enn jeg har rettigheter til), slik at jeg kan få tilgang til data [rettigheter] - Åpne data statistikk, datajournalistikk og stordata)

(Enterprise Continuum - Authority Structures)

(BA30. Som API-konsument ønsker jeg informasjon om hvilke hjemler som gir tilgang til API-er der tilgangen er begrenset, slik at jeg kan vurdere om min virksomhet har lov til å benytte API-et til det aktuelle formålet. - Studenter, gründere og app-utviklere)

(En konsument applikasjon - Et applikasjonsgrensesnitt)

(API-tilbyder - Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de.)

(API-beskrivelsen - EPOS 5: Som API konsument ønsker jeg kvalitets- og sikkerhetsvurderinger om API-et slik at jeg kan forstå hvordan jeg kan ta det i bruk)

(Mikrotjenesten/API-et - BB36. Som API-konsument (ETL) ønsker jeg å unngå å laste komplette datasett og heller få de delene som har endret seg siden sist jeg lastet ned datasett slik at jeg minimerer egen ressursbruk. [varsel] )

(Som virksomhet ønsker jeg en egen oversikt for intern bruk over datasett slik at... - Integrasjon med AD)

(Felles rammeverk - BB36. Som API-konsument (ETL) ønsker jeg å unngå å laste komplette datasett og heller få de delene som har endret seg siden sist jeg lastet ned datasett slik at jeg minimerer egen ressursbruk. [varsel] )

(Scope - Scope)

(EPOS 1: Som API-konsument ønsker jeg eier- og kontaktinformasjon slik at man kan få hjelp - Som API-konsument ønsker jeg kontaktinformasjon slik at man kan få hjelp)

(BA43. Som API-konsument ønsker jeg å bli varslet om at et API er “deprecated” (skal tas ut av bruk), slik at jeg kan oppdatere min applikasjon. - Studenter, gründere og app-utviklere)

(Regnskapsregisteret - organisasjonsnummer)

(Datasettkatalog - Modelleringsklient)

(API-beskrivelsen - BFP011: Som API-konsument ønsker jeg et kontaktpunkt hos API-eier slik at man kan gi tilbakemelding og spørsmål. )

(Som API-konsument ønsker jeg informasjon om tilgang til dataene (tilgangsnivå) slik at jeg kan forstå hvordan jeg skal ta det i bruk - BA29. Som API-konsument ønsker jeg informasjon om hvordan jeg kan skaffe meg tilgang til API-er som ikke er offentlig tilgjengelig. [Kommentar: manglar “slik at <forretningsverdi>”] )

(rov:Entity - Organization)

(BA21. Som API-konsument ønsker jeg et API som gir godt strukturerte responser slik at data er lett å bruke. - Studenter, gründere og app-utviklere)

(SKOS-AP-NO - Begrep)

(Nettverk (faglig forum) - BFP030: Som API-konsument ønsker jeg å kunne spørre produsent om mer og bedre data slik at vi kan tilby et bedre og mer helhetlig bilde. )

(Krav (EPOS og nødvendige krav) - Intern kontaktperson)

(data.norge.no API - FDK-høsting ADM)

(get token - Access token)

(Krav (EPOS og nødvendige krav) - Som API-konsument ønsker jeg å kunne søke og filtrer på API-er slik at jeg kan raskt finne rett API)

(Registreringsapplikasjon begrep - REST GET Begrepskatalog)

( BAM03 - Som ansvarlig for API-management ønsker jeg å notifisere endringer i mine API til dem som benytter API-ene slik at man ikke bryter kontrakter - API-management)

(Operational Systems - Deploy)

(API-katalogen - BTI004 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å redusere mine forvaltningskostnader, for eksempel for å få redusert manuelle henvendelser )

(Virksomheter - Forretningsobjekt)

(API-beskrivelsen - Som API-konsument ønsker jeg at det er gjort en sikkerhetsvurdering slik at krav til innebygd personvern er best mulig ivaretatt)

(API-konsumenter forvaltningen og proffesjonelle - BFP003: Som API-konsument ønsker jeg å kunne se eventuelt tilknyttede informasjonsmodeller der det finnes, slik at jeg også kan finne og kvalitetssikre data og informasjon. )

(Informasjonsforvaltning - Datakatalogen)

(create delegation - Deleger tilgang)

(API-tilbyder - 27. Som API-katalogeier ønsker jeg å koordinere beskrivelsene av API-ene som inngår i min katalog, slik at beskrivelsene fremstår som ensartet for de som skal benytte API-ene.)

(Linked data - Business)

(MyData, viderebruk av personopplysninger - Som deltakar i ein treningsaksjon, f.eks. Sykletiljobben eller sprekere.no, ønskjer eg å kunne gje treningstenesta tilgang til informasjon om kven som er min arbeidsgjevar, slik at eg kan bli med i ei gruppe for min arbeidsplass og skape intern konkurranse, i staden for at eg må manuelt bli med i grupper, nokon på arbeidsplassen må legge meg til manuelt og bruke mykje tid på ajourhald av dette. )

(Informasjonsmodell - Begrep)

(API-katalogen - 34. Som API-katalogeier som ikke har en katalog, så ønsker jeg enkel måte å eksponere API-er på, ikke egen katalog med maskinlesbar beskrivelse, slik at jeg slipper å lage et eget verktøy med egne beskrivelser. )

(API-katalogen - BAM17 - Som ansvarlig for API-management ønsker jeg at å tilby effektiv selvregistrering av brukere av API-ene, f.eks. gjennom autentisering via ID-porten/Altinn av dem som tar i bruk API-ene, slik at jeg senker terskelen for å ta API-et i bruk, samtidig som jeg beholder nødvendig oversikt over brukere. )

(En_API-konsument - API-konsument (design time))

(API-detaljer - API-beskrivelse)

(Tilgangsstyring - Begrepskatalog GUI)

(? - Informasjonsmodell)

(Som forretningsutvikler ønsker jeg å se filtrere på datasett som tilbyr API slik at jeg kan benytte det i mine tjenester - BFDK01 - Som forretningsutvikler ønsker jeg å se hvilke datasett som tilbyr API, slik at jeg kan vurdere om det kan brukes i mine tjenester.)

(API-konsument (design time) - BA54. Som API-konsument ønsker jeg REST-API-er i tråd med REST-prinsippene/beste praksis slik at jeg kan bygge på erfaringene mine med andre REST-API-er, og forstå effekten av kallene i API-et med minst mulig teknisk dokumentasjon. )

(Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles - Som API-forvalter ønsker jeg at definerte APIer i API-katalogen kan overføres til felleskomponenter for tilgangsstyring og autentisering slik at jeg slipper å registrere disse dobbelt (og dermed risikere feil i registreringer))

(Mikrotjenesten/API-et - BFP015: Som API-konsument ønsker jeg at nye versjoner av apiene blir gjort tilgjengelig før de settes i produksjon slik at jeg er forberedt. )

(Lokal datasett registreringsløsning - Som tjenesteutvikler og data scientist ønsker jeg å kunne annotere datasettene etter egen tematiske inndeling)

(Datasettbeskrivelse - Datasett)

(API-konsument (design time) - BB2. Som API-konsument ønsker jeg å gjøre spørringer og sammenstillinger og styre strukturen/formatet på resultatdatasettet selv, slik at jeg kan enkelt kan få det utsnittet av dataene som passer til den oppgaven jeg skal løse. )

(Felles rammeverk - Premissgiver - Betaling på API/mikrotjenester)

(API-konsument (design time) - BA16. Som API-konsument ønsker jeg at API-et tåler stor trafikk slik at jeg kan bruke API-et direkte i applikasjon)

(API-konsument (design time) - BA48. Som API-konsument ønsker jeg at API-ene jeg bruker tilbyr komplett nedlasting av datasett slik at jeg kan bearbeide data lokalt. )

(API-beskrivelsen - EPOS 1: Som API-konsument ønsker jeg eier- og kontaktinformasjon slik at man kan få hjelp)

(Mapping agency - Administrative borders API)

(Informasjonsmodell-katalog - Informasjonsmodell-katalog GUI)

(EPOS 2: Som API-forvalter ønsker jeg å registrere mine API-er slik at de kan gjøres tilgjengelig for andre - Som API-eier ønsker jeg å publisere API-er som ikke kan knyttes til et datasett slik at også mine mine API-er som gjør beregninger e.l. kan publiseres)

(Altinn Studio (Tjeneste 3.0) - Skjemaklient)

(API-beskrivelsen - BFP024: Som API-konsument ønsker jeg i de tilfeller hvor API er basert på et lukket datasett å koble meg til et miljø med syntetisk data for bruk i utvikling og test. )

(data.norge.no portal - Anonym bruker)

(Enterprise Continuum - Solutions)

(Som deltakar i ein treningsaksjon, f.eks. Sykletiljobben eller sprekere.no, ønskjer eg å kunne gje treningstenesta tilgang til informasjon om kven som er min arbeidsgjevar, slik at eg kan bli med i ei gruppe for min arbeidsplass og skape intern konkurranse, i staden for at eg må manuelt bli med i grupper, nokon på arbeidsplassen må legge meg til manuelt og bruke mykje tid på ajourhald av dette. - Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv)

(API-beskrivelsen - Som API-konsument ønsker API-beskrivelsen refererer til begreper slik at jeg kan forstå innholdet i API-et )

(Difi - 5. Oppdateres dato?)

(Brønnøysundregistrene - Register)

(EPOS 4: Som API-konsument ønsker jeg å finne detaljert beskrivelse av API-ene slik at jeg kan vurdere om jeg kan benytte API-et i mine tjenester - Som API-konsument ønsker jeg å se request og respons på et API slik at jeg kan planlegge design)

(Referansedata - API-katalog GUI)

(API-konsument (design time) - BB10. Som API-konsument ønsker jeg mulighet til å innhente data om tekstdatasett slik at jeg kan lage analyser av disse og koble til andre kilde. [tekst som data] )

(API-konsument (design time) - BFP002: Som API-konsument ønsker jeg enhetlig dokumentasjon og mulighet til “kundeservice” fra tjenesteleverandør. )

(API-katalogen - Som API-konsument ønsker jeg at distribusjoner av samme (eller geografisk komplementære) datasett fra ulike tilbydere eller er samlet under et datasett)

(BAM01 - Som ansvarlig for API-management ønsker jeg å publisere mine API i en API-katalog slik at utviklere raskt kan finne frem til mitt API/økt synlighet - API-management)

(Som sykkeleier vil jeg ha automatisert innfylling av tapsmelding til forsikringsselskapet fra innmeldte sak til politiet for å sikre konsistens og spare tid. - Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv)

(API-beskrivelsen - BFP009: Som API-konsument ønsker jeg å få dokumentere hvordan en kan oppdatere en egen kopi slik at en til hver tid bruker korrekte data. )

(API-beskrivelsen - Som API-konsument ønsker jeg oversikt over testmiljø og syntetiske data slik at jeg kan teste ut API-ene)

( Jeg ønsker å få tilgang til reisedata (tid, pris, fra-til-sted osv) for ulike transporttjenester slik at jeg kan bruke data i stedet for kvitteringer ved innlevering av reiseregninger. - Som sluttbruker ønsker jeg at en privat virksomhet skal ha tilgang til data om meg fra en tredjepart (app) slik at jeg kan slippe å tiljgengeliggjøre dataene selv)

(API-katalogen - BFDK02 - Som forretningsutvikler ønsker jeg å søke etter API, slik at jeg raskt kan finne ut om det finnes data jeg kan gjenbruke)

autorisasjon (Altinn Autorisasjon - Datasettkatalog)

(Domain Architects - Develop)

(Premissgiver - styring dokumentasjon av API-er - BAM16 - Som ansvarlig for API-management ønsker jeg tydelige føringer på hvordan mitt API skal dokumenteres og gjøres tilgjengelig i en felles API-katalog slik at arbeidet kan planlegges, fordeles og operasjonaliseres i min virksomhet med et forutsigbart omfang. )

(BFDK13 - Som konsument av et åpent api ønsker jeg informasjon om hvor pålitelig leveransen av data er (forventet oppetid, responstid ved feil osb) slik at jeg kan gjøre en tilstrekkelig ROS-analyser for min integrasjon - FDK)

(API-katalogen - BAM13 - Som ansvarlig for API-management ønsker jeg at brukerne av mine API-er skal kunne gi innspill til endringer av mine API-er, slik at jeg gjøre API-ene mine mer brukervennlige. )

(FDK - GUI FDK-høsting ADM)

(Eg vil bruke ei bildelingsteneste for å leige ut min bil. Der vil eg gje samtykke til å hente data frå vegvesenet sitt køyretøysregister om kva bilar eg eig, så slepp eg å taste inn informasjonen sjølv, og kan i staden få ferdig utfylt informasjon om kva bil det er, modell etc. Bildelingstenesten kan vidare nytte informasjonen til å hente inn informasjon om mine bilar, til dømes bilde av bilen, så eg slepp å legge inn dette sjølv. - Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv)

(Mikrotjenesten/API-et - BA37. Som API-konsument ønsker jeg at tilgjengelige API-er er robuste slik at jeg kan anta at integrasjonen fungerer også ved høy trafikk)

(BFP033: Som API-konsument ønsker jeg at API-et er avledet av en informasjonsmodell og Masterdata, som både sikrer konsistens mellom API og informasjonsmodell og gir mer og bedre dokumentasjon for API-et. - API-konsumenter forvaltningen og proffesjonelle)

(en API-katalog i virksomheten - FDK-høsting ADM)

(API-beskrivelsen - Som API-konsument ønsker jeg å se en SLA knyttet til API-et slik at jeg kan vurdere om det tilfredsstiller mine krav til bruk)

(EPOS 3: Som API-konsument ønsker jeg å kunne søke og filtrer på API-er slik at jeg kan raskt finne rett API - Som API-konsument ønsker jeg at API-er av autoritativ art priorites slik at de er lette å finne)

(API-katalog - Søk og oppslag API)

(Organisasjonskatalog - Informasjonsmodell-katalog GUI)

(Implement - Enterprise Continuum)

(API-beskrivelsen - Som API-forvalter ønsker jeg eierskapet og ansvaret til API-eier kommer tydlig frem slik at man unngår uklarheter)

(Registreringsapplikasjon API - REST GET API-katalog)

( BFP017: Som API-konsument ønsker jeg en endringslogg så tidlig som mulig slik at jeg vet hva som har endret seg mellom versjoner. - API-konsumenter forvaltningen og proffesjonelle)

(Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles - BA2. Som API-konsument ønsker jeg umiddelbar tilgang (slipper å vente på manuell tildeling av API-nøkler og tokens) til data (eller testdata) slik at jeg kan vurdere og eventuelt ta i bruk API-et umiddelbart.)

(Melding uten gjenbruksmulig eller preutfylling - 209. Som tjenesteutvikler ønsker jeg at tjenestens modell også blir oppdatert når jeg legger til et nytt felt i skjemaklient, slik at modellen og brukergrensesnittet hele tiden er gjensidig oppdatert.)

("Min Side" - Skjemeautfyller)

(Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier. - BA22. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg kan stille spørsmål om bruk av API-et slik at jeg kan bruke det mest mulig hensiktsmessig, og gjerne med henvisninger til kjent brukt av API-et. )

(API-tilbyder - 1.Som API-forvalter ønsker jeg at katalogen dekker informasjonsbehovet til de som skal benytte API-ene jeg forvalter, slik at jeg slipper å besvare henvendelser fra dem/redusere antall henvendelser [frigjøre ressurser] )

(Prosjekttutløsende behov (overordnet)- fra handlingsplanen i porteføljestyring - GDPR artikkel 30 stiller krav til protokoll. Tolkes litt ulikt om det er en protokoll pr behandling eller en samlet protokoll med oversikt over alle behandlingene. Uansett er hensikten å kunne gi en samlet oversikt over behandlingen av personopplysninger i en virksomhet. Enighet om at dette løses ved at det legges til en modul for å registrere en behandlingsaktivitet. Summen av de registrerte behandlingsaktivitetene utgjør protokollen. Noe informasjon vil være felles på tvers av behandlingsaktivitetene, slik som hvem som er behandlingsansvarlig (direktøren), hvem som er personvernombud etc.)

(API-mangement verktøyleverandør - BAM05 - Som leverandør av API-management-verktøy ønsker jeg at den felles API-katalogen støtter beste praksis for API-er og de mest utbredte standardene, slik at det blir lett for meg å integrere mitt verktøy med den felles API-katalogen [gjetter jeg på …] )

(EPOS 4: Som API-konsument ønsker jeg å finne detaljert beskrivelse av API-ene slik at jeg kan vurdere om jeg kan benytte API-et i mine tjenester - Datakonsumenter har behov for et ryddig avtaleregime for tilgang til dataene. )

(Entity Registry API - OrganizationAPI)

(API-katalog - FDK-høsting ADM)

(Ansatt - Som ansatt ønsker jeg å finne oversikt over TEST-datasett slik at jeg kan finne og bruke testdatasett som konform med lovverk i tilknytningen til utvikling)

(Register scope - API-katalog)

(API-beskrivelsen - Som API-konsument ønsker jeg informasjon om tilgang til dataene (tilgangsnivå) slik at jeg kan forstå hvordan jeg skal ta det i bruk)

(27. Som API-katalogeier ønsker jeg å koordinere beskrivelsene av API-ene som inngår i min katalog, slik at beskrivelsene fremstår som ensartet for de som skal benytte API-ene. - API-forvalter og API katalogeier)

(en API-katalog i virksomheten - data.norge.no API-høster)

(BFP008: Som API-konsument ønsker jeg å vite oppdateringsfrekvens slik at jeg kan bestemme egen oppdatering. - API-konsumenter forvaltningen og proffesjonelle)

(BA47. Som API-konsument ønsker jeg at API-ene jeg skal bruke er så like som mulig (men så forskjellige som nødvendig), slik at jeg ikke trenger sette meg inn i unødvendig mye nytt for hvert API jeg skal vurdere eller bruke. - Studenter, gründere og app-utviklere)

(3. Mer informasjon om variabler og tidsfrekvens av data - Difi)

(Datakonsumenter har behov for tilgang til dataene på en enkel og standardisert måte. - Difi konseptutredning "deling av data")

(API-katalogen - BB8. Som API-konsument ønsker jeg at utforskingsfasen/exploration/discovery gir meg rask oversikt og innsikt slik at jeg minimerer tiden jeg bruker på å velge et utsnitt eller må bruke egne verktøy for å skaffe meg oversikt. [dokumentasjon] )

(Difi - 6. Tilgangsoversikt ... logg? )

(Nasjonalt - Registreringsløsning informasjonsmodell)

(Difi - 1. Informasjon om dataeier (intern navngitt person))

(Fagterminologibaser - REST GET Begrepskatalog)

(BA2. Som API-konsument ønsker jeg umiddelbar tilgang (slipper å vente på manuell tildeling av API-nøkler og tokens) til data (eller testdata) slik at jeg kan vurdere og eventuelt ta i bruk API-et umiddelbart. - Studenter, gründere og app-utviklere)

(API-konsument (design time) - BB24. Som API-konsument (ETL) ønsker, jeg stabile API-er som er uavhengige av underliggende data slik at jeg ikke trenger å følge med endringer i data formater/strukturer. [forutsigbarhet] )

(Felles rammeverk - BB4. Som API-konsument (ETL) ønsker jeg API-er som gir meg uttrekk som er tilpasset mine rettigheter og filtreringsbehov slik at jeg kan innhente uttrekket jeg trenger og har rett til. [rettigheter] )

(data.norge.no API - data.norge.no datasetthøsting)

(Search-API - Search Service)

(9. Som API-forvalter ønsker jeg en felles løsning for API-dokumentasjon som er så god at jeg selv ønsker å bruke løsningen fremfor andre verktøy - API-forvalter og API katalogeier)

(Felles rammeverk - Veiledning - Beste praksis - dokumentasjon av API-er)

(Datasettbeskrivelse - API-beskrivelse)

(API-konsument (design time) - BFP022: Som API-konsument ønsker jeg eksempler/mal på bruk slik at jeg kan ta i bruk nye datasett raskest mulig. )

(Enterprise Architects - Develop)

(213. Som tjenesteutvikler ønsker jeg at det er mulig å navigere mellom modelleringsvisning og skjemavisning mens jeg ut utvikler en tjeneste slik at jeg kan velge i hvilken visning jeg utfører en endring og hele tiden kan se hvordan endringen blir i begge visningene. - 5 = gir nødvendig funksjonalitet til produktet)

(Ansatt - Som ansatt ønsker jeg å se hvilke datasett som er publisert i Lokal datakatalog og Felles datakatalog, slik at jeg klart kan skille mellom hva som er lokalt og hva som er felles.)

(BA28. Som API-konsument ønsker jeg informasjon om ytelsesmessige (svartid, antall oppslag) begrensninger i API-et, slik at jeg kan vurdere om API-et har god nok ytelse til mitt formål. - Studenter, gründere og app-utviklere)

(Offentlig Virksomhet - Begrepssamling)

(Brønnøysundregistrene - 2-14 Som dataforvalter og forenklingsaktør ønsker jeg å koble dataelement (datafelt) og BR-begrepskatalog, slik at andre eksterne aktører lettere kan finne data fra BR som kan gjenbrukes.)

(BA42. Som API-konsument ønsker jeg varsler om “breaking changes” slik at jeg kan gjøre de nødvendige endringene før de brekker mine systemer/applikasjoner også. [f.eks. ved registrere e-postadresse] - Studenter, gründere og app-utviklere)

(Begrepskatalog API - Datasettkatalog)

(Nasjonalt - Informasjonsmodell-katalog GUI)

Change (Implementation Projects - Operational Systems)

(EPOS 2: Som API-konsument ønsker jeg en grunnleggende informasjon om API-et som er oppdatert og forståelig lsik at jeg kan ta API-et i bruk - Som API-konsument ønsker jeg å få tekstlig beskrivelse av et API slik at jeg kan forstå hvordan jeg skal bruke et API)

(Grensesnitt - Register 2)

(Datakatalogen - Datasettbeskrivelse)

(Skatteetaten - Som API-konsument ønsker jeg standardiserte autentiserings- og autoriseringsmekanismer som kan gjenbrukes for flere tjenester)

(Deploy - Enterprise Continuum)

(Felles rammeverk - BB14. Som API-konsument ønsker jeg standardavtaler for både vilkår for bruk av data og tjeneste slik at jeg vet hvilke vilkår og tjenestenivå jeg har å forholde meg til. [databehandleravtaler, SLA] )

(En konkret tjeneste - Mikrotjenesten/API-et)

(Som dataeier ønsker jeg å kunne styre publiseringen av et datasett slik at den kan publisere enten til virksominternt publisering eller til felles datakatalog - 2-2 Som datasetteier ønsker jeg å registrere våre datasett i Lokal datakatalog i henhold til DCAT slik at jeg kan dele dem i felles datakatalog.)

(API-katalogen - 5. Som API-forvalter ønsker jeg at API-katalogen kan vise min Swagger-dokumentasjon slik at jeg bare kan eksponere for eksempel Swagger-data (YAML) og slipper å drifte min egen Swagger UI-nettside. [relatert til Swagger-brukerhistorien, trur eg] )

(Som API-konsument ønsker jeg at API-er av autoritativ art priorites slik at de er lette å finne - 25. Som API-forvalter som forvalter API-er til autoritative data ønsker jeg at API-katalogen skal prioritere presentasjon av mine API-er fremfor API-er som tilbyr samme data, men fra ikke-autoritative kilder, slik at API-brukerne ikke ubevisst bruker ikke-autoritative data )

(Mikrotjenesten/API-et - BB25. Som API-konsument (ETL) ønsker jeg mulighet til å abonnere på endringsvarslinger om både data og API-versjoner slik at jeg kan oppfriske data og/eller utnytte nye datafelter. [varsel] )

(API-konsument (design time) - BA35. Som API-konsument ønsker jeg at det er tydelig hva som er de rettslige rammene for bruk av API-ene slik at jeg kan være sikker på at jeg ikke kan få krav mot meg senere, f.eks. NLOD. )

(API-tilbyder - BTI004 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å redusere mine forvaltningskostnader, for eksempel for å få redusert manuelle henvendelser )

(Mikrotjenesten/API-et - BFP018: Som API-konsument ønsker jeg at apiene inneholder referanser til lokale kodeverk som forklarer innholdet i apiene slik at jeg forstår detaljene i apiene. )

(Felles datasettkatalog portal - Search)

(API-mangement verktøyleverandør - BAM15 - Som ansvarlig for API-management ønsker jeg å publisere informasjon om kostnader og trafikkbegrensninger for mine API-er, slik at potensielle brukere av mine API-er slipper å spørre meg om denne informasjonen )

( BAM09 - Som ansvarlig for API-management ønsker jeg å kunne administrere nøkler gitt til de enkelte konsumentene slik at jeg enkelt kan fjerne ev. misbruk av API-et - API-management)

(skv:Kommune - Kommune)

(Nasjonalt - Tjenestekatalog)

(Krav (EPOS og nødvendige krav) - (Behov for registrering av begreper))

(Felles rammeverk - 4. Som API-forvalter ønsker jeg råd og forslag til avtaler med konsumenter slik at jeg kan gjøre flere API-er tilgjengelige for eksterne (f.eks. innovatører) og er trygg på å ha et godt avtaleverk og slipper å gjøre grunnarbeidet med vilkår og avtale for bruk. )

(Entity Registry API - er:motherOrganization)

(BA44. Som API-konsument ønsker jeg intelligente API-er som kan f.eks. filtrere, aggrerere, gruppere slik at jeg bare få inn de resultater jeg trenger av hensyn til personvern, kapasitet etc. - Studenter, gründere og app-utviklere)

(API-katalogen - 1.Som API-forvalter ønsker jeg at katalogen dekker informasjonsbehovet til de som skal benytte API-ene jeg forvalter, slik at jeg slipper å besvare henvendelser fra dem/redusere antall henvendelser [frigjøre ressurser] )

(Mikrotjenesten/API-et - BB33. Som API-konsument ønsker jeg å kunne laste ned kun endringer i et datasett for å oppdatere min lokale kopi av et datasett slik at jeg slipper å laste ned hele datasettet på nytt og import-jobben blir mindre. [varsel] )

(API-katalogen - 35. Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de. )

(EPOS 5: Som API konsument ønsker jeg kvalitets- og sikkerhetsvurderinger om API-et slik at jeg kan forstå hvordan jeg kan ta det i bruk - Som API-konsument ønsker jeg at det er gjort en sikkerhetsvurdering slik at krav til innebygd personvern er best mulig ivaretatt)

(Mikrotjenesten/API-et - BA53. Som API-konsument ønsker jeg at API-et støtter HTTP-standard med accept header for å velge data-format slik at kan gjøre det jeg er vant til. )

(Som API-konsument ønsker jeg referanser til brukte kodeverk slik at jeg kan forstå hvordan de skal fortolkes - BB16. Som API-konsument ønsker jeg at støttedatasett (f.eks. kodelister) er omtalt i dokumentasjonen slik at jeg kan anvende data fullt ut.[dokumentasjon] )

(Virksomheter - Begrep)

(Regnskapsregisteret - Åpent Regnskapsdata API (maskinlesbart))

(BA19. Som API-konsument ønsker jeg API der kodeverk (f.eks. kommunenummer, næringskoder) er en del av API-responsen slik at jeg slipper å utføre flere API-kall og hente fra ulike kilder for å få data jeg trenger. - Studenter, gründere og app-utviklere)

(REST GET API-katalog - Søk og oppslag API)

(API-beskrivelsen - Som API-konsument ønsker jeg informasjon om et API har varsligskanal slik at jeg kan fange opp endringer)

(Tjenesteeier (Applikasjons-/tjenesteutvikler/API-konsument) - Finn API)

(Datasett-eier - Som datasetteier ønsker jeg å kunne registrere merknader om et datasett i et fritekstfelt slik at andre ved BR kan bli oppmerksom på forhold som kan ha betydning for bruk av datasettet)

(EPOS 2: Som API-forvalter ønsker jeg å registrere mine API-er slik at de kan gjøres tilgjengelig for andre - Som dataeier ønsker jeg å knytte API til datasettet slik at jeg kan vise hvilke distribusjoner som finnes)

(En_API-tilbyder - en API-katalog i virksomheten)

(Som API-konsument ønsker jeg å forstå om API-et tilbyr datamimimering slik at jeg kan understøtte godt personvern - BFP025: Som API-konsument ønsker jeg å se hvilke muligheter det finnes for konfigurasjon både hos meg og hos API-leverandør for å begrense tilgjengelig data til mitt faktiske formål. Kommentar: Dataminimering?)

(15. Som API-forvalter/eier ønsker jeg en ensartet og samlet beskrivelse av alle våre API-er slik at det er enkelt for brukerne å gjenbruke sin kunnskap om de skal bruke flere API-er. - API-forvalter og API katalogeier)

(Contract - )

(Nasjonalt - API-beskrivelse (OAS))

(BFP015: Som API-konsument ønsker jeg at nye versjoner av apiene blir gjort tilgjengelig før de settes i produksjon slik at jeg er forberedt. - API-konsumenter forvaltningen og proffesjonelle)

(Som API-konsument ønsker jeg at dokumentasjonen er genererert fra kode slik at jeg kan stole på at den er oppdatert - BA41. Som API-konsument som benytter verktøy for å generere deler av kildekoden ønsker jeg at API-et er dokumentert iht “Open API Specification”, slik at jeg kan bruke kodegenereringsverktøy for å generere mye av den kildekoden som trengs for å bruke API-et fremfor å måtte skrive den selv [ref epost] )

(Enterprise Continuum - Organizational Standards)

(Enhetsregisteret - Lenkede data)

( BFP010: Som API-konsument ønsker jeg å bare lese endringer som er gjort på siste oppdatering slik at vi slipper å lese hele datasettet. - API-konsumenter forvaltningen og proffesjonelle)

(BA48. Som API-konsument ønsker jeg at API-ene jeg bruker tilbyr komplett nedlasting av datasett slik at jeg kan bearbeide data lokalt. - Studenter, gründere og app-utviklere)

(JSON - )

(Brønnøysundregistrene - 2-2 Som datasetteier ønsker jeg å registrere våre datasett i Lokal datakatalog i henhold til DCAT slik at jeg kan dele dem i felles datakatalog.)

(Tilgangsstyring - admin)

( BB34. Som API-konsument ønsker jeg å kunne se når hvilke deler av et datasett som er endret slik at jeg kan analysere endringer i data. [varsel] - Åpne data statistikk, datajournalistikk og stordata)

(Felles rammeverk - 6. Som API-forvalter ønsker jeg at de aktivitetene jeg må gjøre og de standardene jeg må forholde meg til for å gjøre API-dokumentasjonen tilgjengelig i en nasjonal API-katalog, også gir verdi for andre, kommersielle, internasjonale API-kataloger, f.eks. synliggjøring på søkemotorer, ref Schema.orgs arbeid med vokabular for WebAPI http://pending.webschemas.org/WebAPI )

(BFDK12 - Som konsument ønsker jeg kontaktinformasjon til brukerstøtte for API slik at jeg kan få hjelp - FDK)

(Veiledning - Beste praksis - API/mikrotjeneste - BB3. Som API-konsument ønsker jeg å gjøre spørringer som gir meg dataene jeg har rettighet til å få (og ikke blir blokkert tilgang fordi API-et bare gir tilgang til mer data enn jeg har rettigheter til), slik at jeg kan få tilgang til data [rettigheter] )

(API-konsument (design time) - BB17. Som API-konsument ønsker jeg at spørringer, programkode og bibliotek som andre utvikler gjøres tilgjengelig som åpen kildekode slik at jeg kan dra nytte av disse i min prosess [gjenbruk av kildekode] )

(Som API-forvalter ønsker jeg å tilgjengeliggjøre API-et i en sanntids-tjenestekatalog (SMP) slik at den kan brukes til capability lookup i sanntids meldingsutveksling - Som API-eier ønsker jeg å angi at API’et skal være tilgjengelig i en runtime-tjenestekatalog (SMP/capability lookup) og Altinn tjenestekatalog/Authorization for samtykke og tilgangsstyring. )

(Melding uten gjenbruksmulig eller preutfylling - 205. Som tjenesteutvikler ønsker jeg at tjenestens modell også blir oppdatert når jeg endrer felttypen til et felt i skjemaklient, slik at modellen og brukergrensesnittet hele tiden er gjensidig oppdatert.)

(API-katalog - Datalagring)

(data.norge.no portal - Kommentator bruker)

(API-katalogen - BA36. Som API-konsument ønsker jeg at noen tar jobben med å holde oversikt over om API-er er tilgjengelige, utilgjengelige, stabilt, deprecated etc slik at jeg slipper å begynne å ta det i bruk først før jeg oppdager det.)

(Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted. - BAM04 - Som leverandør av API-management-verktøy ønsker jeg at jeg å kunne tilby automatisk integrasjon med den felles API-katalogen slik at jeg kan selge mer av produktet mitt ved å vise til at det støtter opp under de nasjonale føringene. )

(Enhetsregisteret - Organization JSON-LD)

(API-konsument (design time) - BA5. Som API-konsument ønsker jeg at alle begreper linker direkte til en forklaring av begrepet slik at jeg slipper å lete gjennom dokumentasjonen. [kommentar: forskjell på begrep i den tekniske dokumentasjonen (f.eks. parameter i forespørsel) vs. begrep i datasettet (f.eks. fagtermer)] )

(API-mangement verktøyleverandør - API-katalogen)

(API - Dataobjekt)

(Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et - 17. Som API-forvalter ønsker jeg å vise frem eksempel på bruk av mine API-er slik at verdien av API-ene blir synliggjort og det kan inspirere flere til å bruke API-ene og hvordan bruke API-ene. )

( Når jeg flytter til en ny kommune ønsker jeg at mine data fra gamlekommunen automatisk overføres slik at min nye kommune har oversikt over hvilke behov og tilbud som er relevant for meg. - Som sluttbruker ønsker jeg at en offentlig aktør skal ha tilgang til data om meg hos en annen offentlig aktør)

(Som tjenesteutvikler og data scientist ønsker jeg å kunne finne ut hva slags type data datasettet er slik at jeg kan vurdere egnethet - 12. Valg for spørreundersøkelser)

(API-konsument (design time) - BA22. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg kan stille spørsmål om bruk av API-et slik at jeg kan bruke det mest mulig hensiktsmessig, og gjerne med henvisninger til kjent brukt av API-et. )

(EPOS 8: Som API-konsument ønsker jeg informasjon om vilkår slik at jeg kan forstå om jeg kan bentytte API-et - Som konsument av API ønsker jeg informasjon om kostnader og trafikkbegrensninger for bruk av API-et slik at jeg kan ha forutsigbare rammer for min bruk av dataene.)

(EPOS 8: Som API-konsument ønsker jeg informasjon om vilkår slik at jeg kan forstå om jeg kan bentytte API-et - Som API-konsument ønsker jeg å se en SLA knyttet til API-et slik at jeg kan vurdere om det tilfredsstiller mine krav til bruk)

(Felles rammeverk - BB28. Som API-konsument ønsker jeg at API-et har god ytelse slik at jeg kan gjøre enkeltoppslag og ikke blir tvunget til å laste ned hele datasettet fordi API-et har lav ytelse. [tjenestenivå] )

(Som API-forvalter ønsker jeg at API-katalog kan plukke opp min swagger dokumentasjon slik at jeg kan benytte dette verktøyet - 5. Som API-forvalter ønsker jeg at API-katalogen kan vise min Swagger-dokumentasjon slik at jeg bare kan eksponere for eksempel Swagger-data (YAML) og slipper å drifte min egen Swagger UI-nettside. [relatert til Swagger-brukerhistorien, trur eg] )

(EPOS 9: Som API-konsument ønsker jeg oversikt over hvem som bruker et API slik at jeg kan forstå det bedre - BA14. Som API-konsument ønsker jeg lenker til applikasjoner som bruker datasettet, slik at jeg kan finne gode eksempler på bruk av API-et og datasettet. [kommentar: også programvarebibliotek og anna kodeverk som er relevant )

(en API-katalog i virksomheten - API-detaljer)

(Premissgiver - styring dokumentasjon av API-er - 3. Som API-forvalter ønsker jeg at katalogen og dens underliggende spesifikasjoner og standarder gir krav jeg kan bruke i avtaler med leverandører/anskaffelser slik at jeg slipper å sette meg inn i hvilke krav jeg bør stille. )

(2-3-2 Som datasetteier ønsker jeg å registrere GDPR-relatert informasjon om datasett enn det som er mulig i Felles datakatalog slik at interne behov oppfylles i henhold til interne krav. - Brønnøysundregistrene)

(en datasett-katalog i virksomheten - Datasett-eier)

(Prosjekttutløsende behov (overordnet)- fra handlingsplanen i porteføljestyring - Etatene skal beskrive sin tolkning av begreper i lovverk, forvaltningsstandarder og forvaltningspraksis i egen begrepskatalog. Begrepsbeskrivelsene skal bl.a. legge til rette for at opplysningene i datasettene kan beskrives eksplisitt, f.eks. hva inngår i “likningsverdi”. Begrepsbeskrivelsene skal være tilgjengelige slik at regelverksutvikling og digitaliseringsprosjekter kan identifisere forenklinger. )

(data.norge.no datasetthøsting - data.norge.no portal)

(“Den registrerte/subjektet” - Som sluttbruker ønsker jeg å gi samtykke til at en offentlig myndighet kan innhente mine data fra en 3dje part slik at jeg slipper å tilgjengegliggjøre dataene selv.)

(API-katalogen - 12. Som APi-forvalter/eier ønsker jeg at standarder og beskrivelser er helt maskinlesbare slik at høsting og bruk kan automatiseres og min rolle automatiseres bort eller erstattes av AI. )

(Registerdata - )

(API-mangement verktøyleverandør - BAM02 - Som ansvarlig for API-management ønsker jeg å dokumentere mitt API slik at utviklere raskt kan benytte API-et for tilgang til de data API-et representerer )

(Felles datasettkatalog API - Search-DB)

(API-konsument (design time) - BA38. Som API-konsument ønsker jeg (kanskje ....) HATEOAS og linked data-baserte API (for eks. JSON-LD/RDF-representasjoner) slik at jeg kan se hvilke opsjoner jeg har basert på de responsene jeg allerede har fått (den tilstanden jeg er i). [Kommentar frå Steinar: “basert på én informant ... han var tydelig på at han hadde gode erfaringer med API-er med RDF-data”])

( BFP004: Som profesjonell API-konsument ønsker jeg stabile API som beskytter meg mot endringer i underliggende data slik at jeg trenger ikke å oppdatere apiene mine ved dataendringer. - API-konsumenter forvaltningen og proffesjonelle)

(Mikrotjenesten/API-et - BA11. Som API-konsument ønsker jeg at jeg kan bytte til nye versjoner av API-et når det passer meg [Kommentar frå Livar: Litt usikker på denne. Her er det kanskje snakk om versjonering av API, at ein sjølv kan velje når tid ein byttar til ny versjon av API? I motsetnad til at eit API ikkje er versjonert og ved "breaking-changes" så må ein forholde seg til når API-et gjer eit brått hopp til ny versjon?] )

(Administrative borders API - skv:Municipality)

(API-konsument (design time) - BA15. Som API-konsument ønsker jeg at alt jeg er avhengig av for applikasjonen min er tilgjengelig fra samme server, inklusive kodeverk, slik at CORS opprettholdes. )

(Begrep-ext - Begrep)

(Felles rammeverk - Veiledning - Beste praksis - API/mikrotjeneste)

(Som API-forvalter ønsker jeg eierskapet og ansvaret til API-eier kommer tydlig frem slik at man unngår uklarheter - BTI008 Som konsument av data fra offentlige virksomheter ønsker jeg at de offentlige virksomhetene inngår avtaler med sine leverandører som gjør det tydelig hvem som eier dataene, og stiller krav til at de skal være gjøres tilgjengelige uten kostnader, slik at ikke den offentlige virksomheten hindres i å dele sine data med meg som følge av at kostnadene blir for store. )

(Skjema API - Datamottak)

(Datasett - Forretningsobjekt)

(Mapping agency - Lenkede data)

(Felles rammeverk - Premissgiver - Ytelseskrav til API/mikrotjeneste)

(API-beskrivelsen - BFP002: Som API-konsument ønsker jeg enhetlig dokumentasjon og mulighet til “kundeservice” fra tjenesteleverandør. )

(Referansarkitektur - BTI001 Som innkjøper av fagsystemer trenger jeg et nettverk for å stille API-krav for tilgang til data slik at jeg kan trekke inn kompetanse til å spesifisere disse og få markedsmakt til å få leverandøren til å implementere dem. )

(API-katalogen - Som ansvarlig for API-Management ønsker jeg en enkel måte å varsle endringer i oppetid )

(Nasjonalt - Lesebruker)

(Mikrotjenesten/API-et - BFP012: Som API-konsument ønsker jeg varsel på endringer (push-varsel og toveiskommunikasjon) slik at jeg kan forberede tiltak. )

(API-tilbyder - 14. Som API-forvalter/eier ønsker jeg en ensartet og samlet API-katalog slik at det blir enklere å publisere informasjonen.)

(Administrative grenser API - skv:Kommune)

(Prosess, involvering og kvalitetssikring - Som behovseier for et begrep ønsker jeg å kunne skisse på et begrep gjentatte ganger før jeg involverer andre , slik at jeg kan levere kvalitet)

(API-konsument (design time) - BA6. Som API-konsument ønsker jeg å kunne på en enkel måte gi kontekstavhengige tilbakemeldinger til API-forvalteren, slik at dokumentasjonen og eller API-et blir bedre. )

(Mikrotjenesten/API-et - BA49. Som API-konsument ønsker jeg ikke å tvinges til å bruke API-er der hvor det aller enkleste for meg ville vært å få lastet ned hele datasettet. [kommentar: ønskjer i alle fall anledning til å velje] )

(Som konsument av API ønsker jeg informasjon om kostnader og trafikkbegrensninger for bruk av API-et slik at jeg kan ha forutsigbare rammer for min bruk av dataene. - BAM15 - Som ansvarlig for API-management ønsker jeg å publisere informasjon om kostnader og trafikkbegrensninger for mine API-er, slik at potensielle brukere av mine API-er slipper å spørre meg om denne informasjonen )

(Datasettkatalog - KOR)

(data.norge.no API - data.norge.no tjenestehøsting)

(Architecture Board - Program Management Office)

(Felles rammeverk - BA38. Som API-konsument ønsker jeg (kanskje ....) HATEOAS og linked data-baserte API (for eks. JSON-LD/RDF-representasjoner) slik at jeg kan se hvilke opsjoner jeg har basert på de responsene jeg allerede har fått (den tilstanden jeg er i). [Kommentar frå Steinar: “basert på én informant ... han var tydelig på at han hadde gode erfaringer med API-er med RDF-data”])

(Organization API - rov:Entity)

((Behov for registrering av begreper) - Etatene skal beskrive sin tolkning av begreper i lovverk, forvaltningsstandarder og forvaltningspraksis i egen begrepskatalog. Begrepsbeskrivelsene skal bl.a. legge til rette for at opplysningene i datasettene kan beskrives eksplisitt, f.eks. hva inngår i “likningsverdi”. Begrepsbeskrivelsene skal være tilgjengelige slik at regelverksutvikling og digitaliseringsprosjekter kan identifisere forenklinger. )

( BTI007 Som konsument av data fra kommunene ønsker jeg at kommunene tilbyr felles API for den samme informasjonen, uavhengig av hvilket fagsystem/hvilke leverandører de bruker for å forvalte informasjonen, slik at integrasjonen jeg utvikler mot én kommune kan gjenbrukes mot de resterende ca 400 kommunene. - API-tilbyder/private grossister)

(Forvalte API-tilgang - Deleger tilgang)

utvikler (Tjenesteutvikling - En konsument applikasjon)

(EPOS 5: Som API-konsument ønsker jeg dialog med andre API-konsumenter og API-tilbydere slik at vi få hjelp og hjelpe hverandre - Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier.)

(create access - Angi grovkonet tilgang)

(Felles - REST GET Begrepskatalog)

(Felles datasettkatalog API - Registration-API)

(Altinn.no - Tjenestekatalog)

(API-katalogen - 16. Som API-forvalter ønsker jeg å vite av hvem og hvor ofte mine API-er brukes (trafikkdata og bruksmønstre), slik at jeg optimere tilgang til API-er og ta stilling til hvilke API-er som eventuelt skal avvikles, samt kunne få grunnlag for å kunne rapportere på gevinstrealisering. )

(API-katalogen - Som API-konsument ønsker jeg at API-er av autoritativ art priorites slik at de er lette å finne)

(Som API-forvalter ønsker jeg eierskapet og ansvaret til API-eier kommer tydlig frem slik at man unngår uklarheter - BAM18 - Som ansvarlig for flere datasett og medfølgende API’er ønsker jeg å ha kontroll på de datasettene forretningsenheten min tilbyr og enkelt gi tilgang til datasettene ved behov slik at jeg kan utføre ansvaret jeg har på en enkel måte )

(kontroller delegering - Maskin-porten)

(BA1. Som API-konsument (student) ønsker jeg å filtrere på dataformater i oversikter over (åpne) API-er slik at jeg kan finne API-er i det formatet jeg ønsker å lære mer om eller filtrere ut de jeg ikke kan noe om. - Studenter, gründere og app-utviklere)

(Ferdig søketjeneste API - Som API-konsument ønsker jeg å finne detaljert beskrivelse av API-ene slik at jeg kan vurdere om jeg kan benytte API-et i mine tjenester)

(Maskin-porten - update delegation table)

(API-katalogen - BB10. Som API-konsument ønsker jeg mulighet til å innhente data om tekstdatasett slik at jeg kan lage analyser av disse og koble til andre kilde. [tekst som data] )

(Standardisering - Grensesnitt API/mikrotjeneste - BB31. Som API-konsument ønsker jeg at datasett som er gjort tilgjengelig for nedlasting har et forutsigbart URL-regime for siste versjon og historiske data slik at nedlasting kan automatiseres. [nedlasting, forutsigbarhet] )

(Brønnøysundregistrene - 2-4 Som datasetteier ønsker jeg å gi bruker av datasett en enkel mulighet til å se hvilke dataelementer (ID/navn) datasettene inneholder slik at bruker får avklart om datasettet kan brukes til sitt formål)

(API-konsument (design time) - BA18. Som API-konsument ønsker jeg lenker til aktuelle kodeverk (f.eks. kommunenummer, næringskoder) slik at jeg lett kan hente støtte-datasett og dermed benytte datasettet fullt ut. )

(create access - Scope)

(Som API-konsument ønsker jeg at distribusjoner av samme (eller geografisk komplementære) datasett fra ulike tilbydere eller er samlet under et datasett - BTI010 Som API-tilbyder ønsker jeg å kunne se om andre tilbyr det samme eller nesten det samme som meg, så at det er mulig å harmonisere mellom “oss” [Livar: Case der det er fleire API-er som tilbyr det samme? Marit: Brreg og Skatt som har same datasett i FDK. Mathias: Felles studentsystem (FS) i UH-sektoren innheld personinformasjon. Kan ikkje konsoliderast med HR-data. Kan ikkje legge ned ein av dei. Dekker relasjonsfeltet i DCAT behovet?] )

(Mikrotjenesten/API-et - BB32. Som API-konsument (datajournalist) ønsker jeg at strukturen i datasettene er stabile, slik at jeg ikke trenger gjøre endringer i min integrasjon/kode når nye versjoner hentes. [forutsigbarhet] )

(jwt - 3)

(get token - Få tilgang)

(Felles - REST GET API-katalog)

(BA6. Som API-konsument ønsker jeg å kunne på en enkel måte gi kontekstavhengige tilbakemeldinger til API-forvalteren, slik at dokumentasjonen og eller API-et blir bedre. - Studenter, gründere og app-utviklere)

(Som API-konsument ønsker jeg å forstå om API-et er tilrettelagt for bruk med brukers samtykke eller fullmakt - Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv)

(Harvester API - en API-katalog i virksomheten)

(API-beskrivelsen - BAM15 - Som ansvarlig for API-management ønsker jeg å publisere informasjon om kostnader og trafikkbegrensninger for mine API-er, slik at potensielle brukere av mine API-er slipper å spørre meg om denne informasjonen )

(Som dataeier ønkser jeg logging slik at jeg kan kan se hvilke datasett som det er interesse for - 6. Tilgangsoversikt ... logg? )

(Search-DB - Search-API)

(digitale tjenester - Altinn tjenestekatalog)

(Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles - Som API-konsument ønsker jeg at nasjonal/delt infrastruktur tilbyr felles mønstre for autentisering og autorisering mot API slik at jeg slipper å bestille og forvalte tilgangsstyring hos hver enkelt tjenestetilbyder.)

(en informasjonsmodel-katalog i virksomheten - Som eier av datasett ønsker jeg å gi bruker av datasett en enkel mulighet til å se hvilke dataelementer (ID/navn) datasettene inneholder.)

(Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer - BAM03 - Som ansvarlig for API-management ønsker jeg å notifisere endringer i mine API til dem som benytter API-ene slik at man ikke bryter kontrakter )

(Prosess, involvering og kvalitetssikring - Som interessent ønsker jeg å se om begrepet jobbes med eller om det er ferdigstilt, slik at jeg kan vurdere om det er stabilt å benytte det.)

(API 2 - Standardisert API [ABSTRACT])

(API-katalog - API-backend)

(API-spesifikasjon - Hent liste over gitte API-spesifikasjoner)

(Kodelister - )

(Tjenestebeskrivelse - )

(Som virksomhet som behandler personopplysninger ønsker jeg [verktøystøtte] slik at jeg ivaretar kravene til protokoll iht GDPR artikkel 30 (protokoll) - GDPR artikkel 30 stiller krav til protokoll. Tolkes litt ulikt om det er en protokoll pr behandling eller en samlet protokoll med oversikt over alle behandlingene. Uansett er hensikten å kunne gi en samlet oversikt over behandlingen av personopplysninger i en virksomhet. Enighet om at dette løses ved at det legges til en modul for å registrere en behandlingsaktivitet. Summen av de registrerte behandlingsaktivitetene utgjør protokollen. Noe informasjon vil være felles på tvers av behandlingsaktivitetene, slik som hvem som er behandlingsansvarlig (direktøren), hvem som er personvernombud etc.)

(Premissgiver - Kvalitetskrav til API/mikrotjeneste - BA11. Som API-konsument ønsker jeg at jeg kan bytte til nye versjoner av API-et når det passer meg [Kommentar frå Livar: Litt usikker på denne. Her er det kanskje snakk om versjonering av API, at ein sjølv kan velje når tid ein byttar til ny versjon av API? I motsetnad til at eit API ikkje er versjonert og ved "breaking-changes" så må ein forholde seg til når API-et gjer eit brått hopp til ny versjon?] )

(API-beskrivelsen - BFP025: Som API-konsument ønsker jeg å se hvilke muligheter det finnes for konfigurasjon både hos meg og hos API-leverandør for å begrense tilgjengelig data til mitt faktiske formål. Kommentar: Dataminimering?)

(Nasjonalt - Begrepskatalog GUI)

(Prosjekttutløsende behov (overordnet)- fra handlingsplanen i porteføljestyring - For å ta i bruk dataene må tilgangen til opplysningene være beskrevet gjennom API-beskrivelser. API-ene må beskrives og forvaltes av dataeier (eller distributør) (API Management), og inkludere detaljer som protokoller, utvekslingsformater, sikkerhetskrav, innholdsstrukturer, avhengigheter til kodelister, terms of service m.m. API-beskrivelsene vil finnes som en del av datakatalogen. (2018).)

(Mikrotjenesten/API-et - 33. Som API-forvalter ønsker jeg at man tilbyr ei løsning/det blir spesifisert hvordan man skal tilby API på samme format.)

(API-katalogen - BFDK09 - Som datasetteier for historiske (avleverte) data ønsker jeg å kunne koble de historiske datasettene med tilsvarende aktive/nåværende datasett, slik at jeg kan tilby brukerne en helhetlig tilgang til dataene.)

(En_API-tilbyder - API-tilbyder)

(API-katalogen - BA6. Som API-konsument ønsker jeg å kunne på en enkel måte gi kontekstavhengige tilbakemeldinger til API-forvalteren, slik at dokumentasjonen og eller API-et blir bedre. )

(API-katalogen - 15. Som API-forvalter/eier ønsker jeg en ensartet og samlet beskrivelse av alle våre API-er slik at det er enkelt for brukerne å gjenbruke sin kunnskap om de skal bruke flere API-er. )

(SecurityScheme - Scope)

(API beskrivelse 1 - Standard xyz)

(API-katalogen - BAM08 - Som ansvarlig for API-management ønsker jeg oversikt over brukerne av mitt API slik at jeg kan formidle endringer i APIet. [Livar: duplikat av BAM03?] )

( BB24. Som API-konsument (ETL) ønsker, jeg stabile API-er som er uavhengige av underliggende data slik at jeg ikke trenger å følge med endringer i data formater/strukturer. [forutsigbarhet] - Åpne data statistikk, datajournalistikk og stordata)

(Datasettkatalog - Datasettkatalog GUI)

(jwt - 2)

(API-beskrivelsen - BA28. Som API-konsument ønsker jeg informasjon om ytelsesmessige (svartid, antall oppslag) begrensninger i API-et, slik at jeg kan vurdere om API-et har god nok ytelse til mitt formål. )

(Som API-konsument ønsker jeg oversikt over testmiljø og syntetiske data slik at jeg kan teste ut API-ene - BFP013: Som API-konsument ønsker jeg en oversikt over tilgjengelige testmiljø for å teste ut apiene. )

(Skatteetaten - Som API-forvalter/API-management ansvarlig ønsker jeg en nasjonal/delt infrastruktur for administrasjon og utstedelse av tilgangstokens for API-konsumenter slik at jeg slipper å utstede og forvalte disse selv (dette gjelder både hjemmelsbasert og samtykkebasert tilgang).)

(Registreringsapplikasjon begrep - Jurist)

(EPOS 6: Som API-konsument ønsker jeg informasjon om autentisering og tilgangskontroll for å ta API-et i bruk - Som API-konsument ønsker jeg hjelp til tilgang til nøkler eller tokens for raskt å ta i bruk API-et)

(Felles rammeverk - BA27. Som API-konsument ønsker jeg at API-forvaltere lærer av webutviklere og tenker på brukerinvolvering og brukertesting slik at jeg kan få et API-som er lagt til rette for bruk )

(Kostnader - BAM15 - Som ansvarlig for API-management ønsker jeg å publisere informasjon om kostnader og trafikkbegrensninger for mine API-er, slik at potensielle brukere av mine API-er slipper å spørre meg om denne informasjonen )

(Publisere begreper til FDK (aka Jira adapter) (ORDEN-596) - Behov for å publisere begreper eksternt (ORDEN-584))

( BTI003 Som innkjøper av fagsystemer ønsker jeg at Statens Standardavtaler inneholder krav til at leverandøren skal tilgjengeliggjøre API-er og data, slik at jeg får tilgang til og slipper å kjøpe tilbake mine egne data. - API-tilbyder/private grossister)

(er:Organization - Organization)

(Felles rammeverk - BFP024: Som API-konsument ønsker jeg i de tilfeller hvor API er basert på et lukket datasett å koble meg til et miljø med syntetisk data for bruk i utvikling og test. )

(Registreringstjeneste API - Som API-forvalter ønsker jeg å registrere mine API-er slik at de kan gjøres tilgjengelig for andre)

(API-beskrivelsen - BA31. Som API-konsument ønsker jeg informasjon om eventuelle økonomiske betingelser for bruk av API-er, slik at jeg kan vurdere hvorvidt det er aktuelt å betale for bruk av API-et. )

(Begrep - SKOS)

(Felles rammeverk - BFP031: Som kommersiell API-konsument ønsker jeg at offentlige aktører ikke tilbyr konkurrerende verdiøkende tjenester på de API de tilbyr slik at jeg kan sikre min return on investment. )

(31. Som API-portaleier ønsker jeg å få inn statistikk fra API-forvaltere slik at vi kan få et overordnet oversikt for hele sektoren/landet. - API-forvalter og API katalogeier)

(Felles rammeverk - 13. Som API-forvalter ønsker jeg å kunne påvirke utformingen av felles nasjonale oppskrifter for API-beskrivelser slik at de dekker mine behov.)

registrert i (DCAT-AP-NO v2.0 - FDK-høsting ADM)

(Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles - Som API-forvalter/API-management ansvarlig ønsker jeg en nasjonal/delt infrastruktur for administrasjon og utstedelse av tilgangstokens for API-konsumenter slik at jeg slipper å utstede og forvalte disse selv (dette gjelder både hjemmelsbasert og samtykkebasert tilgang).)

(Begrep - 4)

(Felles datakatalog portal (fellesdatakatalog.brreg.no) - Datasett søk)

(API-katalog - Scope)

(Lokal datasett registreringsløsning - 2-3-1 Som datasetteier ønsker jeg å registrere kontaktinformasjon til dataeier, datasetteier og teknisk kontakt slik at interne behov oppfylles i henhold til interne krav)

(Prosjekttutløsende behov (overordnet)- fra handlingsplanen i porteføljestyring - En lokal datasettkatalog med virksomhetsintern informasjon, til bruk for “orden i eget hus”, GDPR, statistikk etc og som er grunnlaget for informasjonen som synliggjøres i felles datakatalog )

(Felles rammeverk - BB33. Som API-konsument ønsker jeg å kunne laste ned kun endringer i et datasett for å oppdatere min lokale kopi av et datasett slik at jeg slipper å laste ned hele datasettet på nytt og import-jobben blir mindre. [varsel] )

(API-katalogen - Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles)

(API-konsument (design time) - BFP004: Som profesjonell API-konsument ønsker jeg stabile API som beskytter meg mot endringer i underliggende data slik at jeg trenger ikke å oppdatere apiene mine ved dataendringer. )

(Som API-konsument ønsker jeg informasjon hvordan endringer i modell varsles slik at jeg kan fange opp endringer - BFP030: Som API-konsument ønsker jeg å kunne spørre produsent om mer og bedre data slik at vi kan tilby et bedre og mer helhetlig bilde. )

(Åpent Regnskapsdata API (maskinlesbart) - organisasjonsnummer)

( Jeg ønsker å få tilgang til reisedata (tid, pris, fra-til-sted osv) for ulike transporttjenester slik at jeg kan bruke data i stedet for kvitteringer ved innlevering av reiseregninger. - MyData, viderebruk av personopplysninger )

(Etat - Utfyllt skjema)

(Mikrotjenesten/API-et - BB4. Som API-konsument (ETL) ønsker jeg API-er som gir meg uttrekk som er tilpasset mine rettigheter og filtreringsbehov slik at jeg kan innhente uttrekket jeg trenger og har rett til. [rettigheter] )

(A Technology Service - A service in a container)

(Etat - Preutfylling)

(Datasettkatalog - Behandlingsaktivitet katalog)

(BA10.Som API-konsument ønsker jeg en indikasjon på hvor dynamisk datasettet er, slik at jeg har en idé om hvor ofte jeg trenger å lese data på nytt. - Studenter, gründere og app-utviklere)

(Forretningsutvikler - BFDK05 - Som forretningsutvikler ønsker jeg å kunne sammenligne APIere, slik at jeg vurdere om et API passer bedre enn et annet for min bruk.)

(EPOS 5: Som API-konsument ønsker jeg dialog med andre API-konsumenter og API-tilbydere slik at vi få hjelp og hjelpe hverandre - Som bruker ønsker jeg å kunne authentisere meg på en enkel måte mot katalogen slik at jeg kan gi tilbakemeldninger og melde om bruk av et API)

(API-katalog API - Informasjonsmodell-katalog)

(Undersøke, gjenfinne, få oversikt - Som bruker (produsent) ønsker jeg å undersøke, gjenfinne, få oversikt over begreper, slik at jeg kan få kunnskap om autoritative beskrivelser)

(API-beskrivelsen - BFP027: Som API-konsument ønsker jeg at dokumentasjonen til API-er jeg skal bruke har informasjon om kvalitet og tilgjengelighet, slik at jeg slipper mange henvendelser til API-tilbyder for å få svar på enkle ting. )

(Som API-konsument ønsker jeg at det er gjort en sikkerhetsvurdering slik at krav til innebygd personvern er best mulig ivaretatt - BFP001: Som API-forvalter ønsker jeg at det knyttes opplysninger om sikkerhetsvurderinger tilknyttet felt i API’et (identifiserende, lokaliserende, krav til sikring, osv.) slik at hensyn til innebygd personvern i større grad er ivaretatt for det datasettet som publiseres. )

(Bruk - Som oversetter på et fagområde ønsker jeg å ha tilgang til begreper fra autoritative kilder, slik at jeg kan legge innholdet til grunn for mine oversettelser)

(API-katalogen - Som dataeier ønsker jeg å knytte API til datasettet slik at jeg kan vise hvilke distribusjoner som finnes)

(BFDK04 - Som forretningsutvikler ønsker jeg å filtrere på datasett som har API, slik at jeg bedre treff på mine søk i katalogen. - FDK)

(Enhetsregisteret - Registreringsapplikasjon datasett)

(API-katalog - REST GET API-katalog)

(Andre API-kataloger - data.norge.no API-høster)

(Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API - BB8. Som API-konsument ønsker jeg at utforskingsfasen/exploration/discovery gir meg rask oversikt og innsikt slik at jeg minimerer tiden jeg bruker på å velge et utsnitt eller må bruke egne verktøy for å skaffe meg oversikt. [dokumentasjon] )

(Felles datasettkatalog portal - Harvester)

(Altinn Studio (Tjeneste 3.0) - Skjemamodell)

(EPOS 2: Som API-forvalter ønsker jeg å registrere mine API-er slik at de kan gjøres tilgjengelig for andre - Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles)

(Offentlig Virksomhet - en tjenestekatalog i virksomheten)

(Chief Architect - Enterprise Architects)

(Felles datasettkatalog API - Registration Service)

(Registreringsløsning informasjonsmodell - Informasjonsmodell-katalog)

(BB32. Som API-konsument (datajournalist) ønsker jeg at strukturen i datasettene er stabile, slik at jeg ikke trenger gjøre endringer i min integrasjon/kode når nye versjoner hentes. [forutsigbarhet] - Åpne data statistikk, datajournalistikk og stordata)

(API-beskrivelsen - BA2. Som API-konsument ønsker jeg umiddelbar tilgang (slipper å vente på manuell tildeling av API-nøkler og tokens) til data (eller testdata) slik at jeg kan vurdere og eventuelt ta i bruk API-et umiddelbart.)

(Organization JSON-LD - Organization)

(BFP016: Som API-konsument ønsker jeg en oversikt over hvilke versjoner som er tilgjengelig i hvilke miljø slik at jeg vet hva jeg kan teste mot. (prod og test) - API-konsumenter forvaltningen og proffesjonelle)

(Register 2 - Datasett (copy))

( Når jeg flytter til en ny kommune ønsker jeg at mine data fra gamlekommunen automatisk overføres slik at min nye kommune har oversikt over hvilke behov og tilbud som er relevant for meg. - MyData, viderebruk av personopplysninger )

(Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API - 24. Som API-forvalter (f.eks. av hotell.difi.no) ønsker jeg at API-ene er lette å finne og ta i bruk slik at verdien blir realisert. )

( BB30. Som API-konsument ønsker jeg å slippe å ha en kopi av xxregistreret eller datasettet slik at jeg kan være sikker på at dataene er oppdaterte. [tjenestenivå] - Åpne data statistikk, datajournalistikk og stordata)

(Datasett-eier - Som datasetteier ønsker jeg motta varsel etter en fast periodisering om at det er tid for å sjekke om omtale av datasett er oppdatert slik at jeg sikrer best mulig datakvalitet på omtalen)

(Premissgiver - Ytelseskrav til API/mikrotjeneste - BB28. Som API-konsument ønsker jeg at API-et har god ytelse slik at jeg kan gjøre enkeltoppslag og ikke blir tvunget til å laste ned hele datasettet fordi API-et har lav ytelse. [tjenestenivå] )

(Enterprise Continuum - Organizational Standards)

(en datasett-katalog i virksomheten - Lokal Datasett søkeløsning)

4 (Begrepskatalog API - Begrepskatalog GUI)

(API-beskrivelsen - BAM02 - Som ansvarlig for API-management ønsker jeg å dokumentere mitt API slik at utviklere raskt kan benytte API-et for tilgang til de data API-et representerer )

(32. Som API-bruker ønsker jeg å registrere en anvendelse slik at jeg kan oppgi den i API-kallet. Alternativt: Som API-forvalter ønsker jeg at brukere kan registrere seg med en ID som de bruker i API-kallet slik at jeg kan koble trafikk og anvendelse. [f.eks. ved overbruk av API-et kan man lett kontakte den som har satt opp anvendelsen] - API-forvalter og API katalogeier)

(Registreringsapplikasjon datasett - Datasett-eier)

(Mikrotjenesten/API-et - BA38. Som API-konsument ønsker jeg (kanskje ....) HATEOAS og linked data-baserte API (for eks. JSON-LD/RDF-representasjoner) slik at jeg kan se hvilke opsjoner jeg har basert på de responsene jeg allerede har fått (den tilstanden jeg er i). [Kommentar frå Steinar: “basert på én informant ... han var tydelig på at han hadde gode erfaringer med API-er med RDF-data”])

(Veiledning - Beste praksis - API/mikrotjeneste - 33. Som API-forvalter ønsker jeg at man tilbyr ei løsning/det blir spesifisert hvordan man skal tilby API på samme format.)

(Tilgangsstyring - Angi grovkonet tilgang)

(BA33. Som API-konsument ønsker jeg at det er så få tekniske sperrer på API-ene som mulig slik at jeg kan ta det i bruk med minst mulig “prosess” mot API-forvalteren - Studenter, gründere og app-utviklere)

(En_API-tilbyder - en datasett-katalog i virksomheten)

(EPOS 5: Som API konsument ønsker jeg kvalitets- og sikkerhetsvurderinger om API-et slik at jeg kan forstå hvordan jeg kan ta det i bruk - Som API-konsument ønsker jeg informasjon om tilgang til dataene (tilgangsnivå) slik at jeg kan forstå hvordan jeg skal ta det i bruk)

(register scope - Scope)

( BFP030: Som API-konsument ønsker jeg å kunne spørre produsent om mer og bedre data slik at vi kan tilby et bedre og mer helhetlig bilde. - API-konsumenter forvaltningen og proffesjonelle)

(DCAT-AP-NO v2.0 - data.norge.no API-høster)

Stewardship (CIO/CTO - Implement)

(API-beskrivelsen - BTI008 Som konsument av data fra offentlige virksomheter ønsker jeg at de offentlige virksomhetene inngår avtaler med sine leverandører som gjør det tydelig hvem som eier dataene, og stiller krav til at de skal være gjøres tilgjengelige uten kostnader, slik at ikke den offentlige virksomheten hindres i å dele sine data med meg som følge av at kostnadene blir for store. )

( Jeg ønsker å få kontinuerlig økonomisk og rettslig rådgivning fra “velferdsrådgiverne A/S”, slik at de kan identifisere hvilke offentlige tjenester jeg har rett på, evt anbefale meg å jobbe litt mindre slik at jeg kommer under inntektsgrenser som igjen trigger nye utbetalinger -- jobbe mindre og tjene mere! - MyData, viderebruk av personopplysninger )

(data.norge.no portal - Informasjonsmodell-katalog)

(Felles rammeverk - Premissgiver - Tjenesteutvikling på API/mikrotjenester)

(TIlgjengeliggjøring og utveksling - Som katalogeier (FBK) ønsker jeg å kunne endre felter i publiseringsløsningen når standardene jeg bruker endrer seg, slik at jeg kan være konform med utvekslingsstandard for begreper.)

(API-katalogen - 26. Som API-forvalter ønsker jeg at opplysninger som er relevante for datakatalogen og som finnes i API-et (feks “sist oppdatert”), høstes til datakatalogen slik at datasettbeskrivelsen er så god som mulig. )

(API-konsument (design time) - BB16. Som API-konsument ønsker jeg at støttedatasett (f.eks. kodelister) er omtalt i dokumentasjonen slik at jeg kan anvende data fullt ut.[dokumentasjon] )

(Offentlig Virksomhet - en datasett-katalog i virksomheten)

(Melding uten gjenbruksmulig eller preutfylling - 211. Som tjenesteutvikler ønsker jeg at modellen til tjenesten automatisk blir opprettet når jeg starter med å lage brukergrensesnittet til tjenesten i skjemaklienten slik at jeg slipper å manuelt modellere modellen i etterkant og så koble denne til grensesnittet til tjenesten.)

(Felles rammeverk - BFP006: Som API-konsument ønsker jeg at det ikke er for rigide krav til dokumentering og til selve APIet slik at det ikke hemmer rask utvikling av API )

(API-katalog - API-katalog GUI)

(API-beskrivelsen - BFP022: Som API-konsument ønsker jeg eksempler/mal på bruk slik at jeg kan ta i bruk nye datasett raskest mulig. )

(en informasjonsmodel-katalog i virksomheten - data.norge.no informasjonsmodell-høsting)

(Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et - 32. Som API-bruker ønsker jeg å registrere en anvendelse slik at jeg kan oppgi den i API-kallet. Alternativt: Som API-forvalter ønsker jeg at brukere kan registrere seg med en ID som de bruker i API-kallet slik at jeg kan koble trafikk og anvendelse. [f.eks. ved overbruk av API-et kan man lett kontakte den som har satt opp anvendelsen] )

(en API-katalog i virksomheten - REST GET API-katalog)

(API-katalogen - Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted.)

(Søk og oppslag datasett-beskrivelser - Altinn Studio (Tjeneste 3.0))

(API-konsument (design time) - BTI007 Som konsument av data fra kommunene ønsker jeg at kommunene tilbyr felles API for den samme informasjonen, uavhengig av hvilket fagsystem/hvilke leverandører de bruker for å forvalte informasjonen, slik at integrasjonen jeg utvikler mot én kommune kan gjenbrukes mot de resterende ca 400 kommunene. )

(API-konsument (design time) - BA40. Som API-tilbyder* ønsker jeg retningslinjer og beste praksis for dokumentasjon av API-ene mine slik at jeg kan dokumentere så effektivt og bra som mulig. )

(Modellkatalog, Datamodell, Data dictionary - Informasjonsmodell)

(Organisasjonskatalog - API-katalog GUI)

Publish START_HARVEST_APIs (Cron service - Publish/Subscribe Service)

(Begrepskatalog API - Forretningsutvikler)

(Felles datasettkatalog API - Harvester-API)

(Som API-forvalter ønsker jeg en godt dokumentert felles løsning for registering av API-beskrivelser slik at jeg slipper å installere egne verktøy. - 34. Som API-katalogeier som ikke har en katalog, så ønsker jeg enkel måte å eksponere API-er på, ikke egen katalog med maskinlesbar beskrivelse, slik at jeg slipper å lage et eget verktøy med egne beskrivelser. )

( BFP005: Som API-konsument ønsker jeg at dokumentasjonen skal integreres i koden slik at den til enhver tid er oppdatert - API-konsumenter forvaltningen og proffesjonelle)

( BFP020: Som API-konsument ønsker jeg informasjon om oppdateringsfrekvens av dataene eller om dataene er statiske. - API-konsumenter forvaltningen og proffesjonelle)

(Lenkede data - Organization)

(API-katalogen - API-forvalter og API katalogeier)

(API-katalog - For å ta i bruk dataene må tilgangen til opplysningene være beskrevet gjennom API-beskrivelser. API-ene må beskrives og forvaltes av dataeier (eller distributør) (API Management), og inkludere detaljer som protokoller, utvekslingsformater, sikkerhetskrav, innholdsstrukturer, avhengigheter til kodelister, terms of service m.m. API-beskrivelsene vil finnes som en del av datakatalogen. (2018).)

(BA32. Som API-konsument (gründer) ønsker jeg en tematisk oversikt over offentlige API slik at jeg kan lage nye tjenester. - Studenter, gründere og app-utviklere)

(Lokal registreringsløsning - Som datasetteier ønsker jeg å se en tydelig status (i arbeid, ferdig/validerer, publisert) på datasettbeskrivelsen, slik at det ikke er tvil om gyldighet og tilgjengelighet)

(API-tilbyder - BTI002 Som API-tilbyder som sammenstiller data på vegne av f.eks. kommuner ønsker jeg at de større systemene og registrene skal tilby API-er slik at jeg enkelt kan få tilgang til dataene for å gjennomføre mitt oppdrag. )

(Standardisering - Grensesnitt API/mikrotjeneste - BA53. Som API-konsument ønsker jeg at API-et støtter HTTP-standard med accept header for å velge data-format slik at kan gjøre det jeg er vant til. )

(9. Virksomheten kan selv justere intern datakatalog etter egne behov - Difi)

(API-katalogen - Som API-forvalter ønsker jeg kontaktinfo til brukere av mine API slik at jeg kan ta kontakt med dem)

(OrganizationAPI - rov:Entity)

(Som API-konsument ønsker jeg at API-beskrivelser er oppdaterte, og at API-er som ikke lenger er tilgjengelig/deprecated fjernes fra katalogen slik at jeg ikke studerer beskrivelser som ikke kan brukes - BA25. Som API-konsument ønsker jeg at beskrivelser av API-er som ikke lengre er tilgjengelige, skal fjernes fra API-katalogen, slik at jeg slipper å lese om API-er som jeg uansett ikke kan bruke.)

(API-katalog - Harvester API)

(Tjenestebeskrivelse - )

(Maskin-porten - create access)

Conformance (Implementation Projects - Domain Architects)

(Nasjonalt - Kommentator bruker)

(Som API-konsument ønsker jeg å kunne sammenlikne API slik at jeg kan vurdere om et API passer bedre enn et annet - BFDK05 - Som forretningsutvikler ønsker jeg å kunne sammenligne APIere, slik at jeg vurdere om et API passer bedre enn et annet for min bruk.)

(Felles rammeverk - Standardisering - API beskrivelser)

( Som pasient vil jeg at fastlegen skal ha tilgang til treningsdata (helst AI bearbeidet) (med automatisert varsling om avvik?) for å bidra til bedre, raskere og billigere diagnostisering - Som sluttbruker ønsker jeg å gi samtykke til at en offentlig myndighet kan innhente mine data fra en 3dje part slik at jeg slipper å tilgjengegliggjøre dataene selv.)

(API-konsument (design time) - BB28. Som API-konsument ønsker jeg at API-et har god ytelse slik at jeg kan gjøre enkeltoppslag og ikke blir tvunget til å laste ned hele datasettet fordi API-et har lav ytelse. [tjenestenivå] )

(Node - Persistering)

(“Den registrerte/subjektet” - Som sluttbruker ønsker jeg at en privat virksomhet skal ha tilgang til data om meg fra en tredjepart (app) slik at jeg kan slippe å tiljgengeliggjøre dataene selv)

(EPOS 9: Som API-konsument ønsker jeg oversikt over hvem som bruker et API slik at jeg kan forstå det bedre - BFP022: Som API-konsument ønsker jeg eksempler/mal på bruk slik at jeg kan ta i bruk nye datasett raskest mulig. )

(Norwegian Accounting Registry - Open Accounting API)

(Mikrotjenesten/API-et - BB28. Som API-konsument ønsker jeg at API-et har god ytelse slik at jeg kan gjøre enkeltoppslag og ikke blir tvunget til å laste ned hele datasettet fordi API-et har lav ytelse. [tjenestenivå] )

(API-katalogen - BAM09 - Som ansvarlig for API-management ønsker jeg å kunne administrere nøkler gitt til de enkelte konsumentene slik at jeg enkelt kan fjerne ev. misbruk av API-et )

(Register - Register API)

(Veiledning - Beste praksis - API/mikrotjeneste - BA48. Som API-konsument ønsker jeg at API-ene jeg bruker tilbyr komplett nedlasting av datasett slik at jeg kan bearbeide data lokalt. )

(Mapping agency - Municipality)

(Kartverket - skv:Kommune)

(Registreringsapplikasjon datasett - REST GET Datasettkatalog)

(Datasett-eier - Som datasetteier ønsker jeg å registrere våre datasett i Lokal datakatalog i henhold til DCAT slik at jeg kan dele dem i felles datakatalog.)

(Standardisering - Grensesnitt API/mikrotjeneste - BFP021: Som API-konsument ønsker jeg en standardisering av API-grensesnittene (inn og ut) slik at jeg kan ta i bruk nye datasett raskest mulig. )

( BAM02 - Som ansvarlig for API-management ønsker jeg å dokumentere mitt API slik at utviklere raskt kan benytte API-et for tilgang til de data API-et representerer - API-management)

(Lokal registreringsløsning - Som dataeier ønsker jeg motta varsel og purring etter en fast periodisering om at det er tid for å sjekke om omtale av datasett er oppdatert slik at jeg sikrer best mulig datakvalitet på omtalen )

(Brønnøysundregistrene - Grensesnitt)

(Preutfylling - Datamottak)

(Registerenhet i Belgia - Organzation JSON-LD)

(Referansarkitektur - BA34. Som API-konsument ønsker jeg at eventuelle krav til API-nøkler etc lar seg løse raskt/selvbetjent slik at jeg kan komme i gang raskt. [f.eks. autorisering basert på eksisterende mekanismer fremfor å måtte kontakte forvalter og vente på svar (ID-porten, Altinn), bruksvilkår fremfor avtaler] )

(Begrepskatalog GUI - Lesebruker)

(API-katalogen - 24. Som API-forvalter (f.eks. av hotell.difi.no) ønsker jeg at API-ene er lette å finne og ta i bruk slik at verdien blir realisert. )

(Modellkatalog, Datamodell, Data dictionary - BFDK06 - Som arkitekt ønsker jeg å se hvilke data jeg må benytte for å gjøre oppslag mot et API og hvilke data jeg får tilbake slik at jeg kan planlegge design av løsning. )

(en API-katalog i virksomheten - Opprett API beskrivelse)

(Som API-konsument ønsker jeg at rettslige rammer og lisens er tydelig beskrevet slik at jeg kan vurdere om det er forenelig med min bruk av dataene - BA35. Som API-konsument ønsker jeg at det er tydelig hva som er de rettslige rammene for bruk av API-ene slik at jeg kan være sikker på at jeg ikke kan få krav mot meg senere, f.eks. NLOD. )

(Nasjonalt - Registreringsapplikasjon datasett)

(Nettverk (faglig forum) - BTI011 Som API-tilbyder/privat grossist (som er databehandler for innrapportering og tilgjengeliggjøring av informasjon), ønsker jeg at det finnes et forum / nettverk der dataeiere og databrukere utarbeider gode krav til tilgjengeliggjøring og tilbakerapportering av aggregert informasjon. )

(API-katalogen - EPOS 3: Som API-konsument ønsker jeg å kunne søke og filtrer på API-er slik at jeg kan raskt finne rett API)

(API-beskrivelse (OAS) - SecurityScheme)

(Få tilgang - Tjenesteeier (Applikasjons-/tjenesteutvikler/API-konsument))

(Som API-konsument ønsker jeg at datasett som er relatert til hverandre vises sammen slik at jeg kan få et helhetlig bilde av et fenomen - BA20. Som API-konsument ønsker jeg informasjon om hvor jeg kan finne statiske data som brukes til API-requests (Kommunenr, Kommunenavn..) slik at jeg slipper å lete etter dette selv. )

(API-tilbyder - BTI011 Som API-tilbyder/privat grossist (som er databehandler for innrapportering og tilgjengeliggjøring av informasjon), ønsker jeg at det finnes et forum / nettverk der dataeiere og databrukere utarbeider gode krav til tilgjengeliggjøring og tilbakerapportering av aggregert informasjon. )

(API-konsument (design time) - BA2. Som API-konsument ønsker jeg umiddelbar tilgang (slipper å vente på manuell tildeling av API-nøkler og tokens) til data (eller testdata) slik at jeg kan vurdere og eventuelt ta i bruk API-et umiddelbart.)

(Enhetsregisteret - Enhetsregisteret API)

(Mikrotjenesten/API-et - BA44. Som API-konsument ønsker jeg intelligente API-er som kan f.eks. filtrere, aggrerere, gruppere slik at jeg bare få inn de resultater jeg trenger av hensyn til personvern, kapasitet etc. )

(Andre API-kataloger - DCAT-AP-NO v2.0)

(API-katalog - Utvid API-beskrivelse)

(en API-katalog i virksomheten - Registreringsløsning API)

(Felles datakatalog portal (fellesdatakatalog.brreg.no) - REST GET informasjonsmodell-katalog)

(Begrep - Begrep-ext)

(Informasjonsforvaltning - CIO/CTO)

(En konkret tjeneste - BTI006 Som kommunal API-konsument ønsker jeg digital tilgang til kommunesektorens rapporteringskategorier (f.eks. om rapportering er periodisk, om den er hendelsesutløst, eventuell dato for søknadsfrister) slik at jeg kan sikre at alle tidsfrister kan holdes )

( BAM08 - Som ansvarlig for API-management ønsker jeg oversikt over brukerne av mitt API slik at jeg kan formidle endringer i APIet. [Livar: duplikat av BAM03?] - API-management)

( Som brukar er eg villig til å dele mine posisjonsdata slik at ein kan verifisere at eg har tatt buss-reiser og dermed …. kan eg få statistikk om kor mykje eg har reist kollektivt og dette kan brukast til … Premisset for dette er at alle bussar som køyrer kollektivtrafikk har ordentleg GPS-sporing, og at ein har tilgang til historiske posisjonsdata for bussane slik at ein kan kryssjekke kvar og når bussane faktisk har køyrt med mine personlege posisjonsdata. - Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv)

( BAM17 - Som ansvarlig for API-management ønsker jeg at å tilby effektiv selvregistrering av brukere av API-ene, f.eks. gjennom autentisering via ID-porten/Altinn av dem som tar i bruk API-ene, slik at jeg senker terskelen for å ta API-et i bruk, samtidig som jeg beholder nødvendig oversikt over brukere. - API-management)

(Node - Kontainer runtime)

( BFP013: Som API-konsument ønsker jeg en oversikt over tilgjengelige testmiljø for å teste ut apiene. - API-konsumenter forvaltningen og proffesjonelle)

(Registreringsapplikasjon API - Felles datakatalog portal (fellesdatakatalog.brreg.no))

(API-katalogen - Som API-konsument ønsker jeg standardiserte autentiserings- og autoriseringsmekanismer som kan gjenbrukes for flere tjenester)

(Personvern - API/mikrotjeneste - BB4. Som API-konsument (ETL) ønsker jeg API-er som gir meg uttrekk som er tilpasset mine rettigheter og filtreringsbehov slik at jeg kan innhente uttrekket jeg trenger og har rett til. [rettigheter] )

(API-konsument (design time) - BFP012: Som API-konsument ønsker jeg varsel på endringer (push-varsel og toveiskommunikasjon) slik at jeg kan forberede tiltak. )

(Informasjonsforvaltning - effektivisere og samordne det offentlige Norges bruk av data)

( BFP011: Som API-konsument ønsker jeg et kontaktpunkt hos API-eier slik at man kan gi tilbakemelding og spørsmål. - API-konsumenter forvaltningen og proffesjonelle)

(Referansarkitektur - BTI002 Som API-tilbyder som sammenstiller data på vegne av f.eks. kommuner ønsker jeg at de større systemene og registrene skal tilby API-er slik at jeg enkelt kan få tilgang til dataene for å gjennomføre mitt oppdrag. )

(Veiledning - Beste praksis - dokumentasjon av API-er - 4. Som API-forvalter ønsker jeg råd og forslag til avtaler med konsumenter slik at jeg kan gjøre flere API-er tilgjengelige for eksterne (f.eks. innovatører) og er trygg på å ha et godt avtaleverk og slipper å gjøre grunnarbeidet med vilkår og avtale for bruk. )

(API-beskrivelsen - BFP013: Som API-konsument ønsker jeg en oversikt over tilgjengelige testmiljø for å teste ut apiene. )

(API-tilbyder - 6. Som API-forvalter ønsker jeg at de aktivitetene jeg må gjøre og de standardene jeg må forholde meg til for å gjøre API-dokumentasjonen tilgjengelig i en nasjonal API-katalog, også gir verdi for andre, kommersielle, internasjonale API-kataloger, f.eks. synliggjøring på søkemotorer, ref Schema.orgs arbeid med vokabular for WebAPI http://pending.webschemas.org/WebAPI )

(Standardisering - Grensesnitt API/mikrotjeneste - BA47. Som API-konsument ønsker jeg at API-ene jeg skal bruke er så like som mulig (men så forskjellige som nødvendig), slik at jeg ikke trenger sette meg inn i unødvendig mye nytt for hvert API jeg skal vurdere eller bruke. )

(Nasjonalt - Datasettkatalog GUI)

(API-konsumenter forvaltningen og proffesjonelle - BFP032: Som API-konsument ønsker jeg klar informasjon rundt lisensen på dataene APIet tilbyr for å raskt se om dette er forenlig med min bruk av dataene. )

(Difi - 10. Automatisering)

(API-beskrivelsen - BA29. Som API-konsument ønsker jeg informasjon om hvordan jeg kan skaffe meg tilgang til API-er som ikke er offentlig tilgjengelig. [Kommentar: manglar “slik at <forretningsverdi>”] )

(Personvern - API/mikrotjeneste - BA45. Som API-konsument ønsker jeg et API med gode muligheter for å filtrere data slik at jeg kan hente ut akkurat det utsnittet av datasettet som jeg trenger til mitt formål og slipper å gjøre ekstra prosessering av responsen jeg får fra API-et. )

(SMP (Service Metadata Publishing) (run time) - API-katalogen)

(API-beskrivelsen - BB15. Som API-konsument ønsker jeg at relevante opplysninger som ikke er tilgjengelig i API-et er omtalt i dokumentasjonen, slik at jeg kan bruke API-et riktig. [dokumentasjon] )

(Utvid API-beskrivelse - Administrasjon av API-beskrivelser (design time))

(API-beskrivelsen - 8. Som API-forvalter som tilbyr data som ikke er åpne ønsker jeg å synliggjøre testmiljø for mine API-er slik at de er lette å oppdage for brukerne )

(Offentlig virksomhet (Lokalt) - en datasett-katalog i virksomheten)

(API-beskrivelse - Informasjonsmodell)

((Behov for registrering av begreper) - Som ansvarlig virksomhet (begrepseier) ønsker jeg å kunne dele begreper med andre etter anbefalte standarder, slik at andre virksomheter (menneske og maskin) kan se begreper innenfor vårt domene. )

(Felles datakatalog portal (fellesdatakatalog.brreg.no) - Begrepskatalog API)

(API-tilbyder - 3. Som API-forvalter ønsker jeg at katalogen og dens underliggende spesifikasjoner og standarder gir krav jeg kan bruke i avtaler med leverandører/anskaffelser slik at jeg slipper å sette meg inn i hvilke krav jeg bør stille. )

(API-beskrivelsen - Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv)

(API-katalog - API-beskrivelse (OAS))

(Veiledning - Beste praksis - API/mikrotjeneste - BA12. Som API-konsument ønsker jeg å hente inn data uavhengig av dataenes egentlig form slik at den ikke endrer seg når dataformatet endres. )

(API-konsument (design time) - BB21. Som API-konsument ønsker jeg å kunne laste ned endringer i et datasett jeg allerede har en lokal kopi av slik at jeg effektivt kan vaske eget register basert på samme datakilde. [varsel] )

(Felles datasettkatalog API - Search Service)

(Andre komponenter - DCAT-AP-NO v2.0)

(API-katalog API - Registreringsapplikasjon API)

(Dataeier - BFDK09 - Som datasetteier for historiske (avleverte) data ønsker jeg å kunne koble de historiske datasettene med tilsvarende aktive/nåværende datasett, slik at jeg kan tilby brukerne en helhetlig tilgang til dataene.)

(Krav (EPOS og nødvendige krav) - Beskrive endepunkt (FDK-575))

(Difi - ID-porten)

(Access token - request)

(Melding uten gjenbruksmulig eller preutfylling - 213. Som tjenesteutvikler ønsker jeg at det er mulig å navigere mellom modelleringsvisning og skjemavisning mens jeg ut utvikler en tjeneste slik at jeg kan velge i hvilken visning jeg utfører en endring og hele tiden kan se hvordan endringen blir i begge visningene. )

(Kostnader - BFP026: Som profesjonell API-konsument ønsker jeg forutsigbare økonomiske og juridiske rammer rundt (helst åpen/gratis) tilgang til offentlig data slik at jeg kan lage gode business cases. )

(API-konsument (design time) - BFP026: Som profesjonell API-konsument ønsker jeg forutsigbare økonomiske og juridiske rammer rundt (helst åpen/gratis) tilgang til offentlig data slik at jeg kan lage gode business cases. )

(Datakatalogen - BTI010 Som API-tilbyder ønsker jeg å kunne se om andre tilbyr det samme eller nesten det samme som meg, så at det er mulig å harmonisere mellom “oss” [Livar: Case der det er fleire API-er som tilbyr det samme? Marit: Brreg og Skatt som har same datasett i FDK. Mathias: Felles studentsystem (FS) i UH-sektoren innheld personinformasjon. Kan ikkje konsoliderast med HR-data. Kan ikkje legge ned ein av dei. Dekker relasjonsfeltet i DCAT behovet?] )

(Undersøke, gjenfinne, få oversikt - Som fagansvarlig i prosjekt ønsker jeg å dokumentere og avgrense begrep på mitt område, slik at jeg unngår misforståelser når vi skal bygge ny løsning)

(en API-katalog i virksomheten - API Meta-data)

(Veiledning - Beste praksis - API/mikrotjeneste - BB32. Som API-konsument (datajournalist) ønsker jeg at strukturen i datasettene er stabile, slik at jeg ikke trenger gjøre endringer i min integrasjon/kode når nye versjoner hentes. [forutsigbarhet] )

(Som API-konsument ønsker jeg oversikt over testmiljø og syntetiske data slik at jeg kan teste ut API-ene - BFP016: Som API-konsument ønsker jeg en oversikt over hvilke versjoner som er tilgjengelig i hvilke miljø slik at jeg vet hva jeg kan teste mot. (prod og test) )

(FDK - Publish/Subscribe Service)

(BFDK10 - Som konsument ønsker jeg å få en liste over de datasett jeg vil ha tilgang til, presentert med grunnleggende informasjon om API slik at jeg sammenligne egenskaper (for eksempel hvilken protokoll som er brukt) ved API-ene - FDK)

( BTI008 Som konsument av data fra offentlige virksomheter ønsker jeg at de offentlige virksomhetene inngår avtaler med sine leverandører som gjør det tydelig hvem som eier dataene, og stiller krav til at de skal være gjøres tilgjengelige uten kostnader, slik at ikke den offentlige virksomheten hindres i å dele sine data med meg som følge av at kostnadene blir for store. - API-tilbyder/private grossister)

(Brønnøysundregistrene - Grensesnitt)

request (En konsument applikasjon - API-et)

(Node - Monitorering)

(API-konsumenter forvaltningen og proffesjonelle - BFP014: Som API-konsument ønsker jeg oversikt over tilgjengelige referanseimplementasjoner slik at jeg raskere kan komme i gang med å bruke apiene. )

(Enterprise Architects - Domain Architects)

(API-beskrivelsen - BA3. Som API-konsument ønsker jeg at det pekes til gode landingssider for API-et slik at jeg raskt settes i stand til å ta det i bruk.)

(Mikrotjenesten/API-et - Som sluttbruker ønsker jeg at en privat virksomhet skal ha tilgang til data om meg fra en tredjepart (app) slik at jeg kan slippe å tiljgengeliggjøre dataene selv)

( Fra BRREGs arbeid: Registrere seg som Über-sjåfør (dokumentere førerkort) - Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv)

(Bruk - Som kvalitetsansvarlig for et domene ønsker jeg å hente ut statistikk på søk etter mine begreper?)

((Behov for begreper i FDK søkeløsning) - Etatene skal beskrive sin tolkning av begreper i lovverk, forvaltningsstandarder og forvaltningspraksis i egen begrepskatalog. Begrepsbeskrivelsene skal bl.a. legge til rette for at opplysningene i datasettene kan beskrives eksplisitt, f.eks. hva inngår i “likningsverdi”. Begrepsbeskrivelsene skal være tilgjengelige slik at regelverksutvikling og digitaliseringsprosjekter kan identifisere forenklinger. )

(Nasjonalt - API-katalog)

(Implementation Projects - Implement)

(Access token - Delegering)

GET /endoints?type=API (FDK-høsting ADM - data.norge.no API-høster)

(API-konsument (design time) - BA1. Som API-konsument (student) ønsker jeg å filtrere på dataformater i oversikter over (åpne) API-er slik at jeg kan finne API-er i det formatet jeg ønsker å lære mer om eller filtrere ut de jeg ikke kan noe om.)

(Mikrotjenesten/API-et - BA16. Som API-konsument ønsker jeg at API-et tåler stor trafikk slik at jeg kan bruke API-et direkte i applikasjon)

(register scope - Angi grovkonet tilgang)

(BA24. Som API-konsument ønsker jeg, når jeg får en respons fra et datasett, en henvisning til arkiverte versjoner av “det samme” datasettet (med elementer som ikke lenger finnes i det løpende datasettet), slik at jeg kan gi en mer komplett respons til brukeren. - Studenter, gründere og app-utviklere)

(REST GET Datasettkatalog - Søk og oppslag datasett)

(Fagterminologibaser - Begrepskatalog API)

(Begrepsbeskrivelse - Som forvalter av registreringsløsning ønsker jeg å kunne endre felter som skal fylles ut, slik at jeg kan være konform med standard for begrepsbeskrivelser)

(API-tilbyder - 23. Som API-forvalter ønsker jeg at de API-ene jeg tilbyr skal være lette å finne og ta i bruk for de som har verdi av dem, slik at innsatsen jeg har lagt ned i API-ene får størst mulig verdi [forsvare kostnadene ved utviklingen/forvaltningen av API-ene/generere størst mulig nytte] )

(Tilgangsstyring - /login)

(Register - Register)

(Etat - "Min Side")

(Melding uten gjenbruksmulig eller preutfylling - 203. Som tjenesteeier ønsker jeg å kunne gi en modell en status slik at det er tydelig hvor modellen er i sitt livsløp og dermed også hvilken kvalitet modellen sannsynligvis har. )

(API-tilbyder - Som API-eier ønsker jeg å kunne beskrive et API som ikke nødvendigvis kan knyttes til et datasett, slik at også dynamiske tjenester kan synliggjøres for andre konsumenter. )

(Mikrotjenesten/API-et - BFP019: Som API-konsument ønsker jeg at apiene inneholder referanser til begrepene som er brukt i apiene slik at jeg forstår detaljene og bruker dataene korrekt. )

(Offentlig Virksomhet - en API-katalog i virksomheten)

(Begrepsbeskrivelse - Som begrepseier ønsker jeg tilgang til å redigere begrepsinnhold, også etter at begrepet er publisert, slik at jeg kan forvalte begreper og ta høyde for at omverden eller forutsetninger, rammer og krav endrer seg)

(Som API-forvalter ønsker jeg at det med API-beskrivelsen følger en veileder slik at jeg kan følge beste praksis - BA40. Som API-tilbyder* ønsker jeg retningslinjer og beste praksis for dokumentasjon av API-ene mine slik at jeg kan dokumentere så effektivt og bra som mulig. )

(Som API-konsument ønsker jeg å se request og respons på et API slik at jeg kan planlegge design - BFDK06 - Som arkitekt ønsker jeg å se hvilke data jeg må benytte for å gjøre oppslag mot et API og hvilke data jeg får tilbake slik at jeg kan planlegge design av løsning. )

(Informasjonsmodell - Representation)

(Som API-konsument ønsker jeg å få tekstlig beskrivelse av et API slik at jeg kan forstå hvordan jeg skal bruke et API - BFP009: Som API-konsument ønsker jeg å få dokumentere hvordan en kan oppdatere en egen kopi slik at en til hver tid bruker korrekte data. )

(API-konsument (design time) - BA29. Som API-konsument ønsker jeg informasjon om hvordan jeg kan skaffe meg tilgang til API-er som ikke er offentlig tilgjengelig. [Kommentar: manglar “slik at <forretningsverdi>”] )

( BTI010 Som API-tilbyder ønsker jeg å kunne se om andre tilbyr det samme eller nesten det samme som meg, så at det er mulig å harmonisere mellom “oss” [Livar: Case der det er fleire API-er som tilbyr det samme? Marit: Brreg og Skatt som har same datasett i FDK. Mathias: Felles studentsystem (FS) i UH-sektoren innheld personinformasjon. Kan ikkje konsoliderast med HR-data. Kan ikkje legge ned ein av dei. Dekker relasjonsfeltet i DCAT behovet?] - API-tilbyder/private grossister)

(Felles rammeverk - BB31. Som API-konsument ønsker jeg at datasett som er gjort tilgjengelig for nedlasting har et forutsigbart URL-regime for siste versjon og historiske data slik at nedlasting kan automatiseres. [nedlasting, forutsigbarhet] )

(Som API-konsument ønsker jeg referanser til dokumentasjon som ikke beskrives i API-beskrivelsen slik at jeg kan nøste meg videre - BA23. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg får tilgang til FAQ om API-et. [Kommentar: manglar “slik at <forretningsverdi>”] )

(Åpne data statistikk, datajournalistikk og stordata - BB20. Som API-konsument ønsker jeg eksempel på bruk av dataene som en del av dokumentasjonen av API-et, slik at de er enklere å fortså og ta i bruk [dokumentasjon] )

( BB27. Som API-konsument ønsker jeg å kunne laste ned en komplett versjon av datasettet i tillegg til API-funksjonalitet slik at jeg kan kjøre analyse på en lokal kopi av datasettet der dette er mest hensiktsmessig.[nedlasting] - Åpne data statistikk, datajournalistikk og stordata)

(API-konsument (design time) - BA43. Som API-konsument ønsker jeg å bli varslet om at et API er “deprecated” (skal tas ut av bruk), slik at jeg kan oppdatere min applikasjon. )

(26. Som API-forvalter ønsker jeg at opplysninger som er relevante for datakatalogen og som finnes i API-et (feks “sist oppdatert”), høstes til datakatalogen slik at datasettbeskrivelsen er så god som mulig. - API-forvalter og API katalogeier)

(Nasjonalt - data.norge.no API)

(8. Som API-forvalter som tilbyr data som ikke er åpne ønsker jeg å synliggjøre testmiljø for mine API-er slik at de er lette å oppdage for brukerne - API-forvalter og API katalogeier)

levert av (Leverandør - En konsument applikasjon)

(Harvester-API - Harvester Service)

(API-tilbyder - 25. Som API-forvalter som forvalter API-er til autoritative data ønsker jeg at API-katalogen skal prioritere presentasjon av mine API-er fremfor API-er som tilbyr samme data, men fra ikke-autoritative kilder, slik at API-brukerne ikke ubevisst bruker ikke-autoritative data )

(API-konsument (design time) - BA34. Som API-konsument ønsker jeg at eventuelle krav til API-nøkler etc lar seg løse raskt/selvbetjent slik at jeg kan komme i gang raskt. [f.eks. autorisering basert på eksisterende mekanismer fremfor å måtte kontakte forvalter og vente på svar (ID-porten, Altinn), bruksvilkår fremfor avtaler] )

(Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer - BA42. Som API-konsument ønsker jeg varsler om “breaking changes” slik at jeg kan gjøre de nødvendige endringene før de brekker mine systemer/applikasjoner også. [f.eks. ved registrere e-postadresse] )

(Skatteetaten - Som API-forvalter/API-Management ansvarlig ønsker jeg en enkel måte å kommunisere informasjon rettet til enkeltbrukere av tjenester)

(Nasjonalt - Registreringsløsning begrep)

(rov:Entity - Business)

(EPOS 2: Som API-forvalter ønsker jeg å registrere mine API-er slik at de kan gjøres tilgjengelig for andre - Som API-forvalter ønsker jeg at API-katalog kan plukke opp min swagger dokumentasjon slik at jeg kan benytte dette verktøyet)

(API-katalogen - EPOS 4: Som API-konsument ønsker jeg å finne detaljert beskrivelse av API-ene slik at jeg kan vurdere om jeg kan benytte API-et i mine tjenester)

(Datasettkatalog - REST GET Datasettkatalog)

(EPOS 4: Som API-konsument ønsker jeg å finne detaljert beskrivelse av API-ene slik at jeg kan vurdere om jeg kan benytte API-et i mine tjenester - Som API-konsument ønsker jeg at distribusjoner av samme (eller geografisk komplementære) datasett fra ulike tilbydere eller er samlet under et datasett)

(API-konsument (design time) - BFP009: Som API-konsument ønsker jeg å få dokumentere hvordan en kan oppdatere en egen kopi slik at en til hver tid bruker korrekte data. )

(API-beskrivelsen - Som API-konsument ønsker jeg å forstå om API-et er tilrettelagt for bruk med brukers samtykke eller fullmakt)

(API-katalog - Datasettkatalog)

(Felleskomponent - API-katalog API)

(OASIS SMP protokoll - Addresseringstjeneste - Capability lookup (OASIS SMP))

(Felles rammeverk - BB27. Som API-konsument ønsker jeg å kunne laste ned en komplett versjon av datasettet i tillegg til API-funksjonalitet slik at jeg kan kjøre analyse på en lokal kopi av datasettet der dette er mest hensiktsmessig.[nedlasting] )

(Mikrotjenesten/API-et - BB3. Som API-konsument ønsker jeg å gjøre spørringer som gir meg dataene jeg har rettighet til å få (og ikke blir blokkert tilgang fordi API-et bare gir tilgang til mer data enn jeg har rettigheter til), slik at jeg kan få tilgang til data [rettigheter] )

(API-konsument (design time) - BA24. Som API-konsument ønsker jeg, når jeg får en respons fra et datasett, en henvisning til arkiverte versjoner av “det samme” datasettet (med elementer som ikke lenger finnes i det løpende datasettet), slik at jeg kan gi en mer komplett respons til brukeren. )

(Felles rammeverk - Personvern - API/mikrotjeneste)

(Som API-forvalter ønsker jeg at mine API-beskrivelser følger et standard med veiledning og verktøystøtte slik at det er enkelt for brukerne og jeg kan redusere mine forvaltningskostnader og henvendelser - Det er behov for enkel tilgang til data av god kvalitet, og som er beskrevet på en standardisert måte )

(Felles rammeverk - BB30. Som API-konsument ønsker jeg å slippe å ha en kopi av xxregistreret eller datasettet slik at jeg kan være sikker på at dataene er oppdaterte. [tjenestenivå] )

(BFP019: Som API-konsument ønsker jeg at apiene inneholder referanser til begrepene som er brukt i apiene slik at jeg forstår detaljene og bruker dataene korrekt. - API-konsumenter forvaltningen og proffesjonelle)

(API-katalogen - BFDK04 - Som forretningsutvikler ønsker jeg å filtrere på datasett som har API, slik at jeg bedre treff på mine søk i katalogen. )

(Enhetsregisteret API - kommunenummer)

(API Meta-data - Betaling)

(Felles rammeverk - BA8. Som API-konsument ønsker jeg mulighet til enkelt å teste API-ene (utforske) f.eks. gjennom Swagger eller tilsvarende, slik at jeg raskere forstår API-et, og raskere klarer å bruke det (riktig) [ref BA7].)

(Som API-konsument ønsker jeg at rettslige rammer og lisens er tydelig beskrevet slik at jeg kan vurdere om det er forenelig med min bruk av dataene - BFP032: Som API-konsument ønsker jeg klar informasjon rundt lisensen på dataene APIet tilbyr for å raskt se om dette er forenlig med min bruk av dataene. )

(Som API-konsument ønsker jeg at dokumentasjonen er genererert fra kode slik at jeg kan stole på at den er oppdatert - BB18. Som API-konsument ønsker jeg at kildekoden til API-tjenesten er tilgjengelig som åpen kildekode, slik at jeg kan lese kildekode for å forstå APIet og kunne bruke det optimalt [dokumentasjon] )

(Som API-konsument ønsker jeg kunnskapsbase (f.eks. FAQ funksjonalitet) slik at jeg som bruker kan få svar på kjente utfordringer og ikke behøver å bruke tid på henvendelser - 10. Som en API-forvalter ønsker jeg å kunne ha “FAQ-funksjonalitet” (eller kunnskapsbase), slik at brukerne mine lettere kan få tak i svar på kjente utfordringer og jeg kan redusere kostnader ved å håndtere brukerhenvendelser. )

(API-tilbyder/private grossister - BTI011 Som API-tilbyder/privat grossist (som er databehandler for innrapportering og tilgjengeliggjøring av informasjon), ønsker jeg at det finnes et forum / nettverk der dataeiere og databrukere utarbeider gode krav til tilgjengeliggjøring og tilbakerapportering av aggregert informasjon. )

Harvesting (en begrepskatalog i virksomheten - concept-cat-harvester)

(Referansarkitektur - BTI007 Som konsument av data fra kommunene ønsker jeg at kommunene tilbyr felles API for den samme informasjonen, uavhengig av hvilket fagsystem/hvilke leverandører de bruker for å forvalte informasjonen, slik at integrasjonen jeg utvikler mot én kommune kan gjenbrukes mot de resterende ca 400 kommunene. )

( BAM04 - Som leverandør av API-management-verktøy ønsker jeg at jeg å kunne tilby automatisk integrasjon med den felles API-katalogen slik at jeg kan selge mer av produktet mitt ved å vise til at det støtter opp under de nasjonale føringene. - API-management)

(An external service - An external service)

(Definisjon - Begrep)

(Nasjonalt - KOR)

(Felles rammeverk - Premissgiver - Tilgjengelighetskrav API-er til grunndata)

(API-katalogen - MyData, viderebruk av personopplysninger )

(Felles rammeverk - BA33. Som API-konsument ønsker jeg at det er så få tekniske sperrer på API-ene som mulig slik at jeg kan ta det i bruk med minst mulig “prosess” mot API-forvalteren )

(Mikrotjenesten/API-et - BA24. Som API-konsument ønsker jeg, når jeg får en respons fra et datasett, en henvisning til arkiverte versjoner av “det samme” datasettet (med elementer som ikke lenger finnes i det løpende datasettet), slik at jeg kan gi en mer komplett respons til brukeren. )

(BFP028: Som API-konsument ønsker jeg at API-et i større grad er “selvbeskrivende” og, dersom det brukes interne koder, at betydningen/forklaringen på disse er enkelt tilgjengelig, slik at jeg forstår hvordan jeg skal bruke API-et. - API-konsumenter forvaltningen og proffesjonelle)

(Altinn data modellering - 210. Som tjenesteutvikler ønsker jeg at tjenestens modell også blir oppdatert når jeg fjerner et felt i skjemaklienten, slik at modellen og brukergrensesnittet hele tiden er gjensidig oppdatert.)

(API-konsument (design time) - BA55. Som API-konsument, ønsker jeg at API-et er designet etter en felles “beste praksis” som gjelder for API-er i API-katalogen, slik at jeg lett kjenner meg igjen på tvers av API-ene i katalogen.)

(Som dataeier ønsker jeg at relevante opplysninger fra API-beskrivelsen er tilgjengelig i datasettbeskrivelsen slik at jeg unngår dobbeltarbeid - 26. Som API-forvalter ønsker jeg at opplysninger som er relevante for datakatalogen og som finnes i API-et (feks “sist oppdatert”), høstes til datakatalogen slik at datasettbeskrivelsen er så god som mulig. )

(Mikrotjenesten/API-et - BFP010: Som API-konsument ønsker jeg å bare lese endringer som er gjort på siste oppdatering slik at vi slipper å lese hele datasettet. )

(Felles rammeverk - BA11. Som API-konsument ønsker jeg at jeg kan bytte til nye versjoner av API-et når det passer meg [Kommentar frå Livar: Litt usikker på denne. Her er det kanskje snakk om versjonering av API, at ein sjølv kan velje når tid ein byttar til ny versjon av API? I motsetnad til at eit API ikkje er versjonert og ved "breaking-changes" så må ein forholde seg til når API-et gjer eit brått hopp til ny versjon?] )

(API-beskrivelsen - BFP030: Som API-konsument ønsker jeg å kunne spørre produsent om mer og bedre data slik at vi kan tilby et bedre og mer helhetlig bilde. )

(API-tilbyder - 18. Som API-forvalter ønsker jeg oversikt over integrasjoner mot mine API-er slik at konsekvenser og kostnader ved endringer kan forutses og minimeres. )

(Tilgangsstyring - Informasjonsmodell-katalog GUI)

(en API-katalog i virksomheten - Registreringsapplikasjon API)

(Felles datakatalog portal (fellesdatakatalog.brreg.no) - API-katalog)

(BFDK01 - Som forretningsutvikler ønsker jeg å se hvilke datasett som tilbyr API, slik at jeg kan vurdere om det kan brukes i mine tjenester. - FDK)

(API-katalogen - Data.norge.no)

(API-katalog - data.norge.no portal)

(BTI009 Som konsument av offentlig data ønsker jeg en koordinert forvaltning av offentlig master data slik at jeg kan utvikle anvendelser/analyser med forutsigbar kvalitet og fornuftige økonomiske og juridiske betingelser. - API-tilbyder/private grossister)

(API-katalog - data.norge.no API-høster)

(API-katalogen - API-beskrivelse)

( BFP007: Som API-konsument ønsker jeg god og forutsigbar ytelse slik at det er lett å velge bruk av rett API som samsvarer med krav til andre API som inngår i tjenesten/prosessen - API-konsumenter forvaltningen og proffesjonelle)

(Lokal registreringsløsning - Som datasetteier ønsker jeg å registrere våre datasett i Lokal datakatalog i henhold til DCAT slik at jeg kan dele dem i felles datakatalog.)

(Registreringsapplikasjon API - API-tilbyder)

(Begrepsbeskrivelse - Som begrepseier ønsker jeg å dele begrepsinnholdet mitt inn i gitte felter, slik at jeg kan beskrive begrep i tråd med anbefalte standarder)

(Altinn tjenestekatalog - Tjenestekatalog)

(Felles datasettkatalog portal - Datasett Registrering)

(API-tilbyder - API-tilbyder)

(Som befolkning i et område vil vi gi bevegelsesinformasjon (fra telefon, gpx, google location history osv.) til en kommune for bedre planlegging av a) utbygging av sykkel/turveier b) vedlikehold c) øvrig kommunale tjenester. - MyData, viderebruk av personopplysninger )

(API-katalogen - Som API-konsument ønsker jeg å kunne sammenlikne API slik at jeg kan vurdere om et API passer bedre enn et annet)

(Mikrotjenesten/API-et - BFP007: Som API-konsument ønsker jeg god og forutsigbar ytelse slik at det er lett å velge bruk av rett API som samsvarer med krav til andre API som inngår i tjenesten/prosessen )

(API-katalogen - 9. Som API-forvalter ønsker jeg en felles løsning for API-dokumentasjon som er så god at jeg selv ønsker å bruke løsningen fremfor andre verktøy )

(Altinn Studio (Tjeneste 3.0) - Modelleringsklient)

(Nasjonalt - Enhetsregisteret)

(CIO/CTO - Deploy)

(Som API-eier ønsker jeg å kunne beskrive funksjonaliteten i API-et på en overordnet måte slik at brukere får et innblikk i hva API-et innholder. - Informasjonsforvaltning fagmiljø)

(Offentlig Virksomhet - Lokal datasett registreringsløsning)

(Entity Registry API - Administrative borders API)

(en tjenestekatalog i virksomheten - data.norge.no tjenestehøsting)

(API-beskrivelsen - EPOS 9: Som API-konsument ønsker jeg oversikt over hvem som bruker et API slik at jeg kan forstå det bedre )

(Modelleringsforum - Som informasjonsarkitekt ønsker jeg retningslinjer for modellering av strukturmodeller i UML som begrenser utrykksevnen slik at jeg kan realisere modellene i ulike formater og språk)

(API-beskrivelsen - EPOS 7: Som API-konsuement ønsker jeg å forstå hvordan endringer varsles slik at jeg kan fange opp endringer)

(Designer Backend - Skjema API)

(API-konsument (design time) - BA21. Som API-konsument ønsker jeg et API som gir godt strukturerte responser slik at data er lett å bruke. )

(Som API-konsument ønsker jeg at datasett som er relatert til hverandre vises sammen slik at jeg kan få et helhetlig bilde av et fenomen - BB10. Som API-konsument ønsker jeg mulighet til å innhente data om tekstdatasett slik at jeg kan lage analyser av disse og koble til andre kilde. [tekst som data] )

(Felles - Felles datakatalog portal (fellesdatakatalog.brreg.no))

(Studenter, gründere og app-utviklere - BA23. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg får tilgang til FAQ om API-et. [Kommentar: manglar “slik at <forretningsverdi>”] )

(API-beskrivelsen - BA35. Som API-konsument ønsker jeg at det er tydelig hva som er de rettslige rammene for bruk av API-ene slik at jeg kan være sikker på at jeg ikke kan få krav mot meg senere, f.eks. NLOD. )

(Felles rammeverk - BA48. Som API-konsument ønsker jeg at API-ene jeg bruker tilbyr komplett nedlasting av datasett slik at jeg kan bearbeide data lokalt. )

(Registration-BACKEND - Registration Service)

(EPOS 6: Som API-forvalter ønsker jeg at API-beskrivelsen er tilgjengeliggjort fra API-katalog slik at de kan benyttes i andre sammenhenger og at jeg unngår å måtte beskrive API-er flere steder - Som dataeier ønsker jeg at relevante opplysninger fra API-beskrivelsen er tilgjengelig i datasettbeskrivelsen slik at jeg unngår dobbeltarbeid)

(Felles rammeverk - BA46. Som API-konsument ønsker jeg mulighet for å bruke filtre i API-et slik at jeg kan ha bedre kontroll med hvilket utvalg av data jeg mottar, og ikke er avhengig av hvilke utvalg API-forvalteren har definert. )

(SSB - dei ulike etatane som eig kvar sine kodeverkssystem må tilgjengeleggjere desse for omverda og sjølve sørgje for å bruke dei andre etatane sine system ved behov, slik at eitt og same kodeverk berre ligg ein plass)

(Mikrotjenesten/API-et - BB21. Som API-konsument ønsker jeg å kunne laste ned endringer i et datasett jeg allerede har en lokal kopi av slik at jeg effektivt kan vaske eget register basert på samme datakilde. [varsel] )

(Altinn Autorisasjon - create delegation)

(Oppgaveregisteret - Tjenestekatalog)

(4. Som API-forvalter ønsker jeg råd og forslag til avtaler med konsumenter slik at jeg kan gjøre flere API-er tilgjengelige for eksterne (f.eks. innovatører) og er trygg på å ha et godt avtaleverk og slipper å gjøre grunnarbeidet med vilkår og avtale for bruk. - API-forvalter og API katalogeier)

(Offentlig Virksomhet - Frittstående API-beskrivelser)

(Begrepsbeskrivelse - Som ansvarlig virksomhet (begrepseier) ønsker jeg å kunne dele begreper med andre etter anbefalte standarder, slik at andre virksomheter (menneske og maskin) kan se begreper innenfor vårt domene. )

(Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier. - Som API-forvalter ønsker jeg å kunne motta strukturerte tilbakemeldinger (f.eks. feil) og endringsforslag for mine tjenester slik at tjenestene kan forbedres)

(Ferdig søketjeneste API - Som API-konsument ønsker jeg dialog med andre API-konsumenter og API-tilbydere slik at vi få hjelp og hjelpe hverandre)

(API-beskrivelsen - Som konsument av API ønsker jeg informasjon om kostnader og trafikkbegrensninger for bruk av API-et slik at jeg kan ha forutsigbare rammer for min bruk av dataene.)

(Register - Register API)

(Som tjenesteeier og data scientist ønsker jeg å vite om et datasett er uferdig eller ufulstendig slik at jeg kan vurdere om jeg kan bruke det - 8. Kjente feil og mangler)

(Contract - )

(Kartverket - Kommune)

( BB14. Som API-konsument ønsker jeg standardavtaler for både vilkår for bruk av data og tjeneste slik at jeg vet hvilke vilkår og tjenestenivå jeg har å forholde meg til. [databehandleravtaler, SLA] - Åpne data statistikk, datajournalistikk og stordata)

(“Den registrerte/subjektet” - Jeg ønsker å få kontinuerlig økonomisk og rettslig rådgivning fra “velferdsrådgiverne A/S”, slik at de kan identifisere hvilke offentlige tjenester jeg har rett på, evt anbefale meg å jobbe litt mindre slik at jeg kommer under inntektsgrenser som igjen trigger nye utbetalinger -- jobbe mindre og tjene mere! )

(3. Som API-forvalter ønsker jeg at katalogen og dens underliggende spesifikasjoner og standarder gir krav jeg kan bruke i avtaler med leverandører/anskaffelser slik at jeg slipper å sette meg inn i hvilke krav jeg bør stille. - API-forvalter og API katalogeier)

(???? - )

(API-beskrivelsen - Som API-konsuement ønsker jeg en tematisk oversikt over API slik at jeg lett kan finne fram)

(API-konsument (design time) - BFP018: Som API-konsument ønsker jeg at apiene inneholder referanser til lokale kodeverk som forklarer innholdet i apiene slik at jeg forstår detaljene i apiene. )

(23. Som API-forvalter ønsker jeg at de API-ene jeg tilbyr skal være lette å finne og ta i bruk for de som har verdi av dem, slik at innsatsen jeg har lagt ned i API-ene får størst mulig verdi [forsvare kostnadene ved utviklingen/forvaltningen av API-ene/generere størst mulig nytte] - API-forvalter og API katalogeier)

(Grensesnitt - Produkt)

(Registerenhet i Belgia - Organization)

(Difi - 4. Mer detaljering av type data)

(API-konsument (design time) - BA23. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg får tilgang til FAQ om API-et. [Kommentar: manglar “slik at <forretningsverdi>”] )

(API-konsument (design time) - BFDK11 - Som konsument ønsker jeg å abonnere på varslinger om etablering, endring, driftsstans og avvikling av API’er slik at jeg kan tilpasse meg endringer)

(Lenkede data - Kommune)

(Dataeier - BFDK07 - Som datasetteier (og som beskriver datasett i datakatalogen) ønsker jeg å kunne kople beskrivelser av APIer (i flertall) til et gitt datasett, slik at jeg kan vise hvilke distribusjoner som finnes av et datasett )

(REST GET API-katalog - API-katalog)

(API-katalogen - EPOS 5: Som API-konsument ønsker jeg dialog med andre API-konsumenter og API-tilbydere slik at vi få hjelp og hjelpe hverandre)

(Krav (EPOS og nødvendige krav) - Som API-forvalter ønsker jeg å registrere mine API-er slik at de kan gjøres tilgjengelig for andre)

(Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier. - 20. Som API-forvalter ønsker jeg at brukerne av mitt API skal ha en åpen kommunikasjon med meg og hverandre om hvilke behov de har som ikke er dekket i dag, slik at min videreutvikling treffer flest mulig brukere på en tilstrekkelig måte.)

(Felles rammeverk - Premissgiver - styring dokumentasjon av API-er)

(FDK - FDK-høsting ADM)

(API-tilbyder - 33. Som API-forvalter ønsker jeg at man tilbyr ei løsning/det blir spesifisert hvordan man skal tilby API på samme format.)

(API-katalogen - Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API)

(Begrepskatalog API - REST GET Begrepskatalog)

(Difi - 13. Valg for ferdig/uferdig/midlertidig/ufullstendig )

(CIO/CTO - Develop)

Monitoring (Service Management - Operational Systems)

(Lokal datasett registreringsløsning - 3-1 Som leder ønsker jeg å administrere tilganger til registreringsløsning for Lokal datakatalog slik at jeg ivaretar tilgangsrettighetersikkerhet og personvern)

(Lokal registreringsløsning - Som dataeier ønsker jeg å skille mellom datasettbeskrivelser som skal tilgjengeliggjøres i Felles datakatalog og dem som kun skal være tilgjengelig i Lokal datakatalog, slik at vi kun deler med Felles datakatalog den omtalen (feltene) om datasett vi ønsker å dele.)

(Tjeneste med informasjonsbehov - En tjeneste)

(API-beskrivelse (OAS) - API Meta-data)

(API-konsumenter forvaltningen og proffesjonelle - BFP002: Som API-konsument ønsker jeg enhetlig dokumentasjon og mulighet til “kundeservice” fra tjenesteleverandør. )

(Registry in Belgium - OrganizationAPI)

(Veiledning - Beste praksis - API/mikrotjeneste - BB33. Som API-konsument ønsker jeg å kunne laste ned kun endringer i et datasett for å oppdatere min lokale kopi av et datasett slik at jeg slipper å laste ned hele datasettet på nytt og import-jobben blir mindre. [varsel] )

(Felles datakatalog portal (fellesdatakatalog.brreg.no) - REST GET API-katalog)

(Felles datakatalog portal (fellesdatakatalog.brreg.no) - Datasettkatalog)

( BB11. Som API-konsument (analytiker) ønsker jeg mulighet for å legg inn spørsmål, tips, eksempler knyttet til APIer slik at jeg kan øke min egen, andre brukere og api-forvalternes kjennskap om semantikk, selve APIen og bruk [økosystem] - Åpne data statistikk, datajournalistikk og stordata)

(Som API-forvalter ønsker jeg en godt dokumentert felles løsning for registering av API-beskrivelser slik at jeg slipper å installere egne verktøy. - Som utvikler i Altinn ønsker jeg å kunne registrere de API jeg utvikler for mine T.3 applikasjoner slik at <hensikt>)

(API-beskrivelsen - BFP016: Som API-konsument ønsker jeg en oversikt over hvilke versjoner som er tilgjengelig i hvilke miljø slik at jeg vet hva jeg kan teste mot. (prod og test) )

(Som API-konsument ønsker API-beskrivelsen refererer til begreper slik at jeg kan forstå innholdet i API-et - BA5. Som API-konsument ønsker jeg at alle begreper linker direkte til en forklaring av begrepet slik at jeg slipper å lete gjennom dokumentasjonen. [kommentar: forskjell på begrep i den tekniske dokumentasjonen (f.eks. parameter i forespørsel) vs. begrep i datasettet (f.eks. fagtermer)] )

(Seksjon for informasjonsforvaltning - Kompetanse om modellering)

(29. Som API-katalogeier med en eksisterende API-dokumentasjon ønsker jeg å bruke eksisterende API-dokumentasjon slik at jeg slipper å vedlikeholde API-dokumentasjon (manuelt) flere steder. - API-forvalter og API katalogeier)

(EPOS 2: Som API-konsument ønsker jeg en grunnleggende informasjon om API-et som er oppdatert og forståelig lsik at jeg kan ta API-et i bruk - Som API-konsuement ønsker jeg en tematisk oversikt over API slik at jeg lett kan finne fram)

(Referansedata - Begrepskatalog GUI)

(Open Accounting API - organisation number)

(API-konsument (design time) - BFP023: Som API-konsument ønsker jeg å se hvilken SLA som er forbundet med API et slik at jeg kan vurdere om det tilfredsstiller mine krav for bruk. )

(Mikrotjenesten/API-et - BB31. Som API-konsument ønsker jeg at datasett som er gjort tilgjengelig for nedlasting har et forutsigbart URL-regime for siste versjon og historiske data slik at nedlasting kan automatiseres. [nedlasting, forutsigbarhet] )

(Frittstående API-beskrivelser - API-tilbyder)

(Mikrotjenesten/API-et - BB29. Som API-konsument ønsker jeg en god mekanisme for å få beskjed om endringer i API eller dataformat (f.eks. ikke-brytende-endring som nye felt i dataformatet) slik at jeg kan tilpasse konsum av data når dataformatet blir endret eller utvidet.[varsel] )

(14. Som API-forvalter/eier ønsker jeg en ensartet og samlet API-katalog slik at det blir enklere å publisere informasjonen. - API-forvalter og API katalogeier)

( BB6. Som API-konsument ønsker jeg at semantikken rundt dataene er forklart (dataene er definert), slik at jeg kan ta et informert valg om å bruke dataene fordi jeg forstår kontekst, formål og omfanget av dem. [dokumentasjon] - Åpne data statistikk, datajournalistikk og stordata)

(Felles rammeverk - BFP026: Som profesjonell API-konsument ønsker jeg forutsigbare økonomiske og juridiske rammer rundt (helst åpen/gratis) tilgang til offentlig data slik at jeg kan lage gode business cases. )

(Felles rammeverk - BA2. Som API-konsument ønsker jeg umiddelbar tilgang (slipper å vente på manuell tildeling av API-nøkler og tokens) til data (eller testdata) slik at jeg kan vurdere og eventuelt ta i bruk API-et umiddelbart.)

(DCAT-AP-NO v 2.0 - )

(FDK - FDK API-høster API)

(en datasett-katalog i virksomheten - En lokal datasettkatalog med virksomhetsintern informasjon, til bruk for “orden i eget hus”, GDPR, statistikk etc og som er grunnlaget for informasjonen som synliggjøres i felles datakatalog )

(Som API-konsument ønsker jeg informasjon om tilgang til dataene (tilgangsnivå) slik at jeg kan forstå hvordan jeg skal ta det i bruk - BB7. Som API-konsument ønsker jeg at det angis tydelig i dokumentasjonen hvilke data som er tilgjengelig, men også hva som ikke er tilgjengelig, slik at jeg slipper merarbeid pga. uklar dokumentasjon. [dokumentasjon] )

(API-konsument (design time) - BFP032: Som API-konsument ønsker jeg klar informasjon rundt lisensen på dataene APIet tilbyr for å raskt se om dette er forenlig med min bruk av dataene. )

(Som API-forvalter ønsker jeg at mine API-beskrivelser følger et standard med veiledning og verktøystøtte slik at det er enkelt for brukerne og jeg kan redusere mine forvaltningskostnader og henvendelser - BTI005 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å sikre at det blir enkelt å ta API’ene i bruk slik at vi bidrar til forenkling og samordning )

(Felles rammeverk - BA15. Som API-konsument ønsker jeg at alt jeg er avhengig av for applikasjonen min er tilgjengelig fra samme server, inklusive kodeverk, slik at CORS opprettholdes. )

(TBX - Begrep)

(API-mangement verktøyleverandør - BAM03 - Som ansvarlig for API-management ønsker jeg å notifisere endringer i mine API til dem som benytter API-ene slik at man ikke bryter kontrakter )

(Krav (EPOS og nødvendige krav) - Som virksomhet ønsker jeg en egen oversikt for intern bruk over datasett slik at...)

(Hent alle API-beskrivesler - API-katalog)

(BA49. Som API-konsument ønsker jeg ikke å tvinges til å bruke API-er der hvor det aller enkleste for meg ville vært å få lastet ned hele datasettet. [kommentar: ønskjer i alle fall anledning til å velje] - Studenter, gründere og app-utviklere)

(/login - Datasettkatalog GUI)

(API-beskrivelsen - BAM09 - Som ansvarlig for API-management ønsker jeg å kunne administrere nøkler gitt til de enkelte konsumentene slik at jeg enkelt kan fjerne ev. misbruk av API-et )

(Utfyllt skjema - )

(Altinn data modellering - 214. Som tjenesteutvikler ønsker jeg muligheten til å maskinelt validere en modell slik at jeg raskt og enkelt kan få kontrollert at modellen ikke inneholder alvorlige feil og/eller mangler.)

(API-konsument (design time) - BA9. Som API-konsument ønsker jeg at API-et er tilrettelagt for bruk, og ikke bare speiler innholdet i en database, slik at jeg kan slippe å forholde meg til et fagdomene, sette meg inn i interne kodeverk [brukerorientert, ikke avsenderstyrt …] )

(Som API-forvalter ønsker jeg at det med API-beskrivelsen følger en veileder slik at jeg kan følge beste praksis - BA55. Som API-konsument, ønsker jeg at API-et er designet etter en felles “beste praksis” som gjelder for API-er i API-katalogen, slik at jeg lett kjenner meg igjen på tvers av API-ene i katalogen.)

(Referansemodell - )

(Difi - 7. Tema – interne tema fremfor de generelle EU-temaene)

(API-konsument (design time) - BA47. Som API-konsument ønsker jeg at API-ene jeg skal bruke er så like som mulig (men så forskjellige som nødvendig), slik at jeg ikke trenger sette meg inn i unødvendig mye nytt for hvert API jeg skal vurdere eller bruke. )

(Informasjonsforvaltning - Develop)

(API-katalogen - Som API-forvalter ønsker jeg en godt dokumentert felles løsning for registering av API-beskrivelser slik at jeg slipper å installere egne verktøy.)

(Som API-konsument ønsker jeg å se relasjoner slik at jeg flere som tilbyr liknende API - BTI010 Som API-tilbyder ønsker jeg å kunne se om andre tilbyr det samme eller nesten det samme som meg, så at det er mulig å harmonisere mellom “oss” [Livar: Case der det er fleire API-er som tilbyr det samme? Marit: Brreg og Skatt som har same datasett i FDK. Mathias: Felles studentsystem (FS) i UH-sektoren innheld personinformasjon. Kan ikkje konsoliderast med HR-data. Kan ikkje legge ned ein av dei. Dekker relasjonsfeltet i DCAT behovet?] )

(BA15. Som API-konsument ønsker jeg at alt jeg er avhengig av for applikasjonen min er tilgjengelig fra samme server, inklusive kodeverk, slik at CORS opprettholdes. - Studenter, gründere og app-utviklere)

(Felles rammeverk - BA47. Som API-konsument ønsker jeg at API-ene jeg skal bruke er så like som mulig (men så forskjellige som nødvendig), slik at jeg ikke trenger sette meg inn i unødvendig mye nytt for hvert API jeg skal vurdere eller bruke. )

(Nasjonalt - SKOS-AP-NO)

(Informasjonsmodell-katalog - API-katalog)

(API-konsument (design time) - BFP029: Som API-konsument ønsker jeg at offentlige dataeiere tilbyr APIer så tidlig som mulig (med tilsvarende varsling om datakvalitet) slik at jeg kan utvikle tjenester og bidra til kvalitetsforbedring av dataene. )

(API-tilbyder - 9. Som API-forvalter ønsker jeg en felles løsning for API-dokumentasjon som er så god at jeg selv ønsker å bruke løsningen fremfor andre verktøy )

(API-beskrivelsen - Som sluttbruker ønsker jeg å gi samtykke til at en offentlig myndighet kan innhente mine data fra en 3dje part slik at jeg slipper å tilgjengegliggjøre dataene selv.)

(EPOS 9: Som API-konsument ønsker jeg oversikt over hvem som bruker et API slik at jeg kan forstå det bedre - BB5. Som API-konsument ønsker jeg å få tilgang til eksempler på bruk av API-et slik at jeg kan se mulighetene for bruk og bedre forstå hva API-et er ment å brukes til. [dokumentasjon] )

(API-katalogen - Som API-konsument ønsker jeg at API-beskrivelser er oppdaterte, og at API-er som ikke lenger er tilgjengelig/deprecated fjernes fra katalogen slik at jeg ikke studerer beskrivelser som ikke kan brukes)

(data.norge.no portal - Datasettkatalog)

(API-beskrivelsen - BA4. Som API-konsument ønsker jeg eksempler på API-requests slik at jeg kan komme fort i gang.)

(en datasett-katalog i virksomheten - Registeringsløsning datasett)

( BAM10 - Som ansvarlig for API-management ønsker jeg ??? - API-management)

(Maskin-porten - register scope)

(API-katalogen - Som bruker ønsker jeg å kunne authentisere meg på en enkel måte mot katalogen slik at jeg kan gi tilbakemeldninger og melde om bruk av et API)

(en datasett-katalog i virksomheten - Felles datakatalog portal (fellesdatakatalog.brreg.no))

(Mikrotjenesten/API-et - BA15. Som API-konsument ønsker jeg at alt jeg er avhengig av for applikasjonen min er tilgjengelig fra samme server, inklusive kodeverk, slik at CORS opprettholdes. )

(Andre API-kataloger - FDK-høsting ADM)

(Som API-konsument ønsker jeg at API-beskrivelsen refererer til informasjonsmodeller slik at jeg forstår strukturen i API-ets respons - BFP003: Som API-konsument ønsker jeg å kunne se eventuelt tilknyttede informasjonsmodeller der det finnes, slik at jeg også kan finne og kvalitetssikre data og informasjon. )

(API-konsument (design time) - BA19. Som API-konsument ønsker jeg API der kodeverk (f.eks. kommunenummer, næringskoder) er en del av API-responsen slik at jeg slipper å utføre flere API-kall og hente fra ulike kilder for å få data jeg trenger.)

(API-konsument (design time) - BB30. Som API-konsument ønsker jeg å slippe å ha en kopi av xxregistreret eller datasettet slik at jeg kan være sikker på at dataene er oppdaterte. [tjenestenivå] )

(en API-katalog i virksomheten - Scope)

(Norwegian Entity Register (Bus - Business)

(28. Som API-katalogeier ønsker jeg å, slik at jeg kan ha en total oversikt over API-ene våre kunne vite hvilke API-er min virksomhet tilbyr (og forvalte de på felles måte, vite hvem som bruker hvilke API-er osv.). - API-forvalter og API katalogeier)

(Difi - 11. Publiseringsknapp)

(Regnskapsregisteret - Lenkede data)

(API-tilbyder - BTI010 Som API-tilbyder ønsker jeg å kunne se om andre tilbyr det samme eller nesten det samme som meg, så at det er mulig å harmonisere mellom “oss” [Livar: Case der det er fleire API-er som tilbyr det samme? Marit: Brreg og Skatt som har same datasett i FDK. Mathias: Felles studentsystem (FS) i UH-sektoren innheld personinformasjon. Kan ikkje konsoliderast med HR-data. Kan ikkje legge ned ein av dei. Dekker relasjonsfeltet i DCAT behovet?] )

(Grensesnitt - API (copy))

(create access - Access)

(Felles datakatalog portal (fellesdatakatalog.brreg.no) - Søk og oppslag API-beskrivelser)

(Som API-konsument ønsker jeg at dokumentasjonen er genererert fra kode slik at jeg kan stole på at den er oppdatert - 11. Som API-forvalter/eier ønsker jeg å generere dokumentasjon ut fra koden eller tester, slik at jeg er sikker på at dokumentasjonen til enhver tid er oppdatert.)

(Datalagring - API-backend)

(API-konsument (design time) - BA41. Som API-konsument som benytter verktøy for å generere deler av kildekoden ønsker jeg at API-et er dokumentert iht “Open API Specification”, slik at jeg kan bruke kodegenereringsverktøy for å generere mye av den kildekoden som trengs for å bruke API-et fremfor å måtte skrive den selv [ref epost] )

(SKOS-AP-NO - )

(API-konsument (design time) - BFP006: Som API-konsument ønsker jeg at det ikke er for rigide krav til dokumentering og til selve APIet slik at det ikke hemmer rask utvikling av API )

(concept-cat-harvester - data.norge.no portal)

(API-katalogen - Altinn)

(Nasjonalt - ????)

(BB33. Som API-konsument ønsker jeg å kunne laste ned kun endringer i et datasett for å oppdatere min lokale kopi av et datasett slik at jeg slipper å laste ned hele datasettet på nytt og import-jobben blir mindre. [varsel] - Åpne data statistikk, datajournalistikk og stordata)

(Som informasjonsarkitekt ønsker jeg å beskrive et forretningsobjekt og hvilke egenskaper den har (strukturmodell) slik at vi har en spesifikasjon av hvordan informasjonen skal struktureres og at de logiske sammenhengen mellom informasjonen er avklart og førende for løsningsmodeller - Modelleringsforum)

(Veiledning - Beste praksis - dokumentasjon av API-er - BA40. Som API-tilbyder* ønsker jeg retningslinjer og beste praksis for dokumentasjon av API-ene mine slik at jeg kan dokumentere så effektivt og bra som mulig. )

(EPOS 3: Som API-konsument ønsker jeg at beskrivelsen forklarer kall og innholdet i responsen slik at jeg kan forstå dataene jeg mottar - Som API-konsument ønsker jeg å se eksempler på kall slik at jeg kan raskt sette meg inn i bruk av API-et)

(Datakatalogen - BB10. Som API-konsument ønsker jeg mulighet til å innhente data om tekstdatasett slik at jeg kan lage analyser av disse og koble til andre kilde. [tekst som data] )

(Skatteetaten - Som API-konsument ønsker jeg at nasjonal/delt infrastruktur tilbyr felles mønstre for autentisering og autorisering mot API slik at jeg slipper å bestille og forvalte tilgangsstyring hos hver enkelt tjenestetilbyder.)

(API-katalog API - data.norge.no API-høster)

(Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer - Som potensiell API-konsument ønsker jeg å kjenne til livssyklus planer og garantier for en tjeneste (f.eks. nedleggelse/utfasing) slik at jeg ikke gjør meg avhengig av eksterne APIer som kan forsvinne)

(API-tilbyder - 20. Som API-forvalter ønsker jeg at brukerne av mitt API skal ha en åpen kommunikasjon med meg og hverandre om hvilke behov de har som ikke er dekket i dag, slik at min videreutvikling treffer flest mulig brukere på en tilstrekkelig måte.)

(API-konsument (design time) - BFP013: Som API-konsument ønsker jeg en oversikt over tilgjengelige testmiljø for å teste ut apiene. )

(API-katalogen - BB19. Som API-konsument ønsker jeg å diskutere semantiske og tekniske spørsmål i en åpen kanal (wiki, github issues el liknende) for APIet jeg bruker, slik at brukerne kan hjelpe hverandre og tilbyder kan kommunisere åpent med sitt økosystem. [nettverk, dokumentasjon] )

(Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier. - BB11. Som API-konsument (analytiker) ønsker jeg mulighet for å legg inn spørsmål, tips, eksempler knyttet til APIer slik at jeg kan øke min egen, andre brukere og api-forvalternes kjennskap om semantikk, selve APIen og bruk [økosystem] )

(Felles rammeverk - 2. Som API-forvalter ønsker jeg at katalogen gir føringer for hvordan API-ene mine skal dokumenteres, etter “beste praksis”, så jeg slipper å sette meg inn i/holde meg oppdatert på hva som er beste praksis for API-dokumentasjon [frigjøre ressurser/bedre kvalitet] )

(API-katalog - Harvester)

(EPOS 2: Som API-konsument ønsker jeg en grunnleggende informasjon om API-et som er oppdatert og forståelig lsik at jeg kan ta API-et i bruk - Som API-konsument ønsker jeg å se formater på responsen slik at jeg enklest mulig kan bruke og sammenstille informasjon)

(24. Som API-forvalter (f.eks. av hotell.difi.no) ønsker jeg at API-ene er lette å finne og ta i bruk slik at verdien blir realisert. - API-forvalter og API katalogeier)

(Krav (EPOS og nødvendige krav) - Som API-konsument ønsker jeg å finne detaljert beskrivelse av API-ene slik at jeg kan vurdere om jeg kan benytte API-et i mine tjenester)

(API-konsument (design time) - BB1. Som API-konsument ønsker jeg et spørregrensesnitt (SQL-aktig/SPARQL/ODATA/GraphQL/NoSQL) mot API-et slik at jeg kan utforske datasettet og datasettets struktur/datamodell interaktivt som suplement til å lese dokumentasjon )

(Enterprise Continuum - SLAs/OLAs)

(Enterprise Continuum - Architectures)

(SKOS-AP-NO - Harvesting)

(A Technology Service - A service in a container)

(er:Organization - Business)

(EPOS 3: Som API-konsument ønsker jeg at beskrivelsen forklarer kall og innholdet i responsen slik at jeg kan forstå dataene jeg mottar - Som API-konsument ønsker jeg at API-beskrivelsen refererer til informasjonsmodeller slik at jeg forstår strukturen i API-ets respons)

(API-katalogen - Som API-eier ønsker jeg å kunne beskrive funksjonaliteten i API-et på en overordnet måte slik at brukere får et innblikk i hva API-et innholder. )

(API tilbyder - request)

(API-konsument (design time) - BFDK12 - Som konsument ønsker jeg kontaktinformasjon til brukerstøtte for API slik at jeg kan få hjelp )

(Skjemamodell - )

(Search-API - Search Service)

(API-katalogen - BFDK01 - Som forretningsutvikler ønsker jeg å se hvilke datasett som tilbyr API, slik at jeg kan vurdere om det kan brukes i mine tjenester.)

(Mikrotjenesten/API-et - BB27. Som API-konsument ønsker jeg å kunne laste ned en komplett versjon av datasettet i tillegg til API-funksjonalitet slik at jeg kan kjøre analyse på en lokal kopi av datasettet der dette er mest hensiktsmessig.[nedlasting] )

(API-katalogen - BA22. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg kan stille spørsmål om bruk av API-et slik at jeg kan bruke det mest mulig hensiktsmessig, og gjerne med henvisninger til kjent brukt av API-et. )

(Standardisert API [ABSTRACT] - Standard xyz)

(BA54. Som API-konsument ønsker jeg REST-API-er i tråd med REST-prinsippene/beste praksis slik at jeg kan bygge på erfaringene mine med andre REST-API-er, og forstå effekten av kallene i API-et med minst mulig teknisk dokumentasjon. - Studenter, gründere og app-utviklere)

(API-beskrivelsen - 19. Som API-forvalter ønsker jeg kontaktinfo til de som bruker mine API slik at jeg kan ta kontakt med de om brukerundersøkelser, driftsmeldinger, endring av API, nye API og liknande. [dersom jeg ikke har egne løsninger for dette allerede] )

(Skatteetaten - Som ansvarlig for API-Management ønsker jeg en enkel måte å varsle endringer i oppetid )

(Grensesnitt - API)

(API-konsument (design time) - BA53. Som API-konsument ønsker jeg at API-et støtter HTTP-standard med accept header for å velge data-format slik at kan gjøre det jeg er vant til. )

(Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et - BAM08 - Som ansvarlig for API-management ønsker jeg oversikt over brukerne av mitt API slik at jeg kan formidle endringer i APIet. [Livar: duplikat av BAM03?] )

(6. Som API-forvalter ønsker jeg at de aktivitetene jeg må gjøre og de standardene jeg må forholde meg til for å gjøre API-dokumentasjonen tilgjengelig i en nasjonal API-katalog, også gir verdi for andre, kommersielle, internasjonale API-kataloger, f.eks. synliggjøring på søkemotorer, ref Schema.orgs arbeid med vokabular for WebAPI http://pending.webschemas.org/WebAPI - API-forvalter og API katalogeier)

(Tjenesteutvikler - Som deltaker i utviklingen av nye digitale tjenester ønsker jeg å få oversikt over hvor i organisasjonen eierskapet til datasettet hører hjemme, slik at jeg kan identifisere hvilke data som kan være relevante for mine oppgaver.)

(Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles - BA34. Som API-konsument ønsker jeg at eventuelle krav til API-nøkler etc lar seg løse raskt/selvbetjent slik at jeg kan komme i gang raskt. [f.eks. autorisering basert på eksisterende mekanismer fremfor å måtte kontakte forvalter og vente på svar (ID-porten, Altinn), bruksvilkår fremfor avtaler] )

(API-konsument (design time) - BB9. Som API-konsument (datajournalist) ønsker jeg å få forklaringer/dokumentasjon på hvordan dataene henger sammen slik at jeg kan spare tid på semantisk fortolkning (kobling mot datakatalogen?) [dokumentasjon] )

(API-tilbyder - Som API-eier ønsker jeg å kunne beskrive funksjonaliteten i API-et på en overordnet måte slik at brukere får et innblikk i hva API-et innholder. )

(BA53. Som API-konsument ønsker jeg at API-et støtter HTTP-standard med accept header for å velge data-format slik at kan gjøre det jeg er vant til. - Studenter, gründere og app-utviklere)

organisasjonsnummer (API-tilbyder - API tilbyder)

(Studenter, gründere og app-utviklere - BA45. Som API-konsument ønsker jeg et API med gode muligheter for å filtrere data slik at jeg kan hente ut akkurat det utsnittet av datasettet som jeg trenger til mitt formål og slipper å gjøre ekstra prosessering av responsen jeg får fra API-et. )

(skv:Municipality - Municipality)

(Informasjonsmodell-katalog - REST GET informasjonsmodell-katalog)

(en begrepskatalog i virksomheten - REST GET Begrepskatalog)

(EPOS 9: Som API-konsument ønsker jeg oversikt over hvem som bruker et API slik at jeg kan forstå det bedre - 19. Som API-forvalter ønsker jeg kontaktinfo til de som bruker mine API slik at jeg kan ta kontakt med de om brukerundersøkelser, driftsmeldinger, endring av API, nye API og liknande. [dersom jeg ikke har egne løsninger for dette allerede] )

(Nasjonalt - Anonym bruker)

(EPOS 1: Som API-konsument ønsker jeg at API-beskrivelser samles slik at det er lett å få oversikt - Som API-forvalter ønsker jeg at mine API-beskrivelser følger et standard med veiledning og verktøystøtte slik at det er enkelt for brukerne og jeg kan redusere mine forvaltningskostnader og henvendelser)

(Enterprise Continuum - Regulatory Requirements)

(API-beskrivelsen - BB7. Som API-konsument ønsker jeg at det angis tydelig i dokumentasjonen hvilke data som er tilgjengelig, men også hva som ikke er tilgjengelig, slik at jeg slipper merarbeid pga. uklar dokumentasjon. [dokumentasjon] )

(API-katalog API - Leseapplikasjon API)

(Maskin-porten - Access token)

(Tjenestekatalog - data.norge.no tjenestehøsting)

(Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer - Som API-forvalter/ansvarlig for API-management ønsker jeg en enkel måte å kommunisere livssyklus planer og garantier for en tjeneste (f.eks. nedleggelse/utfasing) slik at jeg kan avvikle tjenester når det er ønskelig)

(Spesifikasjon for informasjonsmodeller - )

(Grensesnitt - Register)

(API-konsument (design time) - BB33. Som API-konsument ønsker jeg å kunne laste ned kun endringer i et datasett for å oppdatere min lokale kopi av et datasett slik at jeg slipper å laste ned hele datasettet på nytt og import-jobben blir mindre. [varsel] )

(Forvalte API-tilgang - Angi grovkonet tilgang)

(API-tilbyder - 7. Som API-forvalter har jeg behov for å selv velge hvor selve dokumentasjonen skal ligge, slik at jeg kan bruke de verktøyene som er mest hensiktsmessig til formålet. )

(Forbedring av søketjeneste - (Behov for begreper i FDK søkeløsning))

(API-katalogen - BAM01 - Som ansvarlig for API-management ønsker jeg å publisere mine API i en API-katalog slik at utviklere raskt kan finne frem til mitt API/økt synlighet )

(Prosjekttutløsende behov (overordnet)- fra handlingsplanen i porteføljestyring - Ulik representasjon av sentral informasjon, for eksempel adresse, personopplysninger og organisasjoner medfører et løpende integrasjonsarbeid og risiko for kvalitetsforringelser. EU er pådriver for etablering av informasjonsmodeller som forener ulike land og virksomheters representasjoner og reduserer kostnaden for sammenstilling av data. Lokalt betyr dette også for BRSys en mer sømløs integrasjon mellom registrene. Altinn har verktøystøtte for informasjonsmodellering i dag (SERES) som vil migreres til ny arkitektur (2017) og etter hvert knyttes tettere til Tjenester 3.0 )

(Lokal registreringsløsning - Som datasetteier ønsker jeg å kunne registrere merknader om et datasett i et fritekstfelt slik at andre ved BR kan bli oppmerksom på forhold som kan ha betydning for bruk av datasettet)

(Registerenhet i Belgia - Organization API)

(BA25. Som API-konsument ønsker jeg at beskrivelser av API-er som ikke lengre er tilgjengelige, skal fjernes fra API-katalogen, slik at jeg slipper å lese om API-er som jeg uansett ikke kan bruke. - Studenter, gründere og app-utviklere)

(API-beskrivelsen - BFP014: Som API-konsument ønsker jeg oversikt over tilgjengelige referanseimplementasjoner slik at jeg raskere kan komme i gang med å bruke apiene. )

(data.norge.no API-høster - FDK API-høster API)

(Som API-konsument ønsker API-beskrivelsen refererer til begreper slik at jeg kan forstå innholdet i API-et - BA39. Som API-konsument ønsker jeg at begreper i API-ene er dokumentert slik at jeg forstår dokumentasjonen og bruker dataene i API-ene rett. )

(Mikrotjenesten/API-et - BA33. Som API-konsument ønsker jeg at det er så få tekniske sperrer på API-ene som mulig slik at jeg kan ta det i bruk med minst mulig “prosess” mot API-forvalteren )

(Behov for å publisere begreper eksternt (ORDEN-584) - Etatene skal beskrive sin tolkning av begreper i lovverk, forvaltningsstandarder og forvaltningspraksis i egen begrepskatalog. Begrepsbeskrivelsene skal bl.a. legge til rette for at opplysningene i datasettene kan beskrives eksplisitt, f.eks. hva inngår i “likningsverdi”. Begrepsbeskrivelsene skal være tilgjengelige slik at regelverksutvikling og digitaliseringsprosjekter kan identifisere forenklinger. )

(Skatteetaten - Som API-forvalter ønsker jeg å kunne få overført mine API-definisjoner til en runtime tjenestekatalog (SMP, CapabiliityLookup eller den tekniske endepunktedelen av KoFuVi?) for å kunne legge til metadata for runtime-kall slik at jeg ikke må registrere mine API-definisjoner dobbelt.)

(Open API Specification - API-beskrivelse)

(EPOS 4: Som API-konsument ønsker jeg å finne detaljert beskrivelse av API-ene slik at jeg kan vurdere om jeg kan benytte API-et i mine tjenester - Som API-konsument ønsker jeg kontaktinformasjon til brukerstøtte for API slik at jeg kan få hjelp om jeg står fast)

(API-beskrivelsen - BTI010 Som API-tilbyder ønsker jeg å kunne se om andre tilbyr det samme eller nesten det samme som meg, så at det er mulig å harmonisere mellom “oss” [Livar: Case der det er fleire API-er som tilbyr det samme? Marit: Brreg og Skatt som har same datasett i FDK. Mathias: Felles studentsystem (FS) i UH-sektoren innheld personinformasjon. Kan ikkje konsoliderast med HR-data. Kan ikkje legge ned ein av dei. Dekker relasjonsfeltet i DCAT behovet?] )

( Når Oslo kommune trenger data om hvordan jeg beveger meg -- for å drive byutvikling, prioritere sykkelstier m.m., kan jeg gi dem mine Strava-data - Som sluttbruker ønsker jeg å gi samtykke til at en offentlig myndighet kan innhente mine data fra en 3dje part slik at jeg slipper å tilgjengegliggjøre dataene selv.)

(Altinn data modellering - 205. Som tjenesteutvikler ønsker jeg at tjenestens modell også blir oppdatert når jeg endrer felttypen til et felt i skjemaklient, slik at modellen og brukergrensesnittet hele tiden er gjensidig oppdatert.)

(/login - Tilgangsstyring Admin GUI)

(Som API-konsument ønsker jeg informasjon om et API har varsligskanal slik at jeg kan fange opp endringer - BA43. Som API-konsument ønsker jeg å bli varslet om at et API er “deprecated” (skal tas ut av bruk), slik at jeg kan oppdatere min applikasjon. )

(API-konsument (design time) - BB32. Som API-konsument (datajournalist) ønsker jeg at strukturen i datasettene er stabile, slik at jeg ikke trenger gjøre endringer i min integrasjon/kode når nye versjoner hentes. [forutsigbarhet] )

(Som API-konsument ønsker jeg å forstå om API-et er tilrettelagt for bruk med brukers samtykke eller fullmakt - Som sluttbruker ønsker jeg at en privat virksomhet skal ha tilgang til data om meg fra en tredjepart (app) slik at jeg kan slippe å tiljgengeliggjøre dataene selv)

(Harvester-API - Harvester Service)

(Mikrotjenesten/API-et - BA9. Som API-konsument ønsker jeg at API-et er tilrettelagt for bruk, og ikke bare speiler innholdet i en database, slik at jeg kan slippe å forholde meg til et fagdomene, sette meg inn i interne kodeverk [brukerorientert, ikke avsenderstyrt …] )

(API-beskrivelsen - Som API-konsument ønsker jeg å vite hvilken interaksjonsform som tilbys i APIet (spørring, feed, fil) , slik at jeg kan vite om det dekker mine behov. )

(BA50. Som API-konsument, ønsker jeg å kunne gi tilbakemeldinger til god (eller dårlig) “beste praksis” for API-er, slik at dette kan være til hjelp for framtidige API-er som utvikles. - Studenter, gründere og app-utviklere)

(API-katalogen - 18. Som API-forvalter ønsker jeg oversikt over integrasjoner mot mine API-er slik at konsekvenser og kostnader ved endringer kan forutses og minimeres. )

(API-konsument (design time) - BA49. Som API-konsument ønsker jeg ikke å tvinges til å bruke API-er der hvor det aller enkleste for meg ville vært å få lastet ned hele datasettet. [kommentar: ønskjer i alle fall anledning til å velje] )

( BAM15 - Som ansvarlig for API-management ønsker jeg å publisere informasjon om kostnader og trafikkbegrensninger for mine API-er, slik at potensielle brukere av mine API-er slipper å spørre meg om denne informasjonen - API-management)

(Som API-konsument ønsker jeg oversikt over testmiljø og syntetiske data slik at jeg kan teste ut API-ene - 8. Som API-forvalter som tilbyr data som ikke er åpne ønsker jeg å synliggjøre testmiljø for mine API-er slik at de er lette å oppdage for brukerne )

(API-konsument (design time) - BA44. Som API-konsument ønsker jeg intelligente API-er som kan f.eks. filtrere, aggrerere, gruppere slik at jeg bare få inn de resultater jeg trenger av hensyn til personvern, kapasitet etc. )

(Informasjonsforvaltning - Enterprise Continuum)

(authorization - Begrepskatalog API)

( BB25. Som API-konsument (ETL) ønsker jeg mulighet til å abonnere på endringsvarslinger om både data og API-versjoner slik at jeg kan oppfriske data og/eller utnytte nye datafelter. [varsel] - Åpne data statistikk, datajournalistikk og stordata)

(OASIS SMP protokoll - API-beskrivelse (OAS))

(API-katalogen - Som dataeier ønsker jeg at relevante opplysninger fra API-beskrivelsen er tilgjengelig i datasettbeskrivelsen slik at jeg unngår dobbeltarbeid)

(Åpne data statistikk, datajournalistikk og stordata - BB18. Som API-konsument ønsker jeg at kildekoden til API-tjenesten er tilgjengelig som åpen kildekode, slik at jeg kan lese kildekode for å forstå APIet og kunne bruke det optimalt [dokumentasjon] )

(Melding uten gjenbruksmulig eller preutfylling - 204. Som tjenesteutvikler ønsker jeg å generere en tjeneste direkte fra en modell slik at jeg slipper manuelt å lage brukergrensesnittet til tjenesten for så å koble feltene til modellelementene (ev. XSD-elementene).)

(Som API-eier ønsker jeg å publisere API-er som ikke kan knyttes til et datasett slik at også mine mine API-er som gjør beregninger e.l. kan publiseres - Som API-eier ønsker jeg å kunne beskrive et API som ikke nødvendigvis kan knyttes til et datasett, slik at også dynamiske tjenester kan synliggjøres for andre konsumenter. )

(en datasett-katalog i virksomheten - REST GET Datasettkatalog)

(API-mangement verktøyleverandør - BAM17 - Som ansvarlig for API-management ønsker jeg at å tilby effektiv selvregistrering av brukere av API-ene, f.eks. gjennom autentisering via ID-porten/Altinn av dem som tar i bruk API-ene, slik at jeg senker terskelen for å ta API-et i bruk, samtidig som jeg beholder nødvendig oversikt over brukere. )

(REST GET Begrepskatalog - Begrepskatalog API)

(API-katalog API - Harvester)

(Enhetsregisteret - er:Organization)

(Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted. - 12. Som APi-forvalter/eier ønsker jeg at standarder og beskrivelser er helt maskinlesbare slik at høsting og bruk kan automatiseres og min rolle automatiseres bort eller erstattes av AI. )

Publish START_HARVEST_APIs (API-katalog GUI - Publish/Subscribe Service)

(Åpne data statistikk, datajournalistikk og stordata - BB16. Som API-konsument ønsker jeg at støttedatasett (f.eks. kodelister) er omtalt i dokumentasjonen slik at jeg kan anvende data fullt ut.[dokumentasjon] )

(10. Som en API-forvalter ønsker jeg å kunne ha “FAQ-funksjonalitet” (eller kunnskapsbase), slik at brukerne mine lettere kan få tak i svar på kjente utfordringer og jeg kan redusere kostnader ved å håndtere brukerhenvendelser. - API-forvalter og API katalogeier)

(7. Som API-forvalter har jeg behov for å selv velge hvor selve dokumentasjonen skal ligge, slik at jeg kan bruke de verktøyene som er mest hensiktsmessig til formålet. - API-forvalter og API katalogeier)

(Felles datakatalog portal (fellesdatakatalog.brreg.no) - Registreringsapplikasjon API)

(Difi konseptutredning "deling av data" - Det er behov for enkel tilgang til data av god kvalitet, og som er beskrevet på en standardisert måte )

(Nasjonalt - Begrepskatalog API)

( BB35. Som API-konsument ønsker jeg å kunne abonnere på hendelser slik at jeg får beskjed når hendelser oppstår. [varsel] - Åpne data statistikk, datajournalistikk og stordata)

(Registry in Belgium - Business)

(Offentlig Virksomhet - en begrepskatalog i virksomheten)

(Som tjenesteutvikler og data scientist ønsker jeg å finne informasjon om dataeier slik at jeg kan få tilgang til dataene - 1-2 Som deltaker i utviklingen av nye digitale tjenester ønsker jeg å få oversikt over hvor i organisasjonen eierskapet til datasettet hører hjemme, slik at jeg kan identifisere hvilke data som kan være relevante for mine oppgaver.)

(API-konsument (design time) - BB22. Som API-konsument ønsker jeg å få dokumentasjonen fra samme sted som jeg henter ut data, slik at jeg vet at det er oppdatert og lett tilgjengelig. [dokumentasjon] )

(Modellkatalog, Datamodell, Data dictionary - BA42. Som API-konsument ønsker jeg varsler om “breaking changes” slik at jeg kan gjøre de nødvendige endringene før de brekker mine systemer/applikasjoner også. [f.eks. ved registrere e-postadresse] )

(Veiledning - Beste praksis - API/mikrotjeneste - BA26. Som API-konsument ønsker jeg at API-et støtter CORS slik at jeg kan nå det fra en webapplikasjon uten å måtte gå via egen backend eller proxy. )

(Krav (EPOS og nødvendige krav) - Integrasjon med AD)

(API-katalogen - Som utvikler i Altinn ønsker jeg å kunne registrere de API jeg utvikler for mine T.3 applikasjoner slik at <hensikt>)

(API-katalogen - API-tilbyder/private grossister)

(API-konsument (design time) - BA12. Som API-konsument ønsker jeg å hente inn data uavhengig av dataenes egentlig form slik at den ikke endrer seg når dataformatet endres. )

(Informasjonsforvaltning - Se nasjonale felleskomponenter i sammenheng)

(API-konsument (design time) - BA46. Som API-konsument ønsker jeg mulighet for å bruke filtre i API-et slik at jeg kan ha bedre kontroll med hvilket utvalg av data jeg mottar, og ikke er avhengig av hvilke utvalg API-forvalteren har definert. )

(Veiledning - Beste praksis - API/mikrotjeneste - BB13. Som API-konsument ønsker jeg at de tjenestene offentlig sektor har utviklet på sine egne API gjøres tilgjengelig som åpen kildekode, slik at jeg kan gjenbruke relevante deler av koden for mitt eget konsum av API-et. [gjenbruk av kildekode] )

(API-katalogen - Som API-konsument ønsker jeg kontaktinformasjon til brukerstøtte for API slik at jeg kan få hjelp om jeg står fast)

(API-konsument (design time) - BFP021: Som API-konsument ønsker jeg en standardisering av API-grensesnittene (inn og ut) slik at jeg kan ta i bruk nye datasett raskest mulig. )

(BA4. Som API-konsument ønsker jeg eksempler på API-requests slik at jeg kan komme fort i gang. - Studenter, gründere og app-utviklere)

(API-katalogen - FDK)

(Open Accounting API - Entity Registry API)

(Informasjonsforvaltning - Deploy)

(API-tilbyder - 28. Som API-katalogeier ønsker jeg å, slik at jeg kan ha en total oversikt over API-ene våre kunne vite hvilke API-er min virksomhet tilbyr (og forvalte de på felles måte, vite hvem som bruker hvilke API-er osv.). )

(Mikrotjenesten/API-et - BFP033: Som API-konsument ønsker jeg at API-et er avledet av en informasjonsmodell og Masterdata, som både sikrer konsistens mellom API og informasjonsmodell og gir mer og bedre dokumentasjon for API-et. )

(Nasjonalt - TBX-AP-NO)

(Referansedata - data.norge.no portal)

( Som arbeidstager ønsker jeg å få automatisk utfylt reiseregning når jeg sykler, dokumentert med lokasjonsdata fra min mobil - Som sluttbruker ønsker jeg at en privat virksomhet skal ha tilgang til data om meg fra en tredjepart (app) slik at jeg kan slippe å tiljgengeliggjøre dataene selv)

(API-katalogen - BFDK11 - Som konsument ønsker jeg å abonnere på varslinger om etablering, endring, driftsstans og avvikling av API’er slik at jeg kan tilpasse meg endringer)

(API-katalogen - Som API-forvalter/API-Management ansvarlig ønsker jeg en enkel måte å kommunisere sensitiv informasjon sikkert til (enkelt)brukere av tjenester)

(Felles datasettkatalog API - Registration-BACKEND)

(API-beskrivelse (OAS) - Scope)

(Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier. - Som API-konsument ønsker jeg å kunne gi strukturerte tilbakemeldinger (f.eks. feil) og endringsforslag for tjenester slik at tjenestene kan forbedres)

(API-katalogen - Som API-forvalter ønsker jeg at mine API-beskrivelser følger et standard med veiledning og verktøystøtte slik at det er enkelt for brukerne og jeg kan redusere mine forvaltningskostnader og henvendelser)

(API-mangement verktøyleverandør - BAM13 - Som ansvarlig for API-management ønsker jeg at brukerne av mine API-er skal kunne gi innspill til endringer av mine API-er, slik at jeg gjøre API-ene mine mer brukervennlige. )

(Regnskapsdata publiserer - Regnskap)

(BAM16 - Som ansvarlig for API-management ønsker jeg tydelige føringer på hvordan mitt API skal dokumenteres og gjøres tilgjengelig i en felles API-katalog slik at arbeidet kan planlegges, fordeles og operasjonaliseres i min virksomhet med et forutsigbart omfang. - API-management)

(Fagterminologibaser - data.norge.no begrepshøsting)

( BB21. Som API-konsument ønsker jeg å kunne laste ned endringer i et datasett jeg allerede har en lokal kopi av slik at jeg effektivt kan vaske eget register basert på samme datakilde. [varsel] - Åpne data statistikk, datajournalistikk og stordata)

(API-beskrivelsen - BFP019: Som API-konsument ønsker jeg at apiene inneholder referanser til begrepene som er brukt i apiene slik at jeg forstår detaljene og bruker dataene korrekt. )

(REST GET Datasettkatalog - Datasettkatalog)

(API-beskrivelsen - EPOS 2: Som API-konsument ønsker jeg en grunnleggende informasjon om API-et som er oppdatert og forståelig lsik at jeg kan ta API-et i bruk)

(Jira-adapter begrepskatalog - Behov for å publisere begreper eksternt (ORDEN-584))

(Sikkerhetsarkitektur - API/mikrotjeneste - BA2. Som API-konsument ønsker jeg umiddelbar tilgang (slipper å vente på manuell tildeling av API-nøkler og tokens) til data (eller testdata) slik at jeg kan vurdere og eventuelt ta i bruk API-et umiddelbart.)

(API beskrivelse 2 - Standard xyz)

(BB2. Som API-konsument ønsker jeg å gjøre spørringer og sammenstillinger og styre strukturen/formatet på resultatdatasettet selv, slik at jeg kan enkelt kan få det utsnittet av dataene som passer til den oppgaven jeg skal løse. - Åpne data statistikk, datajournalistikk og stordata)

(Premissgiver - styring dokumentasjon av API-er - BB14. Som API-konsument ønsker jeg standardavtaler for både vilkår for bruk av data og tjeneste slik at jeg vet hvilke vilkår og tjenestenivå jeg har å forholde meg til. [databehandleravtaler, SLA] )

(Veiledning - Beste praksis - API/mikrotjeneste - BA44. Som API-konsument ønsker jeg intelligente API-er som kan f.eks. filtrere, aggrerere, gruppere slik at jeg bare få inn de resultater jeg trenger av hensyn til personvern, kapasitet etc. )

(API-beskrivelsen - BFP018: Som API-konsument ønsker jeg at apiene inneholder referanser til lokale kodeverk som forklarer innholdet i apiene slik at jeg forstår detaljene i apiene. )

(Mikrotjenesten/API-et - BFP028: Som API-konsument ønsker jeg at API-et i større grad er “selvbeskrivende” og, dersom det brukes interne koder, at betydningen/forklaringen på disse er enkelt tilgjengelig, slik at jeg forstår hvordan jeg skal bruke API-et. )

(API-beskrivelsen - Som sluttbruker ønsker jeg at en privat virksomhet skal ha tilgang til data om meg fra en tredjepart (app) slik at jeg kan slippe å tiljgengeliggjøre dataene selv)

(EPOS 2: Som API-konsument ønsker jeg en grunnleggende informasjon om API-et som er oppdatert og forståelig lsik at jeg kan ta API-et i bruk - Som API-konsument ønsker jeg å vite hva slags intereaksjonsform/type som API-et tilbyr slik at jeg kan vite om det dekker mine behov)

( BB22. Som API-konsument ønsker jeg å få dokumentasjonen fra samme sted som jeg henter ut data, slik at jeg vet at det er oppdatert og lett tilgjengelig. [dokumentasjon] - Åpne data statistikk, datajournalistikk og stordata)

(Informasjonsmodell-katalog - Søk og oppslag Informasjonsmodeller)

(API-katalog - API-spesifikasjon)

(Som API-konsument ønsker jeg kontaktinformasjon til brukerstøtte for API slik at jeg kan få hjelp om jeg står fast - BFDK12 - Som konsument ønsker jeg kontaktinformasjon til brukerstøtte for API slik at jeg kan få hjelp )

(Ansatt - Som ansatt ønsker jeg å kunne søke på innhold i våre datasettbeskrivelser slik at jeg kan lettere finne fram til relevante datasett)

(Enterprise Continuum - Regulatory Requirements)

(Som dataeier ønsker jeg å knytte API til datasettet slik at jeg kan vise hvilke distribusjoner som finnes - BFDK07 - Som datasetteier (og som beskriver datasett i datakatalogen) ønsker jeg å kunne kople beskrivelser av APIer (i flertall) til et gitt datasett, slik at jeg kan vise hvilke distribusjoner som finnes av et datasett )

(API-konsument (design time) - BFP010: Som API-konsument ønsker jeg å bare lese endringer som er gjort på siste oppdatering slik at vi slipper å lese hele datasettet. )

(API-katalog eier - API-katalogen)

(Premissgiver - Kvalitetskrav til API/mikrotjeneste - BA21. Som API-konsument ønsker jeg et API som gir godt strukturerte responser slik at data er lett å bruke. )

(Enterprise Continuum - SLAs/OLAs)

(API-beskrivelsen - BFP020: Som API-konsument ønsker jeg informasjon om oppdateringsfrekvens av dataene eller om dataene er statiske. )

(Norwegian Accounting Registry - Annual accounts)

(API-mangement verktøyleverandør - BAM11 - Som ansvarlig for API-management ønsker jeg å sikre eierskap av API-ene hos forretningseier/dataeier for å sikre kvalitet og eierskap. )

(Informasjonsmodell - )

(data.norge.no API - data.norge.no API-høster)

(Som API-konsument ønsker jeg å forstå om API-et er tilrettelagt for bruk med brukers samtykke eller fullmakt - Som sluttbruker ønsker jeg å gi samtykke til at en offentlig myndighet kan innhente mine data fra en 3dje part slik at jeg slipper å tilgjengegliggjøre dataene selv.)

(Node - API Gateway)

(digitale tjenester - Oppgaveregisteret)

(Felles - REST GET Datasettkatalog)

(Mikrotjenesten/API-et - BB30. Som API-konsument ønsker jeg å slippe å ha en kopi av xxregistreret eller datasettet slik at jeg kan være sikker på at dataene er oppdaterte. [tjenestenivå] )

(API beskrivelse 1 - API 1)

(API-katalog - Leseapplikasjon API)

(Felles rammeverk - BB3. Som API-konsument ønsker jeg å gjøre spørringer som gir meg dataene jeg har rettighet til å få (og ikke blir blokkert tilgang fordi API-et bare gir tilgang til mer data enn jeg har rettigheter til), slik at jeg kan få tilgang til data [rettigheter] )

(Premissgiver - Tjenesteutvikling på API/mikrotjenester - BFP031: Som kommersiell API-konsument ønsker jeg at offentlige aktører ikke tilbyr konkurrerende verdiøkende tjenester på de API de tilbyr slik at jeg kan sikre min return on investment. )

(BB5. Som API-konsument ønsker jeg å få tilgang til eksempler på bruk av API-et slik at jeg kan se mulighetene for bruk og bedre forstå hva API-et er ment å brukes til. [dokumentasjon] - Åpne data statistikk, datajournalistikk og stordata)

(Altinn UX design tjeneste - 204. Som tjenesteutvikler ønsker jeg å generere en tjeneste direkte fra en modell slik at jeg slipper manuelt å lage brukergrensesnittet til tjenesten for så å koble feltene til modellelementene (ev. XSD-elementene).)

(API-katalogen - BA20. Som API-konsument ønsker jeg informasjon om hvor jeg kan finne statiske data som brukes til API-requests (Kommunenr, Kommunenavn..) slik at jeg slipper å lete etter dette selv. )

(API-katalog - API-katalog API)

request (En konsument applikasjon - Hente API beskrivelser av en viss type (API spesifikasjon))

(Forretningsutvikler - BFDK02 - Som forretningsutvikler ønsker jeg å søke etter API, slik at jeg raskt kan finne ut om det finnes data jeg kan gjenbruke)

(Lokal registreringsløsning - Som datasetteier ønsker jeg å registrere flere egenskaper (interne kontaktpersoner, GDPR-relatert informasjon) om datasett enn det som er mulig i Felles datakatalog slik at interne behov oppfylles i henhold til interne krav. )

(Grensesnitt - Brukere)

(Nettverk (faglig forum) - BA27. Som API-konsument ønsker jeg at API-forvaltere lærer av webutviklere og tenker på brukerinvolvering og brukertesting slik at jeg kan få et API-som er lagt til rette for bruk )

(Som API-konsument ønsker jeg å se en SLA knyttet til API-et slik at jeg kan vurdere om det tilfredsstiller mine krav til bruk - BFP023: Som API-konsument ønsker jeg å se hvilken SLA som er forbundet med API et slik at jeg kan vurdere om det tilfredsstiller mine krav for bruk. )

(Premissgiver - Tilgjengelighetskrav API-er til grunndata - BB30. Som API-konsument ønsker jeg å slippe å ha en kopi av xxregistreret eller datasettet slik at jeg kan være sikker på at dataene er oppdaterte. [tjenestenivå] )

(API-beskrivelsen - BFP003: Som API-konsument ønsker jeg å kunne se eventuelt tilknyttede informasjonsmodeller der det finnes, slik at jeg også kan finne og kvalitetssikre data og informasjon. )

(API-konsument (design time) - BA7. Som API-konsument ønsker jeg selvforklarende API-er slik at jeg kan komme raskt i gang, få raskt nytte av API-et. )

(Offentlig Virksomhet - API-tilbyder)

(Regnskap JSON-LD - Regnskap)

(Standardisering - Grensesnitt API/mikrotjeneste - BA8. Som API-konsument ønsker jeg mulighet til enkelt å teste API-ene (utforske) f.eks. gjennom Swagger eller tilsvarende, slik at jeg raskere forstår API-et, og raskere klarer å bruke det (riktig) [ref BA7].)

(Registreringstjeneste begrep - (Behov for registrering av begreper))

(API-beskrivelsen - BFDK13 - Som konsument av et åpent api ønsker jeg informasjon om hvor pålitelig leveransen av data er (forventet oppetid, responstid ved feil osb) slik at jeg kan gjøre en tilstrekkelig ROS-analyser for min integrasjon )

(API-tilbyder - 34. Som API-katalogeier som ikke har en katalog, så ønsker jeg enkel måte å eksponere API-er på, ikke egen katalog med maskinlesbar beskrivelse, slik at jeg slipper å lage et eget verktøy med egne beskrivelser. )

(Spesifikasjon og standard for begreper (SKOS, TBX) - )

(API-katalogen - BFDK06 - Som arkitekt ønsker jeg å se hvilke data jeg må benytte for å gjøre oppslag mot et API og hvilke data jeg får tilbake slik at jeg kan planlegge design av løsning. )

(Felles - Registreringsapplikasjon begrep)

(Som API-forvalter ønssker jeg å beskrive kjente kvalitetsvurderinger slik at konsumenten kan forstå API-et bedre - BFP008: Som API-konsument ønsker jeg å vite oppdateringsfrekvens slik at jeg kan bestemme egen oppdatering. )

(API-katalogen - BFDK12 - Som konsument ønsker jeg kontaktinformasjon til brukerstøtte for API slik at jeg kan få hjelp )

(Altinn tjenestekatalog - Altinn.no)

(API-beskrivelsen - BB6. Som API-konsument ønsker jeg at semantikken rundt dataene er forklart (dataene er definert), slik at jeg kan ta et informert valg om å bruke dataene fordi jeg forstår kontekst, formål og omfanget av dem. [dokumentasjon] )

(Organisasjonskatalog - Datasettkatalog GUI)

(Sky - Node)

(API-konsument (design time) - BA51. Som API-konsument ønsker jeg mulighet til å gi tilbakemeldinger slik at jeg kan melde fra om feil eller foreslå forbedringer)

(API-katalog - Servers)

(Veiledning - Beste praksis - API/mikrotjeneste - BB27. Som API-konsument ønsker jeg å kunne laste ned en komplett versjon av datasettet i tillegg til API-funksjonalitet slik at jeg kan kjøre analyse på en lokal kopi av datasettet der dette er mest hensiktsmessig.[nedlasting] )

(en begrepskatalog i virksomheten - data.norge.no begrepshøsting)

(API-beskrivelse - API)

(BA52. Som API-konsument ønsker jeg en enkel måte å rapportere inn feil i datakatalog (f.eks. Lenker som ikke fungerer) slik at jeg slipper å bla i utdatert innhold. - Studenter, gründere og app-utviklere)

(API-tilbyder - 8. Som API-forvalter som tilbyr data som ikke er åpne ønsker jeg å synliggjøre testmiljø for mine API-er slik at de er lette å oppdage for brukerne )

(Tilgangskontroll - Tilgangsstyring)

(Som API-forvalter ønsker jeg en godt dokumentert felles løsning for registering av API-beskrivelser slik at jeg slipper å installere egne verktøy. - Som API-eier ønsker jeg å kunne beskrive funksjonaliteten i API-et på en overordnet måte slik at brukere får et innblikk i hva API-et innholder. )

(API-spesifikasjon - API-spesifikasjon)

(API-beskrivelsen - EPOS 6: Som API-konsument ønsker jeg informasjon om autentisering og tilgangskontroll for å ta API-et i bruk)

(FDK-høsting API - data.norge.no API-høster)

(Norwegian Accounting Registry - organisation number)

(Som befolkning i et område vil vi gi bevegelsesinformasjon (fra telefon, gpx, google location history osv.) til en kommune for bedre planlegging av a) utbygging av sykkel/turveier b) vedlikehold c) øvrig kommunale tjenester. - Som sluttbruker ønsker jeg å gi samtykke til at en offentlig myndighet kan innhente mine data fra en 3dje part slik at jeg slipper å tilgjengegliggjøre dataene selv.)

(Kapabilitetsoversikt - Addresseringstjeneste - Capability lookup (OASIS SMP))

(API-tilbyder - 10. Som en API-forvalter ønsker jeg å kunne ha “FAQ-funksjonalitet” (eller kunnskapsbase), slik at brukerne mine lettere kan få tak i svar på kjente utfordringer og jeg kan redusere kostnader ved å håndtere brukerhenvendelser. )

(API-beskrivelsen - BA30. Som API-konsument ønsker jeg informasjon om hvilke hjemler som gir tilgang til API-er der tilgangen er begrenset, slik at jeg kan vurdere om min virksomhet har lov til å benytte API-et til det aktuelle formålet. )

(en tjenestekatalog i virksomheten - Altinn.no)

(Architecture Board - Chief Architect)

(Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles - Som API-konsument ønsker jeg single sign on (SSO) mellom flere tjenester jeg benytter slik at jeg unngår separat autentisering mot hver enkelt tjeneste)

(Informasjonsforvaltning - API-beskrivelse)

(Chief Architect - Develop)

(API-konsument (design time) - BA13. Som API-konsument ønsker jeg at Tableau/R/etc kan hente inn data for meg slik at jeg kan lage visualiseringer uten å måtte vite noe om API-er. )

(API-beskrivelsen - BAM18 - Som ansvarlig for flere datasett og medfølgende API’er ønsker jeg å ha kontroll på de datasettene forretningsenheten min tilbyr og enkelt gi tilgang til datasettene ved behov slik at jeg kan utføre ansvaret jeg har på en enkel måte )

(Som API-forvalter ønsker jeg at API-katalog kan plukke opp min swagger dokumentasjon slik at jeg kan benytte dette verktøyet - 7. Som API-forvalter har jeg behov for å selv velge hvor selve dokumentasjonen skal ligge, slik at jeg kan bruke de verktøyene som er mest hensiktsmessig til formålet. )

(Som API-konsument ønsker jeg informasjon hvordan endringer i modell varsles slik at jeg kan fange opp endringer - BFP017: Som API-konsument ønsker jeg en endringslogg så tidlig som mulig slik at jeg vet hva som har endret seg mellom versjoner. )

(Mikrotjenesten/API-et - BA13. Som API-konsument ønsker jeg at Tableau/R/etc kan hente inn data for meg slik at jeg kan lage visualiseringer uten å måtte vite noe om API-er. )

(Som API-konsument ønsker jeg referanser til brukte kodeverk slik at jeg kan forstå hvordan de skal fortolkes - BFP018: Som API-konsument ønsker jeg at apiene inneholder referanser til lokale kodeverk som forklarer innholdet i apiene slik at jeg forstår detaljene i apiene. )

(“Den registrerte/subjektet” - Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv)

(API-konsument (design time) - BB3. Som API-konsument ønsker jeg å gjøre spørringer som gir meg dataene jeg har rettighet til å få (og ikke blir blokkert tilgang fordi API-et bare gir tilgang til mer data enn jeg har rettigheter til), slik at jeg kan få tilgang til data [rettigheter] )

(Norwegian Entity Register (Bus - Entity Registry API)

(BAM13 - Som ansvarlig for API-management ønsker jeg at brukerne av mine API-er skal kunne gi innspill til endringer av mine API-er, slik at jeg gjøre API-ene mine mer brukervennlige. - API-management)

(TIlgjengeliggjøring og utveksling - Som katalogeier (FBK) ønsker jeg å kunne vise informasjon som som standard for begrepsbeskrivelser stiller krav til eller anbefaler, slik at jeg er konform med registreringsløsning for begrep, og kan tolke det som kommer fra lokale kataloger over samme format. )

(Felles rammeverk - BTI003 Som innkjøper av fagsystemer ønsker jeg at Statens Standardavtaler inneholder krav til at leverandøren skal tilgjengeliggjøre API-er og data, slik at jeg får tilgang til og slipper å kjøpe tilbake mine egne data. )

(Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier. - BB19. Som API-konsument ønsker jeg å diskutere semantiske og tekniske spørsmål i en åpen kanal (wiki, github issues el liknende) for APIet jeg bruker, slik at brukerne kan hjelpe hverandre og tilbyder kan kommunisere åpent med sitt økosystem. [nettverk, dokumentasjon] )

Risk Management (Program Management Office - Implementation Projects)

(data.norge.no API-høster - data.norge.no portal)

(Melding uten gjenbruksmulig eller preutfylling - 201. Som tjenesteutvikler ønsker jeg å kunne knytte en modell til en kategori slik at jeg kan sortere modellene hensiktsmessig.)

(Som dataeier ønsker jeg at relevante opplysninger fra API-beskrivelsen er tilgjengelig i datasettbeskrivelsen slik at jeg unngår dobbeltarbeid - BFDK08 - Som datasetteier (som beskriver datasett i datakatalogen) ønsker jeg å kunne plukke fra API-beskrivelsen dataelementene som jeg ønsker å ta med i datasettbeskrivelsen, slik at dataelementene jeg tar med gjenspeiler det som APIet virkelig kan tilby. )

(API-katalogen - 14. Som API-forvalter/eier ønsker jeg en ensartet og samlet API-katalog slik at det blir enklere å publisere informasjonen.)

(Enterprise Continuum - Architectures)

(API-konsument (design time) - BB12. Som API-konsument ønsker jeg at API-ene støtter de “connector”-teknologiene som brukes av mine foretrukne verktøy for sammenstilling, analyse og visualisering, f.eks. Tableau, slik at jeg slipper å lage en mellomløsning/laste ned datasett for å analysere dem [samhandlingsevne] )

(Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier. - BA52. Som API-konsument ønsker jeg en enkel måte å rapportere inn feil i datakatalog (f.eks. Lenker som ikke fungerer) slik at jeg slipper å bla i utdatert innhold. )

(Som API-konsument ønsker jeg at API-beskrivelser er oppdaterte, og at API-er som ikke lenger er tilgjengelig/deprecated fjernes fra katalogen slik at jeg ikke studerer beskrivelser som ikke kan brukes - BA36. Som API-konsument ønsker jeg at noen tar jobben med å holde oversikt over om API-er er tilgjengelige, utilgjengelige, stabilt, deprecated etc slik at jeg slipper å begynne å ta det i bruk først før jeg oppdager det.)

(Felles rammeverk - Standardisering - Grensesnitt API/mikrotjeneste)

( BFP018: Som API-konsument ønsker jeg at apiene inneholder referanser til lokale kodeverk som forklarer innholdet i apiene slik at jeg forstår detaljene i apiene. - API-konsumenter forvaltningen og proffesjonelle)

(Felles rammeverk - BA7. Som API-konsument ønsker jeg selvforklarende API-er slik at jeg kan komme raskt i gang, få raskt nytte av API-et. )

(Tilgangsstyring - authorization)

(En tjeneste - Sluttbruker)

(Felles rammeverk - BA9. Som API-konsument ønsker jeg at API-et er tilrettelagt for bruk, og ikke bare speiler innholdet i en database, slik at jeg kan slippe å forholde meg til et fagdomene, sette meg inn i interne kodeverk [brukerorientert, ikke avsenderstyrt …] )

(Som API-konsument ønsker jeg referanser til dokumentasjon som ikke beskrives i API-beskrivelsen slik at jeg kan nøste meg videre - BB15. Som API-konsument ønsker jeg at relevante opplysninger som ikke er tilgjengelig i API-et er omtalt i dokumentasjonen, slik at jeg kan bruke API-et riktig. [dokumentasjon] )

(Premissgiver - Kvalitetskrav til API/mikrotjeneste - BA54. Som API-konsument ønsker jeg REST-API-er i tråd med REST-prinsippene/beste praksis slik at jeg kan bygge på erfaringene mine med andre REST-API-er, og forstå effekten av kallene i API-et med minst mulig teknisk dokumentasjon. )

( BFP001: Som API-forvalter ønsker jeg at det knyttes opplysninger om sikkerhetsvurderinger tilknyttet felt i API’et (identifiserende, lokaliserende, krav til sikring, osv.) slik at hensyn til innebygd personvern i større grad er ivaretatt for det datasettet som publiseres. - API-konsumenter forvaltningen og proffesjonelle)

(Nasjonalt - Altinn Autorisasjon)

( BAM07 - Som leverandør av API-management-verktøy ønsker jeg å kunne publisere dokumentasjon om API fra mitt API management verktøy til en felles offentlig API katalog - API-management)

(Lokal datasett registreringsløsning - 2-2 Som datasetteier ønsker jeg å registrere våre datasett i Lokal datakatalog i henhold til DCAT slik at jeg kan dele dem i felles datakatalog.)

(EPOS 2: Som API-forvalter ønsker jeg å registrere mine API-er slik at de kan gjøres tilgjengelig for andre - Som API-forvalter ønsker jeg en godt dokumentert felles løsning for registering av API-beskrivelser slik at jeg slipper å installere egne verktøy.)

( Når jeg kjøper noe i en nettbutikk vil jeg at de nødvendige personalia blir fylt ut automatisk, så lite som mulig, men nok at butikken får sendt produktene til riktig adresse. - Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv)

3 (Begrepskatalog GUI - Begrepskatalog API)

(Mikrotjenesten/API-et - BA54. Som API-konsument ønsker jeg REST-API-er i tråd med REST-prinsippene/beste praksis slik at jeg kan bygge på erfaringene mine med andre REST-API-er, og forstå effekten av kallene i API-et med minst mulig teknisk dokumentasjon. )

(Contract - )

(Dataobjekt - Forretningsobjekt)

registrert i (DCAT-AP-NO v2.0 - FDK-høsting ADM)

(Felles rammeverk - BA12. Som API-konsument ønsker jeg å hente inn data uavhengig av dataenes egentlig form slik at den ikke endrer seg når dataformatet endres. )

(Applikasjon 1 - API 1)

(Mikrotjenesten/API-et - BB1. Som API-konsument ønsker jeg et spørregrensesnitt (SQL-aktig/SPARQL/ODATA/GraphQL/NoSQL) mot API-et slik at jeg kan utforske datasettet og datasettets struktur/datamodell interaktivt som suplement til å lese dokumentasjon )

(API-beskrivelsen - BA5. Som API-konsument ønsker jeg at alle begreper linker direkte til en forklaring av begrepet slik at jeg slipper å lete gjennom dokumentasjonen. [kommentar: forskjell på begrep i den tekniske dokumentasjonen (f.eks. parameter i forespørsel) vs. begrep i datasettet (f.eks. fagtermer)] )

(API-tilbyder - 16. Som API-forvalter ønsker jeg å vite av hvem og hvor ofte mine API-er brukes (trafikkdata og bruksmønstre), slik at jeg optimere tilgang til API-er og ta stilling til hvilke API-er som eventuelt skal avvikles, samt kunne få grunnlag for å kunne rapportere på gevinstrealisering. )

(Felles rammeverk - BB32. Som API-konsument (datajournalist) ønsker jeg at strukturen i datasettene er stabile, slik at jeg ikke trenger gjøre endringer i min integrasjon/kode når nye versjoner hentes. [forutsigbarhet] )

(BB1. Som API-konsument ønsker jeg et spørregrensesnitt (SQL-aktig/SPARQL/ODATA/GraphQL/NoSQL) mot API-et slik at jeg kan utforske datasettet og datasettets struktur/datamodell interaktivt som suplement til å lese dokumentasjon - Åpne data statistikk, datajournalistikk og stordata)

(API-tilbyder - 31. Som API-portaleier ønsker jeg å få inn statistikk fra API-forvaltere slik at vi kan få et overordnet oversikt for hele sektoren/landet. )

(21. Som API-forvalter ønsker jeg å få en effektiv kanal for å få tilbakemeldinger og behov fra de som bruker API-ene mine, slik at det blir lettere å prioritere riktig ved videreutvikling av API-ene [styrke dialog med brukerne av API-ene] - API-forvalter og API katalogeier)

(Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API - BA1. Som API-konsument (student) ønsker jeg å filtrere på dataformater i oversikter over (åpne) API-er slik at jeg kan finne API-er i det formatet jeg ønsker å lære mer om eller filtrere ut de jeg ikke kan noe om.)

(Prosess, involvering og kvalitetssikring - Som begrepseier ønsker jeg at kun de som skal ha tilgang har tilgang til å redigere på innhold jeg eier)

(Krav (EPOS og nødvendige krav) - Som API-konsument ønsker jeg at API-beskrivelser samles slik at det er lett å få oversikt )

(Enhetsregisteret API - er:Organization)

(Offentlig Virksomhet - en informasjonsmodel-katalog i virksomheten)

(Felles rammeverk - BTI011 Som API-tilbyder/privat grossist (som er databehandler for innrapportering og tilgjengeliggjøring av informasjon), ønsker jeg at det finnes et forum / nettverk der dataeiere og databrukere utarbeider gode krav til tilgjengeliggjøring og tilbakerapportering av aggregert informasjon. )

( BB8. Som API-konsument ønsker jeg at utforskingsfasen/exploration/discovery gir meg rask oversikt og innsikt slik at jeg minimerer tiden jeg bruker på å velge et utsnitt eller må bruke egne verktøy for å skaffe meg oversikt. [dokumentasjon] - Åpne data statistikk, datajournalistikk og stordata)

(EPOS 7: Som API-konsuement ønsker jeg å forstå hvordan endringer varsles slik at jeg kan fange opp endringer - Som API-konsument ønsker jeg informasjon hvordan endringer i modell varsles slik at jeg kan fange opp endringer)

(Søk og oppslag API-beskrivelser - Altinn Studio (Tjeneste 3.0))

(xbrl:AnnualAccount - Annual accounts)

(Database - Dataobjekt)

(Skjemamodell - )

(API-katalogen - BFDK03 - Som forretningsutvikler ønsker jeg å se detaljerte beskrivelser av APIene, slik at jeg kan vurdere om de er av tilstrekkelig kvalitet for bruk i mine tjenester )

( Som pasient vil jeg at fastlegen skal ha tilgang til treningsdata (helst AI bearbeidet) (med automatisert varsling om avvik?) for å bidra til bedre, raskere og billigere diagnostisering - MyData, viderebruk av personopplysninger )

(BFP027: Som API-konsument ønsker jeg at dokumentasjonen til API-er jeg skal bruke har informasjon om kvalitet og tilgjengelighet, slik at jeg slipper mange henvendelser til API-tilbyder for å få svar på enkle ting. - API-konsumenter forvaltningen og proffesjonelle)

(API-katalog - API tilbyder)

(Informasjonsmodell-katalog - Søk og oppslag informasjonsmodeller)

(Bruk - Som forretningsutvikler ønsker jeg å kunne generere rapporter og visuelle framstillinger av begrep, slik at jeg enkelt kan se hvordan ulike begrep forholder sweg til hverandre og oppdage nye sammenhenger)

( BFP009: Som API-konsument ønsker jeg å få dokumentere hvordan en kan oppdatere en egen kopi slik at en til hver tid bruker korrekte data. - API-konsumenter forvaltningen og proffesjonelle)

(Informasjonsforvaltning - Implement)

(Som API-konsument ønsker jeg at rettslige rammer og lisens er tydelig beskrevet slik at jeg kan vurdere om det er forenelig med min bruk av dataene - BA30. Som API-konsument ønsker jeg informasjon om hvilke hjemler som gir tilgang til API-er der tilgangen er begrenset, slik at jeg kan vurdere om min virksomhet har lov til å benytte API-et til det aktuelle formålet. )

(Dokumenttype - API-spesifikasjon)

(Forretningsutvikler - BFDK01 - Som forretningsutvikler ønsker jeg å se hvilke datasett som tilbyr API, slik at jeg kan vurdere om det kan brukes i mine tjenester.)

(API manager - en API-katalog i virksomheten)

(A Technology Service - A service in a container)

(EPOS 4: Som API-konsument ønsker jeg å finne detaljert beskrivelse av API-ene slik at jeg kan vurdere om jeg kan benytte API-et i mine tjenester - Som API-konsument ønsker jeg å kunne sammenlikne API slik at jeg kan vurdere om et API passer bedre enn et annet)

(API-beskrivelsen - BA17. Som API-konsument ønsker jeg beskrivelse av API-et sin kapasitet slik at jeg vet om jeg trenger en egen server for sluttbrukerapplikasjoner ved svært høy trafikk.)

(API-tilbyder - 17. Som API-forvalter ønsker jeg å vise frem eksempel på bruk av mine API-er slik at verdien av API-ene blir synliggjort og det kan inspirere flere til å bruke API-ene og hvordan bruke API-ene. )

(API-konsument (design time) - Som API-konsument ønsker jeg å vite hvilken interaksjonsform som tilbys i APIet (spørring, feed, fil) , slik at jeg kan vite om det dekker mine behov. )

(Brønnøysundregistrene - Produkt)

(Nasjonalt - Informasjonsmodell)

(Tilgangskontroll (kun mulig for interne til å se personopplysninger tilknyttet dataeier etc.) - Difi)

(BA41. Som API-konsument som benytter verktøy for å generere deler av kildekoden ønsker jeg at API-et er dokumentert iht “Open API Specification”, slik at jeg kan bruke kodegenereringsverktøy for å generere mye av den kildekoden som trengs for å bruke API-et fremfor å måtte skrive den selv [ref epost] - Studenter, gründere og app-utviklere)

(A service in a container - A user)

(EPOS 1: Som API-konsument ønsker jeg at API-beskrivelser samles slik at det er lett å få oversikt - Som API-konsument ønsker jeg at API-beskrivelser er oppdaterte, og at API-er som ikke lenger er tilgjengelig/deprecated fjernes fra katalogen slik at jeg ikke studerer beskrivelser som ikke kan brukes)

(Premissgiver - styring dokumentasjon av API-er - BTI009 Som konsument av offentlig data ønsker jeg en koordinert forvaltning av offentlig master data slik at jeg kan utvikle anvendelser/analyser med forutsigbar kvalitet og fornuftige økonomiske og juridiske betingelser. )

(Datasett-eier - Som dataeier ønsker jeg å skille mellom datasettbeskrivelser som skal tilgjengeliggjøres i Felles datakatalog og dem som kun skal være tilgjengelig i Lokal datakatalog, slik at vi kun deler med Felles datakatalog den omtalen (feltene) om datasett vi ønsker å dele.)

(Begrepskatalog API - Etatene skal beskrive sin tolkning av begreper i lovverk, forvaltningsstandarder og forvaltningspraksis i egen begrepskatalog. Begrepsbeskrivelsene skal bl.a. legge til rette for at opplysningene i datasettene kan beskrives eksplisitt, f.eks. hva inngår i “likningsverdi”. Begrepsbeskrivelsene skal være tilgjengelige slik at regelverksutvikling og digitaliseringsprosjekter kan identifisere forenklinger. )

(en API-katalog i virksomheten - API-beskrivelse (OAS))

(Prosess, involvering og kvalitetssikring - Som begrepseier ønsker jeg å involvere andre som er interessenter til begrepet, slik at vi får en tverrfaglig konsensus om innholdet)

(Felles datasettkatalog API - Harvester-DB)

(Som API-konsument ønsker jeg å vite hvilken interaksjonsform som tilbys i APIet (spørring, feed, fil) , slik at jeg kan vite om det dekker mine behov. - Informasjonsforvaltning fagmiljø)

(API-katalogen - 28. Som API-katalogeier ønsker jeg å, slik at jeg kan ha en total oversikt over API-ene våre kunne vite hvilke API-er min virksomhet tilbyr (og forvalte de på felles måte, vite hvem som bruker hvilke API-er osv.). )

(API-konsument (design time) - 32. Som API-bruker ønsker jeg å registrere en anvendelse slik at jeg kan oppgi den i API-kallet. Alternativt: Som API-forvalter ønsker jeg at brukere kan registrere seg med en ID som de bruker i API-kallet slik at jeg kan koble trafikk og anvendelse. [f.eks. ved overbruk av API-et kan man lett kontakte den som har satt opp anvendelsen] )

( Som brukar er eg villig til å dele mine posisjonsdata slik at ein kan verifisere at eg har tatt buss-reiser og dermed …. kan eg få statistikk om kor mykje eg har reist kollektivt og dette kan brukast til … Premisset for dette er at alle bussar som køyrer kollektivtrafikk har ordentleg GPS-sporing, og at ein har tilgang til historiske posisjonsdata for bussane slik at ein kan kryssjekke kvar og når bussane faktisk har køyrt med mine personlege posisjonsdata. - Som sluttbruker ønsker jeg å gi samtykke til at en offentlig myndighet kan innhente mine data fra en 3dje part slik at jeg slipper å tilgjengegliggjøre dataene selv.)

(EPOS 2: Som API-konsument ønsker jeg en grunnleggende informasjon om API-et som er oppdatert og forståelig lsik at jeg kan ta API-et i bruk - Som API-konsument ønsker jeg at dokumentasjonen er genererert fra kode slik at jeg kan stole på at den er oppdatert)

(Informasjonsmodell-katalog - Tjenesteutvikler)

(Registreringsapplikasjon datasett - Felles datakatalog portal (fellesdatakatalog.brreg.no))

(Felles - Registreringsapplikasjon datasett)

(Kapabilitetsoversikt - API tilbyder)

(API-detaljer - Open API Specification)

( BB10. Som API-konsument ønsker jeg mulighet til å innhente data om tekstdatasett slik at jeg kan lage analyser av disse og koble til andre kilde. [tekst som data] - Åpne data statistikk, datajournalistikk og stordata)

(Offentlig Virksomhet - Datasett-eier)

(Premissgiver - styring dokumentasjon av API-er - BFP006: Som API-konsument ønsker jeg at det ikke er for rigide krav til dokumentering og til selve APIet slik at det ikke hemmer rask utvikling av API )

(Nasjonalt - Skrivebruker)

(EPOS 3: Som API-konsument ønsker jeg at beskrivelsen forklarer kall og innholdet i responsen slik at jeg kan forstå dataene jeg mottar - Som API-konsument ønsker jeg referanser til brukte kodeverk slik at jeg kan forstå hvordan de skal fortolkes)

(Mikrotjenesten/API-et - BB34. Som API-konsument ønsker jeg å kunne se når hvilke deler av et datasett som er endret slik at jeg kan analysere endringer i data. [varsel] )

(API-konsument (design time) - BB26. Som API-konsument ønsker jeg at API-ene jeg har tilgang til er de samme som API-forvalteren selv benytter til sin tjenesteutvikling, slik at jeg kan ha tillit til at forvaltning og videreutviklingen av API-ene gis prioritet og er verdt å bruke tid på å lære, gjøre bruk av [tjenestenivå/sla] )

(Undersøke, gjenfinne, få oversikt - Som medarbeider ønsker jeg å få oversikt over informasjonen virksomheten forvalter og hva den betyr, slik at jeg kan utføre oppgaver pva virksomheten)

(en API-katalog i virksomheten - API tilbyder)

(Registreringsapplikasjon API - API-spesifikasjon)

(API-katalogen - 25. Som API-forvalter som forvalter API-er til autoritative data ønsker jeg at API-katalogen skal prioritere presentasjon av mine API-er fremfor API-er som tilbyr samme data, men fra ikke-autoritative kilder, slik at API-brukerne ikke ubevisst bruker ikke-autoritative data )

(Virksomheter - Datasett)

(API-katalogen - Som API-eier ønsker jeg å publisere API-er som ikke kan knyttes til et datasett slik at også mine mine API-er som gjør beregninger e.l. kan publiseres)

(Regnskapsdata publiserer - Åpent Regnskapsdata API (maskinlesbart))

(Contract: openAPI specification - )

(API-katalogen - API-management)

(FDK-høsting ADM - GUI FDK-høsting ADM)

(Meldingsmodell - )

(Andre komponenter - DCAT-AP-NO v2.0)

(API-katalogen - 22. Som en API-forvalter med allerede eksisterende API-katalog, ønsker jeg at løsningen er fleksibel(?)/legger til rette for automatisk høsting, slik at jeg kan vedlikeholde dokumentasjonen min lokalt. )

(BB29. Som API-konsument ønsker jeg en god mekanisme for å få beskjed om endringer i API eller dataformat (f.eks. ikke-brytende-endring som nye felt i dataformatet) slik at jeg kan tilpasse konsum av data når dataformatet blir endret eller utvidet.[varsel] - Åpne data statistikk, datajournalistikk og stordata)

(API-konsument (design time) - BFDK06 - Som arkitekt ønsker jeg å se hvilke data jeg må benytte for å gjøre oppslag mot et API og hvilke data jeg får tilbake slik at jeg kan planlegge design av løsning. )

(API-konsument (design time) - BFP033: Som API-konsument ønsker jeg at API-et er avledet av en informasjonsmodell og Masterdata, som både sikrer konsistens mellom API og informasjonsmodell og gir mer og bedre dokumentasjon for API-et. )

(Registerenhet i Belgia - Lenkede data)

(Lokal registreringsløsning - Som datasetteier ønsker jeg å bruke egne kodeverk ( for eksempel)i registreringen av datasettene slik at jeg sikrer at informasjonen tilknyttet datasettene er oppdatert i forhold til gitte standarder )

(Felles datakatalog portal (fellesdatakatalog.brreg.no) - Bruker)

( Når jeg flytter til en ny kommune/et nytt sted, vil jeg bli spurt om jeg ønsker å bytte til ny fastlege på mitt nye bosted, med en oversikt over tilgjengelige fastleger med ledig kapasitet. - Som sluttbruker ønsker jeg at en offentlig aktør skal ha tilgang til data om meg hos en annen offentlig aktør)

(API-konsument (design time) - BB8. Som API-konsument ønsker jeg at utforskingsfasen/exploration/discovery gir meg rask oversikt og innsikt slik at jeg minimerer tiden jeg bruker på å velge et utsnitt eller må bruke egne verktøy for å skaffe meg oversikt. [dokumentasjon] )

(Begrepskatalog API - Begrepskatalog GUI)

(Mikrotjenesten/API-et - BFP025: Som API-konsument ønsker jeg å se hvilke muligheter det finnes for konfigurasjon både hos meg og hos API-leverandør for å begrense tilgjengelig data til mitt faktiske formål. Kommentar: Dataminimering?)

(Search-API - Search)

(FDK - FDK-høsting API)

(Organzation JSON-LD - Organization)

(API-tilbyder - 2. Som API-forvalter ønsker jeg at katalogen gir føringer for hvordan API-ene mine skal dokumenteres, etter “beste praksis”, så jeg slipper å sette meg inn i/holde meg oppdatert på hva som er beste praksis for API-dokumentasjon [frigjøre ressurser/bedre kvalitet] )

(Som API-forvalter ønsker jeg å tilgjengeliggjøre API-et i en sanntids-tjenestekatalog (SMP) slik at den kan brukes til capability lookup i sanntids meldingsutveksling - Som API-forvalter ønsker jeg å kunne få overført mine API-definisjoner til en runtime tjenestekatalog (SMP, CapabiliityLookup eller den tekniske endepunktedelen av KoFuVi?) for å kunne legge til metadata for runtime-kall slik at jeg ikke må registrere mine API-definisjoner dobbelt.)

(TBX-AP-NO - )

(data.norge.no portal - API-katalog)

(Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles - BAM09 - Som ansvarlig for API-management ønsker jeg å kunne administrere nøkler gitt til de enkelte konsumentene slik at jeg enkelt kan fjerne ev. misbruk av API-et )

( Når Oslo kommune trenger data om hvordan jeg beveger meg -- for å drive byutvikling, prioritere sykkelstier m.m., kan jeg gi dem mine Strava-data - MyData, viderebruk av personopplysninger )

( BB15. Som API-konsument ønsker jeg at relevante opplysninger som ikke er tilgjengelig i API-et er omtalt i dokumentasjonen, slik at jeg kan bruke API-et riktig. [dokumentasjon] - Åpne data statistikk, datajournalistikk og stordata)

(API-katalogen - Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer)

(Nasjonalt - Tjenestekatalog GUI)

(Mikrotjenesten/API-et - BA7. Som API-konsument ønsker jeg selvforklarende API-er slik at jeg kan komme raskt i gang, få raskt nytte av API-et. )

(Som API-forvalter ønsker jeg en godt dokumentert felles løsning for registering av API-beskrivelser slik at jeg slipper å installere egne verktøy. - 9. Som API-forvalter ønsker jeg en felles løsning for API-dokumentasjon som er så god at jeg selv ønsker å bruke løsningen fremfor andre verktøy )

(API-konsument (design time) - BB18. Som API-konsument ønsker jeg at kildekoden til API-tjenesten er tilgjengelig som åpen kildekode, slik at jeg kan lese kildekode for å forstå APIet og kunne bruke det optimalt [dokumentasjon] )

(BA17. Som API-konsument ønsker jeg beskrivelse av API-et sin kapasitet slik at jeg vet om jeg trenger en egen server for sluttbrukerapplikasjoner ved svært høy trafikk. - Studenter, gründere og app-utviklere)

(Som tjenesteutvikler og data scientist ønsker jeg å kunne annotere datasettene etter egen tematiske inndeling - 7. Tema – interne tema fremfor de generelle EU-temaene)

(Felles rammeverk - BA44. Som API-konsument ønsker jeg intelligente API-er som kan f.eks. filtrere, aggrerere, gruppere slik at jeg bare få inn de resultater jeg trenger av hensyn til personvern, kapasitet etc. )

(en begrepskatalog i virksomheten - Etatene skal beskrive sin tolkning av begreper i lovverk, forvaltningsstandarder og forvaltningspraksis i egen begrepskatalog. Begrepsbeskrivelsene skal bl.a. legge til rette for at opplysningene i datasettene kan beskrives eksplisitt, f.eks. hva inngår i “likningsverdi”. Begrepsbeskrivelsene skal være tilgjengelige slik at regelverksutvikling og digitaliseringsprosjekter kan identifisere forenklinger. )

(Felles rammeverk - BB29. Som API-konsument ønsker jeg en god mekanisme for å få beskjed om endringer i API eller dataformat (f.eks. ikke-brytende-endring som nye felt i dataformatet) slik at jeg kan tilpasse konsum av data når dataformatet blir endret eller utvidet.[varsel] )

(API-konsument (design time) - BB27. Som API-konsument ønsker jeg å kunne laste ned en komplett versjon av datasettet i tillegg til API-funksjonalitet slik at jeg kan kjøre analyse på en lokal kopi av datasettet der dette er mest hensiktsmessig.[nedlasting] )

(Felles rammeverk - BB17. Som API-konsument ønsker jeg at spørringer, programkode og bibliotek som andre utvikler gjøres tilgjengelig som åpen kildekode slik at jeg kan dra nytte av disse i min prosess [gjenbruk av kildekode] )

(Felles rammeverk - BAM16 - Som ansvarlig for API-management ønsker jeg tydelige føringer på hvordan mitt API skal dokumenteres og gjøres tilgjengelig i en felles API-katalog slik at arbeidet kan planlegges, fordeles og operasjonaliseres i min virksomhet med et forutsigbart omfang. )

(API-beskrivelsen - BA55. Som API-konsument, ønsker jeg at API-et er designet etter en felles “beste praksis” som gjelder for API-er i API-katalogen, slik at jeg lett kjenner meg igjen på tvers av API-ene i katalogen.)

( BAM12 - Som ansvarlig for API-management ønsker jeg et handlingsrom slik at jeg kan bestille endringer i datamodell/informasjonsmodell når behov/muligheter endrer seg. - API-management)

(Modellkatalog, Datamodell, Data dictionary - BAM13 - Som ansvarlig for API-management ønsker jeg at brukerne av mine API-er skal kunne gi innspill til endringer av mine API-er, slik at jeg gjøre API-ene mine mer brukervennlige. )

(Mikrotjenesten/API-et - BA21. Som API-konsument ønsker jeg et API som gir godt strukturerte responser slik at data er lett å bruke. )

(Referansedata - Organisasjonskatalog)

(Nasjonalt - Datasett søk)

(Altinn - Som utvikler i Altinn ønsker jeg å kunne registrere de API jeg utvikler for mine T.3 applikasjoner slik at <hensikt>)

(Spesifikasjon og standard for datasett (DCAT-AP-NO) - )

(Oppdage API - Finn API)

(Harvester Admin-GUI - Felles API-katalog Admin)

(Registeringsløsning datasett - Datasettkatalog)

(Informasjonsforvaltning - Enterprise Continuum)

( Som brukar er eg villig til å dele mine posisjonsdata slik at ein kan verifisere at eg har tatt buss-reiser og dermed …. kan eg få statistikk om kor mykje eg har reist kollektivt og dette kan brukast til … Premisset for dette er at alle bussar som køyrer kollektivtrafikk har ordentleg GPS-sporing, og at ein har tilgang til historiske posisjonsdata for bussane slik at ein kan kryssjekke kvar og når bussane faktisk har køyrt med mine personlege posisjonsdata. - MyData, viderebruk av personopplysninger )

(API-konsument (design time) - BA50. Som API-konsument, ønsker jeg å kunne gi tilbakemeldinger til god (eller dårlig) “beste praksis” for API-er, slik at dette kan være til hjelp for framtidige API-er som utvikles. )

(API-konsument (design time) - BFP015: Som API-konsument ønsker jeg at nye versjoner av apiene blir gjort tilgjengelig før de settes i produksjon slik at jeg er forberedt. )

(Regnskapsregisteret - Regnskap)

(API-katalog - Søk og oppslag API-beskrivelser)

(Som API-konsument ønsker jeg å kunne gi strukturerte tilbakemeldinger (f.eks. feil) og endringsforslag for tjenester slik at tjenestene kan forbedres - Skatteetaten)

(Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer - Som ansvarlig for API-Management ønsker jeg en enkel måte å varsle endringer i oppetid )

(API-beskrivelsen - Som API-konsument ønsker jeg referanser til brukte kodeverk slik at jeg kan forstå hvordan de skal fortolkes)

(Veiledning - Beste praksis - API/mikrotjeneste - BB34. Som API-konsument ønsker jeg å kunne se når hvilke deler av et datasett som er endret slik at jeg kan analysere endringer i data. [varsel] )

(API-katalogen - 21. Som API-forvalter ønsker jeg å få en effektiv kanal for å få tilbakemeldinger og behov fra de som bruker API-ene mine, slik at det blir lettere å prioritere riktig ved videreutvikling av API-ene [styrke dialog med brukerne av API-ene] )

(BFDK11 - Som konsument ønsker jeg å abonnere på varslinger om etablering, endring, driftsstans og avvikling av API’er slik at jeg kan tilpasse meg endringer - FDK)

(Som virksomhet ønsker jeg en egen oversikt for intern bruk over datasett slik at... - En lokal datasettkatalog med virksomhetsintern informasjon, til bruk for “orden i eget hus”, GDPR, statistikk etc og som er grunnlaget for informasjonen som synliggjøres i felles datakatalog )

(Felles rammeverk - Premissgiver - Kvalitetskrav til API/mikrotjeneste)

(Virksomheter - Dataobjekt)

(Begrepskatalog API - data.norge.no portal)

(API-katalogen - BAM07 - Som leverandør av API-management-verktøy ønsker jeg å kunne publisere dokumentasjon om API fra mitt API management verktøy til en felles offentlig API katalog )

(Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted. - 30. Som API-portaleier ønsker jeg at alle skal tilby sin informasjon på samme format, OG at alle har et eget API som beskriver sin katalog eller sitt API, slik at portalen enklest mulig kan høste og sammenstille informasjon om API-er. )

(Standardisering - API beskrivelser - BTI004 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å redusere mine forvaltningskostnader, for eksempel for å få redusert manuelle henvendelser )

(Registration-DB - Registration-BACKEND)

(Harvester-API - Harvester)

(Altinn Autorisasjon - Registreringsapplikasjon datasett)

(Felles rammeverk - 3. Som API-forvalter ønsker jeg at katalogen og dens underliggende spesifikasjoner og standarder gir krav jeg kan bruke i avtaler med leverandører/anskaffelser slik at jeg slipper å sette meg inn i hvilke krav jeg bør stille. )

(Bruk - Som forretningsutvikler ønsker jeg å få opp en oversikt over begreper som er relatert til hverandre, gjennom lik termbruk, likt rettsområde/bruksområde eller fagområde, slik at jeg kan se sammenhenger og gi innspill til forenkling)

(API-konsument (design time) - BB36. Som API-konsument (ETL) ønsker jeg å unngå å laste komplette datasett og heller få de delene som har endret seg siden sist jeg lastet ned datasett slik at jeg minimerer egen ressursbruk. [varsel] )

(API-katalogen - Som API-forvalter ønsker jeg en enkel måte å varsle endringer spesifikasjon av tjenester)

(API-katalogen - BB11. Som API-konsument (analytiker) ønsker jeg mulighet for å legg inn spørsmål, tips, eksempler knyttet til APIer slik at jeg kan øke min egen, andre brukere og api-forvalternes kjennskap om semantikk, selve APIen og bruk [økosystem] )

(EPOS 5: Som API-konsument ønsker jeg dialog med andre API-konsumenter og API-tilbydere slik at vi få hjelp og hjelpe hverandre - Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer)

((Behov for registrering av begreper) - Som begrepseier ønsker jeg å dele begrepsinnholdet mitt inn i gitte felter, slik at jeg kan beskrive begrep i tråd med anbefalte standarder)

(Felleskomponent - API-katalog)

(Felles rammeverk - BB22. Som API-konsument ønsker jeg å få dokumentasjonen fra samme sted som jeg henter ut data, slik at jeg vet at det er oppdatert og lett tilgjengelig. [dokumentasjon] )

(EPOS 4: Som API-konsument ønsker jeg å finne detaljert beskrivelse av API-ene slik at jeg kan vurdere om jeg kan benytte API-et i mine tjenester - BFDK03 - Som forretningsutvikler ønsker jeg å se detaljerte beskrivelser av APIene, slik at jeg kan vurdere om de er av tilstrekkelig kvalitet for bruk i mine tjenester )

(Contract - )

(Felles rammeverk - BB13. Som API-konsument ønsker jeg at de tjenestene offentlig sektor har utviklet på sine egne API gjøres tilgjengelig som åpen kildekode, slik at jeg kan gjenbruke relevante deler av koden for mitt eget konsum av API-et. [gjenbruk av kildekode] )

(Begrep - )

(Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer - Som API-forvalter ønsker jeg en enkel måte å varsle endringer spesifikasjon av tjenester)

(Kartverket - Kommune JSON-LD )

Alignment (Program Management Office - Architecture Board)

(API-beskrivelsen - Som API-konsument ønsker jeg informasjon hvordan endringer i modell varsles slik at jeg kan fange opp endringer)

(Produkt - Grensesnitt)

(BA26. Som API-konsument ønsker jeg at API-et støtter CORS slik at jeg kan nå det fra en webapplikasjon uten å måtte gå via egen backend eller proxy. - Studenter, gründere og app-utviklere)

(13. Som API-forvalter ønsker jeg å kunne påvirke utformingen av felles nasjonale oppskrifter for API-beskrivelser slik at de dekker mine behov. - API-forvalter og API katalogeier)

(BA18. Som API-konsument ønsker jeg lenker til aktuelle kodeverk (f.eks. kommunenummer, næringskoder) slik at jeg lett kan hente støtte-datasett og dermed benytte datasettet fullt ut. - Studenter, gründere og app-utviklere)

(API-beskrivelsen - 35. Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de. )

( BFP026: Som profesjonell API-konsument ønsker jeg forutsigbare økonomiske og juridiske rammer rundt (helst åpen/gratis) tilgang til offentlig data slik at jeg kan lage gode business cases. - API-konsumenter forvaltningen og proffesjonelle)

(BFDK03 - Som forretningsutvikler ønsker jeg å se detaljerte beskrivelser av APIene, slik at jeg kan vurdere om de er av tilstrekkelig kvalitet for bruk i mine tjenester - FDK)

(Felles rammeverk - BA40. Som API-tilbyder* ønsker jeg retningslinjer og beste praksis for dokumentasjon av API-ene mine slik at jeg kan dokumentere så effektivt og bra som mulig. )

(register scope - API-katalog)

(Andre komponenter - en API-katalog i virksomheten)

(Mikrotjenesten/API-et - BA19. Som API-konsument ønsker jeg API der kodeverk (f.eks. kommunenummer, næringskoder) er en del av API-responsen slik at jeg slipper å utføre flere API-kall og hente fra ulike kilder for å få data jeg trenger.)

(Prosess, involvering og kvalitetssikring - Som begrepseier ønsker jeg å kunne skisse på innholdet før jeg ferdigstiller det, slik at jeg kan stå for innholdet faglig.)

(BFP025: Som API-konsument ønsker jeg å se hvilke muligheter det finnes for konfigurasjon både hos meg og hos API-leverandør for å begrense tilgjengelig data til mitt faktiske formål. Kommentar: Dataminimering? - API-konsumenter forvaltningen og proffesjonelle)

(Informasjonsmodell-katalog - data.norge.no portal)

(FDK - data.norge.no API-høster)

(API-konsument (design time) - BA11. Som API-konsument ønsker jeg at jeg kan bytte til nye versjoner av API-et når det passer meg [Kommentar frå Livar: Litt usikker på denne. Her er det kanskje snakk om versjonering av API, at ein sjølv kan velje når tid ein byttar til ny versjon av API? I motsetnad til at eit API ikkje er versjonert og ved "breaking-changes" så må ein forholde seg til når API-et gjer eit brått hopp til ny versjon?] )

(Mikrotjenesten/API-et - BB24. Som API-konsument (ETL) ønsker, jeg stabile API-er som er uavhengige av underliggende data slik at jeg ikke trenger å følge med endringer i data formater/strukturer. [forutsigbarhet] )

response (Hente API beskrivelser av en viss type (API spesifikasjon) - En konsument applikasjon)

(authorization - Datasettkatalog)

(API-katalogen - 7. Som API-forvalter har jeg behov for å selv velge hvor selve dokumentasjonen skal ligge, slik at jeg kan bruke de verktøyene som er mest hensiktsmessig til formålet. )

(API-katalog - Harvester Admin-GUI)

Harvesting (Begrepskatalog SKOS-AP-NO API - concept-cat-harvester)

(Entity Registry API - er:municipalityID)

(Brønnøysundregistrene - 2-3-1 Som datasetteier ønsker jeg å registrere kontaktinformasjon til dataeier, datasetteier og teknisk kontakt slik at interne behov oppfylles i henhold til interne krav)

(API-konsument (design time) - BB6. Som API-konsument ønsker jeg at semantikken rundt dataene er forklart (dataene er definert), slik at jeg kan ta et informert valg om å bruke dataene fordi jeg forstår kontekst, formål og omfanget av dem. [dokumentasjon] )

(Register API - Preutfylling)

(?? - )

(API-mangement verktøyleverandør - BAM06 - Som ansvarlig for API-management ønsker jeg å kunne fordele eierskap og ansvar for de enkelte API-ene til det forretningsområdet som er dataforvalter/dataeier, slik at de kan være mest mulig selvbetjente og redusere flaskehalser (“publisher portal”)/sikre nærhet og dermed kvalitet (ansvarliggjøring av den rette aktøren) )

(Søketjeneste for geografiske administrative områder - Registreringsapplikasjon datasett)

(API-katalogen - BA52. Som API-konsument ønsker jeg en enkel måte å rapportere inn feil i datakatalog (f.eks. Lenker som ikke fungerer) slik at jeg slipper å bla i utdatert innhold. )

(Begrepskatalog API - Begrepskatalog GUI)

(API-katalogen - BFDK10 - Som konsument ønsker jeg å få en liste over de datasett jeg vil ha tilgang til, presentert med grunnleggende informasjon om API slik at jeg sammenligne egenskaper (for eksempel hvilken protokoll som er brukt) ved API-ene)

(Altinn Autorisasjon - Register scope)

(Altinn data modellering - 211. Som tjenesteutvikler ønsker jeg at modellen til tjenesten automatisk blir opprettet når jeg starter med å lage brukergrensesnittet til tjenesten i skjemaklienten slik at jeg slipper å manuelt modellere modellen i etterkant og så koble denne til grensesnittet til tjenesten.)

(API-konsument (design time) - BFDK13 - Som konsument av et åpent api ønsker jeg informasjon om hvor pålitelig leveransen av data er (forventet oppetid, responstid ved feil osb) slik at jeg kan gjøre en tilstrekkelig ROS-analyser for min integrasjon )

(BA8. Som API-konsument ønsker jeg mulighet til enkelt å teste API-ene (utforske) f.eks. gjennom Swagger eller tilsvarende, slik at jeg raskere forstår API-et, og raskere klarer å bruke det (riktig) [ref BA7]. - Studenter, gründere og app-utviklere)

(Lokal datasett registreringsløsning - Som dataeier ønsker jeg at personopplysninger knyttet til dataeier etc. ikke publiseres til felles datakatalog)

(data.norge.no API - GUI FDK-høsting ADM)

(Premissgiver - Ytelseskrav til API/mikrotjeneste - BA16. Som API-konsument ønsker jeg at API-et tåler stor trafikk slik at jeg kan bruke API-et direkte i applikasjon)

(Som tjenesteutvikler og data scientist ønsker jeg å søke om tilgang til data slik at jeg kan få tilgang til dataene - 2. Informasjon om fremgangsmåte)

(Registreringsapplikasjon API - Utvid API-beskrivelse)

(Felles rammeverk - BFP030: Som API-konsument ønsker jeg å kunne spørre produsent om mer og bedre data slik at vi kan tilby et bedre og mer helhetlig bilde. )

(/login - Begrepskatalog GUI)

(Modelleringsforum - Som informasjonsarkitekt i et samhandlingsprosjekt har jeg behov for å se informasjonsmodellen til en samarbeidet etat slik at vi kan ...)

(Som potensiell API-konsument ønsker jeg å kjenne til livssyklus planer og garantier for en tjeneste (f.eks. nedleggelse/utfasing) slik at jeg ikke gjør meg avhengig av eksterne APIer som kan forsvinne - Skatteetaten)

(Altinn Studio (Tjeneste 3.0) - Designer Backend)

( BB23. Som API-konsument (stordata) ønsker jeg tilgang til tekster i maskinlesbart format og under en åpen lisens slik at jeg fritt kan bruke tekster i maskinanalyse av språk eller lignende.[tekst som data] - Åpne data statistikk, datajournalistikk og stordata)

(Begrep - )

(update delegation table - Delegering)

(Som dataeier ønsker jeg å kunne styre publiseringen av et datasett slik at den kan publisere enten til virksominternt publisering eller til felles datakatalog - 11. Publiseringsknapp)

(API-konsument (design time) - BA31. Som API-konsument ønsker jeg informasjon om eventuelle økonomiske betingelser for bruk av API-er, slik at jeg kan vurdere hvorvidt det er aktuelt å betale for bruk av API-et. )

(Behandlingsaktivitet katalog - Behandlingsaktivitet GUI)

(API-konsument (design time) - BFP016: Som API-konsument ønsker jeg en oversikt over hvilke versjoner som er tilgjengelig i hvilke miljø slik at jeg vet hva jeg kan teste mot. (prod og test) )

(Brønnøysundregistrene - 1-2 Som deltaker i utviklingen av nye digitale tjenester ønsker jeg å få oversikt over hvor i organisasjonen eierskapet til datasettet hører hjemme, slik at jeg kan identifisere hvilke data som kan være relevante for mine oppgaver.)

(TIlgjengeliggjøring og utveksling - Som ansvarlig virksomhet (begrepseier) ønsker jeg å kunne dele begreper med andre etter anbefalte standarder, slik at andre virksomheter (menneske og maskin) kan se begreper innenfor vårt domene.)

registrert i (API-katalog API - FDK-høsting ADM)

(en API-katalog i virksomheten - Hent alle API-beskrivesler)

leser (Datasettkatalog - Bruker)

(35. Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de. - API-forvalter og API katalogeier)

(EPOS 1: Som API-konsument ønsker jeg at API-beskrivelser samles slik at det er lett å få oversikt - Som API-forvalter ønsker jeg en å samle beskrivelser av API-ene våre og andres slik at det er enkelt å få oversikt over API-er og bruk)

(Som API-konsument ønsker jeg informasjon om kapasitet, ytelse og pålitelighet slik at jeg kan være sikker på at API-et kan benyttes i mine forretningskritiske tjenester - BA17. Som API-konsument ønsker jeg beskrivelse av API-et sin kapasitet slik at jeg vet om jeg trenger en egen server for sluttbrukerapplikasjoner ved svært høy trafikk.)

(Søk og oppslag API-beskrivelser - Finn API)

(Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API - 23. Som API-forvalter ønsker jeg at de API-ene jeg tilbyr skal være lette å finne og ta i bruk for de som har verdi av dem, slik at innsatsen jeg har lagt ned i API-ene får størst mulig verdi [forsvare kostnadene ved utviklingen/forvaltningen av API-ene/generere størst mulig nytte] )

( BB31. Som API-konsument ønsker jeg at datasett som er gjort tilgjengelig for nedlasting har et forutsigbart URL-regime for siste versjon og historiske data slik at nedlasting kan automatiseres. [nedlasting, forutsigbarhet] - Åpne data statistikk, datajournalistikk og stordata)

(Registry in Belgium - rov:Entity)

(Som API-konsuement ønsker jeg en tematisk oversikt over API slik at jeg lett kan finne fram - 35. Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de. )

(Virksomheter - Database)

(API-konsument (design time) - BA10.Som API-konsument ønsker jeg en indikasjon på hvor dynamisk datasettet er, slik at jeg har en idé om hvor ofte jeg trenger å lese data på nytt. )

(Felles rammeverk - BA54. Som API-konsument ønsker jeg REST-API-er i tråd med REST-prinsippene/beste praksis slik at jeg kan bygge på erfaringene mine med andre REST-API-er, og forstå effekten av kallene i API-et med minst mulig teknisk dokumentasjon. )

(Informasjonsforvaltning - Begrepskatalogen)

(Enhetsregisteret - mor-organisasjon)

(Veiledning - Beste praksis - API/mikrotjeneste - BB1. Som API-konsument ønsker jeg et spørregrensesnitt (SQL-aktig/SPARQL/ODATA/GraphQL/NoSQL) mot API-et slik at jeg kan utforske datasettet og datasettets struktur/datamodell interaktivt som suplement til å lese dokumentasjon )

(API-beskrivelse - Begrep)

(API-beskrivelse (OAS) - API-et)

(API-katalogen - Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de.)

(API-beskrivelsen - Som API-konsument ønsker jeg at API-beskrivelsen refererer til informasjonsmodeller slik at jeg forstår strukturen i API-ets respons)

(API-katalog - SecurityScheme)

(Altinn Studio (Tjeneste 3.0) - API manager)

(Felles rammeverk - BFP029: Som API-konsument ønsker jeg at offentlige dataeiere tilbyr APIer så tidlig som mulig (med tilsvarende varsling om datakvalitet) slik at jeg kan utvikle tjenester og bidra til kvalitetsforbedring av dataene. )

(A service in a container - A client)

(Andre API-kataloger - API-katalog)

(MVP søketjeneste API - Som API-konsument ønsker jeg at API-beskrivelser samles slik at det er lett å få oversikt )

(API-beskrivelse (OAS) - API-spesifikasjon)

(Ansatt - Som ansatt ønsker jeg å finne beskrivelser av våre datasett for å kunne vurdere nye tjenester i fohold til behov og ønsker som er meldt fra (slutt)brukerne)

(Oppdage API - Administrasjon av API-beskrivelser (design time))

(BA37. Som API-konsument ønsker jeg at tilgjengelige API-er er robuste slik at jeg kan anta at integrasjonen fungerer også ved høy trafikk - Studenter, gründere og app-utviklere)

(30. Som API-portaleier ønsker jeg at alle skal tilby sin informasjon på samme format, OG at alle har et eget API som beskriver sin katalog eller sitt API, slik at portalen enklest mulig kan høste og sammenstille informasjon om API-er. - API-forvalter og API katalogeier)

(API-katalogen - Som API-konsument ønsker jeg single sign on (SSO) mellom flere tjenester jeg benytter slik at jeg unngår separat autentisering mot hver enkelt tjeneste)

(Som API-konsument ønsker jeg informasjon om kapasitet, ytelse og pålitelighet slik at jeg kan være sikker på at API-et kan benyttes i mine forretningskritiske tjenester - BA28. Som API-konsument ønsker jeg informasjon om ytelsesmessige (svartid, antall oppslag) begrensninger i API-et, slik at jeg kan vurdere om API-et har god nok ytelse til mitt formål. )

(Maskin-porten - get token)

(en datasett-katalog i virksomheten - Som deltaker i utviklingen av nye digitale tjenester ønsker jeg å få oversikt over hvor i organisasjonen eierskapet til datasettet hører hjemme, slik at jeg kan identifisere hvilke data som kan være relevante for mine oppgaver.)

(Prosess, involvering og kvalitetssikring - Som interessent ønsker jeg å kunne gi tilbakemelding på begrepsinnhold, slik at jeg sikrer at mine faglige interesser ivaretas)

( Jeg lurer på om Osloskolen klarer å få mine barn til å reaching their full potential, og ønsker at en fancy ny utdanningstjeneste skal få tilgang til alle data Osloskolen har om mitt barns oppgaveløsning, f.eks. Hvor lang tid de bruker på ulike typer oppgaver, slik at dataene kan analyseres og jeg kan få et skreddersydd opplegg. - MyData, viderebruk av personopplysninger )

(API-tilbyder - Angi grovkonet tilgang)

(BFP029: Som API-konsument ønsker jeg at offentlige dataeiere tilbyr APIer så tidlig som mulig (med tilsvarende varsling om datakvalitet) slik at jeg kan utvikle tjenester og bidra til kvalitetsforbedring av dataene. - API-konsumenter forvaltningen og proffesjonelle)

(Som API-forvalter ønssker jeg å beskrive kjente kvalitetsvurderinger slik at konsumenten kan forstå API-et bedre - BA10.Som API-konsument ønsker jeg en indikasjon på hvor dynamisk datasettet er, slik at jeg har en idé om hvor ofte jeg trenger å lese data på nytt. )

(Lokal datasett registreringsløsning - Som tjenesteutvikler og data scientist ønsker jeg å kunne finne ut hva slags type data datasettet er slik at jeg kan vurdere egnethet)

(Informasjonsmodell-katalog - data.norge.no informasjonsmodell-høsting)

(Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier. - BA6. Som API-konsument ønsker jeg å kunne på en enkel måte gi kontekstavhengige tilbakemeldinger til API-forvalteren, slik at dokumentasjonen og eller API-et blir bedre. )

(en begrepskatalog i virksomheten - Registreringsløsning begrep)

(API-mangement verktøyleverandør - BAM07 - Som leverandør av API-management-verktøy ønsker jeg å kunne publisere dokumentasjon om API fra mitt API management verktøy til en felles offentlig API katalog )

(FDK-høsting API - GUI FDK-høsting ADM)

(Register - Datasett)

(Som API-forvalter ønsker jeg en å samle beskrivelser av API-ene våre og andres slik at det er enkelt å få oversikt over API-er og bruk - 31. Som API-portaleier ønsker jeg å få inn statistikk fra API-forvaltere slik at vi kan få et overordnet oversikt for hele sektoren/landet. )

(API-beskrivelsen - BB16. Som API-konsument ønsker jeg at støttedatasett (f.eks. kodelister) er omtalt i dokumentasjonen slik at jeg kan anvende data fullt ut.[dokumentasjon] )

(en begrepskatalog i virksomheten - Jurist)

(API-katalogen - Som API-eier ønsker jeg å angi at API’et skal være tilgjengelig i en runtime-tjenestekatalog (SMP/capability lookup) og Altinn tjenestekatalog/Authorization for samtykke og tilgangsstyring. )

(API-katalogen - BA25. Som API-konsument ønsker jeg at beskrivelser av API-er som ikke lengre er tilgjengelige, skal fjernes fra API-katalogen, slik at jeg slipper å lese om API-er som jeg uansett ikke kan bruke.)

adminstrasjon (Datasettkatalog - Datasett-eier)

(Felles datakatalog portal (fellesdatakatalog.brreg.no) - Informasjonsmodell-katalog)

(Felles datakatalog portal (fellesdatakatalog.brreg.no) - Søk og oppslag datasett-beskrivelser)

(Premissgiver - Betaling på API/mikrotjenester - BFP026: Som profesjonell API-konsument ønsker jeg forutsigbare økonomiske og juridiske rammer rundt (helst åpen/gratis) tilgang til offentlig data slik at jeg kan lage gode business cases. )

(Andre Informasjonsmodell-kataloger - data.norge.no informasjonsmodell-høsting)

(API-katalogen - Som API-forvalter ønsker jeg en å samle beskrivelser av API-ene våre og andres slik at det er enkelt å få oversikt over API-er og bruk)

(API-konsument (design time) - BB7. Som API-konsument ønsker jeg at det angis tydelig i dokumentasjonen hvilke data som er tilgjengelig, men også hva som ikke er tilgjengelig, slik at jeg slipper merarbeid pga. uklar dokumentasjon. [dokumentasjon] )

(Felles datakatalog portal (fellesdatakatalog.brreg.no) - Søk og oppslag begreps-beskrivelser)

(API-beskrivelsen - BB5. Som API-konsument ønsker jeg å få tilgang til eksempler på bruk av API-et slik at jeg kan se mulighetene for bruk og bedre forstå hva API-et er ment å brukes til. [dokumentasjon] )

(EPOS 5: Som API-konsument ønsker jeg dialog med andre API-konsumenter og API-tilbydere slik at vi få hjelp og hjelpe hverandre - Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et)

(Felles datasettkatalog API - Registration-DB)

(Melding uten gjenbruksmulig eller preutfylling - 214. Som tjenesteutvikler ønsker jeg muligheten til å maskinelt validere en modell slik at jeg raskt og enkelt kan få kontrollert at modellen ikke inneholder alvorlige feil og/eller mangler.)

(EPOS 8: Som API-konsument ønsker jeg informasjon om vilkår slik at jeg kan forstå om jeg kan bentytte API-et - Som API-konsument ønsker jeg informasjon om kapasitet, ytelse og pålitelighet slik at jeg kan være sikker på at API-et kan benyttes i mine forretningskritiske tjenester)

(Premissgiver - styring dokumentasjon av API-er - 6. Som API-forvalter ønsker jeg at de aktivitetene jeg må gjøre og de standardene jeg må forholde meg til for å gjøre API-dokumentasjonen tilgjengelig i en nasjonal API-katalog, også gir verdi for andre, kommersielle, internasjonale API-kataloger, f.eks. synliggjøring på søkemotorer, ref Schema.orgs arbeid med vokabular for WebAPI http://pending.webschemas.org/WebAPI )

(BA14. Som API-konsument ønsker jeg lenker til applikasjoner som bruker datasettet, slik at jeg kan finne gode eksempler på bruk av API-et og datasettet. [kommentar: også programvarebibliotek og anna kodeverk som er relevant - Studenter, gründere og app-utviklere)

(BA38. Som API-konsument ønsker jeg (kanskje ....) HATEOAS og linked data-baserte API (for eks. JSON-LD/RDF-representasjoner) slik at jeg kan se hvilke opsjoner jeg har basert på de responsene jeg allerede har fått (den tilstanden jeg er i). [Kommentar frå Steinar: “basert på én informant ... han var tydelig på at han hadde gode erfaringer med API-er med RDF-data”] - Studenter, gründere og app-utviklere)

(A service in a container - A user)

(Forretningsutvikler - Datakatalogen)

(Veiledning - Beste praksis - API/mikrotjeneste - BB29. Som API-konsument ønsker jeg en god mekanisme for å få beskjed om endringer i API eller dataformat (f.eks. ikke-brytende-endring som nye felt i dataformatet) slik at jeg kan tilpasse konsum av data når dataformatet blir endret eller utvidet.[varsel] )

(API-beskrivelsen - Som API-konsument ønsker jeg informasjon om kapasitet, ytelse og pålitelighet slik at jeg kan være sikker på at API-et kan benyttes i mine forretningskritiske tjenester)

(Mikrotjenesten/API-et - 16. Som API-forvalter ønsker jeg å vite av hvem og hvor ofte mine API-er brukes (trafikkdata og bruksmønstre), slik at jeg optimere tilgang til API-er og ta stilling til hvilke API-er som eventuelt skal avvikles, samt kunne få grunnlag for å kunne rapportere på gevinstrealisering. )

(API-beskrivelsen - BFP001: Som API-forvalter ønsker jeg at det knyttes opplysninger om sikkerhetsvurderinger tilknyttet felt i API’et (identifiserende, lokaliserende, krav til sikring, osv.) slik at hensyn til innebygd personvern i større grad er ivaretatt for det datasettet som publiseres. )

(Referansarkitektur - BAM04 - Som leverandør av API-management-verktøy ønsker jeg at jeg å kunne tilby automatisk integrasjon med den felles API-katalogen slik at jeg kan selge mer av produktet mitt ved å vise til at det støtter opp under de nasjonale føringene. )

(Som API-konsuement ønsker jeg en tematisk oversikt over API slik at jeg lett kan finne fram - BA32. Som API-konsument (gründer) ønsker jeg en tematisk oversikt over offentlige API slik at jeg kan lage nye tjenester.)

(Tilbyder applikasjon - API-et)

(Offentlig Virksomhet - Jurist)

(API-beskrivelsen - BA43. Som API-konsument ønsker jeg å bli varslet om at et API er “deprecated” (skal tas ut av bruk), slik at jeg kan oppdatere min applikasjon. )

(API-konsument (design time) - BB25. Som API-konsument (ETL) ønsker jeg mulighet til å abonnere på endringsvarslinger om både data og API-versjoner slik at jeg kan oppfriske data og/eller utnytte nye datafelter. [varsel] )

(Lokal registreringsløsning - Som datasetteier ønsker jeg motta varsel etter en fast periodisering om at det er tid for å sjekke om omtale av datasett er oppdatert slik at jeg sikrer best mulig datakvalitet på omtalen)

(Registration-API - Registration Service)

(Datakatalogen - BFDK09 - Som datasetteier for historiske (avleverte) data ønsker jeg å kunne koble de historiske datasettene med tilsvarende aktive/nåværende datasett, slik at jeg kan tilby brukerne en helhetlig tilgang til dataene.)

( BFP023: Som API-konsument ønsker jeg å se hvilken SLA som er forbundet med API et slik at jeg kan vurdere om det tilfredsstiller mine krav for bruk. - API-konsumenter forvaltningen og proffesjonelle)

(Harvester - Harvester API)

(Enhetsregisteret API - mor-organisasjon)

(Develop - Enterprise Continuum)

(BA46. Som API-konsument ønsker jeg mulighet for å bruke filtre i API-et slik at jeg kan ha bedre kontroll med hvilket utvalg av data jeg mottar, og ikke er avhengig av hvilke utvalg API-forvalteren har definert. - Studenter, gründere og app-utviklere)

(Nasjonalt - ?)

(en informasjonsmodel-katalog i virksomheten - 2-14 Som dataforvalter og forenklingsaktør ønsker jeg å koble dataelement (datafelt) og BR-begrepskatalog, slik at andre eksterne aktører lettere kan finne data fra BR som kan gjenbrukes.)

(Core Public Service vocabulary (EU-standard) - Tjenestebeskrivelse)

(Begrepskatalog GUI - Skrivebruker)

(Tjenestebeskrivelse - )

(API-katalog - Hente API beskrivelser av en viss type (API spesifikasjon))

(Informasjonsforvaltning - Tilby åpne data og grensesnitt)

(TBX-AP-NO - Begrep)

(API-konsument (design time) - BFP008: Som API-konsument ønsker jeg å vite oppdateringsfrekvens slik at jeg kan bestemme egen oppdatering. )

(API-katalogen - EPOS 2: Som API-forvalter ønsker jeg å registrere mine API-er slik at de kan gjøres tilgjengelig for andre)

(API-beskrivelsen - Som API-konsument ønsker jeg kontaktinformasjon slik at man kan få hjelp)

(Mikrotjenesten/API-et - BA26. Som API-konsument ønsker jeg at API-et støtter CORS slik at jeg kan nå det fra en webapplikasjon uten å måtte gå via egen backend eller proxy. )

(Felles datasettkatalog API - Search-API)

(Som API-eier ønsker jeg å kunne beskrive et API som ikke nødvendigvis kan knyttes til et datasett, slik at også dynamiske tjenester kan synliggjøres for andre konsumenter. - Informasjonsforvaltning fagmiljø)

( Jeg lurer på om Osloskolen klarer å få mine barn til å reaching their full potential, og ønsker at en fancy ny utdanningstjeneste skal få tilgang til alle data Osloskolen har om mitt barns oppgaveløsning, f.eks. Hvor lang tid de bruker på ulike typer oppgaver, slik at dataene kan analyseres og jeg kan få et skreddersydd opplegg. - Som sluttbruker ønsker jeg at en offentlig aktør skal ha tilgang til data om meg hos en annen offentlig aktør)

(BA5. Som API-konsument ønsker jeg at alle begreper linker direkte til en forklaring av begrepet slik at jeg slipper å lete gjennom dokumentasjonen. [kommentar: forskjell på begrep i den tekniske dokumentasjonen (f.eks. parameter i forespørsel) vs. begrep i datasettet (f.eks. fagtermer)] - Studenter, gründere og app-utviklere)

(en API-katalog i virksomheten - API-tilbyder)

(Produkt - Datasett)

(Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer - BA43. Som API-konsument ønsker jeg å bli varslet om at et API er “deprecated” (skal tas ut av bruk), slik at jeg kan oppdatere min applikasjon. )

(Felles rammeverk - BB34. Som API-konsument ønsker jeg å kunne se når hvilke deler av et datasett som er endret slik at jeg kan analysere endringer i data. [varsel] )

(Begrepskatalog API - Søk og oppslag begreper)

(Contract (copy) (copy) - )

(API-konsument (design time) - BFP031: Som kommersiell API-konsument ønsker jeg at offentlige aktører ikke tilbyr konkurrerende verdiøkende tjenester på de API de tilbyr slik at jeg kan sikre min return on investment. )

(Modellkatalog, Datamodell, Data dictionary - BTI010 Som API-tilbyder ønsker jeg å kunne se om andre tilbyr det samme eller nesten det samme som meg, så at det er mulig å harmonisere mellom “oss” [Livar: Case der det er fleire API-er som tilbyr det samme? Marit: Brreg og Skatt som har same datasett i FDK. Mathias: Felles studentsystem (FS) i UH-sektoren innheld personinformasjon. Kan ikkje konsoliderast med HR-data. Kan ikkje legge ned ein av dei. Dekker relasjonsfeltet i DCAT behovet?] )

(API-forvalter og API katalogeier - 2. Som API-forvalter ønsker jeg at katalogen gir føringer for hvordan API-ene mine skal dokumenteres, etter “beste praksis”, så jeg slipper å sette meg inn i/holde meg oppdatert på hva som er beste praksis for API-dokumentasjon [frigjøre ressurser/bedre kvalitet] )

(22. Som en API-forvalter med allerede eksisterende API-katalog, ønsker jeg at løsningen er fleksibel(?)/legger til rette for automatisk høsting, slik at jeg kan vedlikeholde dokumentasjonen min lokalt. - API-forvalter og API katalogeier)

(Tjenesteutvikler - Tjenesteeier (Applikasjons-/tjenesteutvikler/API-konsument))

(API-konsument (design time) - BFP025: Som API-konsument ønsker jeg å se hvilke muligheter det finnes for konfigurasjon både hos meg og hos API-leverandør for å begrense tilgjengelig data til mitt faktiske formål. Kommentar: Dataminimering?)

(Som API-forvalter ønsker jeg at mine API-beskrivelser følger et standard med veiledning og verktøystøtte slik at det er enkelt for brukerne og jeg kan redusere mine forvaltningskostnader og henvendelser - 1.Som API-forvalter ønsker jeg at katalogen dekker informasjonsbehovet til de som skal benytte API-ene jeg forvalter, slik at jeg slipper å besvare henvendelser fra dem/redusere antall henvendelser [frigjøre ressurser] )

(Veiledning - Beste praksis - API/mikrotjeneste - BB21. Som API-konsument ønsker jeg å kunne laste ned endringer i et datasett jeg allerede har en lokal kopi av slik at jeg effektivt kan vaske eget register basert på samme datakilde. [varsel] )

(Tjenestekatalog - data.norge.no portal)

(Krav (EPOS og nødvendige krav) - Som virksomhet som behandler personopplysninger ønsker jeg [verktøystøtte] slik at jeg ivaretar kravene til protokoll iht GDPR artikkel 30 (protokoll) )

(Søketjeneste for geografiske administrative områder - Datasettkatalog)

(API-konsument (design time) - BFP020: Som API-konsument ønsker jeg informasjon om oppdateringsfrekvens av dataene eller om dataene er statiske. )

(Leseapplikasjon API - API-konsument (design time))

(Node - Log og audit)

(API-konsument (design time) - BA37. Som API-konsument ønsker jeg at tilgjengelige API-er er robuste slik at jeg kan anta at integrasjonen fungerer også ved høy trafikk)

(API-katalogen - 30. Som API-portaleier ønsker jeg at alle skal tilby sin informasjon på samme format, OG at alle har et eget API som beskriver sin katalog eller sitt API, slik at portalen enklest mulig kan høste og sammenstille informasjon om API-er. )

(Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted. - 22. Som en API-forvalter med allerede eksisterende API-katalog, ønsker jeg at løsningen er fleksibel(?)/legger til rette for automatisk høsting, slik at jeg kan vedlikeholde dokumentasjonen min lokalt. )

autentisering (ID-porten - Registreringsapplikasjon datasett)

(API-konsument (design time) - BB5. Som API-konsument ønsker jeg å få tilgang til eksempler på bruk av API-et slik at jeg kan se mulighetene for bruk og bedre forstå hva API-et er ment å brukes til. [dokumentasjon] )

(API-konsument (design time) - BFP005: Som API-konsument ønsker jeg at dokumentasjonen skal integreres i koden slik at den til enhver tid er oppdatert )

(Etat - PreutfyllingAPI)

(API-detaljer - Scope)

(MyData, viderebruk av personopplysninger - Som sykkeleier vil jeg ha automatisert innfylling av tapsmelding til forsikringsselskapet fra innmeldte sak til politiet for å sikre konsistens og spare tid. )

(Norwegian Entity Register (Bus - er:Organization)

(MVP søketjeneste informasjonsmodeller - Som informasjonsarkitekt ønsker jeg å kunne finne representasjoner av sentrale ressurser slik at jeg kan gjenbruke andres modeller og redusere semantisk friksjon)

(Skatteetaten - Som API-forvalter ønsker jeg at definerte APIer i API-katalogen kan overføres til felleskomponenter for tilgangsstyring og autentisering slik at jeg slipper å registrere disse dobbelt (og dermed risikere feil i registreringer))

linked_to (Organization JSON-LD - Regnskap JSON-LD)

(Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et - BB20. Som API-konsument ønsker jeg eksempel på bruk av dataene som en del av dokumentasjonen av API-et, slik at de er enklere å fortså og ta i bruk [dokumentasjon] )

(Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et - BA14. Som API-konsument ønsker jeg lenker til applikasjoner som bruker datasettet, slik at jeg kan finne gode eksempler på bruk av API-et og datasettet. [kommentar: også programvarebibliotek og anna kodeverk som er relevant )

(API-katalog API - Datasettkatalog)

(Kapabilitetsoversikt - Hent liste over gitte API-spesifikasjoner)

(API-katalogen - Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et)

(EPOS 9: Som API-konsument ønsker jeg oversikt over hvem som bruker et API slik at jeg kan forstå det bedre - BFP014: Som API-konsument ønsker jeg oversikt over tilgjengelige referanseimplementasjoner slik at jeg raskere kan komme i gang med å bruke apiene. )

(Mikrotjenesten/API-et - Som sluttbruker ønsker jeg at en offentlig aktør skal ha tilgang til data om meg hos en annen offentlig aktør)

(BA27. Som API-konsument ønsker jeg at API-forvaltere lærer av webutviklere og tenker på brukerinvolvering og brukertesting slik at jeg kan få et API-som er lagt til rette for bruk - Studenter, gründere og app-utviklere)

(API-katalogen - Studenter, gründere og app-utviklere)

(DCAT-AP-NO - Datasettbeskrivelse)

(Krav (EPOS og nødvendige krav) - (Behov for begreper i FDK søkeløsning))

(Registreringsapplikasjon begrep - Etatene skal beskrive sin tolkning av begreper i lovverk, forvaltningsstandarder og forvaltningspraksis i egen begrepskatalog. Begrepsbeskrivelsene skal bl.a. legge til rette for at opplysningene i datasettene kan beskrives eksplisitt, f.eks. hva inngår i “likningsverdi”. Begrepsbeskrivelsene skal være tilgjengelige slik at regelverksutvikling og digitaliseringsprosjekter kan identifisere forenklinger. )

(API-katalogen - EPOS 1: Som API-konsument ønsker jeg at API-beskrivelser samles slik at det er lett å få oversikt)

(Som API-forvalter ønsker jeg kontaktinfo til brukere av mine API slik at jeg kan ta kontakt med dem - 19. Som API-forvalter ønsker jeg kontaktinfo til de som bruker mine API slik at jeg kan ta kontakt med de om brukerundersøkelser, driftsmeldinger, endring av API, nye API og liknande. [dersom jeg ikke har egne løsninger for dette allerede] )

(EPOS 6: Som API-forvalter ønsker jeg at API-beskrivelsen er tilgjengeliggjort fra API-katalog slik at de kan benyttes i andre sammenhenger og at jeg unngår å måtte beskrive API-er flere steder - Som API-forvalter ønsker jeg å tilgjengeliggjøre API-et i en sanntids-tjenestekatalog (SMP) slik at den kan brukes til capability lookup i sanntids meldingsutveksling)

(API-konsument (design time) - BB31. Som API-konsument ønsker jeg at datasett som er gjort tilgjengelig for nedlasting har et forutsigbart URL-regime for siste versjon og historiske data slik at nedlasting kan automatiseres. [nedlasting, forutsigbarhet] )

(EPOS 6: Som API-konsument ønsker jeg informasjon om autentisering og tilgangskontroll for å ta API-et i bruk - Som API-konsument ønsker jeg å forstå om API-et er tilrettelagt for bruk med brukers samtykke eller fullmakt)

(Norwegian Entity Register (Bus - er:motherOrganization)

(API-katalogen - Som utvikler i Altinn ønsker jeg å kunne registrere tredjepart API uten at API-eier har kjennskap til dette slik <hensikt>)

(API beskrivelse 2 - API 2)

(19. Som API-forvalter ønsker jeg kontaktinfo til de som bruker mine API slik at jeg kan ta kontakt med de om brukerundersøkelser, driftsmeldinger, endring av API, nye API og liknande. [dersom jeg ikke har egne løsninger for dette allerede] - API-forvalter og API katalogeier)

(API-katalogen - API-konsument (design time))

(Enhetsregisteret - Organization)

(Som konsument av API ønsker jeg informasjon om kostnader og trafikkbegrensninger for bruk av API-et slik at jeg kan ha forutsigbare rammer for min bruk av dataene. - BFP026: Som profesjonell API-konsument ønsker jeg forutsigbare økonomiske og juridiske rammer rundt (helst åpen/gratis) tilgang til offentlig data slik at jeg kan lage gode business cases. )

(Registerenhet i Belgia - rov:Entity)

(Veiledning - Beste praksis - API/mikrotjeneste - BA33. Som API-konsument ønsker jeg at det er så få tekniske sperrer på API-ene som mulig slik at jeg kan ta det i bruk med minst mulig “prosess” mot API-forvalteren )

(API-beskrivelsen - 27. Som API-katalogeier ønsker jeg å koordinere beskrivelsene av API-ene som inngår i min katalog, slik at beskrivelsene fremstår som ensartet for de som skal benytte API-ene.)

(API-beskrivelsen - BA40. Som API-tilbyder* ønsker jeg retningslinjer og beste praksis for dokumentasjon av API-ene mine slik at jeg kan dokumentere så effektivt og bra som mulig. )

( BB36. Som API-konsument (ETL) ønsker jeg å unngå å laste komplette datasett og heller få de delene som har endret seg siden sist jeg lastet ned datasett slik at jeg minimerer egen ressursbruk. [varsel] - Åpne data statistikk, datajournalistikk og stordata)

(Begrep - Forretningsobjekt)

(Felles rammeverk - 27. Som API-katalogeier ønsker jeg å koordinere beskrivelsene av API-ene som inngår i min katalog, slik at beskrivelsene fremstår som ensartet for de som skal benytte API-ene.)

(Architecture Board - Develop)

(FDK API-høster API - data.norge.no portal)

(BA55. Som API-konsument, ønsker jeg at API-et er designet etter en felles “beste praksis” som gjelder for API-er i API-katalogen, slik at jeg lett kjenner meg igjen på tvers av API-ene i katalogen. - Studenter, gründere og app-utviklere)

(Fagterminologibaser - Felles datakatalog portal (fellesdatakatalog.brreg.no))

(API-katalogen - 17. Som API-forvalter ønsker jeg å vise frem eksempel på bruk av mine API-er slik at verdien av API-ene blir synliggjort og det kan inspirere flere til å bruke API-ene og hvordan bruke API-ene. )

(BFP021: Som API-konsument ønsker jeg en standardisering av API-grensesnittene (inn og ut) slik at jeg kan ta i bruk nye datasett raskest mulig. - API-konsumenter forvaltningen og proffesjonelle)

(EPOS 4: Som API-konsument ønsker jeg å finne detaljert beskrivelse av API-ene slik at jeg kan vurdere om jeg kan benytte API-et i mine tjenester - Som API-konsument ønsker jeg at datasett som er relatert til hverandre vises sammen slik at jeg kan få et helhetlig bilde av et fenomen)

(API-konsument (design time) - BA39. Som API-konsument ønsker jeg at begreper i API-ene er dokumentert slik at jeg forstår dokumentasjonen og bruker dataene i API-ene rett. )

(Enhetsregisteret - Felles datakatalog portal (fellesdatakatalog.brreg.no))

(API-konsument (design time) - BB34. Som API-konsument ønsker jeg å kunne se når hvilke deler av et datasett som er endret slik at jeg kan analysere endringer i data. [varsel] )

(Norwegian Entity Register (Bus - Linked data)

(Skjemaklient - Designer Backend)

(Registreringsapplikasjon begrep - Felles datakatalog portal (fellesdatakatalog.brreg.no))

(Registration-API - Datasett Registrering)

(API-beskrivelsen - BA10.Som API-konsument ønsker jeg en indikasjon på hvor dynamisk datasettet er, slik at jeg har en idé om hvor ofte jeg trenger å lese data på nytt. )

(Mikrotjenesten/API-et - BB2. Som API-konsument ønsker jeg å gjøre spørringer og sammenstillinger og styre strukturen/formatet på resultatdatasettet selv, slik at jeg kan enkelt kan få det utsnittet av dataene som passer til den oppgaven jeg skal løse. )

( BB13. Som API-konsument ønsker jeg at de tjenestene offentlig sektor har utviklet på sine egne API gjøres tilgjengelig som åpen kildekode, slik at jeg kan gjenbruke relevante deler av koden for mitt eget konsum av API-et. [gjenbruk av kildekode] - Åpne data statistikk, datajournalistikk og stordata)

(Nasjonalt - Begrep)

(BB9. Som API-konsument (datajournalist) ønsker jeg å få forklaringer/dokumentasjon på hvordan dataene henger sammen slik at jeg kan spare tid på semantisk fortolkning (kobling mot datakatalogen?) [dokumentasjon] - Åpne data statistikk, datajournalistikk og stordata)

linked_to (Organization JSON-LD - Organzation JSON-LD)

(A service in a container - An application)

linked_to (Organization JSON-LD - Kommune JSON-LD )

(API-spesifikasjon - API-beskrivelse (OAS))

(33. Som API-forvalter ønsker jeg at man tilbyr ei løsning/det blir spesifisert hvordan man skal tilby API på samme format. - API-forvalter og API katalogeier)

(BA35. Som API-konsument ønsker jeg at det er tydelig hva som er de rettslige rammene for bruk av API-ene slik at jeg kan være sikker på at jeg ikke kan få krav mot meg senere, f.eks. NLOD. - Studenter, gründere og app-utviklere)

(API-katalogen - Som API-konsument ønsker jeg å se request og respons på et API slik at jeg kan planlegge design)

(Felles rammeverk - BA24. Som API-konsument ønsker jeg, når jeg får en respons fra et datasett, en henvisning til arkiverte versjoner av “det samme” datasettet (med elementer som ikke lenger finnes i det løpende datasettet), slik at jeg kan gi en mer komplett respons til brukeren. )

(API-beskrivelsen - BFP005: Som API-konsument ønsker jeg at dokumentasjonen skal integreres i koden slik at den til enhver tid er oppdatert )

(Som API-forvalter ønssker jeg å beskrive kjente kvalitetsvurderinger slik at konsumenten kan forstå API-et bedre - BFP020: Som API-konsument ønsker jeg informasjon om oppdateringsfrekvens av dataene eller om dataene er statiske. )

(API-tilbyder - 35. Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de. )

(Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted. - 29. Som API-katalogeier med en eksisterende API-dokumentasjon ønsker jeg å bruke eksisterende API-dokumentasjon slik at jeg slipper å vedlikeholde API-dokumentasjon (manuelt) flere steder. )

(Maskin-porten - Access)

(Datasett-eier - Som datasetteier ønsker jeg å registrere flere egenskaper (interne kontaktpersoner, GDPR-relatert informasjon) om datasett enn det som er mulig i Felles datakatalog slik at interne behov oppfylles i henhold til interne krav. )

(Som API-konsument ønsker jeg at dokumentasjonen er genererert fra kode slik at jeg kan stole på at den er oppdatert - BFP005: Som API-konsument ønsker jeg at dokumentasjonen skal integreres i koden slik at den til enhver tid er oppdatert )

(Hent en API beskrivesle - API-katalog)

(API-katalogen - BTI010 Som API-tilbyder ønsker jeg å kunne se om andre tilbyr det samme eller nesten det samme som meg, så at det er mulig å harmonisere mellom “oss” [Livar: Case der det er fleire API-er som tilbyr det samme? Marit: Brreg og Skatt som har same datasett i FDK. Mathias: Felles studentsystem (FS) i UH-sektoren innheld personinformasjon. Kan ikkje konsoliderast med HR-data. Kan ikkje legge ned ein av dei. Dekker relasjonsfeltet i DCAT behovet?] )

(Som API-konsument ønsker jeg kontaktinformasjon slik at man kan få hjelp - BFP002: Som API-konsument ønsker jeg enhetlig dokumentasjon og mulighet til “kundeservice” fra tjenesteleverandør. )

(API-katalog - Betaling)

(API-beskrivelsen - BA41. Som API-konsument som benytter verktøy for å generere deler av kildekoden ønsker jeg at API-et er dokumentert iht “Open API Specification”, slik at jeg kan bruke kodegenereringsverktøy for å generere mye av den kildekoden som trengs for å bruke API-et fremfor å måtte skrive den selv [ref epost] )

(Som API-forvalter ønsker jeg eierskapet og ansvaret til API-eier kommer tydlig frem slik at man unngår uklarheter - BAM06 - Som ansvarlig for API-management ønsker jeg å kunne fordele eierskap og ansvar for de enkelte API-ene til det forretningsområdet som er dataforvalter/dataeier, slik at de kan være mest mulig selvbetjente og redusere flaskehalser (“publisher portal”)/sikre nærhet og dermed kvalitet (ansvarliggjøring av den rette aktøren) )

(MyData, viderebruk av personopplysninger - Eg vil bruke ei bildelingsteneste for å leige ut min bil. Der vil eg gje samtykke til å hente data frå vegvesenet sitt køyretøysregister om kva bilar eg eig, så slepp eg å taste inn informasjonen sjølv, og kan i staden få ferdig utfylt informasjon om kva bil det er, modell etc. Bildelingstenesten kan vidare nytte informasjonen til å hente inn informasjon om mine bilar, til dømes bilde av bilen, så eg slepp å legge inn dette sjølv. )

(Veiledning - Beste praksis - API/mikrotjeneste - BA24. Som API-konsument ønsker jeg, når jeg får en respons fra et datasett, en henvisning til arkiverte versjoner av “det samme” datasettet (med elementer som ikke lenger finnes i det løpende datasettet), slik at jeg kan gi en mer komplett respons til brukeren. )

(Informasjonsforvaltning - API-katalogen)

(Virksomheter - API)

(Som API-konsument ønsker jeg at datasett som er relatert til hverandre vises sammen slik at jeg kan få et helhetlig bilde av et fenomen - BFDK09 - Som datasetteier for historiske (avleverte) data ønsker jeg å kunne koble de historiske datasettene med tilsvarende aktive/nåværende datasett, slik at jeg kan tilby brukerne en helhetlig tilgang til dataene.)

(API-konsument (design time) - BB13. Som API-konsument ønsker jeg at de tjenestene offentlig sektor har utviklet på sine egne API gjøres tilgjengelig som åpen kildekode, slik at jeg kan gjenbruke relevante deler av koden for mitt eget konsum av API-et. [gjenbruk av kildekode] )

(Felles rammeverk - BA21. Som API-konsument ønsker jeg et API som gir godt strukturerte responser slik at data er lett å bruke. )

START_HARVEST APIs event (Publish/Subscribe Service - data.norge.no API-høster)

(Datasettkatalog - Tjenestekatalog)

(Service Management - Deploy)

(API Meta-data - API-beskrivelse)

(Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et - 16. Som API-forvalter ønsker jeg å vite av hvem og hvor ofte mine API-er brukes (trafikkdata og bruksmønstre), slik at jeg optimere tilgang til API-er og ta stilling til hvilke API-er som eventuelt skal avvikles, samt kunne få grunnlag for å kunne rapportere på gevinstrealisering. )

( Når jeg flytter til en ny kommune/et nytt sted, vil jeg bli spurt om jeg ønsker å bytte til ny fastlege på mitt nye bosted, med en oversikt over tilgjengelige fastleger med ledig kapasitet. - MyData, viderebruk av personopplysninger )

(Som API-konsument ønsker jeg at API-beskrivelsen refererer til informasjonsmodeller slik at jeg forstår strukturen i API-ets respons - BB9. Som API-konsument (datajournalist) ønsker jeg å få forklaringer/dokumentasjon på hvordan dataene henger sammen slik at jeg kan spare tid på semantisk fortolkning (kobling mot datakatalogen?) [dokumentasjon] )

(API-katalogen - Som API-konsument ønsker jeg at datasett som er relatert til hverandre vises sammen slik at jeg kan få et helhetlig bilde av et fenomen)

Import (Begrepskatalog API - Begrepssamling)

(Nasjonalt - API-beskrivelse)

(Som virksomhet ønsker jeg en egen oversikt for intern bruk over datasett slik at... - Støtte for arbeidsflyt)

(Felles rammeverk - BB1. Som API-konsument ønsker jeg et spørregrensesnitt (SQL-aktig/SPARQL/ODATA/GraphQL/NoSQL) mot API-et slik at jeg kan utforske datasettet og datasettets struktur/datamodell interaktivt som suplement til å lese dokumentasjon )

(Datasettbeskrivelse - Begrep)

(Datasettkatalog - Søk og oppslag datasett)

(API-katalogen - Åpne data statistikk, datajournalistikk og stordata)

(Altinn data modellering - 209. Som tjenesteutvikler ønsker jeg at tjenestens modell også blir oppdatert når jeg legger til et nytt felt i skjemaklient, slik at modellen og brukergrensesnittet hele tiden er gjensidig oppdatert.)

(BFP012: Som API-konsument ønsker jeg varsel på endringer (push-varsel og toveiskommunikasjon) slik at jeg kan forberede tiltak. - API-konsumenter forvaltningen og proffesjonelle)

(API-katalogen - Som API-forvalter ønsker jeg at definerte APIer i API-katalogen kan overføres til felleskomponenter for tilgangsstyring og autentisering slik at jeg slipper å registrere disse dobbelt (og dermed risikere feil i registreringer))

(Modelleringsforum - Som informasjonsarkitekt ønsker jeg felles strukturmodeller (FIMs) på et riktig granuleringsnivå slik at jeg kan forvalte dem uten for mye prosess)

(BA22. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg kan stille spørsmål om bruk av API-et slik at jeg kan bruke det mest mulig hensiktsmessig, og gjerne med henvisninger til kjent brukt av API-et. - Studenter, gründere og app-utviklere)

(en API-katalog i virksomheten - Servers)

(data.norge.no informasjonsmodell-høsting - data.norge.no portal)

(Grensesnitt - Produkt)

(An external service - A service in a container)

(Registreringsløsning begrep - Begrepskatalog API)

(BFDK05 - Som forretningsutvikler ønsker jeg å kunne sammenligne APIere, slik at jeg vurdere om et API passer bedre enn et annet for min bruk. - FDK)

(Referansedata - Datasettkatalog GUI)

(API-beskrivelsen - EPOS 3: Som API-konsument ønsker jeg at beskrivelsen forklarer kall og innholdet i responsen slik at jeg kan forstå dataene jeg mottar)

(Nasjonalt - ??)

(Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted. - BAM02 - Som ansvarlig for API-management ønsker jeg å dokumentere mitt API slik at utviklere raskt kan benytte API-et for tilgang til de data API-et representerer )

(Melding uten gjenbruksmulig eller preutfylling - 210. Som tjenesteutvikler ønsker jeg at tjenestens modell også blir oppdatert når jeg fjerner et felt i skjemaklienten, slik at modellen og brukergrensesnittet hele tiden er gjensidig oppdatert.)

(Som API-forvalter ønsker jeg at mine API-beskrivelser følger et standard med veiledning og verktøystøtte slik at det er enkelt for brukerne og jeg kan redusere mine forvaltningskostnader og henvendelser - BTI004 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å redusere mine forvaltningskostnader, for eksempel for å få redusert manuelle henvendelser )

( Fra BRREGs arbeid: Registrere seg som Über-sjåfør (dokumentere førerkort) - MyData, viderebruk av personopplysninger )

(Nasjonalt - Behandlingsaktivitet GUI)

(Tjenestebeskrivelse - )

(Begrepskatalogen - Begrep)

(Orden i eget hus - beskrivelse av API - 27. Som API-katalogeier ønsker jeg å koordinere beskrivelsene av API-ene som inngår i min katalog, slik at beskrivelsene fremstår som ensartet for de som skal benytte API-ene.)

(Som API-konsument ønsker jeg informasjon om kapasitet, ytelse og pålitelighet slik at jeg kan være sikker på at API-et kan benyttes i mine forretningskritiske tjenester - BFDK13 - Som konsument av et åpent api ønsker jeg informasjon om hvor pålitelig leveransen av data er (forventet oppetid, responstid ved feil osb) slik at jeg kan gjøre en tilstrekkelig ROS-analyser for min integrasjon )

(API-mangement verktøyleverandør - BAM01 - Som ansvarlig for API-management ønsker jeg å publisere mine API i en API-katalog slik at utviklere raskt kan finne frem til mitt API/økt synlighet )

(Søk og oppslag API - Søk og oppslag API-beskrivelser)

(Felles rammeverk - BA13. Som API-konsument ønsker jeg at Tableau/R/etc kan hente inn data for meg slik at jeg kan lage visualiseringer uten å måtte vite noe om API-er. )

(Felles datakatalog portal (fellesdatakatalog.brreg.no) - REST GET Datasettkatalog)

(209. Som tjenesteutvikler ønsker jeg at tjenestens modell også blir oppdatert når jeg legger til et nytt felt i skjemaklient, slik at modellen og brukergrensesnittet hele tiden er gjensidig oppdatert. - 5 = gir nødvendig funksjonalitet til produktet)

(Datasettkatalog - data.norge.no portal)

(API-tilbyder - Som API-eier ønsker jeg å angi at API’et skal være tilgjengelig i en runtime-tjenestekatalog (SMP/capability lookup) og Altinn tjenestekatalog/Authorization for samtykke og tilgangsstyring. )

(API-katalog - Modelleringsklient)

Diffusion (Domain Architects - Implementation Projects)

(BA36. Som API-konsument ønsker jeg at noen tar jobben med å holde oversikt over om API-er er tilgjengelige, utilgjengelige, stabilt, deprecated etc slik at jeg slipper å begynne å ta det i bruk først før jeg oppdager det. - Studenter, gründere og app-utviklere)

(get token - virksomhetssertifikat )

(Harvester - Harvester Admin-GUI)

(Som API-forvalter ønsker jeg en å samle beskrivelser av API-ene våre og andres slik at det er enkelt å få oversikt over API-er og bruk - 14. Som API-forvalter/eier ønsker jeg en ensartet og samlet API-katalog slik at det blir enklere å publisere informasjonen.)

(Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier. - BA50. Som API-konsument, ønsker jeg å kunne gi tilbakemeldinger til god (eller dårlig) “beste praksis” for API-er, slik at dette kan være til hjelp for framtidige API-er som utvikles. )

(Fagterminologibaser - concept-cat-harvester)

(API-et - API-beskrivelse (OAS))

(Datamottak - Datamottak)

(API-konsument (design time) - BA20. Som API-konsument ønsker jeg informasjon om hvor jeg kan finne statiske data som brukes til API-requests (Kommunenr, Kommunenavn..) slik at jeg slipper å lete etter dette selv. )

Guidance (Architecture Board - Enterprise Architects)

(Contract - )

(Nasjonalt - Datasettkatalog)

(API-katalogen - BFDK05 - Som forretningsutvikler ønsker jeg å kunne sammenligne APIere, slik at jeg vurdere om et API passer bedre enn et annet for min bruk.)

(API-beskrivelsen - Som sluttbruker ønsker jeg at en offentlig aktør skal ha tilgang til data om meg hos en annen offentlig aktør)

(BA9. Som API-konsument ønsker jeg at API-et er tilrettelagt for bruk, og ikke bare speiler innholdet i en database, slik at jeg kan slippe å forholde meg til et fagdomene, sette meg inn i interne kodeverk [brukerorientert, ikke avsenderstyrt …] - Studenter, gründere og app-utviklere)

(??? - Service Metadata Publisher (SMP))

Publish START_HARVEST_APIs (FDK-høsting ADM - Publish/Subscribe Service)

(EPOS 8: Som API-konsument ønsker jeg informasjon om vilkår slik at jeg kan forstå om jeg kan bentytte API-et - Som API-konsument ønsker jeg at rettslige rammer og lisens er tydelig beskrevet slik at jeg kan vurdere om det er forenelig med min bruk av dataene)

(API-konsument (design time) - BA17. Som API-konsument ønsker jeg beskrivelse av API-et sin kapasitet slik at jeg vet om jeg trenger en egen server for sluttbrukerapplikasjoner ved svært høy trafikk.)

( BB28. Som API-konsument ønsker jeg at API-et har god ytelse slik at jeg kan gjøre enkeltoppslag og ikke blir tvunget til å laste ned hele datasettet fordi API-et har lav ytelse. [tjenestenivå] - Åpne data statistikk, datajournalistikk og stordata)

(API-beskrivelsen - BFP026: Som profesjonell API-konsument ønsker jeg forutsigbare økonomiske og juridiske rammer rundt (helst åpen/gratis) tilgang til offentlig data slik at jeg kan lage gode business cases. )

(Som API-konsument ønsker jeg referanser til dokumentasjon som ikke beskrives i API-beskrivelsen slik at jeg kan nøste meg videre - BA22. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg kan stille spørsmål om bruk av API-et slik at jeg kan bruke det mest mulig hensiktsmessig, og gjerne med henvisninger til kjent brukt av API-et. )

(en datasett-katalog i virksomheten - Som ansatt ønsker jeg å se hvilke datasett som er publisert i Lokal datakatalog og Felles datakatalog, slik at jeg klart kan skille mellom hva som er lokalt og hva som er felles.)

(Felles rammeverk - BAM02 - Som ansvarlig for API-management ønsker jeg å dokumentere mitt API slik at utviklere raskt kan benytte API-et for tilgang til de data API-et representerer )

(Altinn - Som utvikler i Altinn ønsker jeg å kunne registrere tredjepart API uten at API-eier har kjennskap til dette slik <hensikt>)

(Mikrotjenesten/API-et - Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv)

(Andre datasettkataloger - data.norge.no datasetthøsting)

(Et applikasjonsgrensesnitt - En tjeneste)

(Undersøke, gjenfinne, få oversikt - Som kvalitetsansvarlig i virksomheten ønsker jeg å få oversikt over domener som er godt beskrevet, slik at jeg kan vite hvilke områder som trenger forbedring )

(Veiledning - Beste praksis - API/mikrotjeneste - BA15. Som API-konsument ønsker jeg at alt jeg er avhengig av for applikasjonen min er tilgjengelig fra samme server, inklusive kodeverk, slik at CORS opprettholdes. )

(Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de. - Informasjonsforvaltning fagmiljø)

(Datasettkatalog - API-katalog)

(Som API-konsument ønsker jeg å vite hva slags intereaksjonsform/type som API-et tilbyr slik at jeg kan vite om det dekker mine behov - Som API-konsument ønsker jeg å vite hvilken interaksjonsform som tilbys i APIet (spørring, feed, fil) , slik at jeg kan vite om det dekker mine behov. )

(API-katalogen - 29. Som API-katalogeier med en eksisterende API-dokumentasjon ønsker jeg å bruke eksisterende API-dokumentasjon slik at jeg slipper å vedlikeholde API-dokumentasjon (manuelt) flere steder. )

(Felles rammeverk - BA26. Som API-konsument ønsker jeg at API-et støtter CORS slik at jeg kan nå det fra en webapplikasjon uten å måtte gå via egen backend eller proxy. )

(Begrepskatalog API - Informasjonsmodell-katalog)

(2. Informasjon om fremgangsmåte - Difi)

(API-beskrivelse (OAS) - response)

(Skatteetaten - Som API-forvalter/API-Management ansvarlig ønsker jeg en enkel måte å kommunisere sensitiv informasjon sikkert til (enkelt)brukere av tjenester)

(Som API-forvalter ønsker jeg kontaktinfo til brukere av mine API slik at jeg kan ta kontakt med dem - Som API-forvalter/API-Management ansvarlig ønsker jeg en enkel måte å kommunisere informasjon rettet til enkeltbrukere av tjenester)

(Veiledning - Beste praksis - API/mikrotjeneste - BA46. Som API-konsument ønsker jeg mulighet for å bruke filtre i API-et slik at jeg kan ha bedre kontroll med hvilket utvalg av data jeg mottar, og ikke er avhengig av hvilke utvalg API-forvalteren har definert. )

(Andre datasettkataloger - Datasettkatalog)

(Informasjonsforvaltning - støtte opp om nytenkning og videreutvikling av digitale tjenester)

(data.norge.no portal - Begrepskatalog API)

(? - )

(API-beskrivelsen - BAM11 - Som ansvarlig for API-management ønsker jeg å sikre eierskap av API-ene hos forretningseier/dataeier for å sikre kvalitet og eierskap. )

(Nasjonalt - concept-cat-harvester)

(API-konsument (design time) - BFP028: Som API-konsument ønsker jeg at API-et i større grad er “selvbeskrivende” og, dersom det brukes interne koder, at betydningen/forklaringen på disse er enkelt tilgjengelig, slik at jeg forstår hvordan jeg skal bruke API-et. )

(API-konsument (design time) - BA32. Som API-konsument (gründer) ønsker jeg en tematisk oversikt over offentlige API slik at jeg kan lage nye tjenester.)

(API-beskrivelsen - BA14. Som API-konsument ønsker jeg lenker til applikasjoner som bruker datasettet, slik at jeg kan finne gode eksempler på bruk av API-et og datasettet. [kommentar: også programvarebibliotek og anna kodeverk som er relevant )

(Mikrotjenesten/API-et - BA45. Som API-konsument ønsker jeg et API med gode muligheter for å filtrere data slik at jeg kan hente ut akkurat det utsnittet av datasettet som jeg trenger til mitt formål og slipper å gjøre ekstra prosessering av responsen jeg får fra API-et. )

(Harvester-DB - Harvester-API)

(API-tilbyder/private grossister - BTI004 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å redusere mine forvaltningskostnader, for eksempel for å få redusert manuelle henvendelser )

(Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier. - 21. Som API-forvalter ønsker jeg å få en effektiv kanal for å få tilbakemeldinger og behov fra de som bruker API-ene mine, slik at det blir lettere å prioritere riktig ved videreutvikling av API-ene [styrke dialog med brukerne av API-ene] )

(data.norge.no API - data.norge.no informasjonsmodell-høsting)

(API-konsument (design time) - BB19. Som API-konsument ønsker jeg å diskutere semantiske og tekniske spørsmål i en åpen kanal (wiki, github issues el liknende) for APIet jeg bruker, slik at brukerne kan hjelpe hverandre og tilbyder kan kommunisere åpent med sitt økosystem. [nettverk, dokumentasjon] )

(BA12. Som API-konsument ønsker jeg å hente inn data uavhengig av dataenes egentlig form slik at den ikke endrer seg når dataformatet endres. - Studenter, gründere og app-utviklere)

(EPOS 5: Som API konsument ønsker jeg kvalitets- og sikkerhetsvurderinger om API-et slik at jeg kan forstå hvordan jeg kan ta det i bruk - Som API-konsument ønsker jeg å forstå om API-et tilbyr datamimimering slik at jeg kan understøtte godt personvern)

(API-katalogen - 31. Som API-portaleier ønsker jeg å få inn statistikk fra API-forvaltere slik at vi kan få et overordnet oversikt for hele sektoren/landet. )

(Domain Architects - Enterprise Architects)

(Informasjonsmodell-katalog - Ulik representasjon av sentral informasjon, for eksempel adresse, personopplysninger og organisasjoner medfører et løpende integrasjonsarbeid og risiko for kvalitetsforringelser. EU er pådriver for etablering av informasjonsmodeller som forener ulike land og virksomheters representasjoner og reduserer kostnaden for sammenstilling av data. Lokalt betyr dette også for BRSys en mer sømløs integrasjon mellom registrene. Altinn har verktøystøtte for informasjonsmodellering i dag (SERES) som vil migreres til ny arkitektur (2017) og etter hvert knyttes tettere til Tjenester 3.0 )

(API-beskrivelsen - BA23. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg får tilgang til FAQ om API-et. [Kommentar: manglar “slik at <forretningsverdi>”] )

(FDK - BFDK02 - Som forretningsutvikler ønsker jeg å søke etter API, slik at jeg raskt kan finne ut om det finnes data jeg kan gjenbruke)

(EPOS 7: Som API-konsuement ønsker jeg å forstå hvordan endringer varsles slik at jeg kan fange opp endringer - Som API-konsument ønsker jeg informasjon om et API har varsligskanal slik at jeg kan fange opp endringer)

(API-katalogen - Som API-forvalter/API-management ansvarlig ønsker jeg en nasjonal/delt infrastruktur for administrasjon og utstedelse av tilgangstokens for API-konsumenter slik at jeg slipper å utstede og forvalte disse selv (dette gjelder både hjemmelsbasert og samtykkebasert tilgang).)

(API-beskrivelsen - BFP017: Som API-konsument ønsker jeg en endringslogg så tidlig som mulig slik at jeg vet hva som har endret seg mellom versjoner. )

(API-katalogen - BA50. Som API-konsument, ønsker jeg å kunne gi tilbakemeldinger til god (eller dårlig) “beste praksis” for API-er, slik at dette kan være til hjelp for framtidige API-er som utvikles. )

(18. Som API-forvalter ønsker jeg oversikt over integrasjoner mot mine API-er slik at konsekvenser og kostnader ved endringer kan forutses og minimeres. - API-forvalter og API katalogeier)

(Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et - 18. Som API-forvalter ønsker jeg oversikt over integrasjoner mot mine API-er slik at konsekvenser og kostnader ved endringer kan forutses og minimeres. )

(API-katalogen - BA42. Som API-konsument ønsker jeg varsler om “breaking changes” slik at jeg kan gjøre de nødvendige endringene før de brekker mine systemer/applikasjoner også. [f.eks. ved registrere e-postadresse] )

(API-spesifikasjon - request)

(Enhetsregisteret - kommunenummer)

Alignment (Program Management Office - Service Management)

(BA7. Som API-konsument ønsker jeg selvforklarende API-er slik at jeg kan komme raskt i gang, få raskt nytte av API-et. - Studenter, gründere og app-utviklere)

(“Den registrerte/subjektet” - API-katalogen)

(11. Som API-forvalter/eier ønsker jeg å generere dokumentasjon ut fra koden eller tester, slik at jeg er sikker på at dokumentasjonen til enhver tid er oppdatert. - API-forvalter og API katalogeier)

(API-katalogen - 19. Som API-forvalter ønsker jeg kontaktinfo til de som bruker mine API slik at jeg kan ta kontakt med de om brukerundersøkelser, driftsmeldinger, endring av API, nye API og liknande. [dersom jeg ikke har egne løsninger for dette allerede] )

(API-beskrivelsen - Som API-konsument ønsker jeg å se relasjoner slik at jeg flere som tilbyr liknende API)

(API-konsument (design time) - BFP030: Som API-konsument ønsker jeg å kunne spørre produsent om mer og bedre data slik at vi kan tilby et bedre og mer helhetlig bilde. )

(Mikrotjenesten/API-et - BA48. Som API-konsument ønsker jeg at API-ene jeg bruker tilbyr komplett nedlasting av datasett slik at jeg kan bearbeide data lokalt. )

(API-katalogen - Som API-forvalter ønsker jeg at API-katalog kan plukke opp min swagger dokumentasjon slik at jeg kan benytte dette verktøyet)

(Altinn Autorisasjon - kontroller delegering)

(API-beskrivelsen - Som API-konsument ønsker jeg referanser til dokumentasjon som ikke beskrives i API-beskrivelsen slik at jeg kan nøste meg videre)

(Åpne data statistikk, datajournalistikk og stordata - BB19. Som API-konsument ønsker jeg å diskutere semantiske og tekniske spørsmål i en åpen kanal (wiki, github issues el liknende) for APIet jeg bruker, slik at brukerne kan hjelpe hverandre og tilbyder kan kommunisere åpent med sitt økosystem. [nettverk, dokumentasjon] )

(5. Som API-forvalter ønsker jeg at API-katalogen kan vise min Swagger-dokumentasjon slik at jeg bare kan eksponere for eksempel Swagger-data (YAML) og slipper å drifte min egen Swagger UI-nettside. [relatert til Swagger-brukerhistorien, trur eg] - API-forvalter og API katalogeier)

(Datasett-eier - Som eier av datasett ønsker jeg å gi bruker av datasett en enkel mulighet til å se hvilke dataelementer (ID/navn) datasettene inneholder.)

(API-beskrivelsen - Som API-konsument ønsker jeg å vite hva slags intereaksjonsform/type som API-et tilbyr slik at jeg kan vite om det dekker mine behov)

(Mikrotjenesten/API-et - BB12. Som API-konsument ønsker jeg at API-ene støtter de “connector”-teknologiene som brukes av mine foretrukne verktøy for sammenstilling, analyse og visualisering, f.eks. Tableau, slik at jeg slipper å lage en mellomløsning/laste ned datasett for å analysere dem [samhandlingsevne] )

(16. Som API-forvalter ønsker jeg å vite av hvem og hvor ofte mine API-er brukes (trafikkdata og bruksmønstre), slik at jeg optimere tilgang til API-er og ta stilling til hvilke API-er som eventuelt skal avvikles, samt kunne få grunnlag for å kunne rapportere på gevinstrealisering. - API-forvalter og API katalogeier)

(Etat - Datamottak)

(EPOS 5: Som API-konsument ønsker jeg dialog med andre API-konsumenter og API-tilbydere slik at vi få hjelp og hjelpe hverandre - Som API-forvalter ønsker jeg kontaktinfo til brukere av mine API slik at jeg kan ta kontakt med dem)

(Veiledning - Beste praksis - API/mikrotjeneste - BFP024: Som API-konsument ønsker jeg i de tilfeller hvor API er basert på et lukket datasett å koble meg til et miljø med syntetisk data for bruk i utvikling og test. )

(Service Management - Program Management Office)

(en API-katalog i virksomheten - SecurityScheme)

(Modelleringsklient - Designer Backend)

(API tilbyder - request)

(Lokal Datasett søkeløsning - Som tjenesteutvikler og data scientist ønsker jeg å finne informasjon om dataeier slik at jeg kan få tilgang til dataene)

(Kartverket - Lenkede data)

(API-konsument (design time) - BB11. Som API-konsument (analytiker) ønsker jeg mulighet for å legg inn spørsmål, tips, eksempler knyttet til APIer slik at jeg kan øke min egen, andre brukere og api-forvalternes kjennskap om semantikk, selve APIen og bruk [økosystem] )

(BA29. Som API-konsument ønsker jeg informasjon om hvordan jeg kan skaffe meg tilgang til API-er som ikke er offentlig tilgjengelig. [Kommentar: manglar “slik at <forretningsverdi>”] - Studenter, gründere og app-utviklere)

(API-katalogen - Som API-eier ønsker jeg å kunne beskrive et API som ikke nødvendigvis kan knyttes til et datasett, slik at også dynamiske tjenester kan synliggjøres for andre konsumenter. )

(Andre tjenestekataloger - data.norge.no tjenestehøsting)

(Datasettbeskrivelse - Informasjonsmodell)

(Som tjenesteutvikler og data scientist ønsker jeg å kunne finne ut hva slags type data datasettet er slik at jeg kan vurdere egnethet - 4. Mer detaljering av type data)

(API-mangement verktøyleverandør - BAM09 - Som ansvarlig for API-management ønsker jeg å kunne administrere nøkler gitt til de enkelte konsumentene slik at jeg enkelt kan fjerne ev. misbruk av API-et )

(Begrepskatalog API - Modelleringsklient)

(Tilgangsstyring - API-katalog GUI)

(Kommune JSON-LD - Kommune)

(EPOS 1: Som API-konsument ønsker jeg eier- og kontaktinformasjon slik at man kan få hjelp - Som API-forvalter ønsker jeg eierskapet og ansvaret til API-eier kommer tydlig frem slik at man unngår uklarheter)

(API-katalog - API-konsument (design time))

(Begrepskatalog API - Begrepskatalog SKOS-AP-NO API)

(API-mangement verktøyleverandør - BAM08 - Som ansvarlig for API-management ønsker jeg oversikt over brukerne av mitt API slik at jeg kan formidle endringer i APIet. [Livar: duplikat av BAM03?] )

(BAM16 - Som ansvarlig for API-management ønsker jeg tydelige føringer på hvordan mitt API skal dokumenteres og gjøres tilgjengelig i en felles API-katalog slik at arbeidet kan planlegges, fordeles og operasjonaliseres i min virksomhet med et forutsigbart omfang. - Felles rammeverk)

(data.norge.no API-høster - API-katalog API)

(“Den registrerte/subjektet” - Som sluttbruker ønsker jeg at en offentlig aktør skal ha tilgang til data om meg hos en annen offentlig aktør)

(API-katalog - API-beskrivelse (OAS))

(Krav (EPOS og nødvendige krav) - Som informasjonsarkitekt ønsker jeg å kunne finne representasjoner av sentrale ressurser slik at jeg kan gjenbruke andres modeller og redusere semantisk friksjon)

(EPOS 1: Som API-konsument ønsker jeg at API-beskrivelser samles slik at det er lett å få oversikt - Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted.)

(BA51. Som API-konsument ønsker jeg mulighet til å gi tilbakemeldinger slik at jeg kan melde fra om feil eller foreslå forbedringer - Studenter, gründere og app-utviklere)

(Forretningsutvikler - BFDK03 - Som forretningsutvikler ønsker jeg å se detaljerte beskrivelser av APIene, slik at jeg kan vurdere om de er av tilstrekkelig kvalitet for bruk i mine tjenester )

( BAM05 - Som leverandør av API-management-verktøy ønsker jeg at den felles API-katalogen støtter beste praksis for API-er og de mest utbredte standardene, slik at det blir lett for meg å integrere mitt verktøy med den felles API-katalogen [gjetter jeg på …] - API-management)

(Felles rammeverk - BB21. Som API-konsument ønsker jeg å kunne laste ned endringer i et datasett jeg allerede har en lokal kopi av slik at jeg effektivt kan vaske eget register basert på samme datakilde. [varsel] )

(API-konsument (design time) - BB20. Som API-konsument ønsker jeg eksempel på bruk av dataene som en del av dokumentasjonen av API-et, slik at de er enklere å fortså og ta i bruk [dokumentasjon] )

(Som API-konsument ønsker jeg oversikt over testmiljø og syntetiske data slik at jeg kan teste ut API-ene - BFP024: Som API-konsument ønsker jeg i de tilfeller hvor API er basert på et lukket datasett å koble meg til et miljø med syntetisk data for bruk i utvikling og test. )

(API-beskrivelse - )

(API-konsument (design time) - BA33. Som API-konsument ønsker jeg at det er så få tekniske sperrer på API-ene som mulig slik at jeg kan ta det i bruk med minst mulig “prosess” mot API-forvalteren )

(API-mangement verktøyleverandør - BAM16 - Som ansvarlig for API-management ønsker jeg tydelige føringer på hvordan mitt API skal dokumenteres og gjøres tilgjengelig i en felles API-katalog slik at arbeidet kan planlegges, fordeles og operasjonaliseres i min virksomhet med et forutsigbart omfang. )

(en informasjonsmodel-katalog i virksomheten - Som dataforvalter og registerfører ønsker jeg å ha oversikt over hvilke datakilder dataelementene innrapporteres via, slik at det blir lettere å avdekke feilkilder.)

(API-beskrivelsen - BAM06 - Som ansvarlig for API-management ønsker jeg å kunne fordele eierskap og ansvar for de enkelte API-ene til det forretningsområdet som er dataforvalter/dataeier, slik at de kan være mest mulig selvbetjente og redusere flaskehalser (“publisher portal”)/sikre nærhet og dermed kvalitet (ansvarliggjøring av den rette aktøren) )

(Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles - Som API-konsument ønsker jeg standardiserte autentiserings- og autoriseringsmekanismer som kan gjenbrukes for flere tjenester)

(Felles datasettkatalog API - Harvester-API)

(Felles datasettkatalog API - Harvester Service)

(25. Som API-forvalter som forvalter API-er til autoritative data ønsker jeg at API-katalogen skal prioritere presentasjon av mine API-er fremfor API-er som tilbyr samme data, men fra ikke-autoritative kilder, slik at API-brukerne ikke ubevisst bruker ikke-autoritative data - API-forvalter og API katalogeier)

(Registrering av lokale datasett - Som virksomhet ønsker jeg en egen oversikt for intern bruk over datasett slik at...)

( BB7. Som API-konsument ønsker jeg at det angis tydelig i dokumentasjonen hvilke data som er tilgjengelig, men også hva som ikke er tilgjengelig, slik at jeg slipper merarbeid pga. uklar dokumentasjon. [dokumentasjon] - Åpne data statistikk, datajournalistikk og stordata)

(Bruk - Som forretningsutvikler som gir innspill til regelverksutvikling ønsker jeg å se helheten på et utvalgt område slik at jeg kan vurdere hvordan lovendringsforslag vil slå ut på vårt område )

(admin - Tilgangsstyring Admin GUI)

(Datasettkatalog - Forretningsutvikler)

(Som konsument av API ønsker jeg informasjon om kostnader og trafikkbegrensninger for bruk av API-et slik at jeg kan ha forutsigbare rammer for min bruk av dataene. - BA31. Som API-konsument ønsker jeg informasjon om eventuelle økonomiske betingelser for bruk av API-er, slik at jeg kan vurdere hvorvidt det er aktuelt å betale for bruk av API-et. )

(Felles rammeverk - BFP033: Som API-konsument ønsker jeg at API-et er avledet av en informasjonsmodell og Masterdata, som både sikrer konsistens mellom API og informasjonsmodell og gir mer og bedre dokumentasjon for API-et. )

(API-tilbyder - 12. Som APi-forvalter/eier ønsker jeg at standarder og beskrivelser er helt maskinlesbare slik at høsting og bruk kan automatiseres og min rolle automatiseres bort eller erstattes av AI. )

(Frittstående API-beskrivelser - Registreringsapplikasjon API)

(API-tilbyder - 26. Som API-forvalter ønsker jeg at opplysninger som er relevante for datakatalogen og som finnes i API-et (feks “sist oppdatert”), høstes til datakatalogen slik at datasettbeskrivelsen er så god som mulig. )

(Som tjenesteutvikler eller data scientist ønsker jeg detaljer knyttet til variable og tidsfrekvens slik at vurdere hvordan jeg kan sammenstille dataene - 2-4 Som datasetteier ønsker jeg å gi bruker av datasett en enkel mulighet til å se hvilke dataelementer (ID/navn) datasettene inneholder slik at bruker får avklart om datasettet kan brukes til sitt formål)

(Som API-konsument ønsker jeg at strukturmodeller er publisert slik at jeg kan forstå informasjonen som bæres av API-et - Modelleringsforum)

(Prosess, involvering og kvalitetssikring - Som begrepseier ønsker jeg å knytte en status til innholdet, slik at jeg kan synliggjøre at begrepet jobbes med eller at det er ferdigstilt eller ikke lenger gjeldende (utgått).)

(Veiledning - Beste praksis - API/mikrotjeneste - BB36. Som API-konsument (ETL) ønsker jeg å unngå å laste komplette datasett og heller få de delene som har endret seg siden sist jeg lastet ned datasett slik at jeg minimerer egen ressursbruk. [varsel] )

( BFP006: Som API-konsument ønsker jeg at det ikke er for rigide krav til dokumentering og til selve APIet slik at det ikke hemmer rask utvikling av API - API-konsumenter forvaltningen og proffesjonelle)

(Referansarkitektur - BAM05 - Som leverandør av API-management-verktøy ønsker jeg at den felles API-katalogen støtter beste praksis for API-er og de mest utbredte standardene, slik at det blir lett for meg å integrere mitt verktøy med den felles API-katalogen [gjetter jeg på …] )

(API-beskrivelsen - BFP023: Som API-konsument ønsker jeg å se hvilken SLA som er forbundet med API et slik at jeg kan vurdere om det tilfredsstiller mine krav for bruk. )

(Datamottak - "Min Side")

(API-konsument (design time) - BB15. Som API-konsument ønsker jeg at relevante opplysninger som ikke er tilgjengelig i API-et er omtalt i dokumentasjonen, slik at jeg kan bruke API-et riktig. [dokumentasjon] )

(Enterprise Continuum - Processes)

(API-beskrivelse (OAS) - )

(Enterprise Continuum - Processes)

(Norwegian Accounting Registry - Linked data)

(Felles rammeverk - BTI002 Som API-tilbyder som sammenstiller data på vegne av f.eks. kommuner ønsker jeg at de større systemene og registrene skal tilby API-er slik at jeg enkelt kan få tilgang til dataene for å gjennomføre mitt oppdrag. )

(Andre komponenter - Andre API-kataloger)

(API tilbyder - API-tilbyder)

(Ansatt - Som ansatt ønsker jeg at det blir etablert en løsning for å navigere meg langs ulike dimensjoner fram til ønskede datasettbeskrivelser slik at jeg lettere kan finne fram til rett datasett)

(Regnskapsopplysning (Forretningsobjekt) - Norsk Standard Kontoplan)

(Contract: Gherkin - )

(API-beskrivelsen - Som API-konsument ønsker jeg å forstå om API-et tilbyr datamimimering slik at jeg kan understøtte godt personvern)

(Som API-konsument ønsker jeg hjelp til tilgang til nøkler eller tokens for raskt å ta i bruk API-et - BAM09 - Som ansvarlig for API-management ønsker jeg å kunne administrere nøkler gitt til de enkelte konsumentene slik at jeg enkelt kan fjerne ev. misbruk av API-et )

(API-beskrivelsen - BA22. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg kan stille spørsmål om bruk av API-et slik at jeg kan bruke det mest mulig hensiktsmessig, og gjerne med henvisninger til kjent brukt av API-et. )

(API-katalogen - BA43. Som API-konsument ønsker jeg å bli varslet om at et API er “deprecated” (skal tas ut av bruk), slik at jeg kan oppdatere min applikasjon. )

(A service in a container - An application (copy) (copy))

(Som API-konsument ønsker jeg referanser til brukte kodeverk slik at jeg kan forstå hvordan de skal fortolkes - BA18. Som API-konsument ønsker jeg lenker til aktuelle kodeverk (f.eks. kommunenummer, næringskoder) slik at jeg lett kan hente støtte-datasett og dermed benytte datasettet fullt ut. )

(Felles rammeverk - BTI008 Som konsument av data fra offentlige virksomheter ønsker jeg at de offentlige virksomhetene inngår avtaler med sine leverandører som gjør det tydelig hvem som eier dataene, og stiller krav til at de skal være gjøres tilgjengelige uten kostnader, slik at ikke den offentlige virksomheten hindres i å dele sine data med meg som følge av at kostnadene blir for store. )

(API-katalogen - Som forretningsutvikler ønsker jeg å se filtrere på datasett som tilbyr API slik at jeg kan benytte det i mine tjenester)

(API-tilbyder - 21. Som API-forvalter ønsker jeg å få en effektiv kanal for å få tilbakemeldinger og behov fra de som bruker API-ene mine, slik at det blir lettere å prioritere riktig ved videreutvikling av API-ene [styrke dialog med brukerne av API-ene] )

(Felles rammeverk - 33. Som API-forvalter ønsker jeg at man tilbyr ei løsning/det blir spesifisert hvordan man skal tilby API på samme format.)

(API-beskrivelsen - Som API-konsument ønsker jeg at dokumentasjonen er genererert fra kode slik at jeg kan stole på at den er oppdatert)

(API-tilbyder - 22. Som en API-forvalter med allerede eksisterende API-katalog, ønsker jeg at løsningen er fleksibel(?)/legger til rette for automatisk høsting, slik at jeg kan vedlikeholde dokumentasjonen min lokalt. )

(BA3. Som API-konsument ønsker jeg at det pekes til gode landingssider for API-et slik at jeg raskt settes i stand til å ta det i bruk. - Studenter, gründere og app-utviklere)

(Offentlig Virksomhet - API manager)

(Begrepskatalog API - Begrepskatalog API)

(Node - Kontainer orkestrering)

(Regnskapsregisteret - Regnskap JSON-LD)

(API-konsument (design time) - BFP027: Som API-konsument ønsker jeg at dokumentasjonen til API-er jeg skal bruke har informasjon om kvalitet og tilgjengelighet, slik at jeg slipper mange henvendelser til API-tilbyder for å få svar på enkle ting. )

(API-tilbyder - Administrasjon av API-beskrivelser (design time))

(Altinn data modellering - 213. Som tjenesteutvikler ønsker jeg at det er mulig å navigere mellom modelleringsvisning og skjemavisning mens jeg ut utvikler en tjeneste slik at jeg kan velge i hvilken visning jeg utfører en endring og hele tiden kan se hvordan endringen blir i begge visningene. )

(Datasettkatalog - Søk og oppslag datasett-beskrivelser)

(Veiledning - Beste praksis - API/mikrotjeneste - BB17. Som API-konsument ønsker jeg at spørringer, programkode og bibliotek som andre utvikler gjøres tilgjengelig som åpen kildekode slik at jeg kan dra nytte av disse i min prosess [gjenbruk av kildekode] )

(BA34. Som API-konsument ønsker jeg at eventuelle krav til API-nøkler etc lar seg løse raskt/selvbetjent slik at jeg kan komme i gang raskt. [f.eks. autorisering basert på eksisterende mekanismer fremfor å måtte kontakte forvalter og vente på svar (ID-porten, Altinn), bruksvilkår fremfor avtaler] - Studenter, gründere og app-utviklere)

(Ansatt - Som ansatt av nye digitalte tjenester ønsker jeg å se nærmere på beskrivelsene i katalogen - innhold (begrep) og egenskaper slik at jeg kan evaluere mulig bruk i de nye tjenestene)

(Nasjonalt - Informasjonsmodell-katalog)

(FDK-høsting ADM - FDK-høsting API)

(Mapping agency - skv:Municipality)

(Datasettkatalog - Registreringsapplikasjon datasett)

(Få tilgang - Leverandør)

(Som bruker ønsker jeg å kunne authentisere meg på en enkel måte mot katalogen slik at jeg kan gi tilbakemeldninger og melde om bruk av et API - BAM17 - Som ansvarlig for API-management ønsker jeg at å tilby effektiv selvregistrering av brukere av API-ene, f.eks. gjennom autentisering via ID-porten/Altinn av dem som tar i bruk API-ene, slik at jeg senker terskelen for å ta API-et i bruk, samtidig som jeg beholder nødvendig oversikt over brukere. )

(A service in a container - A user (copy))

(API-beskrivelsen - 11. Som API-forvalter/eier ønsker jeg å generere dokumentasjon ut fra koden eller tester, slik at jeg er sikker på at dokumentasjonen til enhver tid er oppdatert.)

(Veiledning - Beste praksis - API/mikrotjeneste - BB26. Som API-konsument ønsker jeg at API-ene jeg har tilgang til er de samme som API-forvalteren selv benytter til sin tjenesteutvikling, slik at jeg kan ha tillit til at forvaltning og videreutviklingen av API-ene gis prioritet og er verdt å bruke tid på å lære, gjøre bruk av [tjenestenivå/sla] )

(Felles rammeverk - Nettverk (faglig forum))

(Standardisering - Grensesnitt API/mikrotjeneste - BA7. Som API-konsument ønsker jeg selvforklarende API-er slik at jeg kan komme raskt i gang, få raskt nytte av API-et. )

(xbrl:Regnskap - Regnskap)

(Grensesnitt - Produkt)

(OASIS SMP protokoll - API tilbyder)

(Informasjonsforvaltning - Datasettbeskrivelse)

(Som API-forvalter ønsker jeg kontaktinfo til brukere av mine API slik at jeg kan ta kontakt med dem - Som API-forvalter/API-Management ansvarlig ønsker jeg en enkel måte å kommunisere sensitiv informasjon sikkert til (enkelt)brukere av tjenester)

( Som API-forvalter/ansvarlig for API-management ønsker jeg en enkel måte å kommunisere livssyklus planer og garantier for en tjeneste (f.eks. nedleggelse/utfasing) slik at jeg kan avvikle tjenester når det er ønskelig - Skatteetaten)

(API-katalog - Tjenesteutvikler)

(API-beskrivelsen - BA18. Som API-konsument ønsker jeg lenker til aktuelle kodeverk (f.eks. kommunenummer, næringskoder) slik at jeg lett kan hente støtte-datasett og dermed benytte datasettet fullt ut. )

(Difi - 12. Valg for spørreundersøkelser)

(Tjenestebeskrivelse - )

(Som API-konsument ønsker API-beskrivelsen refererer til begreper slik at jeg kan forstå innholdet i API-et - BFP019: Som API-konsument ønsker jeg at apiene inneholder referanser til begrepene som er brukt i apiene slik at jeg forstår detaljene og bruker dataene korrekt. )

(Forretningsutvikler - BFDK04 - Som forretningsutvikler ønsker jeg å filtrere på datasett som har API, slik at jeg bedre treff på mine søk i katalogen. )

(Registrering av protokoll/behanlingsaktiviteter - Som virksomhet som behandler personopplysninger ønsker jeg [verktøystøtte] slik at jeg ivaretar kravene til protokoll iht GDPR artikkel 30 (protokoll) )

(Tjenestekatalog - Tjenestekatalog GUI)

(Kostnader - BA31. Som API-konsument ønsker jeg informasjon om eventuelle økonomiske betingelser for bruk av API-er, slik at jeg kan vurdere hvorvidt det er aktuelt å betale for bruk av API-et. )

(API-katalogen - Som API-konsument ønsker jeg kunnskapsbase (f.eks. FAQ funksjonalitet) slik at jeg som bruker kan få svar på kjente utfordringer og ikke behøver å bruke tid på henvendelser)

(Veiledning - Beste praksis - API/mikrotjeneste - BA9. Som API-konsument ønsker jeg at API-et er tilrettelagt for bruk, og ikke bare speiler innholdet i en database, slik at jeg kan slippe å forholde meg til et fagdomene, sette meg inn i interne kodeverk [brukerorientert, ikke avsenderstyrt …] )

(Som tjenesteeier og data scientist ønsker jeg å vite om et datasett er uferdig eller ufulstendig slik at jeg kan vurdere om jeg kan bruke det - 13. Valg for ferdig/uferdig/midlertidig/ufullstendig )

(Altinn Studio (Tjeneste 3.0) - Skjema API)

(API-katalogen - 20. Som API-forvalter ønsker jeg at brukerne av mitt API skal ha en åpen kommunikasjon med meg og hverandre om hvilke behov de har som ikke er dekket i dag, slik at min videreutvikling treffer flest mulig brukere på en tilstrekkelig måte.)

(Som API-konsument ønsker jeg å forstå om API-et er tilrettelagt for bruk med brukers samtykke eller fullmakt - Som sluttbruker ønsker jeg at en offentlig aktør skal ha tilgang til data om meg hos en annen offentlig aktør)

(en datasett-katalog i virksomheten - Lokal datasett registreringsløsning)

(API-katalogen - 32. Som API-bruker ønsker jeg å registrere en anvendelse slik at jeg kan oppgi den i API-kallet. Alternativt: Som API-forvalter ønsker jeg at brukere kan registrere seg med en ID som de bruker i API-kallet slik at jeg kan koble trafikk og anvendelse. [f.eks. ved overbruk av API-et kan man lett kontakte den som har satt opp anvendelsen] )

(API-mangement verktøyleverandør - BAM04 - Som leverandør av API-management-verktøy ønsker jeg at jeg å kunne tilby automatisk integrasjon med den felles API-katalogen slik at jeg kan selge mer av produktet mitt ved å vise til at det støtter opp under de nasjonale føringene. )

(API-beskrivelsen - Som API-konsument ønsker jeg hjelp til tilgang til nøkler eller tokens for raskt å ta i bruk API-et)

(API-konsument (design time) - BA45. Som API-konsument ønsker jeg et API med gode muligheter for å filtrere data slik at jeg kan hente ut akkurat det utsnittet av datasettet som jeg trenger til mitt formål og slipper å gjøre ekstra prosessering av responsen jeg får fra API-et. )

( BFP031: Som kommersiell API-konsument ønsker jeg at offentlige aktører ikke tilbyr konkurrerende verdiøkende tjenester på de API de tilbyr slik at jeg kan sikre min return on investment. - API-konsumenter forvaltningen og proffesjonelle)

(API-katalogen - Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier.)

(Nasjonalt - API-katalog GUI)

(Nasjonalt - Registreringsløsning API)

(API-katalogen - BFDK08 - Som datasetteier (som beskriver datasett i datakatalogen) ønsker jeg å kunne plukke fra API-beskrivelsen dataelementene som jeg ønsker å ta med i datasettbeskrivelsen, slik at dataelementene jeg tar med gjenspeiler det som APIet virkelig kan tilby. )

(API-tilbyder/private grossister - BTI005 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å sikre at det blir enkelt å ta API’ene i bruk slik at vi bidrar til forenkling og samordning )

(en API-katalog i virksomheten - Hent en API beskrivesle)

(BB12. Som API-konsument ønsker jeg at API-ene støtter de “connector”-teknologiene som brukes av mine foretrukne verktøy for sammenstilling, analyse og visualisering, f.eks. Tableau, slik at jeg slipper å lage en mellomløsning/laste ned datasett for å analysere dem [samhandlingsevne] - Åpne data statistikk, datajournalistikk og stordata)

(Felles - Registreringsapplikasjon API)

(API-beskrivelsen - EPOS 8: Som API-konsument ønsker jeg informasjon om vilkår slik at jeg kan forstå om jeg kan bentytte API-et)

(Dataeier - Datakatalogen)

GET /catalogs (DCAT-AP-NO v2.0 - data.norge.no API-høster)

(API-konsument (design time) - BA14. Som API-konsument ønsker jeg lenker til applikasjoner som bruker datasettet, slik at jeg kan finne gode eksempler på bruk av API-et og datasettet. [kommentar: også programvarebibliotek og anna kodeverk som er relevant )

( BTI006 Som kommunal API-konsument ønsker jeg digital tilgang til kommunesektorens rapporteringskategorier (f.eks. om rapportering er periodisk, om den er hendelsesutløst, eventuell dato for søknadsfrister) slik at jeg kan sikre at alle tidsfrister kan holdes - API-tilbyder/private grossister)

(Difi - 8. Kjente feil og mangler)

(Begrepskatalog API - Søk og oppslag begreps-beskrivelser)

1) (Begrepskatalog GUI - /login)

(Nasjonalt - Felles datakatalog portal (fellesdatakatalog.brreg.no))

(Begrep - Forvaltningsstandard begrepsbeskrivelser)

(API-tilbyder - API-katalogen)

(API-konsument (design time) - BB29. Som API-konsument ønsker jeg en god mekanisme for å få beskjed om endringer i API eller dataformat (f.eks. ikke-brytende-endring som nye felt i dataformatet) slik at jeg kan tilpasse konsum av data når dataformatet blir endret eller utvidet.[varsel] )

(Begrepskatalog API - Registreringsapplikasjon begrep)

(API-beskrivelsen - Som API-forvalter ønssker jeg å beskrive kjente kvalitetsvurderinger slik at konsumenten kan forstå API-et bedre)

(Representation - Regnskapsopplysning (Forretningsobjekt))

(API-tilbyder - 30. Som API-portaleier ønsker jeg at alle skal tilby sin informasjon på samme format, OG at alle har et eget API som beskriver sin katalog eller sitt API, slik at portalen enklest mulig kan høste og sammenstille informasjon om API-er. )

(Felles datakatalog portal (fellesdatakatalog.brreg.no) - Søk og oppslag informasjonsmodeller)

(BFDK09 - Som datasetteier for historiske (avleverte) data ønsker jeg å kunne koble de historiske datasettene med tilsvarende aktive/nåværende datasett, slik at jeg kan tilby brukerne en helhetlig tilgang til dataene. - FDK)

(5 = gir nødvendig funksjonalitet til produktet - 204. Som tjenesteutvikler ønsker jeg å generere en tjeneste direkte fra en modell slik at jeg slipper manuelt å lage brukergrensesnittet til tjenesten for så å koble feltene til modellelementene (ev. XSD-elementene).)

(Veiledning - Beste praksis - dokumentasjon av API-er - BA55. Som API-konsument, ønsker jeg at API-et er designet etter en felles “beste praksis” som gjelder for API-er i API-katalogen, slik at jeg lett kjenner meg igjen på tvers av API-ene i katalogen.)

(Som tjenesteutvikler eller data scientist ønsker jeg detaljer knyttet til variable og tidsfrekvens slik at vurdere hvordan jeg kan sammenstille dataene - 3. Mer informasjon om variabler og tidsfrekvens av data)

(Organisasjonskatalog - Begrepskatalog GUI)

(12. Som APi-forvalter/eier ønsker jeg at standarder og beskrivelser er helt maskinlesbare slik at høsting og bruk kan automatiseres og min rolle automatiseres bort eller erstattes av AI. - API-forvalter og API katalogeier)

(API-katalogen - BA1. Som API-konsument (student) ønsker jeg å filtrere på dataformater i oversikter over (åpne) API-er slik at jeg kan finne API-er i det formatet jeg ønsker å lære mer om eller filtrere ut de jeg ikke kan noe om.)

(Lenkede data - Regnskap)

(Som API-konsument ønsker jeg å se formater på responsen slik at jeg enklest mulig kan bruke og sammenstille informasjon - 30. Som API-portaleier ønsker jeg at alle skal tilby sin informasjon på samme format, OG at alle har et eget API som beskriver sin katalog eller sitt API, slik at portalen enklest mulig kan høste og sammenstille informasjon om API-er. )

( BAM18 - Som ansvarlig for flere datasett og medfølgende API’er ønsker jeg å ha kontroll på de datasettene forretningsenheten min tilbyr og enkelt gi tilgang til datasettene ved behov slik at jeg kan utføre ansvaret jeg har på en enkel måte - API-management)

(API-konsument (design time) - BA8. Som API-konsument ønsker jeg mulighet til enkelt å teste API-ene (utforske) f.eks. gjennom Swagger eller tilsvarende, slik at jeg raskere forstår API-et, og raskere klarer å bruke det (riktig) [ref BA7].)

(Som API-konsument ønsker jeg hjelp til tilgang til nøkler eller tokens for raskt å ta i bruk API-et - BA2. Som API-konsument ønsker jeg umiddelbar tilgang (slipper å vente på manuell tildeling av API-nøkler og tokens) til data (eller testdata) slik at jeg kan vurdere og eventuelt ta i bruk API-et umiddelbart.)

(FDK - data.norge.no portal)

(Grensesnitt - Offentlig sektor)

(Felles - REST GET informasjonsmodell-katalog)

(API-konsument (design time) - BB4. Som API-konsument (ETL) ønsker jeg API-er som gir meg uttrekk som er tilpasset mine rettigheter og filtreringsbehov slik at jeg kan innhente uttrekket jeg trenger og har rett til. [rettigheter] )

(FDK-høsting ADM - data.norge.no portal)

(API-konsument (design time) - BA27. Som API-konsument ønsker jeg at API-forvaltere lærer av webutviklere og tenker på brukerinvolvering og brukertesting slik at jeg kan få et API-som er lagt til rette for bruk )

(API-katalog - API-katalog API)

(Enhetsregisteret - Datasettkatalog)

(Linked data - Annual accounts)

(Krav (EPOS og nødvendige krav) - Behov for å publisere begreper eksternt (ORDEN-584))

(Premissgiver - styring dokumentasjon av API-er - BTI003 Som innkjøper av fagsystemer ønsker jeg at Statens Standardavtaler inneholder krav til at leverandøren skal tilgjengeliggjøre API-er og data, slik at jeg får tilgang til og slipper å kjøpe tilbake mine egne data. )

(Felles rammeverk - BA53. Som API-konsument ønsker jeg at API-et støtter HTTP-standard med accept header for å velge data-format slik at kan gjøre det jeg er vant til. )

(EPOS 3: Som API-konsument ønsker jeg å kunne søke og filtrer på API-er slik at jeg kan raskt finne rett API - Som forretningsutvikler ønsker jeg å se filtrere på datasett som tilbyr API slik at jeg kan benytte det i mine tjenester)

( Som API-forvalter ønsker jeg å kunne motta strukturerte tilbakemeldinger (f.eks. feil) og endringsforslag for mine tjenester slik at tjenestene kan forbedres - Skatteetaten)

(Nasjonalt - Registeringsløsning datasett)

(Hente API beskrivelser av en viss type (API spesifikasjon) - Kapabilitetsoversikt)

(Tjenesteeier (Applikasjons-/tjenesteutvikler/API-konsument) - Deleger tilgang)

(API-katalogen - BAM03 - Som ansvarlig for API-management ønsker jeg å notifisere endringer i mine API til dem som benytter API-ene slik at man ikke bryter kontrakter )

( Når jeg kjøper noe i en nettbutikk vil jeg at de nødvendige personalia blir fylt ut automatisk, så lite som mulig, men nok at butikken får sendt produktene til riktig adresse. - MyData, viderebruk av personopplysninger )

(API-beskrivelsen - BA32. Som API-konsument (gründer) ønsker jeg en tematisk oversikt over offentlige API slik at jeg kan lage nye tjenester.)

(API-beskrivelsen - Som API-konsument ønsker jeg å se eksempler på kall slik at jeg kan raskt sette meg inn i bruk av API-et)

(API-tilbyder - 4. Som API-forvalter ønsker jeg råd og forslag til avtaler med konsumenter slik at jeg kan gjøre flere API-er tilgjengelige for eksterne (f.eks. innovatører) og er trygg på å ha et godt avtaleverk og slipper å gjøre grunnarbeidet med vilkår og avtale for bruk. )

(Behov for å publisere begreper eksternt (ORDEN-584) - Publisere begreper til FDK (aka Jira adapter) (ORDEN-596))

(Lokal registreringsløsning - Som forvalter av datakatalogrammeverk ved BR ønsker jeg å skille på hvilke regler/disipliner/felter i den lokale datakatalogen som er knyttet til hvilke rammeverk, slik at jeg kan skille innhold i “lokale” rammeverkregelverk fra de nasjonalt rammeverke.)

(Kartverket - Administrative grenser API)

(17. Som API-forvalter ønsker jeg å vise frem eksempel på bruk av mine API-er slik at verdien av API-ene blir synliggjort og det kan inspirere flere til å bruke API-ene og hvordan bruke API-ene. - API-forvalter og API katalogeier)

(Som API-konsument ønsker jeg å se eksempler på kall slik at jeg kan raskt sette meg inn i bruk av API-et - BA4. Som API-konsument ønsker jeg eksempler på API-requests slik at jeg kan komme fort i gang.)

(API-konsument (design time) - BFP019: Som API-konsument ønsker jeg at apiene inneholder referanser til begrepene som er brukt i apiene slik at jeg forstår detaljene og bruker dataene korrekt. )

(API-tilbyder - BFP001: Som API-forvalter ønsker jeg at det knyttes opplysninger om sikkerhetsvurderinger tilknyttet felt i API’et (identifiserende, lokaliserende, krav til sikring, osv.) slik at hensyn til innebygd personvern i større grad er ivaretatt for det datasettet som publiseres. )

(en informasjonsmodel-katalog i virksomheten - Registreringsløsning informasjonsmodell)

(BFP022: Som API-konsument ønsker jeg eksempler/mal på bruk slik at jeg kan ta i bruk nye datasett raskest mulig. - API-konsumenter forvaltningen og proffesjonelle)

(Datasettkatalog - data.norge.no datasetthøsting)

(Felles - Søk og oppslag begreper)

(Nasjonalt - data.norge.no portal)

( Som arbeidstager ønsker jeg å få automatisk utfylt reiseregning når jeg sykler, dokumentert med lokasjonsdata fra min mobil - MyData, viderebruk av personopplysninger )

(API-beskrivelsen - Kostnader)

(API-beskrivelsen - Som API-konsument ønsker jeg å få tekstlig beskrivelse av et API slik at jeg kan forstå hvordan jeg skal bruke et API)

(API-konsument (design time) - BA28. Som API-konsument ønsker jeg informasjon om ytelsesmessige (svartid, antall oppslag) begrensninger i API-et, slik at jeg kan vurdere om API-et har god nok ytelse til mitt formål. )

(data.norge.no API - data.norge.no begrepshøsting)

(Veiledning - Beste praksis - API/mikrotjeneste - BFP029: Som API-konsument ønsker jeg at offentlige dataeiere tilbyr APIer så tidlig som mulig (med tilsvarende varsling om datakvalitet) slik at jeg kan utvikle tjenester og bidra til kvalitetsforbedring av dataene. )

(en datasett-katalog i virksomheten - GDPR artikkel 30 stiller krav til protokoll. Tolkes litt ulikt om det er en protokoll pr behandling eller en samlet protokoll med oversikt over alle behandlingene. Uansett er hensikten å kunne gi en samlet oversikt over behandlingen av personopplysninger i en virksomhet. Enighet om at dette løses ved at det legges til en modul for å registrere en behandlingsaktivitet. Summen av de registrerte behandlingsaktivitetene utgjør protokollen. Noe informasjon vil være felles på tvers av behandlingsaktivitetene, slik som hvem som er behandlingsansvarlig (direktøren), hvem som er personvernombud etc.)

(API-tilbyder/private grossister - BTI002 Som API-tilbyder som sammenstiller data på vegne av f.eks. kommuner ønsker jeg at de større systemene og registrene skal tilby API-er slik at jeg enkelt kan få tilgang til dataene for å gjennomføre mitt oppdrag. )

(Som API-forvalter ønsker jeg at mine API-beskrivelser følger et standard med veiledning og verktøystøtte slik at det er enkelt for brukerne og jeg kan redusere mine forvaltningskostnader og henvendelser - 15. Som API-forvalter/eier ønsker jeg en ensartet og samlet beskrivelse av alle våre API-er slik at det er enkelt for brukerne å gjenbruke sin kunnskap om de skal bruke flere API-er. )

(Skatteetaten - Som API-konsument ønsker jeg single sign on (SSO) mellom flere tjenester jeg benytter slik at jeg unngår separat autentisering mot hver enkelt tjeneste)

(API-konsument (design time) - BA30. Som API-konsument ønsker jeg informasjon om hvilke hjemler som gir tilgang til API-er der tilgangen er begrenset, slik at jeg kan vurdere om min virksomhet har lov til å benytte API-et til det aktuelle formålet. )

(Åpent Regnskapsdata API (maskinlesbart) - Representation)

(API-katalogen - Som API-forvalter/API-Management ansvarlig ønsker jeg en enkel måte å kommunisere informasjon rettet til enkeltbrukere av tjenester)

(Nasjonalt - Behandlingsaktivitet katalog)

(Datasett - Register)

(API-beskrivelse (OAS) - )

(API-konsument (design time) - BA3. Som API-konsument ønsker jeg at det pekes til gode landingssider for API-et slik at jeg raskt settes i stand til å ta det i bruk.)

(Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer - BFDK11 - Som konsument ønsker jeg å abonnere på varslinger om etablering, endring, driftsstans og avvikling av API’er slik at jeg kan tilpasse meg endringer)

(Altinn Studio (Tjeneste 3.0) - Tjenesteutvikler)

(API-konsument (design time) - BA52. Som API-konsument ønsker jeg en enkel måte å rapportere inn feil i datakatalog (f.eks. Lenker som ikke fungerer) slik at jeg slipper å bla i utdatert innhold. )

(API-katalog - Service Metadata Publisher (SMP))

(Felles rammeverk - BB12. Som API-konsument ønsker jeg at API-ene støtter de “connector”-teknologiene som brukes av mine foretrukne verktøy for sammenstilling, analyse og visualisering, f.eks. Tableau, slik at jeg slipper å lage en mellomløsning/laste ned datasett for å analysere dem [samhandlingsevne] )

(Veiledning - Beste praksis - dokumentasjon av API-er - BB22. Som API-konsument ønsker jeg å få dokumentasjonen fra samme sted som jeg henter ut data, slik at jeg vet at det er oppdatert og lett tilgjengelig. [dokumentasjon] )

(Informasjonsmodell-katalog - Modelleringsklient)

(Spesifikasjon for API (OAS) - )

(API-katalog - Administrasjon av API-beskrivelser (design time))

(Maskin-porten - Scope)

(API-konsument (design time) - BFDK10 - Som konsument ønsker jeg å få en liste over de datasett jeg vil ha tilgang til, presentert med grunnleggende informasjon om API slik at jeg sammenligne egenskaper (for eksempel hvilken protokoll som er brukt) ved API-ene)

(Premissgiver - Tilgjengelighetskrav API-er til grunndata - BTI002 Som API-tilbyder som sammenstiller data på vegne av f.eks. kommuner ønsker jeg at de større systemene og registrene skal tilby API-er slik at jeg enkelt kan få tilgang til dataene for å gjennomføre mitt oppdrag. )

(Regnskapsregisteret - xbrl:Regnskap)

(API-beskrivelsen - BB18. Som API-konsument ønsker jeg at kildekoden til API-tjenesten er tilgjengelig som åpen kildekode, slik at jeg kan lese kildekode for å forstå APIet og kunne bruke det optimalt [dokumentasjon] )

(API-konsument (design time) - BFP024: Som API-konsument ønsker jeg i de tilfeller hvor API er basert på et lukket datasett å koble meg til et miljø med syntetisk data for bruk i utvikling og test. )

(API-katalogen - 23. Som API-forvalter ønsker jeg at de API-ene jeg tilbyr skal være lette å finne og ta i bruk for de som har verdi av dem, slik at innsatsen jeg har lagt ned i API-ene får størst mulig verdi [forsvare kostnadene ved utviklingen/forvaltningen av API-ene/generere størst mulig nytte] )

(API-katalogen - BA14. Som API-konsument ønsker jeg lenker til applikasjoner som bruker datasettet, slik at jeg kan finne gode eksempler på bruk av API-et og datasettet. [kommentar: også programvarebibliotek og anna kodeverk som er relevant )

(BFP024: Som API-konsument ønsker jeg i de tilfeller hvor API er basert på et lukket datasett å koble meg til et miljø med syntetisk data for bruk i utvikling og test. - API-konsumenter forvaltningen og proffesjonelle)

(BA40. Som API-tilbyder* ønsker jeg retningslinjer og beste praksis for dokumentasjon av API-ene mine slik at jeg kan dokumentere så effektivt og bra som mulig. - Studenter, gründere og app-utviklere)

(API-konsument (design time) - BA25. Som API-konsument ønsker jeg at beskrivelser av API-er som ikke lengre er tilgjengelige, skal fjernes fra API-katalogen, slik at jeg slipper å lese om API-er som jeg uansett ikke kan bruke.)

(Felles datakatalog portal (fellesdatakatalog.brreg.no) - Registreringsapplikasjon datasett)

(An external service (copy) (copy) - A service in a container)

(get token - Tjenesteeier (Applikasjons-/tjenesteutvikler/API-konsument))

(Felles rammeverk - BFP021: Som API-konsument ønsker jeg en standardisering av API-grensesnittene (inn og ut) slik at jeg kan ta i bruk nye datasett raskest mulig. )

(API-beskrivelsen - BA39. Som API-konsument ønsker jeg at begreper i API-ene er dokumentert slik at jeg forstår dokumentasjonen og bruker dataene i API-ene rett. )

(Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API - Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de.)

(Virksomheter - Definisjon)

(BB4. Som API-konsument (ETL) ønsker jeg API-er som gir meg uttrekk som er tilpasset mine rettigheter og filtreringsbehov slik at jeg kan innhente uttrekket jeg trenger og har rett til. [rettigheter] - Åpne data statistikk, datajournalistikk og stordata)

(Veiledning - Beste praksis - API/mikrotjeneste - BA13. Som API-konsument ønsker jeg at Tableau/R/etc kan hente inn data for meg slik at jeg kan lage visualiseringer uten å måtte vite noe om API-er. )

(Begrepsbeskrivelse - Som begrepseier ønsker jeg å søke og filtrere på begrep (og lagre søket), slik at jeg enkelt å kunne finne fram til de begrepene jeg skal jobbe med )

(Mikrotjenesten/API-et - Som sluttbruker ønsker jeg å gi samtykke til at en offentlig myndighet kan innhente mine data fra en 3dje part slik at jeg slipper å tilgjengegliggjøre dataene selv.)

(EPOS 4: Som API-konsument ønsker jeg å finne detaljert beskrivelse av API-ene slik at jeg kan vurdere om jeg kan benytte API-et i mine tjenester - Som API-konsument ønsker jeg kunnskapsbase (f.eks. FAQ funksjonalitet) slik at jeg som bruker kan få svar på kjente utfordringer og ikke behøver å bruke tid på henvendelser)

(API-tilbyder - BTI005 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å sikre at det blir enkelt å ta API’ene i bruk slik at vi bidrar til forenkling og samordning )

(Veiledning - Beste praksis - API/mikrotjeneste - BA38. Som API-konsument ønsker jeg (kanskje ....) HATEOAS og linked data-baserte API (for eks. JSON-LD/RDF-representasjoner) slik at jeg kan se hvilke opsjoner jeg har basert på de responsene jeg allerede har fått (den tilstanden jeg er i). [Kommentar frå Steinar: “basert på én informant ... han var tydelig på at han hadde gode erfaringer med API-er med RDF-data”])

(data.norge.no begrepshøsting - data.norge.no portal)

(A service in a container - An application)

(API-beskrivelse (OAS) - API beskrivelse)

(et begrep - Regnskapsopplysning (Forretningsobjekt))

(BFDK07 - Som datasetteier (og som beskriver datasett i datakatalogen) ønsker jeg å kunne kople beskrivelser av APIer (i flertall) til et gitt datasett, slik at jeg kan vise hvilke distribusjoner som finnes av et datasett - FDK)

(OASIS SMP protokoll - Service metadata lookup (runtime))

(Ferdig søketjeneste API - Som API-konsument ønsker jeg å kunne søke og filtrer på API-er slik at jeg kan raskt finne rett API)

(BA20. Som API-konsument ønsker jeg informasjon om hvor jeg kan finne statiske data som brukes til API-requests (Kommunenr, Kommunenavn..) slik at jeg slipper å lete etter dette selv. - Studenter, gründere og app-utviklere)

(REST GET informasjonsmodell-katalog - Informasjonsmodell-katalog)

(Dataeier - BAM18 - Som ansvarlig for flere datasett og medfølgende API’er ønsker jeg å ha kontroll på de datasettene forretningsenheten min tilbyr og enkelt gi tilgang til datasettene ved behov slik at jeg kan utføre ansvaret jeg har på en enkel måte )

(Åpent Regnskapsdata API (maskinlesbart) - xbrl:Regnskap)

(API-katalog - Registreringsapplikasjon API)

(API-tilbyder - 11. Som API-forvalter/eier ønsker jeg å generere dokumentasjon ut fra koden eller tester, slik at jeg er sikker på at dokumentasjonen til enhver tid er oppdatert.)

(Norwegian Accounting Registry - xbrl:AnnualAccount)

(API-katalogen - BAM02 - Som ansvarlig for API-management ønsker jeg å dokumentere mitt API slik at utviklere raskt kan benytte API-et for tilgang til de data API-et representerer )

(API-beskrivelse (OAS) - Servers)

(Felles datasettkatalog API - Search-API)

(Enterprise Continuum - Solutions)

(Lokal registreringsløsning - Som datasetteier ønsker jeg sporing og historikk på datasettbeskrivelsene slik at det er enkelt å se detaljer i endringene og hvem som har utført dem.)

(API-katalog API - data.norge.no portal)

(BA39. Som API-konsument ønsker jeg at begreper i API-ene er dokumentert slik at jeg forstår dokumentasjonen og bruker dataene i API-ene rett. - Studenter, gründere og app-utviklere)

(EPOS 2: Som API-konsument ønsker jeg en grunnleggende informasjon om API-et som er oppdatert og forståelig lsik at jeg kan ta API-et i bruk - Som API-konsument ønsker jeg referanser til dokumentasjon som ikke beskrives i API-beskrivelsen slik at jeg kan nøste meg videre)

(API-katalogen - Som API-forvalter ønsker jeg å tilgjengeliggjøre API-et i en sanntids-tjenestekatalog (SMP) slik at den kan brukes til capability lookup i sanntids meldingsutveksling)

(20. Som API-forvalter ønsker jeg at brukerne av mitt API skal ha en åpen kommunikasjon med meg og hverandre om hvilke behov de har som ikke er dekket i dag, slik at min videreutvikling treffer flest mulig brukere på en tilstrekkelig måte. - API-forvalter og API katalogeier)

response (API-et - En konsument applikasjon)

(BFDK06 - Som arkitekt ønsker jeg å se hvilke data jeg må benytte for å gjøre oppslag mot et API og hvilke data jeg får tilbake slik at jeg kan planlegge design av løsning. - FDK)

(API-katalogen - Som API-konsument ønsker jeg at nasjonal/delt infrastruktur tilbyr felles mønstre for autentisering og autorisering mot API slik at jeg slipper å bestille og forvalte tilgangsstyring hos hver enkelt tjenestetilbyder.)

(Mikrotjenesten/API-et - BA46. Som API-konsument ønsker jeg mulighet for å bruke filtre i API-et slik at jeg kan ha bedre kontroll med hvilket utvalg av data jeg mottar, og ikke er avhengig av hvilke utvalg API-forvalteren har definert. )

(API-tilbyder - 29. Som API-katalogeier med en eksisterende API-dokumentasjon ønsker jeg å bruke eksisterende API-dokumentasjon slik at jeg slipper å vedlikeholde API-dokumentasjon (manuelt) flere steder. )

(API-konsument (design time) - BA42. Som API-konsument ønsker jeg varsler om “breaking changes” slik at jeg kan gjøre de nødvendige endringene før de brekker mine systemer/applikasjoner også. [f.eks. ved registrere e-postadresse] )

(Tjenesteutvikler - Som lokal tjenesteutvikler (Altinn) ønsker jeg å se på beskrivelser av våre lokale datasett med tanke på gjenbruk og utvikling av mer brukerorienterte tjenester (prosesstilnærming/samhandling))

(Premissgiver - styring dokumentasjon av API-er - 13. Som API-forvalter ønsker jeg å kunne påvirke utformingen av felles nasjonale oppskrifter for API-beskrivelser slik at de dekker mine behov.)

(Veiledning - Beste praksis - API/mikrotjeneste - BB12. Som API-konsument ønsker jeg at API-ene støtter de “connector”-teknologiene som brukes av mine foretrukne verktøy for sammenstilling, analyse og visualisering, f.eks. Tableau, slik at jeg slipper å lage en mellomløsning/laste ned datasett for å analysere dem [samhandlingsevne] )

(Kartverket - Søketjeneste for geografiske administrative områder)

(Som API-eier ønsker jeg å angi at API’et skal være tilgjengelig i en runtime-tjenestekatalog (SMP/capability lookup) og Altinn tjenestekatalog/Authorization for samtykke og tilgangsstyring. - Informasjonsforvaltning fagmiljø)

(Åpne data statistikk, datajournalistikk og stordata - BB17. Som API-konsument ønsker jeg at spørringer, programkode og bibliotek som andre utvikler gjøres tilgjengelig som åpen kildekode slik at jeg kan dra nytte av disse i min prosess [gjenbruk av kildekode] )

(API-konsument (design time) - BB35. Som API-konsument ønsker jeg å kunne abonnere på hendelser slik at jeg får beskjed når hendelser oppstår. [varsel] )

(Etat - Datamottak)

(API-tilbyder - 15. Som API-forvalter/eier ønsker jeg en ensartet og samlet beskrivelse av alle våre API-er slik at det er enkelt for brukerne å gjenbruke sin kunnskap om de skal bruke flere API-er. )

(API-tilbyder - 24. Som API-forvalter (f.eks. av hotell.difi.no) ønsker jeg at API-ene er lette å finne og ta i bruk slik at verdien blir realisert. )

(Oppgave - Tjeneste)

(Som API-konsument ønsker jeg informasjon om kapasitet, ytelse og pålitelighet slik at jeg kan være sikker på at API-et kan benyttes i mine forretningskritiske tjenester - BFP027: Som API-konsument ønsker jeg at dokumentasjonen til API-er jeg skal bruke har informasjon om kvalitet og tilgjengelighet, slik at jeg slipper mange henvendelser til API-tilbyder for å få svar på enkle ting. )

(EPOS 2: Som API-konsument ønsker jeg en grunnleggende informasjon om API-et som er oppdatert og forståelig lsik at jeg kan ta API-et i bruk - Som API-konsument ønsker jeg å se relasjoner slik at jeg flere som tilbyr liknende API)

(API-beskrivelsen - Som API-konsument ønsker jeg at rettslige rammer og lisens er tydelig beskrevet slik at jeg kan vurdere om det er forenelig med min bruk av dataene)

(API-katalogen - 10. Som en API-forvalter ønsker jeg å kunne ha “FAQ-funksjonalitet” (eller kunnskapsbase), slik at brukerne mine lettere kan få tak i svar på kjente utfordringer og jeg kan redusere kostnader ved å håndtere brukerhenvendelser. )

(API-beskrivelsen - Som API-forvalter ønsker jeg at det med API-beskrivelsen følger en veileder slik at jeg kan følge beste praksis)

(Hent liste over gitte API-spesifikasjoner - API-katalog)

(Begrepskatalog API - Begrepsanalyse)

(EPOS 3: Som API-konsument ønsker jeg at beskrivelsen forklarer kall og innholdet i responsen slik at jeg kan forstå dataene jeg mottar - Som API-konsument ønsker API-beskrivelsen refererer til begreper slik at jeg kan forstå innholdet i API-et )

(205. Som tjenesteutvikler ønsker jeg at tjenestens modell også blir oppdatert når jeg endrer felttypen til et felt i skjemaklient, slik at modellen og brukergrensesnittet hele tiden er gjensidig oppdatert. - 5 = gir nødvendig funksjonalitet til produktet)

(Felles rammeverk - BA16. Som API-konsument ønsker jeg at API-et tåler stor trafikk slik at jeg kan bruke API-et direkte i applikasjon)

(API-konsument (design time) - BB23. Som API-konsument (stordata) ønsker jeg tilgang til tekster i maskinlesbart format og under en åpen lisens slik at jeg fritt kan bruke tekster i maskinanalyse av språk eller lignende.[tekst som data] )

(Dataeier - BFDK08 - Som datasetteier (som beskriver datasett i datakatalogen) ønsker jeg å kunne plukke fra API-beskrivelsen dataelementene som jeg ønsker å ta med i datasettbeskrivelsen, slik at dataelementene jeg tar med gjenspeiler det som APIet virkelig kan tilby. )

(Skatteetaten - Som API-forvalter ønsker jeg en enkel måte å varsle endringer spesifikasjon av tjenester)

(EPOS 5: Som API konsument ønsker jeg kvalitets- og sikkerhetsvurderinger om API-et slik at jeg kan forstå hvordan jeg kan ta det i bruk - Som API-forvalter ønssker jeg å beskrive kjente kvalitetsvurderinger slik at konsumenten kan forstå API-et bedre)

( BTI001 Som innkjøper av fagsystemer trenger jeg et nettverk for å stille API-krav for tilgang til data slik at jeg kan trekke inn kompetanse til å spesifisere disse og få markedsmakt til å få leverandøren til å implementere dem. - API-tilbyder/private grossister)

(Grensesnitt - API)

(EPOS 3: Som API-konsument ønsker jeg å kunne søke og filtrer på API-er slik at jeg kan raskt finne rett API - Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API)

(Som API-konsument ønsker jeg kontaktinformasjon slik at man kan få hjelp - BFP011: Som API-konsument ønsker jeg et kontaktpunkt hos API-eier slik at man kan gi tilbakemelding og spørsmål. )

(Som API-forvalter ønsker jeg en godt dokumentert felles løsning for registering av API-beskrivelser slik at jeg slipper å installere egne verktøy. - Som utvikler i Altinn ønsker jeg å kunne registrere tredjepart API uten at API-eier har kjennskap til dette slik <hensikt>)

(Felles rammeverk - BB26. Som API-konsument ønsker jeg at API-ene jeg har tilgang til er de samme som API-forvalteren selv benytter til sin tjenesteutvikling, slik at jeg kan ha tillit til at forvaltning og videreutviklingen av API-ene gis prioritet og er verdt å bruke tid på å lære, gjøre bruk av [tjenestenivå/sla] )

(digitalt transformerte tjenester - Altinn tjenestekatalog)

(Tilgangsstyring - Datasettkatalog GUI)

(API-spesifikasjon - request)

(Begrep - Begrep)

(Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API - 35. Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de. )

(API-beskrivelse (OAS) - API-detaljer)

(API 1 - Standardisert API [ABSTRACT])

(Brønnøysundregistrene - 3-1 Som leder ønsker jeg å administrere tilganger til registreringsløsning for Lokal datakatalog slik at jeg ivaretar tilgangsrettighetersikkerhet og personvern)

(Tjenesteeier (Applikasjons-/tjenesteutvikler/API-konsument) - Tjenesteutvikling)

(ikke-digitale tjenester - Oppgaveregisteret)

(Felles rammeverk - BTI004 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å redusere mine forvaltningskostnader, for eksempel for å få redusert manuelle henvendelser )

(data.norge.no tjenestehøsting - data.norge.no portal)

(Standard - )

(Felles rammeverk - BA55. Som API-konsument, ønsker jeg at API-et er designet etter en felles “beste praksis” som gjelder for API-er i API-katalogen, slik at jeg lett kjenner meg igjen på tvers av API-ene i katalogen.)

(en API-katalog i virksomheten - DCAT-AP-NO v2.0)

(API-katalog - API tilbyder)

(Som tjenesteutvikler og data scientist ønsker jeg å finne informasjon om dataeier slik at jeg kan få tilgang til dataene - 2-3-1 Som datasetteier ønsker jeg å registrere kontaktinformasjon til dataeier, datasetteier og teknisk kontakt slik at interne behov oppfylles i henhold til interne krav)

(API-katalogen - BTI005 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å sikre at det blir enkelt å ta API’ene i bruk slik at vi bidrar til forenkling og samordning )

(API-konsument (design time) - BA36. Som API-konsument ønsker jeg at noen tar jobben med å holde oversikt over om API-er er tilgjengelige, utilgjengelige, stabilt, deprecated etc slik at jeg slipper å begynne å ta det i bruk først før jeg oppdager det.)

(Fil - Regnskap)

(Datakonsumenter har behov for et ryddig avtaleregime for tilgang til dataene. - Difi konseptutredning "deling av data")

(en datasett-katalog i virksomheten - data.norge.no datasetthøsting)

(Lokal registreringsløsning - en datasett-katalog i virksomheten)

autentisering (ID-porten - Datasettkatalog)

(Felles rammeverk - BA45. Som API-konsument ønsker jeg et API med gode muligheter for å filtrere data slik at jeg kan hente ut akkurat det utsnittet av datasettet som jeg trenger til mitt formål og slipper å gjøre ekstra prosessering av responsen jeg får fra API-et. )

(en informasjonsmodel-katalog i virksomheten - API-tilbyder)

(API tilbyder - API-beskrivelse (OAS))

(en informasjonsmodel-katalog i virksomheten - REST GET informasjonsmodell-katalog)

(Kompetanse om modellering - Informasjonsforvaltning)

(Som API-forvalter ønsker jeg at det med API-beskrivelsen følger en veileder slik at jeg kan følge beste praksis - BAM02 - Som ansvarlig for API-management ønsker jeg å dokumentere mitt API slik at utviklere raskt kan benytte API-et for tilgang til de data API-et representerer )

(Felles rammeverk - Sikkerhetsarkitektur - API/mikrotjeneste)

(Mikrotjenesten/API-et - BFP004: Som profesjonell API-konsument ønsker jeg stabile API som beskytter meg mot endringer i underliggende data slik at jeg trenger ikke å oppdatere apiene mine ved dataendringer. )

(Contract - )

(Registry in Belgium - Linked data)

(API-beskrivelsen - 6. Som API-forvalter ønsker jeg at de aktivitetene jeg må gjøre og de standardene jeg må forholde meg til for å gjøre API-dokumentasjonen tilgjengelig i en nasjonal API-katalog, også gir verdi for andre, kommersielle, internasjonale API-kataloger, f.eks. synliggjøring på søkemotorer, ref Schema.orgs arbeid med vokabular for WebAPI http://pending.webschemas.org/WebAPI )

(BFDK08 - Som datasetteier (som beskriver datasett i datakatalogen) ønsker jeg å kunne plukke fra API-beskrivelsen dataelementene som jeg ønsker å ta med i datasettbeskrivelsen, slik at dataelementene jeg tar med gjenspeiler det som APIet virkelig kan tilby. - FDK)

(API-beskrivelsen - BB9. Som API-konsument (datajournalist) ønsker jeg å få forklaringer/dokumentasjon på hvordan dataene henger sammen slik at jeg kan spare tid på semantisk fortolkning (kobling mot datakatalogen?) [dokumentasjon] )

(update delegation table - Altinn Autorisasjon)

(Som API-konsument ønsker API-beskrivelsen refererer til begreper slik at jeg kan forstå innholdet i API-et - BB6. Som API-konsument ønsker jeg at semantikken rundt dataene er forklart (dataene er definert), slik at jeg kan ta et informert valg om å bruke dataene fordi jeg forstår kontekst, formål og omfanget av dem. [dokumentasjon] )

(API-konsument (design time) - BA26. Som API-konsument ønsker jeg at API-et støtter CORS slik at jeg kan nå det fra en webapplikasjon uten å måtte gå via egen backend eller proxy. )

(Entity Registry API - er:Organization)

( BAM11 - Som ansvarlig for API-management ønsker jeg å sikre eierskap av API-ene hos forretningseier/dataeier for å sikre kvalitet og eierskap. - API-management)

(Felleskomponent - API-katalog GUI)

(Felles rammeverk - Orden i eget hus - beskrivelse av API)

(API-katalogen - EPOS 6: Som API-forvalter ønsker jeg at API-beskrivelsen er tilgjengeliggjort fra API-katalog slik at de kan benyttes i andre sammenhenger og at jeg unngår å måtte beskrive API-er flere steder)

(API-forvalter og API katalogeier - 1.Som API-forvalter ønsker jeg at katalogen dekker informasjonsbehovet til de som skal benytte API-ene jeg forvalter, slik at jeg slipper å besvare henvendelser fra dem/redusere antall henvendelser [frigjøre ressurser] )

(Krav (EPOS og nødvendige krav) - Støtte for arbeidsflyt)

(SKOS-AP-NO - Harvesting)

((Behov for begreper i FDK søkeløsning) - Beskrive endepunkt (FDK-575))

(API-konsument (design time) - BFP014: Som API-konsument ønsker jeg oversikt over tilgjengelige referanseimplementasjoner slik at jeg raskere kan komme i gang med å bruke apiene. )

(Som virksomhet ønsker jeg en egen oversikt for intern bruk over datasett slik at... - Intern kontaktperson)

(Mikrotjenesten/API-et - BB35. Som API-konsument ønsker jeg å kunne abonnere på hendelser slik at jeg får beskjed når hendelser oppstår. [varsel] )

(BA31. Som API-konsument ønsker jeg informasjon om eventuelle økonomiske betingelser for bruk av API-er, slik at jeg kan vurdere hvorvidt det er aktuelt å betale for bruk av API-et. - Studenter, gründere og app-utviklere)

(API-konsument (design time) - BB14. Som API-konsument ønsker jeg standardavtaler for både vilkår for bruk av data og tjeneste slik at jeg vet hvilke vilkår og tjenestenivå jeg har å forholde meg til. [databehandleravtaler, SLA] )

(Enterprise Continuum - Authority Structures)

(Felles rammeverk - BTI009 Som konsument av offentlig data ønsker jeg en koordinert forvaltning av offentlig master data slik at jeg kan utvikle anvendelser/analyser med forutsigbar kvalitet og fornuftige økonomiske og juridiske betingelser. )

(API-tilbyder - 5. Som API-forvalter ønsker jeg at API-katalogen kan vise min Swagger-dokumentasjon slik at jeg bare kan eksponere for eksempel Swagger-data (YAML) og slipper å drifte min egen Swagger UI-nettside. [relatert til Swagger-brukerhistorien, trur eg] )

(API-katalogen - BAM04 - Som leverandør av API-management-verktøy ønsker jeg at jeg å kunne tilby automatisk integrasjon med den felles API-katalogen slik at jeg kan selge mer av produktet mitt ved å vise til at det støtter opp under de nasjonale føringene. )

(REST GET informasjonsmodell-katalog - Søk og oppslag Informasjonsmodeller)

(Offentlig Virksomhet - Lokal Datasett søkeløsning)

(Premissgiver - styring dokumentasjon av API-er - BTI008 Som konsument av data fra offentlige virksomheter ønsker jeg at de offentlige virksomhetene inngår avtaler med sine leverandører som gjør det tydelig hvem som eier dataene, og stiller krav til at de skal være gjøres tilgjengelige uten kostnader, slik at ikke den offentlige virksomheten hindres i å dele sine data med meg som følge av at kostnadene blir for store. )

(API-katalog API - Service Metadata Publisher (SMP))

(Kapabilitet - Kapabilitetsoversikt)

(An external service - A service in a container)

(API-katalog - API-tilbyder)

(API-konsument (design time) - BFP011: Som API-konsument ønsker jeg et kontaktpunkt hos API-eier slik at man kan gi tilbakemelding og spørsmål. )

(API-backend - API-katalog API)

(Som API-forvalter ønsker jeg eierskapet og ansvaret til API-eier kommer tydlig frem slik at man unngår uklarheter - BAM11 - Som ansvarlig for API-management ønsker jeg å sikre eierskap av API-ene hos forretningseier/dataeier for å sikre kvalitet og eierskap. )

(Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier. - BA51. Som API-konsument ønsker jeg mulighet til å gi tilbakemeldinger slik at jeg kan melde fra om feil eller foreslå forbedringer)

(EPOS 4: Som API-konsument ønsker jeg oversikt over endepunkter slik at jeg kan ta API-et i bruk - Som API-konsument ønsker jeg oversikt over testmiljø og syntetiske data slik at jeg kan teste ut API-ene)

(Opprett API beskrivelse - Administrasjon av API-beskrivelser (design time))

(Som dataeier ønsker jeg at personopplysninger knyttet til dataeier etc. ikke publiseres til felles datakatalog - Tilgangskontroll (kun mulig for interne til å se personopplysninger tilknyttet dataeier etc.))

utvikler (API-tilbyder - API-et)

(Lenkede data - Municipality)

(Kapabilitetsoversikt - API-spesifikasjon)

(Modellkatalog, Datamodell, Data dictionary - BFDK08 - Som datasetteier (som beskriver datasett i datakatalogen) ønsker jeg å kunne plukke fra API-beskrivelsen dataelementene som jeg ønsker å ta med i datasettbeskrivelsen, slik at dataelementene jeg tar med gjenspeiler det som APIet virkelig kan tilby. )

(BA11. Som API-konsument ønsker jeg at jeg kan bytte til nye versjoner av API-et når det passer meg [Kommentar frå Livar: Litt usikker på denne. Her er det kanskje snakk om versjonering av API, at ein sjølv kan velje når tid ein byttar til ny versjon av API? I motsetnad til at eit API ikkje er versjonert og ved "breaking-changes" så må ein forholde seg til når API-et gjer eit brått hopp til ny versjon?] - Studenter, gründere og app-utviklere)

(API-katalogen - BA51. Som API-konsument ønsker jeg mulighet til å gi tilbakemeldinger slik at jeg kan melde fra om feil eller foreslå forbedringer)

(Felles rammeverk - Referansarkitektur)

(API-konsument (design time) - BFP007: Som API-konsument ønsker jeg god og forutsigbar ytelse slik at det er lett å velge bruk av rett API som samsvarer med krav til andre API som inngår i tjenesten/prosessen )

(FDK - Cron service)

(Premissgiver - styring dokumentasjon av API-er - 2. Som API-forvalter ønsker jeg at katalogen gir føringer for hvordan API-ene mine skal dokumenteres, etter “beste praksis”, så jeg slipper å sette meg inn i/holde meg oppdatert på hva som er beste praksis for API-dokumentasjon [frigjøre ressurser/bedre kvalitet] )

(API-tilbyder - 19. Som API-forvalter ønsker jeg kontaktinfo til de som bruker mine API slik at jeg kan ta kontakt med de om brukerundersøkelser, driftsmeldinger, endring av API, nye API og liknande. [dersom jeg ikke har egne løsninger for dette allerede] )

(Applikasjon 2 - API 2)

(Modelleringsklient - Skjemamodell)

(Begrepskatalog API - data.norge.no begrepshøsting)

(API-beskrivelse - )

(API-konsument (design time) - BFP017: Som API-konsument ønsker jeg en endringslogg så tidlig som mulig slik at jeg vet hva som har endret seg mellom versjoner. )

(Som tjenesteutvikler og data scientist ønsker jeg å finne informasjon om dataeier slik at jeg kan få tilgang til dataene - 1. Informasjon om dataeier (intern navngitt person))

(Program Management Office - Implement)

(Registreringsløsning API - API-katalog)

2 (/login - Begrepskatalog GUI)

(Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles - Datakonsumenter har behov for tilgang til dataene på en enkel og standardisert måte. )

(API-konsument (design time) - BA4. Som API-konsument ønsker jeg eksempler på API-requests slik at jeg kan komme fort i gang.)

(Begrepskatalog tjeneste - data.norge.no begrepshøsting)

(Tjenestekatalog tjeneste - data.norge.no tjenestehøsting)

(Begrepskatalog API - Begrepskatalog tjeneste)

(Tjenestekatalog - Tjenestekatalog tjeneste)

(API-katalog - API-katalog tjeneste)

(Informasjonsmodell-katalog - Informasjonsmodellkatalog tjeneste)

(data.norge.no datasettkatalog tjeneste - data.norge.no datasetthøsting)

(API-katalog tjeneste - data.norge.no API-høster)

(Informasjonsmodellkatalog tjeneste - data.norge.no informasjonsmodell-høsting)

(Virksomhet - API-katalog tjeneste)

(Virksomhet - Begrepskatalog GUI)

(Virksomhet - API-katalog GUI)

(Virksomhet - Datasettkatalog)

(Virksomhet - API-katalog)

(Virksomhet - Datasettkatalog GUI)

(Virksomhet - Begrepskatalog tjeneste)

(Virksomhet - Tjenestekatalog tjeneste)

(Virksomhet - data.norge.no datasettkatalog tjeneste)

(Virksomhet - Informasjonsmodellkatalog tjeneste)

(Virksomhet - Begrepskatalog API)

(Digdir - data.norge.no API)

(Digdir - data.norge.no portal)

(data.norge.no informasjonsmodell-høsting - data.norge.no portal)

(Datafabrikken - Datafabrikken portal)

(data.norge.no datasetthøsting - Datafabrikken portal)

(Digdir - data.norge.no datasetthøsting)

(Digdir - data.norge.no portal)

(Virksomhet - Datatilbyder)

(Datahotell tjeneste - Datafabrikk datasett søk)

(Datalandsby tjeneste - data.norge.no portal)

(Datasettkatalog - Virksomhetens datasett)

(Datahotell tjeneste - Virksomhetens datasett)

(Datahotell tjeneste - data.norge.no datasettkatalog tjeneste)

(data.norge.no datasettkatalog tjeneste - data.norge.no portal)

(Virksomhet - Datasettkatalog GUI)

(Virksomhet - Datasettkatalog)

(Virksomhet - Virksomhetens datasett)

(Virksomhet - Datatilbyder)

(Digdir - Datalandsby tjeneste)

(Digdir - data.norge.no portal)

(Digdir - data.norge.no datasettkatalog tjeneste)

(Datafabrikken - Datafabrikken portal)

(Datafabrikken - Datahotell tjeneste)

(data.norge.no portal - Datakonsument)

(Datafabrikken portal - Datakonsument)

(Datasettkatalog GUI - Datatilbyder)

(data.norge.no datasettkatalog tjeneste - Datafabrikk datasett søk)

(Datalandsby tjeneste - Datalandsby gui)

(Digdir - Datahotell tjeneste)

(Digdir - Datahotell API)

(Datahotell tjeneste - Datahotell API)

(Offentlig virksomhet - Datasettkatalog GUI)

(Offentlig virksomhet - Datasettkatalog)

(Offentlig virksomhet - Virksomhetens datasett)

(Offentlig virksomhet - Datatilbyder)

(Datatilbyder - Virksomhetens datasett)

(data.norge.no portal - Datatilbyder)

(Datafabrikken portal - Datatilbyder)

(Datafabrikken - Datalandsby tjeneste)

(Datahotell tjeneste - Datafabrikken datasettkatalog tjeneste)

(Datafabrikken datasettkatalog tjeneste - Datafabrikk datasett søk)

(Datasettkatalog - data.norge.no datasettkatalog tjeneste)

(Datasettkatalog - Datafabrikken datasettkatalog tjeneste)

(data.norge.no datasettkatalog tjeneste - Datafabrikken datasettkatalog tjeneste)

(Datafabrikken datasettkatalog tjeneste - data.norge.no datasettkatalog tjeneste)

(Datalandsby tjeneste - data.norge.no datasettkatalog tjeneste)

(Digdir - Single Information Point)

(Single Information Point - data.norge.no portal)

(data.norge.no datasettkatalog tjeneste - Datakonsument)

(Datahotell tjeneste - Datakonsument)

(Datafabrikken portal - Datafabrikk datasett søk)

(Datafabrikken portal - Datalandsby gui)

(Datafabrikken portal - Datafabrikk nettsamfunn gui)

(Datalandsby tjeneste - Datafabrikk nettsamfunn gui)

(Datafabrikken - Datafabrikken nettsamfun tjeneste)

(Datafabrikken nettsamfun tjeneste - Datafabrikk nettsamfunn gui)

(Datafabrikken - Datafabrikken data-marked tjeneste)

(Datafabrikken data-marked tjeneste - Datafabrikk nettsamfunn gui)

(Datafabrikk datasett søk - Datafabrikk nettsamfunn gui)

(Datahotell tjeneste - Datafabrikken data-marked tjeneste)

(data.norge.no datasettkatalog tjeneste - Datafabrikken data-marked tjeneste)

(Datalandsby tjeneste - Datafabrikken data-marked tjeneste)

(Datafabrikken nettsamfun tjeneste - Datafabrikken data-marked tjeneste)

(Datafabrikken datasettkatalog tjeneste - Datafabrikken data-marked tjeneste)

(Datafabrikken data-marked tjeneste - Datalandsby gui)