URI-standard. leverandørworkshop

Størrelse: px

Begynne med side:

Download "URI-standard. leverandørworkshop"

Hedda Løken
7 år siden
Visninger:

1 URI-standard leverandørworkshop

2 Kort intro Kort om Difi og arbeidet vi gjør på IKT og standardisering Innledning til hva vi tenker rundt URIstandardisering eller pekere til ressurser Kort om hvordan vi pleier å gå frem for å utrede ulike områder Diskusjon/ innspill

3 Difis rolle En forvaltning som er åpen, effektiv og tilpasset brukernes behov Difi skal bidra til å fornye, forenkle og forbedre offentlig sektor ved hjelp av IKT Difi skal gjøre dette som premissgiver, pådriver, veileder og partner

4 Felles forvaltningsstandarder Gir bedre samhandling med innbyggere og næringsliv (Uavhengig av brukerutstyr og funksjonsnivå) Gir bedre samhandling mellom offentlige virksomheter (once only og sammenhengende tjenester) Hindrer bindinger til enkeltleverandører og gir bedre konkurranse i markedet.

5 Hvordan velger vi forvaltningsstandarder? Felles standarder for hele offentlig sektor på tvers av forvaltningsnivåer: Standardiseringssekretariat i Difi som lager beslutningsunderlag (referansegrupper) Henter inn råd fra Standardiseringsrådet Obligatoriske besluttet av regjeringen i forskrift Anbefalte vedtas av Difi etter råd fra Standardiseringsrådet Samlet et sted (Referansekatalogen) Krav satt per bruksområder Standardiseringsrådet Åpen prosess

6 Referansekatalogen - innhold Starte i det små og utvide etter hvert Et bruksområde i bruksområder nå (noen utvidet stegvis) Først standarder som bidrar i dialogen med brukerne Senere standarder som bidrar til et bedre leveranseapparat for å levere gode, sammenhengende og effektive tjenester

7 Et viktig område er informasjonsforvaltning Standarder for begreps og definisjonsarbeid Termlosen for terminologiarbeid Standard for begrepsbeskrivelser v. 1.0 Standard for begrepskoordinering v. 1.0 Beskrivelse av datasett og datakataloger DCAT-AP-NO-1.0

8 Bruksområdet - Pekere til ressurser i offentlig sektor Tilrettelegge for å kunne identifisere ressurser, finne ressurser, lenke dem og verifisere dem. URI-standardisering Det har lenge vært ytret et behov for URI standarder i Standardiseringsrådet. Da tenker vi på følgende: Pekere til begrepsbeskrivelser Pekere til kodeverksbeskrivelser Pekere til tjenestebeskrivelser Pekere til selve datakilden Pekere til selve kodeverkene Pekere til tjenestene (Pekere til hvilken som helst ressurs eller modell element) Skal ses i sammenheng med åpne og lenkede data.

9 IETFs RFC-3986 definerer den generelle URI-syntaks: hvor: og URI=[<skjemanavn>:]<hierarkisk del>[?<spørring>][#<fragment>] [] betegner en valgfri del <> angir en navngitt del : avslutter skjemanavn? innleder spørring # innleder fragment <skjemanavn> Begynner med bokstav, deretter er lovlige tegn bokstaver, tall, «+», «.» og «-» (Internett-protokoll) <hierarkisk del> Begynner enten med «//», deretter «autoritetssti» eller det begynner uten «//» og har så deretter kun «sti» <autoritet> [<brukerinformasjon>@]<hostnavn>[:<portnummer>] <sti> {[/]<segment[[{;<parameter>}]]>} <spørring> streng <fragment> streng (del av referert ressurs) <brukerinformasjon> streng <hostnavn> streng <port> heltall

10 Ytterligere behov for samordning?

11 Utredningsmetodikk 1. Beskrivelse og avgrensning av området 2. Kartlegging av behovet i offentlig sektor på området (intervju med aktuelle offentlige virksomheter/ åpen leverandør workshop) 3. Kartlegging av eksisterende standarder 4. Vurdering av aktuelle standarder (kriterier) 5. Evaluering av ulike sammensetning av standarder og ulike krav (anbefalt/ obligatorisk) 5. Alternativt vurdering av behov for ny standard og hvem som bør lage den (eventuelt utkast til standard) 6. Konklusjon

12 Viktige avgrensninger Vi gjør dette for å få bedre utnyttelse av offentlige ressurser og få ting til å henge bedre sammen Arbeidet handler ikke om hvordan vi skal sikre at standarden skal bli tatt i bruk og hvordan vi skal jobbe annerledes. Selv om det også er et viktig tema Arbeidet handler om å skape et godt utgangspunkt for å komme i gang, for deretter å kunne tilpasse behov over tid

13 Hva skal vi diskutere Scenariobeskrivelser: Hva vil disse URI-ene benyttes til i praksis og hvordan? Er det noen grunnleggende problemstillinger som må diskuteres og besluttes? Hvordan skal URI-ene bygges opp? Er det krav til URI-ene? Er det behov for å bygge opp kodelister for spesifikke felt i URI-ene? Er det behov for tillegg, f.eks. liste over domener for å kunne gjøre distribuerte søk?

14 Bruksscenarier I nettsider kan det pekes på begreps-, kodelisteeller tjeneste-beskrivelser (både som del av informasjon og tjenestesider) I en tjeneste kan man peke direkte på en kodeliste for utfylling, eller en tjeneste for å hente informasjon fra andre steder. I programkode kan man peke på begrepsbeskrivelser eller lovtekster for å vise hvor noe er realisert. En som skriver forskrift kan søke på begrep for å vurdere mulig gjenbruk.

15 Bruksscenarier forts. Man kan tenke seg og kalle en tjeneste for å sjekke om informasjon som tastes inn er gyldig Knytte tjenestene til samtykke for gjenbruk av informasjon I fagsystem knytte lenker mot tidligere vedtak eller rettskjennelser Lenke til tjeneste med rett setting for kommunen du bor i Ta med data fra skjema i en spørring mot underliggende tjeneste

16 Hva finnes av standarder der ute Ulike offentlige virksomheter og medier EU, det som gjøres av ISA (Interoperability Solutions for European Public Administration) 10 regler Storbritannia (data.gov.uk) Life Science Identifier (LSID) Medical Subject Headings (MeSH) DBpedia Linked Movie Database Wikidata

17 Krav til URI-er De skal være enkelt oppbygde og menneskelig forståelige. Dette betyr at det skal være ganske lett å skrive inn en URI uten støtte i en veiledning og de skal være intuitivt forståelige (semantiske, RESTful). De kan inneholde identifikatorer som er offentlig publiserte. Typiske eksempler på slike identifikatorer er fødselsnummer, organisasjonsnummer og matrikkelnummer. De bør bygge på nettdomener som eies av en autoritativ ressursforvalter Det er gunstig at forvalteren av dataressursene har full teknisk råderett over disse ved å publisere dem fra eget internett-domene. Det er ikke praktisk å inkludere navn på organisasjon i en URI. I stedet for det skal det henvises til et internett-domen hvor den autoritative kilde (forvaltende organisasjon) er identifisert. Det er for å minimere behov for endringer av URI-er som følge av organisatoriske endringer. Dersom forvalteren skifter til et nytt internett-domene, bør en fortsette i parallell å publisere på det opprinnelige domenet eller etablere en omdirigering til det nye. Det kan i så måte være en fordel om man sikrer seg et eller flere domener som ikke har institusjonens navn, men mer hensiktsmessige og persistente navn for ressurspubliseringen. De skal ikke inneholde spesialtegn utenom noen få. Dette gjelder tegn som «,», m. fl. «-» og «_» tillates samt «.» som prefiks for format og suffiks for navnerom.

18 Krav til URI-er forts. De skal kunne inneholde alle UTF-8-tegn (utom spesialtegn, jfr. ovenfor). Det betyr at skal kunne uttrykke innhold også basert på særnorske og samiske tegn uten translitterasjon til ASCII-tegnsettet3. De skal bestå av små bokstaver4. URI-er er «case sensitive» og det kan derfor fort oppstå inkonsistenser. De skal ikke inneholde eksplisitte spørringer. Med dette menes å benytte «query»-funksjonalitet fra http-protokollen (innledet med «?»). Men det kan gjerne utløses spørringer bak fasaden som returnerer dynamiske lister/tabeller etc. De skal ikke inneholde versjoner. Her tenkes det på ikke-semantiske versjonsnavn som «1.4» eller «v3» etc. Bruk heller tidsstempler. De skal ikke vise teknologien som benyttes for lagring av de data som det pekes til. En skal ikke angi faktisk folder, filnavn eller filtype for lagring av ressursen på server bortsett fra «filtype» for angivelse av publiseringsformat. De kan inneholde tidsstempler basert på ISO Disse innføres for å hente frem innhold som ikke er av siste versjon, men ble publisert som

19 Grunnleggende problemstillinger Skal URI-ene kun være http URI-er? Hva skal ligge i selve URI-en og hva skal ligge i spørringer? Hvilke felter trenger å være fast og hva kan være valgfritt i URI-en?

20 Hvordan skal URI-ene bygges opp? ikator}[.{format}][/{tidspunkt}]] {domene} er det internett-domenet, ev. subdomenet, som ressursforvalteren bruker for tjenesten. {ressurstype} er type ressurs innenfor et begrenset, predefinert sett av slike. Her er det kun tillatt å bruke en av følgende verdier: data, metadata, datatid, hjemmel, ontologi, format {språk} er en 3-bokstavs forkortelse fra ISO-standard nr (Se referanse 11) {navnerom} er fagområde, forvaltningsområde eller begrepsområde mm. {objekttype} er navnet på en type fysiske eller abstrakte objekter som ressursen beskriver med mulig bruk av «/» dersom objekttypene ligger i et hierarki. {identifikator} er en unik identifikator innenfor objektsamlingen. {format} angir et spesifikt format av flere mulige for spesifisert ressurs. {tidspunkt} angir et spesifikt tidspunkt som data skal forholde seg til, dvs. data i den «versjon» som var blitt gyldig på dette tidspunkt det spørres om.

21 Tekniske krav til URI-ene Støtte for norske tegn æ, ø og å (f.eks. kontantstøtte) UTF-8 Bare små bokstaver

22 Behov for kodelister Liste over alle aktuelle domener Liste over ressurstyper

23 Andre behov Felles komponent som publiserer domene- og ressurskodelistene

Like dokumenter

Standarder for pekere til offentlige ressurser på nett

Standarder for pekere til offentlige ressurser på nett 17.03.2016 Kristian Bergem Avdeling for digital forvaltning Seksjon for nasjonal arkitektur Informasjonsforvaltning er et viktig område Standarder