Öppen data med QlikView – struktur och rekommendationer

PSI-direktivet innehåller en uppsättning minimiregler för vidareutnyttjande av handlingar hos offentliga myndigheter och när denna data publiceras via ett API kallas det Öppen data. Syftet med direktivet är att skapa förutsättningar för en europeisk informationsmarknad.

Pandora som försöker stänga databasen hon just öppnat...Vidareutnyttjande innebär att information används för andra ändamål än dem som de ursprungligen framställdes eller samlades in för. Tanken är att öppen data / offentlig information inte bara ska användas av myndigheter utan även användas av företag och allmänheten för att skapa nya tjänster.

Direktivets bestämmelser har införlivats i svensk rätt genom lagen (SFS 2010:566) om vidareutnyttjande av handlingar från den offentliga förvaltningen.

Rent praktiskt

Den som vill publicera öppen data skapar en portal som ska fungera som en samlad ingång över det data som tillgängliggörs för vidareutnyttjande. I portalen för öppen data ska ett urval av datakällor publiceras som sedan kan nyttjas av externa intressenter.

Dataflödet för öppen data delas in i fem steg.

  1. Källsystem – i vårt fall QlikView
  2. Intern aggregator
  3. Portal – API
  4. Utvecklaren / Gränssnitt
  5. Nyttjaren, allmänheten

Källsystemet är datakällan för öppen data, exempelvis det verksamhetssystem som innehåller information som ska göras offentligt.

Den interna aggregatorn gör nödvändig aggregering och i vissa fall även avidentifiering av data för att säkerställa krav på personlig integritet och hemlighetsstämplat data.

Portalen är gränssnittet mot användaren. Användare ansluter mot en Portal-URI och får en översikt av tillgängligt öppen data samt hur hen kan komma åt dem. All tillgänglig öppen data bör ligga lagrat direkt på eller i närhet av portalen på persistent minne såsom disk eller databas. Endast när API som tillåter sökningar och filtrering direkt i datakällor (exempelvis på grund av utrymmes eller prestandaskäl) bör kommunikation utanför portalen initieras av användaranrop.

Utvecklaren bör inte gå direkt mot datakällan för att undvika onödig belastning på bakomliggande operativa datakällor. Direkt åtkomst kan användas i de fall datamängden anses för stor att duplicera till portalen eller när prestanda i datakällan anses vara väl tilltagen för att klara externa anrop.

Portalen kan naturligtvis kompletteras med ett gränssnitt för nyttjaren för jämförelse inom befintliga datakällor. Det betyder att tjänster som Jämför Stockholm kan skapas som en del av portalen och naturligtvis integreras med befintligt CRM (som EPIsever, SiteVision eller Websphere).

Rent tekniskt

Vår rekommendation är att importera öppen data till portalen och samtidigt omvandla dataformatet på importerat data till att följa en gemensam datamodell i samtliga stödda format. Fördelarna med detta är:

  • Ingen belastning på datanoder förutom Portalen.
  • Portalen skapar alla stödda format av samma data vid import. Detta innebär att samma data sparas duplicerat vilket tar mer diskutrymme än att bara spara en uppsättning av öppen data. Detta är en fördel eftersom det kräver mycket mindre prestanda då varje format genereras enligt schema (förslagvis nattetid) istället för vid inkommande anrop.
  • Portalen behöver bara leverera statiska filter för inkommande anrop.

Vid utveckling av API för publik data är det centralt med en enkel datamodell. Det är också viktigt med val av tekniska lösningar såsom protokoll, filformat och genomtänkt säkerhet.

Riktlinjer

Syftet är framförallt att redan från början eliminera användarens problem för att på så sätt stimulera utnyttjandet av den publicerade datan. Detta kan sammanfattas i fem grundläggande riktlinjer

  • Informationen ska vara lätt att använda även utan dokumentation. Användaren ska väldigt enkelt kunna hämta data för att därefter kunna läsa hur svaret ska tolkas och hanteras.
  • Det ska vara svårt att göra fel. När användaren gör fel ska tydliga felmeddelanden förklara vad som behöver ändras.
  • Det ska vara lätt att bygga ut gränssnittet utan att förstöra befintliga applikationer. Regeln är att aldrig ta bort eller flytta data från ett gränssnittanrop, det är däremot tillåtet att addera data i efterhand. Ett gränssnitt skall anses leva för evigt.
  • Informationen ska vara användbart för slutanvändaren, ha ett enkelt, minimalistiska gränssnitt och levererar den data som utvecklaren förväntar sig.
  • Säkerställ att alla API:er dokumenteras utförligt, gärna innan själva dataexporten implementeras

Frågor på det? Du får gärna ringa mig (0722-047418) eller Daniel (0722-061049).

Bild från Wikipedia – Creative Commons

Share on LinkedInTweet about this on TwitterShare on Google+Share on FacebookEmail this to someone

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *