Viderebruksveileder/Teknisk veileder

6. Teknisk veileder

Generell teknisk introduksjon til åpne data

Målet med åpne data er å gjøre data maskinlesbare og tilgjengeliggjort for dem som måtte ønske å benytte dem.

Ut over tilgjengelighet og maskinlesbarhet, er format i første omgang underordnet. Det må gjøres en jobb med å finne og samle data som idag eksistererer i proprietære systemer, silosystemer og med så tette koblinger til andre datasett at de er utilgjengelige for gjenbruk slik de står oppført idag.

Data kan lagres på mange måter, og det finnes mange forskjellige standardiserte formater som kan brukes ved deling av data. Den viktigste skillelinjen går mellom åpne standardiserte formater og proprietære formater utviklet og kontrollert av enkeltaktører.

Allikevel handler ikke åpne data om å omformattere alt som finnes til «det rette» formatet. Det finnes mange formater som kan realisere det samme første målet, nemlig å gjøre data tilgjengelige i et digitalt format som er maskinlesbart og som helst ikke krever flere konverteringer senere. Det handler om å benytte gjenkjennelige godt støttede formater som ivaretar objektets opprinnelige verdi og mening.

Data kan struktureres på forskjellige måter, med forskjellige teknikker og med forskjellig detaljnivå. Det viktigste er å skille rådata fra presentasjonsinformasjon fordi det er rådata som gir verdiskapning i denne sammenhengen.

Slik går du frem – teknisk dokumentasjon

Denne tekniske delen av veilederen er ment som en introduksjon til arbeidet som må gjøres for å åpne data. Målgruppen er IT-driftspersonale på IT-avdelingen. Det forutsettes en viss teknisk forståelse.

Når beslutningen om å tilgjengeliggjøre åpne data er tatt, er det viktig at IT-avdelingen som gjør den tekniske delen av jobben har samme forståelse som resten av organisasjonen om av hva slags data som skal åpnes for allmennheten.

Målet er å tilgjengeliggjøre relevante åpne data i maskinlesbare formater slik at de kan brukes av andre. Det innebærer å:

1. Kartlegge og velge ut dine data
2. Kvalitetssikre data
3. Klargjøre data
4. Tilgjengeliggjøre data
5. Tilrettelegge for å kunne håndtere tilbakemeldinger/feilmeldinger

1. Kartlegg og velg ut dine data

Ledelse, administrasjon og øvrige ansatte har normalt en god overordnet forståelse av hva slags data organisasjonen sitter på, samt hva som er relevant å åpne opp av data.

IT-avdelingen må først sjekke ut at dataene som ønskes åpnet faktisk eksisterer og er tilgjengelige. Dersom initiativet kommer fra IT-avdelingen selv, må det avklares med ledelsen slik at alle parter er informert.

Fagpersonalet må også identifisere hvilke deler av dataene informasjonen som er relevante på et mer detaljert nivå. Det innebærer en intern kartlegging av hvilke IT-systemer som inneholder hvilke data, samt hvordan de er lagret og hvordan dataene kan hentes ut.

Det er viktig å huske på at det som kan ansees som irrelevant for andre enn for din organisasjon, kanskje er akkurat de datasettene noen andre ønsker seg. Vurder derfor ikke kun etter hva dere selv synes er spennende drømmedata å dele.

I de fleste tilfeller vil dataene ligge lagret i en eller flere sentraliserte serverbaserte databaser, men dataene kan også ligge lagret i dokumentbaserte arkiv på f.eks. filservere.

Eksempler på informasjon om IT-systemer som bør kartlegges for aktuelle datasett:

• IT-system som bruker dataene (produktnavn, leverandørnavn, bruksområde)
• Tett integrasjon med sensitive data (hvor enkelt er det å skille disse datasettene?)
• Lagringssystem (relasjonsdatabase, regneark, dokumentarkiv etc.)
• Hvordan datalagringen er strukturert (f.eks. i hvor stor grad relasjonsdatabaser er normalisert, hvorvidt tabeller i dokumenter er tilgjengelig i separate regneark, etc.)
• Oppdateringsfrekvens (kontinuerlig eller intervall)
• Eksportmuligheter (CSV, SQL, XML, JSON etc.)
• Tilgjengelig API (for ekstern tilgang)
• Dokumentasjon (selvforklarende, metadata, behov for ytterligere beskrivelser)
• Eksisterende datautveksling (eksport til andre interne IT-systemer)
• Bruk av nøkler (unike/entydige, derefererbare, identifiserbare og aksesserbare)

Når det tekniske kartleggingsarbeidet er fullført må det avstemmes med resten av organisasjonen om all data er kartlagt og at utvalget representerer data som ønskes delt av organisasjonen.

Ansvarlige for prosessen gjør en prioritering av hvilke datasett som skal deles og i hvilken rekkefølge.

2. Kvalitetssikre dataene

I tillegg til å sjekke ut opphavsrettslige begrensninger og sikre mot at personsensitive opplysninger lekker ut må IT-avdelingen også vurdere datakvaliteten og hvorvidt de må bearbeides eller dokumenteres bedre for å kunne utnyttes av eksterne aktører.

Typiske momenter å sjekke:

• Er kvaliteten og omfanget av datasettene dokumentert?
• Er dataformatet selvforklarende eller godt nok dokumentert?
• Må dataene restruktureres før de tilgjengeliggjøres?

Er dine data gode, vil de bli brukt av mange, men det må ikke overvurderes hvor mye tid som skal legges i for å gjøre et datasett komplett. Det er ikke slik at et datasett må være komplett for å kunne deles, så lenge dokumentasjonen beskriver hvorvidt det mangler data eller finnes dårlige data. Viktigst er det å huske på at objektenes opprinnelige verdi og sammenheng synliggjøres i dokumentasjon og at relasjoner i datasettene ivaretas gjennom formatet som brukes til å publisere dataene. På den måten unngår man feilbruk og øker sannsynligheten for gjenbruk.

3. Klargjøre dataene

Vurder først hvordan dataene skal tilgjengeliggjøres. Det er i praksis tre overordnede måter å dele data:

• Dokumentformater
• Maskinlesbare dataformater
• API

Dokumenter

Dataprogrammer som f.eks. regneark og tekstbehandlingssystemer leser og skriver informasjon til og fra forskjellige typer dokumenter. Dette gjør det mulig å dele informasjon på tvers av maskiner, og til dels også på tvers av programmer.

Noen eksempel på dokumenttyper:

• .PDF (Adobe Acrobat)
• .doc/.docx (Microsoft Word)
• .txt (ren tekst)
• .htm/.html (nettlesere)
• .xls/.xlsx (Microsoft Excel)
• .odf (OpenOffice.org)

Selv om dokumenter kan leses av dedikerte programmer kan de ikke anses som maskinlesbare. Disse dataformatene er tilrettelagt for brukeren av dataprogrammet, og ikke for datasystemer som skal bruke rådataene til andre formål.

Det er for eksempel svært krevende å utvikle løsninger som støtter all funksjonaliteten som ligger i dataformatet til et Excel-basert regneark. Det er mulig, men kompleksiteten gjør det til en ressurskrevende oppgave med mange potensielle feilkilder.

Samtidig er det til stor hjelp å faktisk få dataene tilgjengeliggjort i Excel-regneark, dersom alternativet f.eks. er å måtte hente informasjonen manuelt ut fra tabeller i et stort dokument. Finansdepartementet har f.eks. delt ut alle tabeller i Statsbudsjettet som egne Excel-regneark.

Merk at de samme fordelen som oppnås ved å publisere data som Excel-regneark, kan oppnås ved å publisere ved hjelp av ODF-formatet. ODF-formatet er obligatorisk for alle statlige og kommunale etater, jfr forskrift om IT-standarder i forvaltningen. Excel-format må eventuelt komme i tillegg.

HTML er et presentasjonsformat og er ikke egnet som et prosesseringsformat. Dette betyr at html-koden forteller deg at det finnes en overskrift H1, ingress og hovedtekst, men den forteller deg ingenting om innholdet i verken H1, ingressen eller hovedteksten.

Maskinlesbare dataformater

Åpne data inkluderer mange forskjellige dataformater. Fire av de mest brukte er CSV, SQL, XML og JSON.

CSV er komma-, tabulator- eller semikolonseparerte tekstfiler der hver linje tilsvarer en rad i en databasetabell eller i et regneark. Hvert felt skilles med et komma, et semikolon, tab eller et fast antall tegn. Alle regnearkprogrammer, samt de fleste databasesystemer støtter import og eksport av data gjennom CSV-filer. Utfordringen ligger i at det kan være stort fortolkningsrom av hva verdienes opprinnelige betydning i hver rad er.

SQL (Structured Query Language) er et språk som benyttes til å håndtere data. De fleste av dagens databasesystemer kan komminiseres med via SQL. En SQL databasedump kan være en god måte å raskt gi tilgang til data med tilhørende relasjoner. Databasedumpen er en tekstfil som inneholder strukturen og alle dataene i databasen. Dersom det er behov for annonymisering av enkelte data i databasedumpen kan dette gjøres med verktøy for tekstprossesering [sed/awk/grep/tr/split mm]. Ved tolking av SQL filer kan det være utfordrende å skjønne verdienes betydning i daglig bruk. Det er nyttig for videre bruk av dataene å kjenne til hvilke verktøy og rutiner som er brukt når databasedumpen ble opprettet.

XML er et strengt strukturert dataformat som organiserer data i hierarkiske strukturer og har støtte for formaliserte skjemaregler for hvordan dataene skal struktureres.

XML er en svært utbredt teknologi, og den støttes i praktisk talt alle programmeringsspråk, men ofte gjennom tredjeparts bibliotek. Ved hjelp av tilleggsteknologier, som f.eks. XSLT, er det også relativt enkelt og raskt å konvertere data fra et XML-spesifisert format til et annet format ved behov for å integrere data fra forskjellige datasystemer som må spille sammen.

XML-formaterte data kan være enkle å bruke og forholde seg til, men kan også bli svært kompliserte når teknologiens potensiale utnyttes. Ved avanserte implementasjoner blir det fort umulig for menneskelige øyne å få oversikt over dataene som presenteres, og dette kan forårsake programmeringsfeil hvis utviklerne ikke klarer å få oversikt over avanserte skjemaregler.

XML er en slags plattformteknologi for mange forskjellige dataformater, men det er to som skiller seg ut som spesielt interessante for bruk i forbindelse med publisering av åpne data.

Atom og RSS er overlappende formatspesifikasjoner som primært brukes til dataformatert publisering av nyhetsartikler, blogginnlegg og lignende tekstbasert innhold. RSS er spesifisert i XML og inneholder støtte for RDF-vokabularet og metadatastandarden Dublin Core.

JSON er et maskinlesbart dataformat som også er tilrettelagt for å kunne leses av mennesker. Det er et av de mest brukte dataformatene i webapplikasjoner, og det finnes JSON-bibliotek for rask og enkel tilpasset bruk i de aller fleste programmerinsspråk.

En potensiell ulempe med JSON er at formatet har en løs struktur, og det kan derfor oppstå problemer hvis et program som leser eller produserer JSON-formaterte data avviker fra den planlagte implementeringen.

YAML er et format som søker å gjøre det enklere for mennesker å skrive maskinlesbare datastrukturer.

Veien mot lenkede datasett

Der målet er å opprette datasett som man kan relatere til hverandre, er det nyttig å se på formater som er tilrettelagt for dette. Det finnes få teknologier med egenskaper som fungerer optimalt til dette formålet. RDF er det formatet som best representerer datasett med semantisk definerte relasjoner og unik representasjon av alle objekter ved hjelp av URier. RDF er et såkalt skjemaløst språk som ikke skiller mellom datamodell og selve dataene. Les mer om dette på http://www.w3.org/RDF/.

5-stjerners data

Denne veilederen ønsker å fokusere på å tilgjengeliggjøre data først og fremst. Uavhengig av format, bør du publisere det fremfor å la det ligge i dine lukkede systemer. Dette kalles 1-stjerners data i en modell som ble laget for å illustrere hvordan man stegvis kan oppgradere verdien og nytten av sine data.

2-stjerners-data betyr å gjøre data tilgjengelige i et strukturert format. Dette innebærer å legge til rette for prosesserbare formater og ikke bruke for eksempel bildefiler.

3-stjerners-data: Sitter du på teknisk avdeling, ønsker å benytte ikke-proprietære formater og vet hvordan man gjør det, så bør du ta sikte å nå tre-stjerners målet. Bruk CSV og JSON og XML, men tenk på å ta sikte på å bruke unike identifiserbare URier som identifikatorer til dataene slik at man på sikt kan tilby langt større grad av kontekst til datasettene ved å lenke de til hverandre.

Tabelloversikt over formater og egenskaper

Hva slags, og hvor mange forskjellige dataformater de åpne dataene skal tilgjengeliggøjres gjennom, må også vurderes ut fra en praktisk orientert tankegang. Jo flere, jo bedre, men jo flere, jo mer krevende. Vedlagt er en tabell som viser noen ulike filtyper og i hvilken grad de er maskinlesbare, menneskelesbare eller åpne.

Filformat	Maskinlesbar	Spesifikasjon tilgjengelig	Åpen	Semantisk struktur	Kommentar
Ren tekst (.txt)	V?	V	V		Ikke maskinlesbart med mindre en spesifikk struktur er spesifisert f.eks i csv eller kommaseparert liste
Kommaseparert fil (.csv/.txt)	V	V	V
Hyper Text Markup Language (.html/.htm)	V?	V	V		Ikke maskinlesbart - fokus på å presentere informasjon for mennesker, ikke strukturere data
Extensible Markup Language (.xml and other XML derivated dialects e.g RSS/ATOM)	V	V	V		Strukturert dataformat med støtte for avanserte programmerbare skjemaregler. Brukes av en rekke etablerte standardiserte dataformater.
Javascript Object Notation (.json)	V	V	V		Maskinlesbart format som er relativt enkelt å lese også for mennesker
Resource Description Framework (.rdf) RDF/XML	V	V	V	V
RDF model, Turtle syntax (.ttl, .n3)	V	V	V	V
Regneark (.odt, .ods, etc)	V?	V	V		Mangler definert struktur for tolkning - slik som. html,. txt -se kommentar om .html
Portable Document Format (.pdf)	X	V	V
Microsoft Word (.doc/.docx)	X	V	X
Microsoft Excel (.xls/.xlsx)	V?	V	X		xls binære format krever biblioteker/APier for å leses

Maksimalisering av gjenbruk og minimalisering av feilbruk

Med viderebruk vil data som har blitt til i en kontekst kunne bli brukt i en annen. Utfordringen med flertallet av systemer idag, er at de er begrenset til kun å få de sammenhengene mellom dataene som utviklerene har tenkt ut. Dersom noen andre behøver dine data, eller skal integrere med ditt system, har de som regel behov for andre sammenhenger mellom dataene enn det som var opprinnelig påtenkt.

Derfor er det ofte vanskelig å gjenbruke eksisterende datasett. Verdiskapningspotensialet ved å tilføre mer data til et opprinnelig datasett forsvinner også, fordi metodene som benyttes for å legge til de manglende datatilknytningene, ikke åpner for å tilbakeføre tilleggsinformasjonen til den opprinnelige kilden.

Når datasett skal gjenbrukes er det av samme årsak viktig å vite at de dataene du gjenbruker ikke tolkes feil i ditt systemet fordi du henter de ut av en annen kontekst. Dette avhenger av hvor godt datasettet du bruker er dokumentert fra dataeiers side og at du ikke legger til altfor mange antagelser om formålet med datasettet.

4. Tilgjengeliggjør data – Nedlastbart eller api?

Ved store datasett, eller behov for at dataene er «ferske» er det viktig å tenke på hvordan tilgangen til data gis. Det er da naturlig å gjøre dem tilgjengelige gjennom et API istedet for fil-nedlasting. Det er da viktig å legge listen for bruk så lav som mulig.

Dersom dataene oppdateres kontinuerlig må det vurderes om de skal tilgjengeliggjøres gjennom et API som åpner for ekstern tilgang og/eller om det skal baseres på eksport ved gitte intervaller. Oppdateringer kan gjøres tilgengelig som endringsfiler [patch/diff] og via rsync. Dersom en ønsker å vise endringer over tid på en effektiv måte, er det mulig bruke revisjonskontroll og fildistribusjon via Git. Det bør også vurderes om eksporteringsrutiner skal automatiseres, eller om det er tilfredsstillende å gjøre en manuell eksport ved behov.

Store datamengder kan skape store datafiler som blir vanskelig å prosessere på vanlige PC-er med vanlig programvare. Er dette tilfelle, kan fildelingsløsninger være en god løsning.

Ved behov for å gi direkte tilgang til dataene over internett gjennom API kommer det en rekke avanserte problemstillinger som ikke dekkes i denne veilederen.

Ved implementering av eksternt API må blant annet følgende vurderes:

• Sikkerhet
• Skalerbarhet

5. Tilrettelegging av dataene

Når dataene er tilgjengeliggjort i et maskinlesbart format er den viktigste delen av jobben gjort. Det neste som bør gjøres, er å tilrettelegge dataene slik at det blir enklere å utnytte potensialet som ligger i åpne data.

Selv om brukeren selv kan konvertere datasettene til ønsket dataformat, er det en fordel om organisasjonen selv tar ansvar for å støtte flere dataformater, samt å dokumentere datastrukturen.

Det er en fordel om dokumentasjonen og kommunikasjon organiseres slik at det er enkelt å gi åpne tilbakemeldinger som blir delt mellom brukerne. [wiki/"redmine"/"github"/etc.].

Målgrupper

Potensielle brukere av åpne data kan grovt sett deles i to hovedtyper: superbrukere og programmerere.

Superbrukere er personer som kan bruke eksisterende verktøy som f.eks. regneark og nettbaserte tjenester til å konsumere, flette sammen og redigere data fra forskjellige kilder. De kan ha basiskunnskaper om programmering, men jobber primært med å bruke dataene. De er avhengig av å få datasett i dataformater som støttes av verktøyene de bruker.

Programmerere er databrukere som selv lager programmer. Ved behov kan de selv utvikle løsninger for å tilpasse datasettene til et dataformat som dekker deres eget behov, men de er avhengige av god dokumentasjon på avanserte datasett. De vil i noen tilfeller kunne trenge en teknisk kontaktperson hos organisasjonen, f.eks. ved utvikling av løsninger som bruker API for direkte tilgang til organisasjonens åpne data.

Dokumenter datastrukturen

Enkle datasett kan være selvforklarende, men selv de enkleste trenger en beskrivelse av hva slags data de inneholder.

Hvert datasett bør inneholde følgende informasjon:

• Hva slags opplysninger datasettet inneholder
• Hvilken kvalitet datasettet har
• Kilden
• Hvor ofte (og når) dataene oppdateres
• Hvor siste oppdatering kan hentes

Hvor detaljert datasettet må dokumenteres avhenger av innholdet. Enkle tabeller kan være selvforklarende, mens data i relasjonsdatabaser kan bli svært kompliserte og uoversiktlige.

Håndtere tilbakemeldinger

En dataeier har ansvaret for å oppdatere datasettene sine dersom de har dokumentert at oppdateringer og feilrettelser skal skje med gitt intervall. Dersom en bruker av dine data rapporterer feil eller melder behov, bør dataeiers organisasjon ha tatt høyde for at dette håndteres og at det ansees som en del av prosessen som er igangsatt.

Forventet responstid etter innmeldte feil bør også dokumenteres, slik at en bruker av dine datasett, på forhånd kan beregne risiko og utfall av feil ved gjenbrukte datasett. På den måten kan en bruker være forberedt på at en rettelse ikke kan forventes innen en uke fra innrapportert feil. Det er forskjell på behov som følger av “ferske” sanntidsdata og arkivdata.

Enkle oppdateringer og rettelser av feil bør ikke ta for mye tid for dataeieren, og ved hjelp av god dokumentasjon og bevissthet omkring kunnskapsdeling, bør man ikke bli avhengig av kunnskapen og kompetansen til én person i IT-avdelingen. Rutiner for å oppdatere og publisere data bør være påtenkt i oppstart av prosessen.

Det er en fordel om det tilrettelegges for åpne tilbakemeldinger som i størst mulig grad blir blir delt mellom dataeier og brukerne [wiki/"redmine"/"github"/etc.]. Dette kan bidra til å øke kunnskapen om dataene og brukerne kan få muliget til å støtte dataeier i den jobben som gjøres.

Det viktigste å huske i denne delen av prosessen er at dette er en mulighet for organisasjonen til å få oppdateringer til sine datasett og det kan ansees som en ekstra kvalitetskontroll.

Referanser og kilder

5-star-data: http://lab.linkeddata.deri.ie/2010/lod-badges/ W3C sitt initiativ for Linked Open Data: http://esw.w3.org/SweoIG/TaskForces/CommunityProjects/LinkingOpenData Metadata standard: http://dublincore.org/ RDF som semantisk maskinlesbar standard : http://www.w3.org/RDF/ XML tutorial: http://www.w3schools.com/xml/default.asp Omfattende informasjon om Linked Data: http://linkeddata.org/