comment 0

Reflektioner från Vinnova Forum Öppna Data

Vinnova Forum Öppna Data
Snygg bild på Öppen Data från Stockholm.se – den tar vi!

Först och främst – det här var en otroligt givande fredag och jag gillar verkligen formatet som Erik Borälv med hjälp av Björn Hagström har ordnat. Great stuff grabbar!

Istället för att gå igenom specifikt varje session tänkte jag gruppera mina reflektioner i personliga highlights inklusive mina egna tankar och idéer på temat;

Aggregering. Syndikering. Federation.

Mycket glädjande var att nästan alla talare berörde dessa 3 ord i någon form – Irina från OKFN när hon talade om CKAN och ”Harvesting”, Erik Borälv när han pratade om hur www.oppnadata.se ska byggas, Kristofer från SVT Pejl när han beskrev deras verksamhet, Magnus Kolsjö när han talade om SKLs riktlinjer för öppna data etc.

Passus : Nämn dessa 3 ord i följd och direkt har man tappat 95% av din åhörarskara. De 5% som fortsätter att lyssna behöver man förmodligen inte förklara något för eftersom de sannolikt direkt förstår poängen alternativt är dina föräldrar och mest är på plats för att stötta.

Vad är då poängen? Jo. Orden representerar i det här fallet en viss mognadsgrad av öppna data. Det är inte förrän vi löser aggregering, syndikering och federation som vi på riktigt kommer kunna innovera på öppna data och öppna tjänster. Det är därför jag glädjer mig över att detta arbetas med på många fronter.

Aggregering

Aggregering betyder ”att sammanslå” eller ”summera” – dvs, ett av de viktiga målen med öppna data är att man som användare lätt ska kunna kombinera olika data från olika källor och helst direkt kunna få ny data och information – eller i bästa fall ny kunskap! Ju bättre struktur (dvs datakvalité, schema och metadata) – ju enklare att aggregera – ju fler kan innovera. Typ.

Vad händer om vi inte kommer överens om struktur?

Låt säga att vi ska göra en studie på hur vi arbetat under 10 år – vilket är ganska vanligt om man vill se trender och prognoser. Det innebär att vi

  1. Letar fram 10 dataset – ett för varje år. I bästa fall existerar dessa 10 dataset – annars måste vi sammanställa dem ifrån olika källor.
  2. Om kolumnerna i dataseten är olika måste man först då alltså försöka standardisera och normalisera kolumnerna – de ska ju heta samma och vara lika många.
  3. Därefter måste vi spana på om datatyperna (att de betyder samma sak) i respektive kolumn överensstämmer – annars måste vi ännu en gång normalisera så att datan följer samma format.
  4. Därefter måste vi se till att det inte finns gap i datan. Där kan vi i undantagsfall fylla gapen med teoretiskt trendande värden men helst ska vi acceptera att datat är ofullständigt.

Detta brukar man lite slarvigt kalla för ”datatvätt”. Sedan kan vi påbörja vår analys – dvs göra data till information, information till kunskap och kunskap till visdom.

För att resultatet av vårt arbete ska kunna vidareförädlas och användas av fler bör vi dessutom försöka ersätta masterdatat – det otvättade datat som vi började med – med vår tvättade variant. Annars måste nästa person göra samma sak innan analysen kan påbörjas.

Risken är dock överhängande att inget av ovanstående görs om hindret för att påbörja analysen är för hög. Det innebär att analysen inte leder till ny kunskap. Förmågan att ta beslut på riktig information uteblir.

I en löjlig liknelse kan det jämföras med att köra bil i slask och regn utan lyktor, spolarvätska och vindrutetorkare. Hur stor är chansen att du kommer i tid? Eller kommer före de som har bättre förutsättningar? Eller kommer fram i huvudtaget?

Syndikering och Federation

Syndikering betyder i kontexten webb och data att göra sitt innehåll tillgängligt i strukturerad form så att det kan återanvändas. Själva essensen av öppna data bygger således på syndikering. Just här menas dock syndikering av kataloginformation. Detta är mycket viktigt för att kunna hantera den explosion av datakällor, hubbar och kataloger som kommer finnas tillgänglig framgent.

Federation betyder här ”Federerad arkitektur” vilket är en designprincip för hur man decentraliserat kan vara överens om enligt vilka mönster och vilken struktur en viss process ska fungera – en central princip för att få interoperabilitet att ”lira”. Sorry för den beskrivningen. Poängen med federation kommer förhoppningsvis fram nedan;

Vad händer om vi inte kommer överens om hur kataloginformation ska syndikeras i en federation?

Brutna länkar, versionskonflikter, irrelevans, missförstånd, olika standarder etc etc. Dvs sånt som gör att kvalitén och därmed användandet och därmed nyttan och därmed innovationen går neråt.

Föreställ er en situation där vi kanske har 100 miljoner dataset (det har vi snart) i webben med tillhörande metadata. Dessa 100 miljoner dataset finns tillgängliga i en uppsjö av sökmotorer, index och kataloger – säg 10000 bara för att ta en siffra. Så fort någonting ändras kring datasettens metadata – vilket är ett mycket vanligt användarfall – måste då den informationen uppdateras manuellt på alla ställen. 10000 manuella uppdateringar är inte så roligt. Om vi däremot tillämpar federerad syndikering görs detta automatiskt, eller semi-automatiskt – och vi får då samma tillförlitbara effekter som vi har för dokument i webben idag.

Vi är inte helt rökta utan syndikering och federation – Harvesting, Scraping, spindling etc etc av index, kataloger och sökmotorer kommer överbrygga bristerna som uppstår i utesluten syndikering och federation – men det är fortfarande bara ”second best”.

PS! Bra syndikeringsprotokoll kommer även potentiellt kunna överbrygga problematik kring förändringar av URL:er och URI:er i scenarion där man ingår i distribution (mashups, DaaS, Baas etc.) och vi bara är lite kluriga.

 

Nytt ord : Slurpa

Verb : Att slurpa.

Att slurpa data är att extrahera data. Kallas också för ”harvesting” –  eller ”scraping”. Jag gillar dock slurpa bättre. Kan tänka mig att participa till det åt att man kan vara en slurpare. Eller att man kan ha en slurpig approach sådär.

Tack Magnus Kolsjö.

 

Metadata

En av de stora klurigheterna kring öppna data och öppna tjänster (eller interoperabilitet) är att komma överens om HUR metadatat ska struktureras – och egentligen är det klurigare än så; Vi måste komma överens ett HUR vi ska skapa ett bra stöd för att vi ska kunna ha en hög flexibilitet kring HUR metadatat ska struktureras.

Vi hade under forumet egentligen ingen specifik diskussion kring det här. Det ligger lite outtalat där vid sidan om diskussionerna kring beskrivningsramverk och vokabulär.

Jag kan själv inte spontant bidra till hur vi ska lösa det på bra standardiserade sätt. Jag lyssnar och låter någon smartare ta tag i det 😉

 

Riksdagens informationssystem

Riksdagens webbar, intranät, appar etc är byggd på ”öppna data”. Jag sätter citationstecken eftersom definitionen snarare lutar åt öppna api:er eller öppna tjänster. Men samtidigt finns det inte någon bra allmän definition så… aja.. nog om det.

Jag är otroligt imponerad över detta insiktsfulla arbete. När jag själv gör principiella ”roadmaps” över vilken riktning man ska åt som verksamhet så brukar jag lägga API:fiering minst 2-3 år fram. De har mycket tidigt insett en arkitekturprincip som kommer bli allmän – att bygga ett eget servicelager i webben av API:er – och låta alla deras tillämpningar använda detta + kunna leverera öppen data som bonus!

Jag kommer inte kunna göra dem rättvisa i en kort reflektion men jag kan säga såhär;
Det är inte första gången jag sett den arkitekturprincipen i produktion. Däremot har jag bara sett den i organisationer som ligger på Forbes lista över världens mest framgångsrika företag. 

Följ riksdagens utveckling här : http://utveckling.riksdagen.se/

Mer om riksdagen i senare inlägg.

 

Satinproject.eu

Måste bara få nämna satinproject.eu. Jag kan inte sluta understryka hur sjukt viktigt initiativ av den här typen är (dvs no code development initiativ). Ållrajt, såhär ligger det till;

Ju bättre vi kan beskriva vårt data och våra API:er – ju mindre behöver vi av varan ”datatvätt” och transformering. Det gör att vi kan sänka tröskeln för vilka som kan innovera på öppna data.

Satinproject.eu är precis en sån – en tröskelsänkare – och en bro mellan verksamheten, användaren och tekniken. Dvs den bron som avgör om ett projekt ska lyckas eller inte.

In å spana : http://www.satinproject.eu/

 

Målgrupper och typanvändare

Gillar att flera pratar om målgrupper och typanvändare. Dvs att vi har klara tydliga användarfall för vår data och våra tjänster. Det gör att kvalitén kommer bli bättre och därmed effekten!

Termen developer experience kommer att öka i relevans – med rätta – när vi nu gör webben mer och mer programmerbar. Läs : http://developerexperience.org/

 

”Frälser de redan frälsta”

En efterföljande twitterdiskussion poängterade en viktig sak;

Vi talade väldigt lite om vår gemensamma uppgift i forumet – att agera ambassadör och evangelist på temat. Vi har alla viktiga ansvar – utöver att vara kunskapspersoner – vi måste inspirera, engagera och entusiasmera alla, högt och lågt, att förstå storheten i öppna data, öppna tjänster och interoperabilitet. Det kanske förtjänar en egen session vid nästa forumträff?

 

Distribution

Mitt egna lilla pet-project, att holistiskt se webben som en stor supply-chain-mashup i iolika beroenden med varandra, tuffar på. I och med att vi börjar få ordning på aggregering, syndikering och federation samt inom snar framtid (hoppas jag) reder ut licensformer och servicevillkor så kommer SLA:er kunna börja upprättas tydligare.

Jag vidhåller att molntjänster + open + big data = true. Men för att landa i den visionen fullt ut så måste vi få ordning på just hur vi ska lösa distribution, licenser och villkor.

 

Avslutningsvis

1. Jag missade massor med bra viktiga saker som sades. Fokuset här hamnade liksom kring syndikering. Jag lyckades dessutom skriva ett helt inlägg utan att nämna att jag tror att DCAT kan göra jobbet.  Eller ja. Nästan.

2. Här hittar ni hela sändningen via bambuser.

3. Skriv gärna en kommentar, twittra eller mailas mä me eller varför inte ta en diskussion ”i köttvärlden” om vi ses!

4. Äh. Jag måste byta typsnitt på den här bloggen!

Kommentera