Hur tar vi oss mot ett förbättrat datadrivet samarbete i städer och kommuner som möjliggör en mer hållbar framtid?

I den här artikeln identifierar vi fyra förmågor som tekniska plattformar behöver för nya datadrivna samarbeten. Därefter visar vi hur varje förmåga omsätts och avslutar med en färdplan mot ett läge där organisationen enkelt kan skapa och underhålla datadrivna processer.

Men låt oss börja med två fiktiva exempel. Oönskat läge i Strulköping och Önskat läge i Drömstad. Du kan klicka på videofönstren nedan för att lyssna två exemplen eller klicka på textversionerna under för att expandera dem. Du är välkommen att använda allt material i den här artikeln i egna workshops.

Vikten av datadrivna samarbeten och artikelns metod

Ju bättre vi kan väva samman behov och lösningar, desto mer hållbara städer kan vi bygga. Ju mer data, kunskap och information vi kan hantera, desto bättre lösningar kan vi skapa.

Olika informationstekniska lösningar har potential att hjälpa oss nå dit, men i dag är det svårt för en kommun att veta vad man faktiskt ska satsa på ur ett tekniskt perspektiv. Det finns en närmast oändlig uppsjö av lösningar och system, begrepp, standarder och processer som påstås kunna bidra till att lösa problemen.

Ska vi börja med att städa i våra databaser? Ska vi investera i den nya teknikplattformen som lovar guld och gröna skogar – eller är det något helt annat vi behöver? Hur vet vi ens att vi rör oss i rätt riktning?

I den här artikeln sållar vi bland alternativen och ringar in vilka delar våra tekniska plattformar behöver för att skapa goda förutsättningar för datadrivet samarbete.
För att göra detta – och validera vårt resonemang – utgår vi från ett användarinteraktionsperspektiv snarare än ett strikt tekniskt. Vi tar avstamp i den process för att skapa nya datadrivna samarbeten som används i projektet Digital Vision Kista (läs mer här).

Fokus ligger inte på metoden i sig, utan på vilka förmågor deltagarna i processen behöver tillgång till.

En process för att skapa datadrivna samarbeten

Vi kommer här att kort gå igenom hur en process för att hitta nya datadrivna samarbeten kan se ut. I processen har vi tillsammans med behovsägare utforskat hur olika samarbeten bör se ut utifrån frågeställningarna.

• Vilka behöver samarbete?
• Vad behöver de samarbeta kring?
• Vad finns det för data som stödjer samarbetet?
• Vilka objekt och egenskaper på dessa objekt skulle vi behöva i en applikation för skapa en gemensam förståelse för de som ska samarbeta?
• Hur interagerar man kring dessa?

I figur 1 ett exempel på hur dessa frågor kan besparas i ett fiktivt scenario.

Om du vill ladda ner exemplet ovan som pdf eller word finns de här:

Metoden ger olika aktörer möjlighet att bygga nya typer av samarbeten genom att identifiera behoven. Även om man inte använder just denna metod så kommer processen med att skapa nya typer av datadrivna samarbeten att likna denna process och ha liknande behov.

Fyra förmågor

För att det ska fungera smidigt att skapa nya samarbeten så måste stadens tekniska infrastruktur stödja processen. Vi har här kan vi identifierat 4 sådana beståndsdelar där infrastrukturen bör stödja processen. Med exemplet ovan i åtanke kan vi i detalj börja härleda ifall de system vi använder eller tänker investera i faktiskt stödjer dessa. Som aktör i en kommun eller stad behöver vi verktyg för följande fyra möjligheter:

1. Att hitta och förstå data som skulle kunna stödjer processen. Dvs att ha verktyg som låter oss svara på fråga 3 i processen i figuren ovan.
2. Att komma åt och kunna utforska eller integrera datakällor i våra lösningar. Dvs att plattformarna stöder utforskande av data och att man länkar in de i andra applikationer utan att behöva kopiera datat.
3. Att kollektivt, kunna skapa och dela kunskap baserat på datat. Tex att kunna lagra nya dataset som skapats eller länkningar mellan datakällor så att andra kan nyttja dessa.
4. Att kunna interagera, samspela och skapa dialoger och berättelser kring datat. Tex kunna se vilken data som kollegor har använt nyligen.

Vi kommer nedan att gå i genom dessa fyra förmågor som stadens tekniska system måste stödja för att vi ska underlätta datadrivna samarbeten i staden. Vi kommer sedan att titta på vad dessa innebär i detalj och hur de kan stödja alla former av samarbeten men först några ord om jämställd åtkomst till data.

🔎Förmåga 1: Att hitta och förstå data

Alla relevanta aktörer – både inom kommunen och externt – behöver veta vilken data som finns tillgänglig och vilken kvalitet den håller, så att de kan avgöra om den är användbar för att lösa aktuella problem eller besvara de frågor som undersöks.

En grundförutsättning för datadrivet samarbete är därför att vi kan beskriva och söka efter data som finns (och som skulle kunna finnas) om olika objekt i staden. Detta knyter an till fråga 3 i processen ovan: ”Vilken data stödjer samarbetet?” Här börjar detektivarbetet: att systematiskt hitta den data som tar oss vidare.

Några utmaningar från ett verkligt fall

Stockholms stad har i dag en plattform för att publicera information om tillgängliga datamängder: https://dataportalen.stockholm.se. Webbplatsen har både en intern och en extern del. Den interna delen innehåller en mer omfattande lista över datamängder som olika delar av staden hanterar. I dagsläget kan man dock inte utgå från att alla datamängder faktiskt finns i systemet.

Vissa förvaltningar, avdelningar och bolag är bättre på att använda portalen än andra. Ofta finns dessutom flera kopior av samma datamängd hos olika aktörer, och dessa kan ha modifierats. När någon gör en utredning och skapar en ny datamängd läggs den inte alltid upp i portalen. Historik hanteras också bristfälligt: äldre versioner tas ofta bort när nya publiceras. Biotopdatabasen 2009 finns till exempel inte kvar i den externa portalen efter att versionen för 2019 publicerades.

För varje datamängd finns i dag ett antal uppgifter (t.ex. senast uppdaterad, ägare osv.). Men ofta saknas uppgifter om omfattning/kvantitet och exempeldata, vilket gör att det krävs ytterligare efterforskningar för att avgöra om datan är användbar. I fallet med Biotopdatabasen – som visar materialindelningar i staden och bygger på ortofoton – saknas dessutom kopplingar mellan årgångar, och metoden kan ha ändrats mellan versioner.

I dag saknas också externa datakällor i portalen, såsom Lantmäteriet, SCB och Trafiklab. En dataportal som även katalogiserar sådana datamängder skulle göra det betydligt enklare att snabbt etablera vilken data som finns för att stödja ett visst samarbete. Staden behöver med andra ord ta ett tydligare användarperspektiv gentemot de egna medarbetarna och samtidigt uppmuntra delning av värdefulla datatillgångar från tidigare projekt – såväl externa som interna. Urvalet av datamängder som beskrivs bör dessutom speglas mot stadens mål, till exempel klimatmålen.

För att komma vidare behöver man både utveckla plattformen och etablera en praktik kring hur den används. En praktik formas av våra föreställningar, de tekniska plattformarna vi har tillgång till och vår förmåga att använda dem.

En snabb sökning i Wayback Machine visar att sidan funnits åtminstone sedan 2014. Hur ofta sidan arkiveras beror både på trafiken och ändringsfrekvensen. Mycket tyder på att användningen tagit fart först 2024–2025. Det tar med andra ord tid att etablera ett verktyg som dataportalen: det handlar med andra ord inte bara om att bygga själva plattformen utan också om att skapa en gemensam förståelse, utbilda användare och få organisationer, avdelningar och individer att ändra arbetssätt.

I dag är verkligheten ofta att även om kommunen kommit en bit med att synliggöra data genom olika plattformar så varierar mognaden mellan datamängder. En rimlig strategi är att identifiera de viktigaste tillämpningsområdena för datadrivet samarbete och börja där, med tillhörande data – och sedan arbeta vidare successivt.

Kort sammanfattning

Målet när det gäller förmågan: att hitta och förstå data i en stad eller kommun är att nå en hög grad av självständighet: aktörer i kommunen ska veta vilken data de har tillgång till utan att behöva passera ”grindvakter”, dvs. fråga en specifik person. För att nå dit krävs en uthålligt arbete med att skapa och förankra interna plattformar för sökning och beskrivning av data.

🔒Förmåga 2 - Åtkomst och delning av data

Det finns flera dimensioner kring åtkomst och delning av data som vi kommer att beskriva nedan men som vårat fiktiva exempel kring Strulköping så kan det ibland finns så många hinder på vägen till att få tag på ett visst dataset att datadrivet samarbete i praktiken blir omöjligt.

Jämlik tillgång till data

De som ska använda en datamängd måste ha teknisk åtkomst till den för att kunna utforska den och koppla den till aktuella visualiseringar eller beräkningar. I många projekt – som i fallet Strulköping – tar detta orimligt lång tid. Vi behöver därför nå en självständig nivå även här där man, utan ”grindvakter”, kan komma åt den data man ska ha tillgång till. Det kräver en välfungerande distributionsmekanism för data.

Om vi gör det så enkelt att komma åt data som i Drömstadsexempelt blir det då inte stor risk att data hamnar i fel händer?

När vi i den här artikeln skriver om jämlik tillgång till data menar vi att alla – på lika villkor – ska ha möjlighet att ta del av data, med det självklara förbehållet att viss data är skyddsvärd och därför bara får hanteras av behöriga personer. Med andra ord: det ska inte finnas andra hinder än sakliga säkerhets- och integritetskrav.

Jämlik tillgång till korrekt information är en grundförutsättning i ett demokratiskt samhälle. Utan den kan varken beslutsfattare eller medborgare fatta välgrundade beslut. Detsamma gäller relationer mellan aktörer på en marknad och vid planering och myndighetsutövning i en kommun.

Samtidigt kräver vägen från data till information, kunskap och insikt ofta betydande arbete. Alla kommer därför inte alltid ha samma förutsättningar att tolka och förstå data. Vi kan dock sträva efter så jämlika förutsättningar som möjligt och skapa mekanismer för att bygga vidare på varandras arbete (t.ex. genom digitala tvillingar). Ju bättre verktyg vi har för att komma åt och förstå data, desto mer demokratiskt och transparent kan samhället bli.

Det betyder inte att alla ska ha tillgång till all data. Känsliga uppgifter måste begränsas till rätt roller och ändamål. Det vi vill undvika är godtyckliga begränsningar. För ett effektivt, datadrivet samarbete i kommuner krävs att de som behöver tillgång får det – och att de som inte ska ha tillgång inte får det. Det förutsätter:

• Tydlig klassificering av data (öppen, intern, sekretessbelagd m.m.),
• Roll- och behörighetsstyrning både inom och utanför organisationen,
• Spårbar, kontrollerad datahantering som inte bygger på okontrollerad filkopiering mellan organisationer, avdelningar och individer.

Historisk dataåtkomst

Ett stort problem som identifierats i Digital Vision Kista är åtkomsten till historisk data, särskilt inom GIS. Ofta skrivs lager över i takt med uppdateringar. En gång per år skickas en PDF till stadsarkivet, men den innehåller långt ifrån all tillgänglig information. Vissa personer kan förstås nå historiken, men den är inte allmänt tillgänglig, utom för några få datamängder.

I många samarbeten måste vi kombinera datamängder för helhetsförståelse. Sensor­data från en IoT-plattform kan till exempel kopplas till GIS-data. Då kan vi förklara varför en luftkvalitetssensor visar ovanligt höga värden (t.ex. vägarbete precis intill vid mättillfället). Utan historiska data missar vi den möjligheten. Problemet finns även utanför kommuner: exempelvis är Boverkets historik för energideklarationer svår att få ut på byggnadsnivå.

Datalagring och kopior

Ett återkommande problem i Stockholm stad är avsaknaden av ett gemensamt åtkomst- eller distributionssystem för datamängder. Resultatet blir att man kopierar data mellan avdelningar. Exempel: Avdelning A kopierar parkdata från avdelning B och tar fram ett nytt lager med avstånd till närmaste park. Senare vill B återanvända A:s lager – men under tiden har B uppdaterat grundlagret (nya parker), och då matchar inte A:s härledda lager längre. I bästa fall synkas något årligen, men ofta lever gamla versioner kvar i decennier då ingen hittar tiden eller budgeten för att uppdatera datasetten.

En bättre metod är att B ger A åtkomst till sitt lager och att A länkar i stället för att kopiera.

Vid ett test i Eskilstuna fann man exempelvis 22 kopior av samma ritning utspridd i organisationen. Kopior kan ibland vara motiverade (test, scenarier, redundans), men vi behöver system som länkar, spårar och meddelar när:

• det finns en ny version av dokumentet/datamängden, eller
• om ett grundlager som en härledd produkt bygger på har ändrats.

(Mer om lösningar för länkad data senare.)

Partiell åtkomst

Ibland behöver vi bara ett värde ur en större datamängd, t.ex. ytan för stadsdelen Kista. I dag kräver Stockholm stads lösning ofta att man:

1. söker på dataportalen,
2. laddar ner en ZIP,
3. packar upp till SHP (”shapefil”),
4. öppnar i t.ex. QGIS,
5. navigerar till rätt objekt och läser attributet.

Alla datamängder är inte lika krångliga, men slutsatsen är tydlig: vi behöver enkel, partiell åtkomst (fråga mot fält/objekt/utdrag) utan full nedladdning.

Prenumeration på data

Vid automatiserad åtkomst använder man nästan alltid request–response (begär–svar), t.ex. via ett REST-API. För att se om något ändrats måste klienten fråga om och om igen. Ett alternativ är publish–subscribe (publicera–prenumerera): klienten prenumererar på ett dataset eller ett delmängdsfilter och får pushade uppdateringar när data ändras. Den modellen gör det enklare att förverkliga obrutna dataflöden: alla prenumeranter meddelas direkt, och härledda nyckeltal kan uppdateras i kedja.

Saknad metadata

I ett tidigare projekt om energiprestanda i Norra Djurgårdsstaden visade det sig att elmätarvärdena inte räckte. En butik hade flyttat in i ett hyreshus men mättes inte separat, vilket förvanskade fastighetselens värden. En schablon fick användas i efterhand. Denna kontext (var mätaren sitter, vad som ingår/inte ingår, ändringar över tid) fanns inte dokumenterad i datasystemet – informationen låg hos en energikonsult på en post-it.

Utan tydlig metadata blir data i t.ex. en IoT-plattform lätt oanvändbar. Vi behöver alltså inte bara data, utan även:

• beskrivande metadata (position, syfte, metod, täckning, enheter),
• förändringslogg/versioner, och
• ett samlat sätt att lagra eller länka sådan dokumentation så att den inte sprids i parallella system.

Kort sammanfattning

• Minska friktionen: Bygg distribution och länkad åtkomst i stället för kopior.
• Bevara historik: Sluta skriva över – versionera och gör historik sökbar.
• Stöd partiella frågor: Gör det lätt att hämta bara det man behöver.
• Gå mot pub/sub: Push-uppdateringar i stället för ständig polling.
• Säkra metadata: Kontext + versioner + ändringslogg i samma ekosystem eller länkat på ett spårbart sätt.

♻️Förmåga 3 - Kollektivt kunskapsskapande

Länka och återanvända data

Det måste finnas tekniska och semantiska lösningar för att länka samman olika datakällor – så att vi kan bygga applikationer som visar helheten. När vi väl har satt samman data ska det dessutom vara enkelt att spara och dela resultatet, så att andra kan återanvända det.

Nästan alla beslut i en stad kräver att man kopplar samman data. Vid ett bygglovsärende arbetar handläggaren med:

• Ansökan (vad den sökande vill göra),
• Regelverk (vilka regler gäller), och
• Lokala förutsättningar (plats, planer, risker m.m.).

Handläggarens uppgift är att koppla information mellan dessa källor och dokumentera bedömningen. Många av dessa kopplingar skulle vara värdefulla för nästa ärende – men i dag lagras sambanden sällan på ett sätt som kan återanvändas.

Kunskapsgrafer (knowledge graphs)

Ett sätt att modellera kopplingar mellan objekt är kunskapsgrafer. Exempel:

• En elmätare är knuten till en våning i en byggnad som hör till ett garage som är kopplat till en väg.
  Då kan man förklara varför elmätarvärden och väg­användning hänger ihop.

Ju mer vi länkar data, desto bättre blir vi på att se sammanhang och ge rätt information till rätt person. En förvaltare för en byggnad kan till exempel få omvärldsinformation som påverkar byggnaden.

Hinder i dag

I Digital Vision Kista såg vi att det är svårt att kombinera data från olika plattformar, t.ex. IoT och GIS. Vill vi ta fram ett nyckeltal för solcellsproduktion per stadsdel måste vi:

1. hitta alla solcellsanläggningar i IoT-plattformen,
2. koppla varje anläggning till rätt stadsdel i GIS,
3. summera produktionen per stadsdel, och
4. normalisera per yta.

Bara att komma åt stadsdelsytor kan i dag kräva flera manuella steg. Ett första steg mot länkning är att entydigt peka på data och lagra referensen för senare bruk.

Mot en gemensam adressrymd

I solcellsexemplet kan varje anläggning märkas med stadsdel. Ännu bättre är att märka den med en adress (identifierare) som enligt en gemensam konvention pekar på objektet Kista i GIS-plattformen. Då blir referensen otvetydig (”Kista” syftar inte på projekt eller något annat med samma namn).

Sådana adresskonventioner behöver tas fram per datamängd och dokumenteras i t.ex. kommunens datakatalog. Exempel på läsbar URI:

data.stockholm.se/gis/stadsdelar/kista/yta/

Åtkomst och uppdateringar (pub/sub)

Nästa steg är att kunna läsa data via adresser – även partiellt (endast det fält man behöver) – och att kunna prenumerera på ändringar. Med en publish–subscribe-modell får ett beräknat nyckeltal automatiskt nya värden när underliggande data uppdateras. För att detta ska fungera måste nya versioner av datamängder länkas på objekt- och attributnivå, så att system vet att det rör sig om senare värden av samma sak.

Databroker / proxy som möjliggörare

Sådana integrationer kan genomföras med en proxy/databroker (dataförmedlare):

1. Klienten prenumererar på …/gis/stadsdelar/kista/yta.
2. Dataförmedlaren hämtar källfilen (t.ex. ZIP från dataportalen), packar upp, plockar ut just Kistas yta och levererar värdet.
3. Förmedlaren övervakar källans uppdateringsdatum.
4. Vid ändring hämtar och extraherar den på nytt och pushar nya värdet till prenumeranterna.

Om flera prenumererar på samma värde återanvänds cache i förmedlaren. Saknas historik i källan kan förmedlaren mellanlagra versioner och tillåta prenumeration på tidpunktsbundna värden (anges i URL:en enligt överenskommen konvention).

Datarymd och digital tvilling

På detta sätt kan vi bygga en datarymd där data ligger kvar i sina respektive plattformar, men där vi ändå kan koppla samman källor och skapa realtidsuppdaterade nyckeltal. Bonus: mellanlagring ger redundans om en källa går ner.

När vi nått hit arbetar vi på digital-tvilling-nivå: fokus ligger på objekt, och vi samlar så mycket relevant data som möjligt kring dem – oavsett system. Med en fungerande datarymd och kunskapsgrafer blir implementering och interaktion i den digitala tvillingen betydligt enklare.

Kort sammanfattning

• Länka data tekniskt och semantiskt; gör komposita resultat delbara.
• Entydiga adresser/URI:er för objekt och attribut; dokumentera konventioner.
• Stöd partiell åtkomst och pub/sub för automatiska uppdateringar.
• Använd databroker för extraktion, cache, historik och notifieringar.
• Bygg en datarymd som möjliggör kunskapsgrafer och digitala tvillingar.

🗪 Förmåga 4 - Interaktion kring datat

För att aktörer ska förstå hur deras verksamhet påverkar andra – och påverkas av andra krävs insyn i vad andra gör och hur de interagerar med stadens data.

I dag finns ofta funktioner som loggar åtkomst och ändringar (t.ex. i polisregister) för att motverka missbruk. Om vi dessutom skapar en delad uppfattning om varandras ”virtuella positioner” – vilka objekt vi tittar på, analyserar eller ändrar – får vi något som liknar ett metaverse, eller, kopplat till en 3D-modell av staden, ett ”cityverse”.

Detta behöver inte vara mer avancerat än hur Google Docs visar andra användares markörer i ett dokument, eller hur Mural/Miro låter oss se post-it-lappar skapas i realtid.

I en smart stad mäter vi inte bara fysisk trafik på en gata, utan även digital aktivitet kring samma plats i en digital tvilling. Ser vi att en kollega ägnar mycket tid åt ett visst område – eller läser deras händelselogg – kan vi ana att ett projekt berör platsen och samordna insatser i tid.

För att detta ska fungera behövs verktyg för att:

• Peka på objekt (”se här”),
• Kommentera och diskutera,
• Rösta/prioritera åtgärder,
• Skapa berättelser/case (text, bild, karta, tidslinje),
• Arbeta synkront på en delad skärm i mötesrum och asynkront i systemet.

All denna interaktion – chattar, kommentarer, markörer, röstningar och berättelser – blir ett ytterligare lager av data i stadens plattformar. Rätt hanterat skapar det spårbarhet, lärande och bättre samordning över tid.

🛣️ En teknisk färdplan mot datadrivna samarbeten i kommuner och städer

En färdplan skulle kunna innehålla följande steg.

1. Skapa en datakatalog där olika aktörer kan börja lägga upp information om tillgänglig data som kan komma till användning i olika samarbeten inom en kommun.
2. Skapa konventioner för hur vi refererar till data i staden eller kommunens olika dataplattformar så som den såg ut vid en viss tidpunkt eller vid senaste uppdateringen.
3. Skapa en dataförmedlare (broker) som kan ge de som ska ha tillgång till datat tillgång till den enligt en preminurations modell.
4. Skapa en plattform som via dataförmedlaren kan lagra kopplingar mellan data för att bygga en kunskapsgraf över staden.
5. Skapa en plattform där vi via dataförmedlaren kan interagera, chattar eller genom att dela våran position i datat i realtid eller historiskt.

🏛️En dataarkitektur för digitala tvillingar

I ett framtida system så kommer vi att behöva få existerande och framtida lösningar inom kommunen och staden i en rad olika organisationer att samverka. En viktigt del i denna lösning är data-brokern eller datamäklaren. Denna ger oss ett enhetligt sätt att komma åt all data i den aktuella datarymden. En konvention som vi fastställer ger oss möjligheten att formulera adresser för datasett i olika system så väl som enskilda datapunkter vid olika tidpunkter i tiden och i olika möjliga framtida scenarion om sådan data skulle finnas. På så sätt skapar vi en gemensam adressrymd som kan spänna över ett antal system via en broker eller över över flera olika brokers och deras underliggande system.

Tänkbara delsystem i en kommuns plattform skulle kunna vara.  

• Datakatalogen – Ett ställe där de olika datasetten som man behöver inom en kommun eller stad dokumenteras.
• Ett eller flera GIS eller BIM system för de olika bolagen och förvaltningarna där spatel data lagras.
• En IoT-plattform för sensorer och strömmande data i staden.
• En koppling till ett eller flera ekonomisystem.
• Kunskapsgrafen som gör det möjligt att lagra kopplingar som gjorts endera automatiskt eller manuellt. Tex vilka solcells anläggningar som finns i Kista.
• En citiverse-server som kan hålla koll på i vilken applikation och vart i det digitala landskapet som olika personer rör sig eller har besökt samt olika chattmedelanden som de lämnat efter sig på de olika objekten och egenskaperna.

Alla dessa är nåbara i en gemensam adressrymd och via en eller flera brokers.

Exempel 1: Säg att Anna utvecklar ett nytt program inom staden och är intresserad av storleken på Kista. Hon går via vår datamäklare in och premierar på en söksträng på adressen broker.stockholm.se/datakatalog/search?query=storlek på Kista

Hon får direkt svar att den data hon är intresserad av finns på:

broker.stockholm.se/GIS/stadsdelar/Kista/Yta

samt

broker.stockholm.se/GIS/stadsdelar/Kista/Yta/2025

broker.stockholm.se/GIS/stadsdelar/Kista/Yta/2020

broker.stockholm.se/GIS/stadsdelar/Kista/Yta/2015

Om Anna skulle stanna i nuvarande vy skulle hon få upp ytterligare en träff dagen då ett nytt datasett publicerades med den aktuella datapunkten utan att behöva göra någonting eftersom hon har en aktiv prenumeration.

Anna klickar på länken för 2020 och får upp att Kista var XXXX kvm stort. Klickar hon på 2025 får hon i stället upp XXXX kvm om hon klickar på:

broker.stockholm.se/GIS/stadsdelar/Kista/Yta

Får hon samma värde som när hon klickade på 2025 men den dagen som det publiceras ett nytt värde så kommer hon automatiskt att få ett nytt tal skickat till sig så länge hon har en aktiv prenumeration.

Anna väljer nu att använda stadens kunskapsgrap. Hon går in på:

broker.stockholm.se/knowlegegraph/search?query=GIS/stadsdelar/Kista/Yta

Hon får nu en lista på all annan data som har en relation till Kistas yta så som närliggande området som tex Tenstas yta men även saker kopplade till Kista så som temperaturen i Kista.

Hon kan även se att det finns data i Citiverse plattformen om vilka som besökt Kista digitalt av hennes kollegor samt olika chatmedelanden som man lagt in på Kista. Hon kan även själv lägga in nya meddelanden och kopplingar. 

Anna kan nu använda all den tillgängliga datan och kopplingarna mellan olika datasett i olika delar av stadens system och bygga en applikation för att stödja ett nytt samarbete i staden. Som ska användas av Rinkeby‑Kista stadsdelsförvaltning. Applikation kommer även att kunna lägga till data som tex chatmedelanden kring olika objekt. Då detta görs så kommer dessa meddelanden även att kunna synas i andra applikationer kring andra samarbeten.  

Att allt är tillgängligt på samma sätt underlättar utvecklingsarbetet. Det blir både läggare att se vilka resurser som skulle kunna användas i den aktuella applikationen men även att integrera stadens data i denna.

Exempel 2:

Slutsats

I den här artikeln har vi använd en rad fiktiva exempel för att bättre förstå vad det är för tekniska verktyg och förmågor som vi behöver för att komma framåt när det gäller att skapa datadrivna samarbeten i staden och i längden hållbara städer och samhällen. Resultaten ska ses som en guide för hur vi ska kunna ta inkrementiella steg mot en bättre funkerande infrastruktur utan att tappa bort oss. Vi har i de fiktiva exempel förhoppningsvis tydkligt argumenterat för varför detta är viktigt. Genom att bättre förstå de behov som utvecklare och användare har i staden och hitta generiska modeller för att bygga samman existerande och framtida system argumenterar vi för att vi behöver skapa datarymd (broker och gemensam adressrymd) skulle underlägga nya applikationer och samarbeten avsevärt.