Introduktion till PSI-data, öppna data och länkade data

Enligt min uppfattning har öppna data (lite oväntat) tagit ny fart inom offentlig sektor. För någon vecka sedan kommenterade en kollega att ”jaha, jag trodde vurmandet kring öppna data ingick i ditt arbete”. Nej, så är inte fallet. Snarare är det väl så att mina chefer av någon anledning frekvent låter mig jobba med det jag brinner för.

Så för att fräscha upp lite om min syn på öppna data-frågan till 2017 skriver jag denna bloggpost. Är det något du tycker verkar skumt, vill korrigera eller har frågor är du varmt välkommen att skriva en kommentar, eller kanske mejla mig på fornamn.efternamn@vgregion.se

Öppna data

Öppna data är begreppet som används nästan oavsett vad man egentligen menar. Kanske för att det låter bra. Det handlar ju om ”data” och när var något som är ”öppet” negativt? För något år sedan var nog precisionen i begreppet bättre. Det finns nämligen ett antal andra begrepp värda att tänka igenom; PSI-data, länkade data och länkade öppna data. Mer om dem senare.

Ordlista – API (Application Programming Interface):

Ett API är en kontaktpunkt för att utbyta information. När det gäller datakällor är ett API en teknisk lösning som lämnar ut den data någon efterfrågar, det den enskilde har rätt att ta emot och i de format passar användningen.

Då öppna data är en naturlig del av ämnet informationsarkitektur kunde jag inte motstå att skriva om det i boken Webbstrategi för alla som publicerades 2014. På ett övergripande plan beskriver det fortfarande öppna data väl och hur det definieras. Så här skrev jag då:

Vad är då öppna data?

Öppna data är digital information som inte har begränsningar avseende återanvändning, till skillnad från PSI-data som tillåter begränsningar i återanvändning. Öppna data ska alltså vara befriat från bland annat upphovsrätt, patent och andra hinder. När staten är utgivare av sådan information brukar det kallas för öppna offentliga data.

Open Government Working Group har gjort ett av flera försök att enas om vad som kan anses vara öppna data. Dessa krav, hämtade från Wikipedia, stämmer åtminstone med min uppfattning:

1. Komplett: Information som inte innehåller personuppgifter eller lyder under sekretess görs tillgänglig i så stor omfattning som möjligt. Detta gäller särskilt databaser med material som skulle kunna vidareförädlas.
2. Primär: Information skall så långt det är möjligt tillhandahållas i originalformatet. Bild- och videomaterial skall tillhandahållas i högsta möjliga upplösning för att möjliggöra vidareförädling.
3. Aktuell: Information skall tillgängliggöras så snabbt som möjligt så att värdet av den inte försvinner. Det bör finnas mekanismer för att automatiskt kunna få information om uppdateringar.
4. Tillgänglig: Information görs tillgänglig för så många användare som möjligt för så många ändamål som möjligt.
5. Maskinläsbar: Informationen är strukturerad på ett sätt som möjliggör maskinell bearbetning och samkörning med andra register.
6. Fri: Informationen är tillgänglig för alla utan krav på betalning, eller inskränkningar i form av licensvillkor och registreringsförfaranden.
7. I ett öppet format: Det format informationen lämnas i följer en öppen standard, alternativt är dokumentationen till formatet fritt tillgänglig och fri från patent eller licensvillkor.
8. Utan licens: Datakällan i sig ska vara fri från licenskrav eller andra saker som kan begränsa möjligheten till återanvändning.

Vissa punkter är mer öppna för tolkning än andra. Kanske främst punkt 7 som kan vara allt från en banal textfil till ett avancerat API för spridning och synkronisering av information.

Om man kombinerar öppna data med ett så kallat API, vilket många anser är en självklar kombination, uppstår möjligheten för andra att direkt bygga tjänster på den information som samlats in. Det är egentligen inte ett krav på öppna data att den erbjuds via ett publikt API, men om du vill uppmuntra till användning är det värt att kolla under vilka förutsättningar utvecklare vill ta del av din info. Utlämningen av data behöver vara pålitlig, smidig och väcka utvecklares förtroende om de ska våga använda det. Utvecklare kanske inte alltid prioriterar att tjäna pengar på det de bygger men snabbt lär de sig att undvika frustrationen som uppstår med till synes onödiga hinder, villkor och annat strul.

Det som är specifikt med öppna data är som du nog listat ut öppenheten. Att vem som helst ska få använda datakällan utan en massa krav, krångel eller kostnader. Men det kanske inte är uppenbart varför man ska lägga tid och energi på att proaktivt öppna alla sina datakällor, kanske finns inget intresse och då har jobbet varit förgäves. Men för att medborgare åtminstone skulle ha rätt att få tillgång till myndighetsdata när intresse finns lanserade EU sitt initiativ kallat PSI.

PSI-data

PSI står för Public Sector Information och är en skapelse inom EU. Det blev svensk lag 2010 med det härligt byråkratiska namnet ”lagen om vidareutnyttjande av handlingar från den offentliga förvaltningen”, populärt kallad PSI-lagen, och inleds med paragrafen:

”Syftet med denna lag är att främja utvecklingen av en informationsmarknad genom att underlätta enskildas användning av handlingar som tillhandahålls av myndigheter.
Lagen avser att förhindra att myndigheter beslutar om sådana villkor för vidareutnyttjande av handlingar som begränsar konkurrensen.
Bestämmelser om tillhandahållande av handlingar finns i annan författning. Lag (2015:289).”

En inledande kritik mot lagen var att svenska staten var ett ”pappers-API”, det vill säga lämnade ut utskrifter istället för digitala filer. Det är helt klart svårt att se smidigheten för den som tar emot en utskrift om deras tjänst är digital. Andra klagomål gick ut på att utlämnandet var motvilligt, gick trögare i Sverige än i andra länder samt att myndigheterna inte agerade proaktivt med öppnadet av datakällor så handläggningen av återkommande ärenden fortsatte ta lång tid (istället kunde man ha lanserat ett API). Dessa klagomål fick jag mig påtalat som representant för vad som entreprenörer upplevde som “myndighetssverige” och det stämde säkert.

Så själva definitionen på PSI-data är den man som myndighet är skyldig att lämna ut enligt lagstiftningen. Det är en EU-harmoniserad variant av det vi i Sverige haft i form av offentlighetsprincipen, att medborgarna ska ha en viss nivå av insyn.

Utmaningen med sekretess

Här kommer också frågan om sekretess in, för givetvis har man inte rätt att kräva insyn i andras känsliga uppgifter. Att lämna ut data i större skala från ett system kräver att man känner till vilken information som lagrats var i ett system. Det kan låta enklare än det visar sig vara i verkligheten. För hur vet man att ingen skrivit personuppgifter på fel ställe, eller att någon laddat upp ett dokument i fel system?

Har man däremot genomfört en kompetent informationsklassificering (och användarna följer den) blir det desto enklare. Då kan man välja att exkludera det som är känsliga uppgifter och erbjuda fri tillgång till allt det andra. Denna problematik är kanske inte uppenbar för den stressade entreprenören som undrar varför det tar en sådan tid, men givetvis kan PSI-ärenden ta lång tid av mindre behjärtansvärda anledningar.

En utmaning med både öppna data och PSI-data är om data är maskinläsbar och på vilket sätt. På sätt och vis är ju allt maskinläsbart, till och med ett inskannat protokoll från ett politiskt möte. Men att få en bild av text är inte smidigt även fast man med OCR-teknik ofta kan omvandla till maskinläsbar text. En PDF-fil är inte heller skitkul, dels för att det är ett dokumentformat (utan att ens diskutera hur öppet det formatet är) så det krävs omvägar för att ta del av innehållet. Men även om innehållet är maskinläsbart är det inte detsamma som att det kan förstås av en maskin. För en längre diskussion om vad en maskin “förstår” så kolla bloggposten om data science.

Just när det gäller möjligheten för en maskin att förstå innehållet är det snarare konceptet länkade data man bör eftersträva.

Länkade data

Den avgörande skillnaden mellan länkade data och andra datakoncept är att länkade data har ett sätt att relatera till andra datakällor. Man kan säga att så som webben är en samling av dokument som länkar sinsemellan är länkade data nästa naturliga steg. Med länkade data gör man likt webben lösa kopplingar fast mellan olika datakällor, man verkar på en mer detaljerad nivå.

Att följa definitioner

Innehållet kan på så vis bli mer förädlat. En liten snutt information kan beskrivas mer exakt och man kan samverka med hur saker definieras. En sådan definition är Schema.org, ett samarbete mellan ett flertal IT-jättar där man standardiserat vad någonting är. Exempelvis kan man med hjälp av Schema.org tala om att två ord i följd är ett namn, och att det namnet finns i ett sammanhang som utgör ett digitalt visitkort med kontaktuppgifter. Visitkortet kan vara i ett ännu större sammanhang av en lista med andra anställda inom en organisation. Både organisationen och individerna kan ha egna kontaktuppgifter, men de har en relation till varandra.

Genom att samarbete med dessa definitioner kan man alltså klargöra vad en delmängd av en webbsida är för något. Och när det handlar om andra sammanställningar, som databaser eller textfiler som RDF, finns ett sätt att berätta att en strukturerad informationsmängd är inbäddad i innehållet.

Var inte dumstolt!

En annan möjlighet är att dansa efter någon annans pipa, det vill säga motsatsen till fenomenet “not invented here”. Istället för att vara dumstolt och själv uppfinna hjulet i sitt eget projekt kan man följa initiativ som finns utom eller över ens egen organisation. För oss som jobbar i hälso- och sjukvårdsbranschen är Socialstyrelsen en sådan övergripande organisation. Antingen följer man deras initiativ och blir kompatibel, eller så gör man det jobbigt för alla parter och hittar på något eget. Visst är jag diskret med min egen åsikt? 🙂

Socialstyrelsen har en lång lista med goda exempel på sin PSI-datasida. De erbjuder nationell informationsstruktur vilket gör att man kan enas om begrepp, metadata och terminologi. Att man har god anledning att tro sig vara överens om begrepp är grunden för att kunna kommunicera…

Metadata och explicit innehållsdeklaration

Problemet man försöker lösa är inte helt intuitivt för alla har jag märkt. Ett vardagligt exempel är hur man ska läsa datum i matbutiken. Det var ett större problem mellan 2001-2012 än det är idag, men om du får sifferserien 12/10/11 kanske du inte är beredd att sätta pensionen i pant på vilken av siffrorna som indikerar årtal, eller hur? För en maskin är det ännu svårare. Gör du ett dokument, stoppar in en tabell och i en cell skriver in “Datum: 2017-02-17” finns det enligt många människor fog för att tro att serien med siffror avser 2:a februari 2017, men maskiner får inte alltid så mycket frihet till egen tolkning (ens om de begriper vissa saker). Det finns ett antal antaganden bara i denna lilla datamängd. Först ordet “datum”, är det tidsangivelsen som avses, en geografisk plats eller en enstaka del av data/information? Har man gett en maskin en ordlista är det inte säkert att den kan bestämma sig.

Tar du sifferserien är det vid första anblick inte givet om det är tänkt att subtraheras till 1998, om det är en tidsangivelse eller annat. Om det är en tidsangivelse kan man undra vilket formatet är.

För att sluta chansa ska man uttalat och explicit berätta _vad_ något är. Om siffrorna deklareras som ett datum i enlighet med ISO-standarden 8601 behöver man inte tveka vilket som är månaden. Då blir innehållet i denna korta textsnutt användbar även för maskiner som då inte tror att det är ett matematiskt uttryck.

URI:er för namngivning och relationer

Men frågan du kanske ställer dig är exakt hur en maskin får reda på att en snutt text är i enlighet med något som Internationella standardorganisationen (ISO) har tagit fram, eller att busslinjen är just den som går i västlig riktning. Det är här URI:er kommer in.

URI står för Uniform Resource Identifier och avser som namnet antyder ett enhetligt sätt att namnge eller identifiera resurser/saker. Du har säkert redan hört talas om den snarlika förkortningen URL (Uniform Resource Locator). Skillnaden dem emellan är att en URI identifierar någonting medan en URL pekar ut något. Både URI:er och URL:er kan se exakt likadana ut. Det är nämligen lämpligt att man delar ut webbadresser som identifiering av något, exempelvis en busslinje. Om den hypotetiska busslinjen i västlig riktning har URI:n https://data.vasttrafik.se/busslinjer/58-vastlig/ är det uppenbart för de flesta att det nog även fungerar som en webbadress.

Det fiffiga är att detta är en unik namngivning. Det kan bara finnas en unik URL, och utfärdaren i form av Västtrafik gör URI:n beskrivande. Den URI:n är ett enhetligt sätt för både Västtrafik och deras partners, men också för utomstående, att hänvisa till samma sak. En sådan URI kan ingå i en databas för att tala om vad som avses, men det kan också agera som en länk tillbaka till källan – Västtrafik alltså.

Länkade relationer kan utforskas maskinellt

Om du eller din maskin börjar utforska vad som erbjud med busslinje 58-västlig har vi alltså en URI att börja med. URI:n ser ut och fungerar som en URL. En av fiffigheterna bakom webbprotokollet HTTP(S) är att man kan ha önskemål när man kommunicerar med en webbserver. Sitter vi vid en webbläsare och surfar tänker vi normalt sett inte på detta, det vi är ute efter är att ta emot läsligt innehåll som är optimerad för människors konsumtion (med eller utan tekniska hjälpmedel som skärmläsare).

Däremot kan en maskin, som en sökmotor eller annan teknik, önska att få svaret i ett mer maskinförståeligt format. Som RDF exempelvis, vilket är ett semantiskt XML-format där innebörd och informationsrelationer finns bevarat i ett format maskiner gillar.

Så det en maskin kan göra är att vid en HTTP-fråga till en webbserver be snällt om att få svaret i RDF-format, men också artigt förklara att webbservern får falla tillbaka på HTML om den inte har något annat (kolla in boken Linking Government Data, 2011 för djupdykning).

I ett svar som är formaterat i RDF kan man för den västliga busslinjen få reda på att den har en relation till busslinje 58 i östlig riktning. Dessutom kan man få en lista över vilka hållplatser som trafikeras, hur tidtabellen är och en lista med metadata.

I listan med hållplatser finns för varje hållplats en identifierande URI. Om maskinen utforskar den kommer den hitta fram till en annan typ av information – något som har en geografisk plats. Att det är en geografisk plats vet maskinen för att det framgår vilken informationsstandard som latitud och longitud är angivna med, utan det ser latitud och longitud (enligt decimala WGS-84-formatet) ut som ett numeriskt tal med en massa decimaler. Ifrån hållplatsens URI går det att upptäcka och utforska alla andra busslinjer som trafikerar just den hållplatsen.

Länkade öppna data – den semantiska webben

Och så fortsätter det. Därav ordet “web”, ett världsomspännande spindelnät är precis vad webben är avsedd att vara, men detta är den semantiska webben – där innebörd och mening inte går förlorad i lika stor utsträckning som den “vanliga” webben.

Men länkade data är inte nödvändigtvis öppna för utomstående eller en del av den publika webben. I de fall man vill sprida sina data och koppla ihop sina länkade data med den dynamiska omvärlden är det länkade _öppna_ data det handlar om. Skillnaden är inte större än att man får in öppenhet som dimension. Så det handlar om både struktur, mening men också att det erbjuds öppet. I ovan hypotetiska exempel med kollektivtrafik är öppenheten uppenbar då vem som helst har nytta av att kunna relatera till en hållplats eller busslinje. På så sätt kan man samarbeta över diverse gränser. Sen kan man ha en hybrid mellan öppenhet och slutenhet, med det material man samarbetar är det öppet och när det öppna materialet hänvisar till något slutet kräver den URI:n en viss behörighet för att visa interna detaljer.

Inom och utom organisationen

Så skulle man kunna resonera kring journaldata inom alla de framtida vårdinformationsmiljöerna som upphandlas just nu. Man gör skillnad på åtkomst, att det finns olika grupper eller zoner för behörighet.

En URI:s svar kan bero på vem som frågar, om frågan ställs från en betrodd parts fysiska nätverk eller liknande. Så om det är jag som frågar efter min egen patientjournal har jag tillgång om det går att verifiera att jag är jag, men om jag frågar efter grannens journal bekräftas inte ens att någon sådan existerar. Mellanvarianter kanske är aktuella i somliga fall, men det gäller att inte råka läcka uppgifter – att bekräfta att något existerar kan vara illa nog i vissa fall.

För mindre känsliga uppgifter kanske man kan ha en intern behörighet som ger en ofarlig sammanfattning av något. Ett tänkbart exempel är att de inom offentlig sektor som signerat sekretessavtal har åtkomst till mer information än de som ännu inte har gjort det. Bredvid dessa som har sekretess finns andra grupper som lyder under striktare sekretess, exempelvis för att man ingår i projekt som har upphandlingssekretess, eller det givna med patientsekretess.

Arkitektur: API:er ska följa DCAT-AP och när väljer man “feta” API:er?

Det finns många hänsyn att ta när man utformar sina API:er. Inte minst att värna om de som använder ens API vilket vi kommer gå igenom strax. Ett sätt att göra listningen, själva katalogen, begriplig är att följa EU:s rekommendation att nyttja DCAT-AP för att beskriva respektive datakälla. Det gör att själva API:et som sådant följer en sådan struktur att den är självbeskrivande för maskiner. Följer ett API DCAT-AP kan API-kataloger likt ÖppnaData.se automatiskt upptäcka och inkludera API:et i sina listningar.

En annan arkitekturfråga kring API:er är hur man skiktar det hela, eller på lekmannatermer, hur man betraktar vad som är själva kärnsystemet. Ett tillvägagångssätt är att ha tunna klienter och mer “feta” API:er. Det innebär att logik och funktion är inkapslat i API:et och den bakomliggande tjänsten. Poängen med feta API:er är att det går snabbt och enkelt att bygga ett nytt gränssnitt, man behöver inte lägga mycket tid på uppenbara funktioner då de istället erbjuds via API:et.

Så låt säga att man vill ha en mobilapp, en webbapp, ett konversationsbaserat gränssnitt via telefon alternativt som en digital hjälpreda, samt att man vill ha en AI oh vad tusan nu framtiden erbjuder. I ett sådant scenario är vissa saker gemensamma och inte direkt unika, de sakerna erbjuds direkt via ett API.

Motpolen är feta klienter/gränssnittssystem/applikationer och tunn backend. I detta fallet ligger funktioner och logik i respektive gränssnitt. På så sätt hamnar innovationen närmre användaren och API:et agerar mer som en korkad datakälla. Här skapas en annan typ av inlåsningseffekter än om man har ett tjockt API. Med feta klienter är det krångligare att komma igång, samt att det är mindre uppenbar skiljelinje mellan gränssnitt och bakomliggande system.

Dogfooding FTW!

Ett sätt att inte låta den som bygger gränssnittet automatiskt få ett defacto-monopol på integration mot backend eller API:er är att skilja på kärnfunktion/kärnsystem och gränssnitt. Det kallas ibland för dogfooding, eller “eat your own dog food”, och i detta sammanhang skulle man göra upp med en leverantör att det gränssnitt som byggs inte får lov att använda några icke-dokumenterade API:er gentemot kärnsystemet. Ska man köra öppna data fullt ut så ska man alltså själv enbart återanvända sin egen öppna data när man skapar något.

På så vis har man inte själv några genvägar. Drabbas externa parter som återanvänder dina data och funktioner via API:et så kommer även dina lösningar lida av liknande problem. Att man själv får lida när API:et strular gör det till en högre prioritet att lösa och de externa parterna kan därmed ha högre förtroende för tjänsten.

Det gäller alltså att sätta sig in i vidareanvändarens situation, tänka tillgänglighet och hur utvecklarnas upplevelse ska vara.

Upplevelsen av data: tillgänglighet och Developer Experience m.m.

Att datakällans innehåll behöver vara tillgänglig för maskiner har du nog fått i dig vid det här laget. Men än den inte tillgänglig eller användbar för människor fattas ändå något. Maskiner styrs fortfarande av utvecklare, och utvecklare är även de människor. Om inte innehåll i datakällor, datasnuttar, katalogen över en organisations datakällor med mera är tillgängligt för den nyfikne utvecklaren när hen är nyfiken kan man som utgivare av öppna data ha missat möjligheten.

Ett sätt att försöka vara tillgänglig både för människor i största allmänhet men specifikt för införsäljning till utvecklare är att följa tipsen från Vägledning för webbutveckling – populärt kallat Webbriklinjer.se – där finns drygt hundra tips på både god praxis men också hur man undviker att råka diskriminera någon användare. Vid upphandling är det smart

Var snäll mot utvecklarna – var förutsägbar

Om någon har byggt vidare på något du lagt ut blir de förstås inte glada om du oväntat stänger ner den tjänsten. Det är viktigt med förutsägbarhet för att bli populär. Ett extremt bra sätt att vara förutsägbar är att jobba med versionshantering, alltså att nya funktioner i ett API inte påverkar de som inte behöver dem. Förändringar som kommer ställa till det behöver kommuniceras med god framförhållning.

Egentligen kommer man långt bara genom att hålla kontakt med de som är tänkbara användare, ödmjukt fråga dem hur de vill ha det och ge dem ett antal veto-kort att använda mot dumma idéer som kommer ställa till det. Det är inte svårare än att lägga manken till för att ha en bra relation med andra utvecklare än de man avlönar.

Men med tanke på att öppna API:er och öppna data funnits i några år finns gott om praxis. Några som dokumenterat detta i form av en recension är non-profitorganisationen Clear Byte – här med recension av Trafikverkets API.

Apropå att vara snäll, genom att köra med öppna kort kring datakällor kommer även de egna anställda ha en större chans att upptäcka information som redan finns inom organisationen. Potentialen att inte återskapa eller köpa data man redan äger finns alltså. Det ger tid för mer innovativt arbete!

Länktips gällande öppna data, länkade data, PSI, API:er m.m.

• Vidareutnyttjande av information – Om PSI och öppna data – drivs av Riksarkivet numer, men togs fram av E-delegationen.
• Socialstyrelsen har statistik, gemensam informationsstruktur och nationella riktlinjer som öppna data
• ÖppnaData.se
• Vägledning för webbutveckling från PTS är smart som upphandlingsunderlag för allt innehåll som en människa är tänkt att ta del av.
• Svensk API-licens – en lite mer juridisk och affärsmässig licens som stödjer både öppenhet och mer kommersiell vinkel
• Krav på öppenhet vid upphandling – dokument under arbete med tips på hur man får med öppna data som fråga vid upphandling
• Open Data Institute (ODI) – grundaren av webben, Tim Berners-Lee, fixade finansiering för ODI att börja lägga grunden för användning av öppna data.
• Public Data – an introduction to opening information resources – Finlands motsvarighet till PTS har tagit fram en intro till öppna data.
• Open Government Datas åtta principer – och sju ytterligare principer om ekonomi, pålitlighet, m.m.
• HIP SDK – ett innovationsramverk som möjliggör tillgång till data i svensk sjukvård.
• PSI-datakollen – hitta organisationer som erbjuder PSI-data i Sverige.
• Open Source Data Integration Tools – öppen ehälsa/mhälsa
• openEHR – öppet initiativ för att ha en gemensam informationsarkitektur när det gäller journalsystem (Electronic Health Records)
• OpenDataMonitor.eu – en överblick för öppna data inom EU.
• OpenDefinition.org – erbjuder en god definition av öppna data.
• Nordic APIs: creating an API style guide
• Guide till öppna data för beslutsfattare
• Göteborg Stad om öppna data och checklistor med kriterier vid öppnande av datakällor