Vitbok länkade öppna data

Denna vitbok har tagits fram inom det VINNOVA-finansierade projektet Kompetensförstärkning kring länkade öppna data - dialog, webbinarier och vitbok.

Se projektets webbsida för mer information.

Målgrupp och målsättning

Vitbokens främsta målsättning är att skapa ökad kompetens och systematik kring processen för att tillgängliggöra länkade öppna data. Vitboken är skriven med svenska aktörer som målgrupp och kan användas för att underlätta och minimera nödvändiga organisationsinterna informations- och förankringsarbeten.

Boken tar upp tekniska aspekter i begränsad omfattning och är inte tänkt som uppslagsverk för modellering och publicering av länkade öppna data. Se kapitlet om relaterad information för vidareförande literatur och andra initiativ.

Författare

Vitboken är skriven av Matthias Palmér och Hannes Ebner från MetaSolutions AB.

Författarnas tack

Stort tack till följande personer som har bidragit till vitboken på ett eller annat sätt (listan är sorterad alfabetiskt):

Johanna Berg, Erik Borälv, Kajsa Bråting, Rong Chen, Klas Eckerberg, Thomas Kvist, Börje Lewin, Niklas Lindström, Rikard Lövström, Robin Mångs, Hans Mehlin, Johanna Nilsson, Maria Noring, Marcus Smith, Henrik Summanen, Solgerd Tanzilli

Licens

Vitboken är licensierad med Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.

Introduktion till länkade data

Bakgrund

1990 skapade Tim Berners-Lee grunden för World Wide Web genom att kombinera principerna bakom internet med hypertext. I korthet introducerade han principer för att identifiera (URL:er), publicera (HTML) och hämta (HTTP) dokument. 2006, 16 år senare, lanserar Tim Berners-Lee Länkade Data, förkortat LD, som ett sätt att skapa en webb av data i en design issue. Skillnaden mot den vanliga webben är att länkade data handlar om att länka samman ting och dess beskrivningar snarare än dokument.

Interestingly, data is relationships. This person was born in Berlin; Berlin is in Germany. And when it has relationships, whenever it expresses a relationship then the other thing that it's related to is given one of those names that starts HTTP. So, I can go ahead and look that thing up. So I look up a person -- I can look up then the city where they were born; then I can look up the region it's in, and the town it's in, and the population of it, and so on. So I can browse this stuff.

So that's it, really. That is linked data.

The next web, by Tim Berners Lee at TED2009.

På sista tiden har intresset för det som kallas öppna data växt kraftigt. Öppna data innebär att man gör data tillgängliga över Internet för att förenkla användning, såväl väntad som oväntad. Att göra sina data tillgängliga som öppna data är ett bra första steg, men saknar den potential som länkad data har. Något förenklat kan man formulera skillnaden så här:

Länkade data tillför länkar och ett enhetligt format (RDF) som saknas hos öppna data.

Oftast är även länkade data tillgängligt öppet och benämns då länkade öppna data. På engelska används akronymen LOD för den engelska benämningen Linked Open Data. I denna vitbok håller vi dock fast vid benämningen länkade data för att markera att det finns fördelar oavsätt om datan är allmänt tillgänglig (öppen) eller inte.

De viktigaste begreppen på 5 minuter

Vad är Länkade Data?

Länkade data handlar om att komplettera den existerande webben av dokument med en webb av data. Det första vi behöver förstå är att länkade data handlar om påståenden om ting, där ting kan vara personer, platser, mediciner, historiska händelser, bilder, filmer, textdokument osv. Konkret räcker det att följa tre principer:

• addresserbarhet - ge varje ting en URI (en webbadress) som gör att påståenden kan hämtas via HTTP
• enhetlig informationsmodell - används språket RDF för att uttrycka påståenden om ting
• länka ihop - förbind ting med varandra genom relationer av olika slag, gärna mellan olika datakällor

Varför ska jag publicera Länkade Data?

Att använda länkade data ger många fördelar, bland annat:

• lättare att förstå och återanvända varandras data
• minska duplicering och fokusera på de egna datas specifika och unika mervärden (genom att länka till andras data)
• din data blir bättre tillgänglig på webben och i sökmotorer
• etablerade tekniker för maskinell bearbetning möjliggörs (då användning av länkade data innebär att semantiken hos datat klargörs)

Hur publicerar jag Länkade Data?

Identifiera vilka ting du har och ge dem webbadresser, tex: http://data.min-domän.se/produkt/15

Skapa lite påståenden om dina ting och lägg upp dem på respektive webbadress. Återanvända gärna etablerade vokabulärer, i exemplet nedan används Dublin Core Terms (förkortat dct). Exempelet använder turtle syntaxen då den är tämligen enkel att läsa:

PREFIX ex: <http://data.min-domän.se/produkt>
PREFIX dct: <http://purl.org/dc/terms/>

ex:15  dct:title "Produkt 15";
       dct:description "Produkt nummer 15 erbjuder en fantastisk...";
       dct:created "2014-09-09".

Lägg sedan gärna till påståenden i form av relationer (länkar) både mellan dina egna ting och till externa ting.

ex:16 dct:title "Produkt 16";
      dct:partOf ex:15;
      dct:relation <http://dbpedia.org/page/Bread>.

Klart! Länkade data är inte svårare än så. Dock tillkomer som alltid frågor kring underhåll, integration med existerande tekniska plattformar, intern kompetens kring informationsmodellen osv.

Webben och länkade data

Webben av idag har stor spridning och är i många fall det gemensamma kitt som binder samman aktörer över kulturella och språkliga gränser. Webben används ofta till både spridning och inhämtning av information samt till att bygga mer avancerade webbapplikationer. Trots denna vida användning är webben i grunden tämligen enkel och dess tekniska beståndsdelar innefattar i huvudsak:

• URI - ett enhetligt sätt att addressera olika informationsresurser (ofta webbsidor)
• HTTP - ett protokoll som används för att hämta och skicka information
• HTML - ett format för att presentera och interagera med information
• Länkar - ett sätt att binda samman informationsresurser

Webben är trots sina vida användningsområden i huvudsak ett presentationsmedium för människor. Det innebär att webben, och framförallt HTML, oftast inte lämpar sig för att utbyta information mellan system.

För att utbyta information mellan system är istället det snarlika initiativet Länkade data ett bättre alternativ. Precis som webben bygger länkade data på användning av URI:er och HTTP, men istället för HTML används RDF. I korthet kan man säga att RDF används för att uttrycka påståenden om ting, där ting är vad som helst som kan identifieras av en URI. Det är alltså inte bara webbsidor som identifieras av URI:er (webbaddresser) utan även fysiska föremål, historiska händelser, abstrakta begrepp osv. Det vill säga, vi kan ge URI:er även till ting som inte har en given digital representation. Sammanfattningsvis, länkade data innefattar i huvudsak följande tekniska beståndsdelar:

• URI - ett enhetligt sätt att addressera ting
• HTTP - ett protokoll som används för att hämta påståenden om ting via deras URI:er
• RDF - ett språk för att uttrycka påståenden om ting
• länkar - påståenden om relationer mellan ting

Bilden nedan visar en jämförelse mellan webben och länkade data:

Stjärnmodellen

I samband med öppna data och länkade öppna data använder man ofta en femstjärnig skala för att markera hur tillgänglig datan är:

★★★★★ gör din information tillgänglig på webben under en öppen licens
★★★★★ (även svårbearbetade format som skannade dokument är ok)
★★★★★ gör informationen tillgänglig som strukturerad data
★★★★★ (t. ex., Excel-format istället för en bild av en tabell)
★★★★★ använd icke-proprietära format
★★★★★ (t. ex., CSV istället för Excel)
★★★★★ använd URI:er för att identifiera ting,
★★★★★ och RDF för att uttrycka påståenden om dem
★★★★★ länka din data till andras data, det ger sammanhang

Nedan beskrivs fördelar med stjärnnivåerna, notera att fördelar ackumuleras ju fler stjärnor man når.

★ En stjärna - data tillgängligt digitalt

Om du lägger ut din data så att den är digitalt tillgänglig och det är tydligt att folk får använda datan (i form av en licens) så får du alltid en stjärna. Till exempel, om man redan har information tillgänglig på vanliga webbsidor och kompletterar hur informationen får vidareanvändas är första stjärnan säkrad.

Det är ett stort steg att gå från att behöva explicit begära data från en organisation till att informationen finns tillgänglig digitalt.

★★ Två stjärnor - öka datakvalitéten

Att dela ut ett format där data är tillgängligt på ett maskinprocessbart sätt utan att man behöver använda någon form av riskfylld extraheringsprocess gör att andra kan förlita sig på datan i större utsträckning. Insatsen för att använda datan i andra sammanhang har sjunkit betydligt och två stjärnor är säkrade.

★★★ Tre stjärnor - öppna data

Med tre stjärnor minskar man behovet av investeringar i proprietär teknologi hos de som vidareutnyttjar datan. Då man förlitar sig på öppna format som antingen är väldigt enkla (t. ex. CSV-formatet) eller väl dokumenterade skapar man förutsättningar för mer långsiktig hållbar data. Man minskar även risken för felaktig bearbetning av information när proprietära format hanteras av tredje parts mjukvara (särskilt när fullständig dokumentation om formatet saknas).

★★★★ Fyra stjärnor - enhetligt informationsuttryck och tydlig semantik

Med den fjärde stjärnan uppnås flera saker:

• Genom att man delat upp datan i ting som har globala identifierare, URI:er, möjliggör man för andra att referera till den egna datan på ett sätt som är standardiserat och effektivt.
• Dataintegration med andra parter förenklas då det datauttryck man väljer inte är bundet till det egna datalagret. Istället beskriver man sin data med hjälp av existerande termer, ofta anpassar och kombinerar man en eller flera existerande informationsmodeller efter egna behov. Detta innebär att när den egna datan ska vidareutnyttjas kan andra parter redan ha kännedom eller till och med utvecklat stöd för att förstå delar av informationsmodellen.
• Den informationsmodell man utvecklat är med stor sannolikhet mer genomtänkt då den är en vidareutveckling av tidigare informationsmodeller.
• Då datan uttrycks med RDF, ett standardiserat språk för hantera information så finns redan många mjukvarubibliotek och tjänster som kan användas för att skapa, validera, lagra, maskinellt bearbeta, kombinera, redigera och utforska datan med existerande frågespråk.

★★★★★ Fem stjärnor - länkade öppna data

Den femte stjärnan ger flera ytterligare fördelar:

• Förtydliga din data genom att länka till väletablerade och väl uttänkta termer/begrepp istället för att skapa egna eller skriva fritext.
• Använd data/begrepp/termer från andra datakällor direkt när behov uppstår utan att först behöva fokusera på tekniska aspekter av dataintegration som import, konvertering och drift/underhåll.
• Effektivt använd länkning kan leda till att öka dataspecialisering då du kan fokusera på att underhålla de delar av datan som är unik för din organisation och mindre med information som redan finns i andra datakällor.
• Länkar till andra datakällor ökar förtroendet för att din data är genomtänkt på ungefär på samma sätt som referenser i artiklar visar på att informationen är förankrad i ett större sammanhang.
• Länkar ut ökar din datas synlighet då det blir en del av det större länkade data molnet vilket i ett längre perspektiv kan leda till återanvändning i nya sammanhang, dvs. i form av länkar in.

Vikten av återanvändning

Återanvänding av existerande termer är en viktig aspekt vid publicering av länkade data. Att återanvända väletablerade termer ökar sannolikheten att applikationer kan konsumera publicerade länkade data utan att det krävs särskilda anpassningar för olika datamängder. Det finns alltid situationer där befintliga termer inte exakt matchar behovet. I sådana fall är det rekommenderat att skapa en ny term som länkar tillbaka till det som förfinas (s.k. "refinements") eller är relaterat. Utan återanvändning eller länkar mellan relaterade termer förlorar man en av de mest kraftfulla egenskaperna av länkade data och man löper risk att det publiceras datamängder som har högst begränsad interoperabilitet med andra data.

Länkade data - en global rörelse

Länkade data introducerades av Webbens grundare sir Tim Berners-Lee 2006 i en inflytelserik Linked Data Design Note. Ett sätt att mäta i vilken omfattning länkade data används är att se hur många dataset och hur många påståenden som publicerats över tiden. Till exempel så ökade antalet publicerade påståenden från 2 miljarder 2007 till 30 miljarder 2011. Antalet dataset har också ökat dramatiskt vilket kan ses i de visualiseringar som gjordes av det så kallade LOD-molnet. Tyvär har ingen visualisering gjorts sedan 2011, då det såg ut så här:

Linking Open Data cloud diagram, by Richard Cyganiak and Anja Jentzsch. http://lod-cloud.net/

En indikation på att det fortsatt att växa sedan dess kan man få genom att söka fram alla dataset på datahub.io, vid skrivande stund är de 898 stycken. Detta ska jämföras med de 295 som ingick i visualiseringen 2011. Det är också troligt att det finns ett stort mörkertal med dataset som antingen inte registrerats alls eller registrerats i nationella register som inte alltid aggregeras i datahub.io.

Innehållsmässigt spänner dataseten över de flesta områden till exempel, myndighetsdata, biomedicin, media, geografisk information osv.

Fördelar med länkade data

Utan tvekan är webben en oerhört framgångsrik och hittills oöverträffad konstruktion när det gäller att ge oss människor tillgång till stora mängder information snabbt och enkelt.

Den webb vi ser idag är nästan uteslutande en vy genererad utifrån underliggande informationsmängder, dvs. data i olika former. Dessa data hanteras av olika system (som databaser) och förvandlas till webbsidor och webbapplikationer oftast millisekunder innan du ser resultatet i din browser.

Vilka vyer/tjänster som skapas och görs tillgängliga för dig bestäms oftast av den organisation som ansvarar för datan och faktorer som ekonomi, tid, kompetens och förväntad användning spelar stor roll för de prioriteringar som görs.

En naturlig slutsats blir att det finns stor potential i att göra underliggande data tillgänglig för en större krets. Dels skulle det kunna medföra att nya vyer/tjänster skapas som hittills inte prioriterats. Dels kan data kombineras på nya sätt vilket möjliggör helt nya vyer/tjänster som utan öppen data skulle kräva samordning mellan flera dataägare.

Men hur ska man exponera data? Vilka format ska man använda och vilka principer ska man följa? Vi listar här några av de viktigaste fördelarna man får av att använda sig av just länkade data:

Att dessa fördelar följer av valet av länkade data är inte helt självklart, nedan följer en fördjupning och analys för den intresserade.

1. Data blir en del av webben - skicka med data i webbsidor

Först och främst så kan länkade data skickas med inne i vanliga webbsidor. Med hjälp av W3C-rekommendationen RDFa kan man ge semantik till olika delar av en webbsida utöver vad som ingår i standarden för HTML. Till exempel så finns det stöd i HTML för att tala om att något är en rubrik, en paragraf osv. Men om man vill uttrycka att ett block av information representerar en person och vad som är förnamn och efternamn så räcker inte HTML. Istället får man använda sig av länkade data i form av en lämplig vokabulär, till exempel Friend Of A Friend (FOAF). Man annoterar då HTML uttrycket med RDFa för att förtydliga att blocket motsvarar en foaf:Person, vilka delar som motsvar foaf:givenName och foaf:familyName. Så här kan det se ut (foaf = http://xmlns.com/foaf/0.1/):

<body vocab="http://xmlns.com/foaf/0.1/">
  <div typeof="Person">
    <span property="givenName">John</span>
    <span property="familyName">Doe</span>
  </div>
</body>

Utöver RDFa bygger länkade data på samma principer som webben, det vill säga användning av URIer. Access till data sker direkt via HTTP samt användning av länkar för att binda samman data. Det innebär att de tekniker som ofta används på webben för att ge stöd åt webbsidor och webbapplikationer också kan använda länkade data. Till exempel innnebär det att länkade data går att hämta via javascript-anrop (Ajax) samt att det går att välja format som är enkla att hantera i en webbrowser (t.ex. JSON).

Visserligen kan man hävda att även andra sätt att representera data går att utnyttja i samband med webben. Men när man studerar vad som är framgångsrikt på webben idag så ser man att enkelhet och integration med andra webbteknologier är starkt premierat. Relevanta exempel är hur JSON ökar i popularitet över XML- och REST-baserade tjänster i förhållande till Web Services. (Länkade data är i grunden baserat på REST och det finns flera lämpliga JSON-format som man kan välja mellan.)

En annan viktig princip som delas mellan webben och länkade data är antagandet om den öppna världen. Detta antagande innebär att man måste hantera att länkar bryts, att information saknas, inte kan nås eller ändras på ett sätt som man inte har kontroll över. Dessa antaganden har visat sig fundamentala för att storskaliga och decentraliserade informationssystem ska kunna växa dynamiskt. Det bör noteras att trots att antagandet om den öppna världen låter negativt så är det en styrka då system som designas för att klara av detta bättre klarar av att hantera den flora av information som finns på webben idag.

2. Förbättrad sökbarhet - sökmaskiner förstår dina data bättre än dina webbsidor

På senare tid har det skett ett paradigmskifte i hur moderna sökmaskiner fungerar. Man söker i större utsträckning efter kunskap snarare än efter webbsidor. I Google manifesterar sig detta dels genom att man får förslag på personer, filmer, företag osv. när man skriver in en sökning och dels att man får upp faktarutor relaterat till det man sökt på. Grunden för detta är att sökmaskinerna kompletterar sin indexering av webbsidor med en kunskapsbas. Till exempel så introducerade Google sin knowledge graph 2012 och Microsoft introducerade Bings Satori Knowledge Base 2013.

En viktig grund för sådana kunskapsbaser är länkade data, t.ex. så klarar Googles Knowledge Graph av att läsa in länkade data som JSON-LD eller inbäddat som RDFa i webbsidor. Man kompletterar också med existerande kunskapsbaser som alla är länkade data-vänliga, t.ex. Freebase, Wikipedia, CIA-factbook osv.

3. Interoperabilitet - lättare att utbyta och samköra data

Interoperabilitet betyder i grunden att när två parter utbyter information så ska mottagarens agerande (i relation till informationen) stämma överens med avsändarens intention. Detta kräver någon form av överenskommelser i förväg kring hur informationen ska överföras och tolkas. Sådana överenskommelser kan vara specifika för två parter, eller etablerade i ett vidare sammanhang, t.ex. i form av en standard.

En situation som ofta uppstår när man ska använda en given standard är att den bara täcker in en del av de behov man har. En naturlig reaktion är då att komplettera med byggstenar från andra standarder och eventuellt skapa nya konstruktioner för att nå bättre täckning av behoven.

Det är i sådana situationer som länkade data visar sin styrka genom att tillhandahålla en gemensam bas och en mängd mer eller mindre standardiserade byggstenar som kan kombineras på olika sätt. Basen består av ett gemensamt språk (RDF tillsammans med RDFS, SKOS och OWL) som tillåter att man definierar byggstenar i form av klasser, egenskaper, vokabulärer osv.

Givet att länkade data tillåter oss att sätta samman vårt datauttryck utifrån en mängd byggstenar, vad får det för konsekvenser? Låt oss tänka på två olika former av datautbyte:

1. Data exponeras för en given mottagare.
2. Data exponeras för flera olika, delvis okända, mottagare.

Given mottagare

Om man man har en given mottagare kan man hävda att det enklaste är att i förväg komma överens om ett eget datauttryck, t.ex. i XML eller JSON, eller kanske definera en specifik Web Service. Men då tappar man fördelar som har med standardisering att göra:

• Någon annan har redan gjort de flesta misstagen och jämnat vägen.
• Dokumentation existerar redan delvis.
• Verktyg finns för att hantera datan.
• Lösningen är skalbar då webben skalar.
• Kunskap om relevanta datauttryck finns redan hos specialiserade aktörer.
• Krävd kompetens är i större omfattning generell än specifik.

Flera olika och delvis okända mottagare

När mottagarna ökar i antal och ibland också är okända är det behändigt att kunna luta sig mot standarder i så stor uttsträckning som möjligt. Notera att olika mottagare ofta behöver olika information och kan därmed ignorera delar av datan som inte är relevanta för dem. Det kan också innebära att specialiserade aktörer redan förstår och har stöd för de delar av datan som de är intresserade av. (Förutsatt att avsändaren har valt att beskriva sin data med hjälp av relevanta och allmänt accepterade byggstenar.)

Alternativet med egna datauttryck är mindre tilltalande då det kräver en mer noggrann och omfattande egen dokumentation för att hålla risken för felaktig användning låg.

4. Återanvänd datauttryck - mindre jobb för den egna organisationen

Som vi nu konstaterat tillåter länkade data oss att definiera nya byggstenar, förfina existerande byggstenar och att återanvända redan existerande.

Nedan är ett exempel där byggstenar från tre olika källor används för att beskriva en bil och dess ägare (ursprunget av byggstenarna indikeras av de tre olika namnrymderna rdf, dct och co där co står för car ontology).

http://example.com/myCar  rdf:type    co:Car ;
                          co:brand    co:Volvo ;
                          dct:title   "My cool car" .

Notera att vem som helst kan introducera nya byggstenar men att det inte med automatik innebär att andra utöver de närmast sörjande kommer att återanvända dem. Det finns ingen central aktör som godkänner, sprider information och rekommenderar andra att återanvända introducerade byggstenar. Istället sker detta mer organiskt, ofta genom att man fyller ett behov som inte redan är löst, är tydlig i sin design och förklaring av byggstenarna och är framgångsrik i sin kommunikation med andra.

Det finns idag en vid flora av byggstenar (terminologier, vokabulärer) och att ge en mer täckande bild är klart utanför ramarna för detta kapitel och denna bok. Men vi kan iallafall nämna några av de idag allmänt etablerade och ofta använda byggstenarna. (Vi hoppar över RDF, RDFS, OWL och SKOS då de är på nivån av vokabulärdefinition snarare än en speciell vokabulär).:

5. Kompetenta datauttryck - inga fyrkantiga lådor i runda hål

Länkade data bygger på att man använder det gemensamma språket RDF för alla olika datauttryck. RDF tillåter att man strukturerar sin data som grafer, som träd, som attribut-värdepar, som listor osv. Men då RDF i grunden baseras på en grafmodell så kallar vi för enkelhets skull alltid ett data uttryck i RDF för en RDF-graf oberoende av vilken datastruktur som uttryckts i en viss situation. RDF har också stöd för en mängd olika primitiva datatyper som heltal, flyttal, datum osv.

I stort kan man säg att så länge din data har en struktur av något slag som inte är ren binärdata så kan RDF användas för att fånga upp den strukturen.

Notera att RDF är ett språk och inte en syntax vilket innebär att RDF kan uttryckas i en mängd olika format. Detta är en betydande skillnad mot XML som är en syntax (dock en utvidgbar sådan), dvs. att det finns bara ett format för XML (det välkända text baserade formatet med en trädstruktur av element).

Att RDF är ett språk medför att det finns en grundläggande och ganska enkel semantik inbyggd. Denna semantik innebär väsentligen att alla RDF-uttryck i sin grund består av påståenden om resurser. En konsekvens av detta är att RDF har en del trevliga egenskaper, RDF grafer kan:

• utan problem slås samman eller delas upp.
• när som helst kompletteras med nya påståenden.
• överföras och lagras som dokument.
• uttryckas i ett format som du är bekväm med (t.ex. XML, JSON eller andra enklare text format).
• bäddas in i andra format, t.ex. i HTML, PDF, SVG osv.
• persisteras i databaser (triplestores) utan krav på databas scheman (schemaless i NoSQL termer).
• bearbetas maskinellt med avseende på förutbestämd semantik (inferens).

6. Öka kvaliteten med länkar - positionera dina data och externalisera information

Det är viktigt för en aktör att hitta lämpliga avgränsningar för vilken data som ska inkluderas och underhållas. Ofta är det ekonomi, verksamhet och kompetens som bidrar till att sätta gränser. Andra aktörer som hanterar liknande data gör troligtvis andra avgränsningar då de har andra behov.

För att ta ett exempel kan data om staden Stockholm se olika ut om det är SJ, SMHI eller Historiska muséet som tillhandahåller den. Samtidigt kan vi tänka oss att en turist kan dra nytta av att få information om Stockholm från dessa tre källor presenterade tillsammans.

Ett bra sätt att åstadkomma detta - då det inte alltid går att hitta globala identifierare - är att skapa relationer mellan de olika datauttrycken med hjälp av länkar. En speciell form av länk (owl:sameAs) uttrycker att det det är samma ting (staden Stockholm) som har fått olika identifierare (URI:er). Men länkar kan också utnyttjas till att förbinda olika ting, t.ex. att staden Stockholm ligger i landet Sverige eller att där har bott historiskt intressanta personer som August Strindberg.

Ur detta exempel inser vi att effektivt använda länkar kan leda till att öka dataspecialisering då varje aktör kan fokusera på att underhålla den data som den kan bäst och förlita sig på andra aktörer för resten.

Det är ofta så att länkar till andra datakällor också ökar förtroendet för data. Dels genom att länkar skapar ett större sammanhang som bekräftar att man hittat rätt data. Dessutom visar existensen av länkar att man ansträngt sig för att placera in sin data i ett större sammanhang och minimera redundans. Detta gör det mindre sannolikt att någon annan redan har eller kommer ta fram en bättre datakälla som gör den aktuella datakällan överflödig.

Att komma igång med länkade data

I detta kapitel ges praktiska råd för hur man kommer igång med länkade data. Först hur man väljer ut vilken informationsmängd man vill börja med och därefter hur man konkret skapar sin första länkade data. Sedan diskuteras i korthet frågor kring best practises och licenser.

Kapitlet avslutas med en introduktion och analys av ett antal tekniska lösningskategorier för publicering av länkade data. Vilken lösningskategori man bör välja beror både på tekniska förutsättningar, t.ex. existerande IT-infrastruktur, och vilken kompetens man har eller vill ha inom den egna organisationen.

Vilken information ska jag börja med?

För en del läsare är detta självklart då orsaken till att man läser denna vitbok är att man planerar att exponera en given informationsmängd som länkade data. Men om du som läsare representerar en organisation som funderar eller har beslutat att publicera länkade data kan det vara bra att få förslag till hur man prioriterar. I E-delegationens vägledning för vidarutnyttjande av offentlig information listas i kapitel 4.4.1 ett antal frågor man ska ställa sig vid prioritering av vad som ska exponeras. Frågorna är i huvudsak skrivna för offentliga aktörer men är relevanta även för andra organisationer och företag. Fritt översatt är frågorna:

1. Efterfrågas information av andra aktörer?
2. Används informationen redan av den egna organisationen i kommunikation utåt?
3. Vilka demokratiska och ekonomiska värden kan en exponering av information bidra till?
4. Hur mycket arbete innebär det att exponera informationen, krävs manuell granskning för en framgångsrik exponering?

För en mer metodisk översikt för prioritering av vilken information man ska börja med se SKLs ramverk för öppna data speciellt de delar som handlar om nyttor och kostnader.

Snabbstart

Det finns många sätt att komma igång med att publicera länkade data. Ett sätt är att lära sig något modelleringsverktyg som Protégé där man kan börja modellera sina datauttryck. Författarnas erfarenhet är dock att det finns en enklare mer praktisk metod som ofta leder till lika bra eller bättre resultat. Särskilt då den inte kräver kompetens i ett avancerat och för de flesta okänt verktyg samt att ett för stort verktygsfokus inte nödvändigtvis främjar samarbete och snabb iteration i början av ett projekt:

1. Skriv ner en lista med de viktigaste tingen du har i din data, t.ex. personer, föremål, händelser, bilder, osv. Komplettera sen listan med viktiga egenskaper som tingen har, t.ex. benämning, personnummer för en person eller registreringsnummer för en bil.
2. Bestämma hur de olika tingen kan ges egna webbadresser, dvs. URI design.
3. Samlas kring en whiteboard eller något digitalt ritverktyg. Rita upp era ting och förbind dem med varandra via olika relationer.
4. Konkretisera egenskaper och relationer genom att återanvända existerande vokabulärer som dcterms, foaf etc. för att hålla nere behovet av att introducera nya specifika termer.
5. Skriv ner uttrycket för några exempel. Använd förslagsvis formatet Turtle då det är tämligen lätt att lära sig, skriva och läsa.
6. Lägg upp exempelfilerna på en webbserver i en katalogstruktur som motsvarar hur URI:erna för tingen ska se ut.

Efter detta har ni faktiskt redan producerat ett exempel med länkade data, på samma sätt som man kan producera statiska webbsidor genom att skriva dem för hand. Vad som återstår är att utveckla den tekniska lösning som ska generera länkade data utifrån underliggande system.

Notera: Det faktum att ni redan från början har tagit fram riktiga exempel på länkade data innebär att tre olika aktiviteter kan ske parallellt:

1. Dokumentation av länkade data uttrycket och eventuell formalisering i RDFS / OWL.
2. Utveckling av en teknisk lösning för publicering av dina länkade data.
3. Utveckling av andra system som ska interagera med dina länkade data.

Best Practices

Det finns best practices med väletablerade angreppssätt för skapning av URIer och val av vokabulärer som bör återanvändas så långt som möjligt. En detaljerad redogörelse av best practices ligger utanför vitbokens ramar, men det finns gott om litteratur som detaljerat beskriver hur man kan gå tillväga. Avsnittet "Externa källor" innehåller en lista med relevant litteratur som även täcker best practices.

Licens

Det är viktigt att förse datamängden med en licens som gör det tydligt vad man får göra med datamängden. Det är allmänt rekommenderat att återanvända väletablerade licenser som är anpassade för öppna data. Exempel på licenser som fungerar bra med länkade öppna data är:

• Creative Commons Zero Public Domain Dedication (CC0)
• Open Data Commons Public Domain Dedication (PDDL)
• European Union Public License (EUPL)
• ISA Open Metadata Licence

Det underlättar (eller möjliggör) att återanvända datamängden när den publiceras tillsammans med en tydlig och godtagbar öppen licens.

Exponera länkade data - lösningskategorier

Vi har identifierat två huvudsakliga lösningskategorier med tillsammans fem underkategorier som på olika sätt klarar av att exponera länkade data från ett givet dataset. För att kunna ge en tydlig översikt av skillnaderna mellan de olika lösningskategorierna använder vi följande benämningar:

Plattform A - den existerande plattformen som i dagsläget inte har stöd för länkade data.

Plattform B - en plattformen som har stöd för länkade data.

Vi beskriver först de två huvudsakliga lösningskategorierna och i kapitlet efter görs en kort analys av de fem underkategorierna.

Utnyttja befintlig plattform

Om man har en existerande plattform som man är nöjd med är det ofta vettigt att hålla fast vid den. Följande fördelar är vanliga:

1. Driftsättningen är klar.
2. Användargränsnitt för redigering och presentation är redan på plats.
3. Organisationen är van vid hanteringen.
4. Integration med andra underliggande system är klar.

Men det finns saker som kan tala emot användning av en existerande plattform, t.ex.:

1. Behov av ändrad informationsmodell för att stödja det avsedda länkade data-uttrycket som ofta är mer kvalificerat.
2. Behov av ett förbättrat och mer lämpligt användargränsnitt för redigering och presentation

Ny plattform

I vissa situationer är det bättre att byta till en ny plattform, t.ex. om en eller flera av följande omständigheter beskriver situationen väl:

1. Datasetet är relativt självständig och det finns få eller inga behov av att integrera med andra underliggande system.
2. Informationsmodellen behöver ändras
   1. då organisationens behov har förändrats.
   2. för att stödja ett mer kvalificerat länkade data-uttryck.
3. Det behövs ett förbättrat och mer lämpligt användargränsnitt för redigering och presentation

Kort analys av lösningskategorier

Nedan analyseras de fem lösningskategorierna. För att förenkla resonemangen en aning så ignorerar vi eventuella behov att integrera med andra underliggande system i de två sista lösningskategorierna.

1. Utvidga plattformen

Syftet här är att utvidga en existerande plattform med stöd för länkade data. Antingen ett generellt stöd för länkade data eller mer specifikt för en begränsad mängd data. Naturligtvis blir en sådan utvidgning specifik för varje plattform. Det finns två huvudvägar att gå:

Syntaktisk lösning - denna lösning innebär att man i ett existerande presentationslager som hittills levererat html lägger till en mall som istället producerar RDF i något format.

Semantisk lösning - denna lösning innebär att man skriver kod som översätter mellan en intern representation av datamodellen och informationsmodellen i RDF genom att jobba mot ett RDF API, typiskt tillhandahållet via ett RDF-bibliotek.

Nackdelen med den syntaktiska lösningen är att man skapar en mappning till en syntax, inte till RDF som språk. Den semantiska lösningen jobbar istället mot RDF som språk och gör det enklare att uppfylla de tekniska kraven 2, 4 och 6. Båda lösningarna innebär en betydande mängd hårdkodning där man binder sig till den interna representationen av informationsmodellen.

2. Lager ovanpå plattformen

Skillnaden mot alternativet ovan (utvidga plattformen) är att man jobbar med någon form av etablerat datagränsnitt istället för en intern representation av informationsmodellen. Till exempel kan det vara så att datan regelbundet dumpas ut som filer (CSV, XML etc.) eller att det går att komma åt datan via ett API (Web Services, REST etc.). I vissa situationer kan också en välstrukturerad databas fungera som ett datagränsnitt. Existensen av någon form av datagränssnitt gör att man kan skapa stöd för länkade data i ett lager som är tämligen oberoende av den existerande plattformen. Beroende på val av programmeringsspråk och ramverk kan lagret driftsättas olika nära den existerande plattformen.

Lagret kan utgöras av standardkomponenter som plockas samman, alternativt används en dedikerad plattform som är lämpad för uppgiften.

3. Molntjänst ovanpå plattformen

Denna kategori av lösningar påminner starkt om lager ovanpå plattformen. Skillnaden är att lagret nu har lyfts ut till en oberoende tjänst i molnet (SaaS). Lösningar bör inkludera ett användargränssnitt för att styra vilken mekanism som ska användas vid inhämtning av data och vilken form av konvertering till länkade data som ska göras.

För att en lösning ska hamna i denna kategori ska den isolera organisationen från drift och underhåll av den mjukvara som exponerar länkade data. Kompetens för hur det länkade data uttrycket ska se ut och hur den egna datan ska översättas till detta uttryck är dock fortfarande nödvändigt att ha inom den egna organisationen. Sådan kompetens kan etableras hos informatiker inom organisationen, eventuellt med stöd utifrån. Efter initial etablering kan i de flesta fall denna kompetens underhållas internt inom organisationen och även bidra till ett vidare perspektiv på den egna informationsmodellen som ofta är av nytta vid samtal och samarbete med andra organisationer. Denna nytta är komplementär till nyttan av att ha ett länkade data-lager för att faktiskt genomföra en dataintegration med andra organisationer.

4. Ny plattform internt

Att flytta relevant data till en plattform som har stöd för länkade data innebär förstås att man måste hantera de konsekvenser som normalt uppstår vid byte av plattform.

Datakonvertering - Relevant data måste flyttas och konverteras till ett format som den nya plattformen kan ta emot. Ny situation för drift och underhåll - Den nya plattformen kommer med nya krav på drift och underhåll. Rutiner för drift påverkas förstås av vilken typ av plattform det handlar om, t.ex. .NET jämfört med java.

Ny teknisk kompetens - Den nya plattformen kommer kräva ny teknisk kompetens av IT-avdelningen och/eller hos en extern partner särskilt vid behov av ändringar eller uppgraderingar.

Ny användarkompetens - Såvida man inte bygger om gränssnittet till att likna det gamla så kommer förändringen innebära en omställning för de som jobbar i systemet. I något läge måste man också se till att existerande data mappas mot ett uttryck i RDF. Om den nya plattformen använder RDF internt sker konverteringen direkt. Om den nya plattformen har en annan intern representation som sedan mappas mot RDF i ett senare skede hamnar man i en situation där man måste göra två konverteringar, först till den nya plattformens interna datamodell och sedan till RDF. Förhoppningsvis är dock den senare mappningen av enklare karaktär om plattformen är en någorlunda kompetent länkad data-plattform.

En allmän reflektion är att omfattning av konsekvenserna ovan beror på hur stor mängden av relevant data och hur komplicerad den ursprungliga plattformen är. För små mängder data och med endast ett fåtal användare så är konsekvenserna troligtvis ganska små.

5. Ny plattform i molnet

Denna lösningskategori skiljer sig från lösningskategorin ovan genom att den nya plattform som man väljer körs som molntjänst istället för i den egna infrastrukturen. Detta innebär vissa fördelar som att drift och underhåll förenklas och att det inte ställs några ytterligare krav på teknisk kompetens inom organisationen. Samtidigt medför det några nackdelar som att eventuella behov av integration med existerande system blir svårare att realisera samt att en molnlösning innebär en återkommande kostnad. De övriga konsekvenerna listade ovan, behov av datakonvertering och behov av ny användarkompetens är desamma.

Teknikplattformar

I listorna nedan ingår plattformar som ett eller flera företag erbjuder kommersiell support för, men det listas även plattformar eller lösningar utan kommersiell support. Det senare förutsätter intern kompetens för att lösa problem som eventuellt kommer att visa sig under utveckling och drift.

Om möjligt och lämpligt så består beskrivningen av varje teknisk plattform av följande delar:

• kort beskrivning,
• aktivitetsgrad (kommersiell support, aktiv community, osv),
• användning och kunder,
• licens.

Plattformarna är grupperade under de lösningskategorier som introducerades i kapitlet kom igång samt under en extra gruppering egen lösning där man bygger mer själv och återanvänder endast ett triple store.

1. Utvidga plattformen
2. Lager ovanpå plattform
3. Molntjänst ovanpå plattformen
4. Ny plattform internt
5. Ny plattform i molnet
6. Egen lösning baserad på lämplig triple store

Utvidga plattformen

Semantic SharePoint

Semantic SP är en integration av PoolParty (se nedan) med Microsoft SharePoint. Semantic SharePoint fokuserar på kontrollerade vokabulär och textanalys för att extrahera semantisk information ur ostrukturerade data (text).

Företaget Semantic Web Company erbjuder licenser och hostning samt kommersiell support till plattformen som är proprietär.

Länk: http://www.semantic-sharepoint.com

Egen lösning genom att jobba med mallar

Utöver en plattform som kan integreras med t.ex. Microsoft SharePoint är det möjligt att bygga mallar (t.ex. ASP i en Microsoft-miljö) som exponerar en databas (eller delar av den) som länkade data. Detta angrepssätt är tekniskt inte särskilt avancerat och kan leda till snabba resultat, men medför en förvaltningsoverhead eftersom man inte bygger på ett ramverk som underlättar framtida anpassningar. Den osäkra skalbarheten kan riskera framtidssäkerheten av en satsning på denna lösning.

Lager ovanpå plattformen

PoolParty Semantic Suite

PoolParty är i första hand en thesaurus manager, med features såsom textanalys och harvesting av länkade data. Textanalysen är baserad på "Natural Language Processing", dvs. extrahering av semantiska entiteter ur text. PoolParty verkar inte ha stöd för svenska. Textanalysen går att kombinera med thesauri som är framtagna i PoolParty. Företaget Semantic Web Company erbjuder licenser och hostning samt kommersiell support till plattformen som är proprietär. PoolParty används inom myndigheter, utgivare/förlag, energi- och finanssektorn.

Länk: http://www.poolparty.biz

OpenLink Virtuoso med Sponger

OpenLink Virtuoso är en s.k. "universal storage engine", dvs. ett backend-system som stöder relationella databaser men också triple stores. Med hjälp av Sponger-modulen kan Virtuoso importera data från många olika källor (dvs. "legacy data"). Företaget OpenLink utvecklar Virtuoso och erbjuder kommersiell support. Det finns även en Open Source-edition utan support. Virtuoso används i många olika projekt som backend, bl a av DBpedia och PoolParty.

Länk: http://virtuoso.openlinksw.com

fluidOps platform

fluidOps är en molnplattform med fokus på "Big Data" som även har stöd för länkade data. Produkten "Information Workbench" är en integrationsplattform för semantisk länkning, samarbete och business intelligence. Företaget fluid Operations utvecklar plattformen och erbjuder molntjänster såväl som kommersiell support.

Länk: http://www.fluidops.com

Redlink

Redlink är en plattform för semantisk berikning och länkade data som bygger på ett flertal Open Source projekt (Apache Solr, Marmotta och Stanbol). Produkten är inte särskilt väldefinierad eftersom företaget Redlink, som erbjuder kommersiell support, befinner sig i uppstartsfasen.

Länk: http://redlink.co

COEUS

COES är ett backend-ramverk för att bygga applikationer i semantiska webben. Ramverket är utvecklat av ett universitet och är Open Source. Kommersiell support erbjuds inte av universitetet.

Länk: http://bioinformatics.ua.pt/coeus/

GNOSS

GNOSS är en plattform för att bygga sociala nätverk med dynamisk publicering av innehåll i en länkade data-miljö. Företaget RIAM I+L Lab erbjuder kommersiell support och molntjänster. Mjukvaran är inte Open Source. Plattformen används huvudsakligen inom kulturarvssektorn på den iberiska halvön.

Länk: http://www.gnoss.com

Molntjänst ovanpå plattformen

Dydra

Dydra är en grafdatabas i molnet med stöd för RDF och SPARQL. Plattformen är i "closed beta" och det är oklart när och om produkten kommer att släppas för produktivt bruk för allmänheten.

Länk: http://dydra.com

EntryScape

EntryScape är en samarbetsplattform driven av länkade data. Plattformen har stöd för att fritt konfigurera eller återanvända entitetsdefinitioner och metadataformulär för att skapa och hantera länkade data.

Företaget MetaSolutions erbjuder kommersiell support och driver utvecklingen av EntryScape som är Open Source. EntryScape erbjuds även som molntjänst.

EntryScape används idag inom offentlig sektor, forskning, undervisning, vård och även helt öppet utan särskilt fokusområde.

Länk: http://entryscape.com

Swirrl PublishMyData

PublishMyData är en molntjänst och datapubliceringsplattform för länkade data. Det är möjligt att importera och länka data för vidare bearbetning och spridning. Företaget Swirrl erbjuder molntjänsten och kommersiell support. PublishMyData finns även som Open Source community edition.

Länk: http://www.swirrl.com/publishmydata

Ny plattform internt

Callimachus Enterprise

Callimachus Enterprise är en applikationsserver för länkade data. Mjukvaran har stöd för hantering och skapande av länkade data och kommer med en utvecklingsmiljö.

Företaget 3RoundStones erbjuder kommersiell support och står även för den aktiva utvecklingen av plattformen som i huvudsak är Open Source. Callimachus erbjuds även som molntjänst.

Exempel på områden där Callimachus används är inom myndigheter, utgivare/förlag, vård och forskning.

Länk: http://3roundstones.com/products/managed-services-for-commercial/

EntryScape

EntryScape är Open Source men erbjuds även som molntjänst med SLA. Se "EntryScape" ovan för en beskrivning.

Graphity

Graphity är en plattform för publicering av länkade data, med särskilt fokus på deklarativ webbutveckling. Mjukvaran är Open Source och företaget Graphity erbjuder kommersiell support kring plattformen.

Länk: http://graphityhq.com

Open Anzo

Open Anzo är en RDF databas med en tjänsteorienterad semantisk middleware plattform. Plattformen är Open Source, men det finns inget företag som erbjuder kommersiell support. Aktiviteten i utvecklingscommunityn har legat nere sedan 2011. Därmed bedömer vi det som osannolikt att det skulle gå att få support i dagsläget.

Länk: http://www.openanzo.org

Ny plattform i molnet

Callimachus Enterprise

Callimachus är Open Source men erbjuds även som "hosted" lösning. Se "Callimachus Enterprise" ovan för en beskrivning.

EntryScape

EntryScape är Open Source men erbjuds även som molntjänst med SLA. Se "EntryScape" ovan för en beskrivning.

Egen lösning baserad på lämplig triple store

Om ingen existerande lösning ska återanvändas så finns möjligheten att bygga en egen lösning som bygger på ett backend-system för att spara RDF-data, ett s.k. triple store. De flesta triple stores är tillgängliga under en Open Source licens och har fullt stöd för alla relevanta W3C-standarder och är därmed i praktiken utbytbara. Precis som med relationella databaser ligger skillnaden mellan triple stores i tekniska detaljer. Man kan skilja mellan triple stores med och utan kommersiell support.

Etablerade triples stores med kommersiell support är:

• Franz Inc. AllegroGraph, http://www.franz.com/agraph/allegrograph/
• Ontotext OWLIM, http://www.ontotext.com/owlim
• OpenLink Virtuoso, http://virtuoso.openlinksw.com

Triple stores utan kommersiell support är:

• Apache Jena, http://jena.apache.org/
• Mulgara Semantic Store, http://www.mulgara.org/
• Systap Bigdata, http://www.systap.com/bigdata.htm
• OpenRDF Sesame, http://www.openrdf.org/
• Garlik 4store, http://4store.org/

Scenarier

Nedan går vi igenom två scenarier. Först berättar vi om länkade nobelpris där länkade data har införts för att ge mervärde och ökad kvalitet åt webbplatsen nobelprize.org. Därefter diskuterar vi ett fiktivt scenario för att visa på hur länkade data har potentialen att lösa breda samverkansproblem mellan en stor mängd organisationer.

Länkade nobelpris - att förstärka en webbplats med extern information

Nobel Media AB är en relativt liten organisation som bland annat förvaltar nobelprize.org, den officiella webbplatsen om nobelpris och nobelpristagare. Webbplatsen innehåller både lättillgänglig och fördjupande information i form av fakta, texter och bilder som går ända tillbaka till de första nobelprisen år 1901. För de senare åren finns också en hel del filmmaterial att ta del av.

Nobel Media lägger ner mycket tid och engagemang på att förmedla information kring nobelprisen, men det är i stort sett omöjligt att ge en komplett bild av sammanhanget. Varje nobelpris är resultaten av en eller flera forskares hängivna arbete under många år, till viss del synligjort genom artiklar i journaler och andra former av publikationer. Men mycket av denna berikande information finns också tillgänglig i andra datakällor. Startpunkten för arbetet med länkade nobelpris är alltså observationen att dessa datakällor, åtminstone de som är öppet tillgängliga, har potentialen att komplettera den information som nobelprize.org själv underhåller.

Målsättningar

Under 2013 initierades ett projekt att skapa länkade nobelpris där de viktigaste målsättningarna var:

1. Berika webbplatsen med information från andra källor
2. Kvalitetsäkra den egna informationen
3. Ge andra tillgång till den underliggande informationen som förvaltas av nobelprize.org

Arbete och resultat av att införa länkade nobelpris

Ett nödvändigt första steg var att skapa länkade data-uttryck kring nobelprisen. Arbetsinsatsen blev relativt okomplicerad på grund av att den existerande databasen var välorganiserad. Som en del av arbetet identifierades lämpliga vokabulärer som kunde återanvändas. Det slutliga valet blev en kombination av DCTerms, FOAF och DBpedia ontology samt en komplementär vokabulär som utvecklades specifikt för länkade nobelpris. I denna process upptäcktes några smärre kvalitetsbrister i den existerande databasen som dock lätt kunde åtgärdas. Ett trevligt resultat är att utöver det existerande databasschemat finns nu också en väldokumenterad informationsmodell för nobelprize.org. Med andra ord, målsättningarna 2 och 3 uppnåddes med detta arbete.

I nästa steg skapades relationer (länkar) till andra datakällor. Ett semi-automatiskt angreppssätt valdes vilket innebar att en mindre mängd relationer skapades med automatik (några hundra) som därefter manuellt veriferades som korrekta. Dessa relationer var viktiga i sig men gav också effekten att nya relationer kunde etableras automatiskt genom att ställa frågor via SPARQL mot de datakällor som det redan fanns länkar till. Effekten av detta är att de flesta nobelpristagare idag har relationer till DBpedia, Freebase, OpenLibrary, Yago, VIAF och Umbel. Därtill finns ett pågående arbete med att förbinda nobelpristagarna med publikationer via LinkedLifeData och Bio2RDF som kommer ta lite mer tid att få komplett.

I ett tredje steg berikades webbsidor på nobelprize.org med sektioner som visade upp information om nobelpristagare från andra datakällor. Exakt vilken information som valdes att visas upp på sidorna var ett redaktionellt beslut som fattades baserat på relevans, täckning (hur ofta information fanns uttryckt) samt informationskvalitet (hur bra de faktiska värdena var). För att nå den tillförlitlighet som behövs för nobelprize.org användes ett länkade data cache. På det sättet behövde man inte längre ta hänsyn till den variation i tillförlitlighet som de andra datakällorna uppvisade.

I ett sista steg lades en länkade data browser till som ett komplement till de vanliga webbsidorna. Syftet med detta var att ge de besökare som är intresserade att gräva vidare i länkade nobelpris och relaterad information ett verktyg som inte begränsas av det redaktionella urvalet.

Resultatet av de två sista stegen innebar att den första målsättningen uppfylldes.

Fiktivt scenario: Samarbete för krisberedskap

I en krissituation är det viktigt att ha tillgång till så mycket relevant information som möjligt. Det kan innefatta information om geografi, miljö, skyddsområden, brandskydd, sjukvård, fastigheter, demografi, beredskap, vatten och framförallt vad som är status kring olika insatser i den aktuella situationen.

Det innebär att en mängd olika organisationer måste dela med sig av information som de förvaltar. Det kan innefatta kommuner, landsting, Lantmäteriet, Naturvårdsverket, Sjöfartsverket, vattenmyndigheterna, Samhällets alarmeringstjänst, Myndigheten för samhällskydd och beredskap, Civilförsvaret och naturligtvis det svenska försvaret. Listan går att göra längre och varierar beroende på situation.

Krav på IT-system

För att IT-system som är inblandade i informationsförsöjning i krissituationer ska kunna vara effektiva finns en mängd saker att tänka på, tre av de viktigaste är:

1. IT-lösningar bör vara pålitliga även när de belastas hårt av olika parter, t.ex. får man betänka att såväl experter, media samt intresserade och drabbade medborgare söker information samtidigt.
2. Informationen bör vara tillgänglig på ett ställe. Det är inte lämpligt att kräva av människor i en krissituation att de ska behöva gå in i flera olika system för att få ut den information de behöver då det är både tidsödande och skapar felskällor.
3. Informationen kring ting man vill ha information kring, t.ex. platser, fastigheter, organisationer, insatser osv. bör vara sammanställd, inte utspridd i många dokument, tabeller eller andra dataformat som minskar överskådligheten.

Varför länkade data är en bra lösning

Det är enkelt att se hur kraven ovan löses naturligt med länkade data:

1. Länkade data bygger i grunden på webbens arkitektur. Detta innebär att det finns väl beprövade lösningar för att hantera skalbarhet och redundans. (*)
2. Länkade data innebär att man använder ett enhetligt format för data. Detta gör att man utan problem kan samla ihop (cacha) data från olika källor i samma databas. Nya datakällor kan inkluderas vid behov utan att någon vidare utveckling behövs.
3. En av huvudpoängerna med länkade data är just att man länkar samman information. Information som är sammanlänkad är en bra grund för att skapa olika sammanställningar då det går att upptäcka vilka benämningar på ting som är samma, snarlika eller hör ihop på något sätt.

(*) Principerna bakom webbens arkitektur, som kallas REST, medför bland annat att det finns standardiserade sätt att cacha data. Detta ska jämföras med tjänstebaserade arkitekturer (SOA), som innebär att man introducerar flaskhalsar och en ökad komplexitet, och som innebär att det är betydligt svårare att hantera skalbarhet och redundans.

Varför just länkade data är en bra lösning för att kunna sammanställa information från olika källor är en intressant frågeställning som utvecklas nedan.

Länkade data är bra på att hantera en stor mängd olika och oväntade sammanställningar

Om man vet i förväg vilka typ av kris som man förväntar sig kan man i lugn och ro inventera vilken information som behövs. Sedan får man se till att automatisera processen att hämta, formatera om, matcha identifierare, översätta relevanta vokabulärer och slutligen kombinera informationen på det sätt som efterfrågas. Man kan se det som att varje sammanställning av information blir en ny och separat vy över informationen.

Det finns dock tre huvudsakliga problem med detta angreppsätt:

1. Om mängden av olika potentiella kriser är stor så kan det innebära mycket jobb.
2. Potentiellt kan det vara problematiskt att matcha information mellan olika datakällor. Detta gäller särskilt om ingen har gjort en ansats att harmonisera datauttrycken, t.ex. så kan vokabulärer vara inkompatibla vilket i värsta fall kan kräva manuell hantering.
3. Förändringar i hur informationen uttrycks hos en eller flera datakällor kan kräva att mycket av nedlagt arbete behöver ses över eller göras om.

Med länkade data börjar man i någon mening i andra änden. Man fokuserar på informationen i sig och försöker se hur man kan få den att hänga ihop mellan organisationer. Det innebär att varje organisation bör se på sin information som en del i ett större pussel (en webb av data). Varje potentiell sammanställning av information bör därmed motsvaras av en kombination av ett eller flera faktiska samband mellan existerande informationbitar. Om en sammanställning av någon anledning inte går att genomföra utifrån en mängd länkade data beror det antingen på att nödvändig information faktiskt saknas, att någon inte har skapat länkar eller återanvänt vokabulärer som man ska när man definierar sina länkade data-uttryck.

Vanliga frågor

1. Hur förhåller sig RDF till XML?
2. Vad är för- och nackdelar med RDF kontra XML?
3. Hur förhåller sig RDF till CSV?
4. Vilken förvaltningsbörda medför RDF och länkade data?
5. Hur konverterbar är RDF?
6. Vilka är de viktigaste skillnaderna mellan RDF och en relationsdatabas? Nackdelar? Fördelar? Kostnader?
7. Hur hanterar man data som kräver licens för åtkomst?
8. Men våra data är inte av tillräckligt bra kvalitet, kan vi släppa ut dem i det tillstånd de är nu?
9. Tappar vi inte kvalitetskontroll med länkar?
10. Ska vi samla ihop länkade data eller lämna i källan?
11. Hur integrerar man bäst med en CMS?

Hur förhåller sig RDF till XML?

XML är ett flexibelt dataformat som klarar av att uttrycka i stort sett vad som helst. Man kan jämföra XML med linjerat papper, det ger ett visst stöd och förenklar maskinell hantering i jämförelse med att skriva direkt på olinjerat papper. XML används idag för att representera allt från böcker till affärstransaktioner.

RDF å andra sidan är en datamodell som används för att uttrycka påståenden om ting. RDF kan uttryckas med hjälp av XML, som JSON, eller något annat format (en del format är skapade från grunden för att passa RDF istället för att utgå från XML eller andra "linjerade papper"). Det finns dock en likhet mellan RDF och XML som kan vara förvirrande. Båda språken är designade för att kunna hantera vilken information som helst. Skillnaden är att RDF kommer med en minimal informationsmodell (grammatik) och en semantik (tolkning) som ger stöd för att uttrycka information på ett enhetligt sätt. I RDF handlar allt om påståenden om ting och relationer mellan ting på ett sätt som bäst beskrivs som en graf av noder och typade bågar mellan noder. I XML är grunden istället en hierarki av data, men det finns ingen semantik (tolkning) av vad det innebär att ordna data i en sådan hierarki.

Vad är för- och nackdelar med RDF kontra XML?

Vi tänker oss att vi ska uttrycka en ny mängd information, t.ex. information om personbilar och vem de är registrerade på. Vi jämför det normala sättet att uttrycka detta i RDF med det naturliga sättet i XML. I XML är det naturliga att skapa ett nytt XML uttryck som är specifikt för denna informationsmängd. (Notera att det alltså inte är RDFs eget XML uttryck vi jämför med då detta inte är en motsättning.) Om det finns ett etablerat XML uttryck för att beskriva just personbilar och vem de är registrerade på så har vi tur och kan återanvända detta uttryck direkt. Tyvärr är återanvändning av XML uttryck mellan olika situationer inte bara ovanligt utan också ofta ganska svårt. Den huvudsakliga orsaken har att göra med att det är vanligt med behov av olika anpassningar i förhållande till vad som formatet ursprungligen var avsett för. I detta fall skulle det kunna vara att man vill använda personnummer istället för den amerikanska motsvarigheten (socials security number) vilket riskerar att validering och existerande mjukvara inte fungerar som tänkt längre.

När vi istället uttrycker informationsmängden i RDF behöver vi inte hitta en perfekt matchning, istället kan vi leta efter relevanta vokabulärer som kan användas för att uttrycka delar av informationen. Den vanliga situationen som man ofta hamnar i är att man kan kombinera existerande vokabulär med en del egna vokabulär. I detta fall kan man använda FOAF vokabulären (Friend Of A Friend) för att uttrycka personer, COO vokabulären (Car Options Ontology) för att uttrycka information om bilar och kombinera med egen vokabulär kring personnummer och hur man kopplar samman en bil med den person den är registrerad på.

Sättet man återanvänder och kombinerar vokabulärer gör att RDF har flera fördelar jämfört med XML. Det finns ett stort utbud av specialiserade vokabulärer att välja på. Betydelsen av vokabulärer är ofta noggrant beskrivna då man vill att de ska vara förståeliga utanför den kontext där de ursprungligen skapades. Återanvändning av vokabulärer gör att delar av informationen som uttrycks ofta kan förstås utanför den kontext där den definierades enbart på grund av att man redan har kunskap om en del av de vokabulärer som används.

Hur förhåller sig RDF till CSV?

CSV är ett format för att hantera tabulär information. Dvs. om den data man har kan beskrivas i en enskild tabell kan det passa att använda CSV, annars är CSV troligen ett olämpligt val.

Även för tabulär information kan CSV vara olämpligt om man har behov av att tydligt dokumentera sitt format på ett maskinläsligt sätt. RDF klarar naturligtvis av att hantera tabulär information precis som CSV, dock innebär det ett lite större arbete med att etablera vilka vokabulärer man ska använda. Dvs. att det tar lite mer tid att komma fram till hur varje kolumn ska uttryckas. Att lägga ner denna tid kan samtidigt vara väl investerad tid om den leder till bättre dokumenterade datauttryck och en bättre förståelse för datan i andra sammanhang.

Vilken förvaltningsbörda medför RDF och länkade data?

Drift av IT system som hanterar RDF skiljer sig inte nämnvärt från andra IT system. Om man driftsätter inom den egna organisationen är det förstås viktigt med kunnig personal, framförallt generella kunskaper om webbarkitektur är viktiga. Om man istället förlitar sig på molntjänster blir förvaltningsbördan och behovet av intern kompetens kring drift betydligt mindre.

När det gäller uppdatering av informationsmodellen har RDF-baserade system en klar fördel över mer traditionella lösningar (t.ex. relationsdatabaser) då de inte har ett fixt schema. Dvs. att de kräver ingen omprogrammering för att anpassa sig till en förändrad informationsmodell, dock kan gammal data behöva transformeras för att fortfarande vara aktuell (det standardiserade frågespråket SPARQL är lämpligt att använda till detta).

Det är värt att notera att användning av RDF har potentialen att förenkla samarbetet mellan verksamheten och de som är ansvariga för systemförvaltningen (som förespråkas av vissa modeller eller perspektiv inom systemförvaltning, t.ex. Pm³ och Agil systemutveckling). Orsaken till ett sådant förenklat samarbete är att informationsmodellen både är enklare att ändra (som noterades ovan) och att den kan lagras som den är. Dvs. de som förvaltar systemet måste inte lägga energi på att översätta informationsmodellen till en annan representation internt för att kunna lagra informationen (t.ex. översätta till olika tabeller i en relationsdatabas).

RDF och länkade öppna data lösningar är per definition tillgängliga då man kan få ut beskrivningar av alla entiteter på separata webbadresser, ofta i flera olika format. Det innebär tyvärr inte med automatik att t.ex. webbapplikationer som byggs ovanpå ett länkade data lager är mer användarvängliga eller bättre följer principer för tillgänglighet som t.ex. W3C WAI. Det är dock en bra grund för att spränga in mer information i ett gränsnitt än det som syns vilket kan fångas upp av både sökmotorer och olika hjälpande teknologier.

Hur konverterbar är RDF?

Först låt oss konstatera att då RDF är en datamodell har det flera uttryck och format, till exempel kan man uttrycka RDF i XML, i JSON-LD och inbäddat i HTML som RDFa. Att översätta mellan dessa är enkelt och stöds av nästan alla RDF bibliotek idag. En mer intressant frågeställning är hur enkelt det är att konvertera från ett RDF uttryck till något annat format som inte har något alls att göra med RDF. Som alltid med RDF är svaret att det beror på vilken information man har uttryckt i RDF. Om man uttryckt information om personer i RDF kan man med fördel översätta till vCard, om det handlar om vokabulärer kan kanske Claml vara lämpligt. Det finns dock ingen allmän mekanism för att göra dessa konverteringar utan det måste utvecklas för varje situation. Det är också värt att notera att om RDF vokabulären inte är helt kompatibel med målformatet så är det högst sannolikt att viss information går förlorad i samband med konverteringen. Brist på stringens i definitionen av semantiken för målformatet är en vanlig orsak till att konverteringar kan vara svåra att skriva på ett sätt som inte är beroende av sammanhanget. Ofta finns det dock ramverk som man kan använda för att bygga konverteringen på, t.ex. för tabulär data kan man använda OpenRefine eller TARQL, för relationsdatabaser kan man använda D2R osv. W3C har upprättat en rekommendation för R2RML, ett standardiserat språk för att mappa data i befintliga relationsdatabaser till en RDF graf; språket stöds t.ex. av det ovannämnda D2R.

Vilka är de viktigaste skillnaderna mellan RDF och en relationsdatabas? Nackdelar? Fördelar? Kostnader? Utbyggbarhet vid stora informationmängder?

En traditionell relationsdatabas kräver att man etablerar ett databasschema som definierar vilka tabeller, kolumner och relationer mellan dessa som ska finnas. Detta fungerar väl när datan man hanterar är relativt uniform och den underliggande informationsmodellen inte ändras alltför ofta. En naturlig konsekvens är att relationsdatabaser inte kan hantera nya data som det inte har explicit förberetts för. En databaslösning som inte kräver ett fördefinierat databaschema är mer flexibel, men kan samtidigt blir mer svåröverskådlig.

De flesta RDF databaser fungerar utan schema och kan därmed hantera vilken information som helst så länge den kan uttryckas som påståenden om resurser identifierade med URI:er, dvs. så länge man följer RDFs abstrakta syntax.

Hur hanterar man data som kräver licens för åtkomst?

Det är först viktigt att notera att frågeställningen om hur man kan använda källor vid publicering av länkade öppna data är att jämställa med annan form av webbpublicering. I huvudsak finns tre möjliga lösningar att prövas i ordning kring källor som har specifika restriktiva licenser.

1. Noga undersöka vad licensen säger, troligtvis är det möjligt att publicera delar av en källa i anslutning till att den används. Eventuellt kan man komma undan genom att inte tillåta renodlad sökning eller bulk nedladdning av källan utan bara indirekt åtkomst till delar.
2. Begränsa åtkomst till vissa källor som länkade data baserat på vem som är användaren.
3. Rekommendera byta till en annan datakälla.

Men våra data är inte av tillräckligt bra kvalitet, kan vi släppa ut dem i det tillstånd de är nu?

Det kan finnas hinder på grund av lagar och regleringar som måste beaktas, till exempel personuppgiftslagen (PUL) och copyrightskydd, läs mer om detta på e-delegationens vägledning kring vidareutnyttjande av information. Ur ett kvalitetsperspektiv är det svårare att säga något generellt, men ofta är det bättre att komma igång med att släppa en del data och få återkoppling från andra än att på egen kammare försöka förutse alla problem. Med andra ord, ett iterativt arbetsätt är ofta att föredra även för publicering av länkade data.

Notera: att göra sina data tillgängliga som länkade data innebär inte med automatik att de måste vara öppet tillgängliga.

Tappar vi inte kvalitetskontroll med länkar?

Det är naturligt att kvaliteten varierar mellan datakällor då ansvariga organisationer lägger olika stor vikt vid sina data. Dessutom är det stor skillnad mellan datakällor som skapas på frivillig basis (t.ex. crowdsourcing) och de som ges ut av organisationer med avlönade experter.

Brist på kvalitet kan yttra sig både genom att datakällor periodvis är otillgängliga eller på brist i konsekvens i vilka påståenden som är uttryckta per ting. Periodvis otillgängliga datakällor går att kompensera för genom smart cachning, men brist på konsekvens är svårare.

En uppenbar lösning är helt enkelt att låta bli att länka till datakällor med för dålig kvalitet. Ett annat mer tilltalande alternativ är att välja att länka med relationer som är medvetet lösare i sin karaktär, t.ex. rdfs:seeAlso istället för owl:sameAs som får mer långtgående konsekvenser i form av maskinell bearbetning. Det är också stor skillnad mellan att länka till ting i andras datakällor och att återanvända klasser, egenskaper eller begrepp vilket i allmänhet ställer högre krav på kvalitet.

Ska vi samla ihop länkade data eller lämna i källan?

Att duplicera information ska i största allmänhet undvikas, men ibland är det nödvändigt för att uppnå god användbarhet i de tjänster eller applikationer som bygger på denna information. Datakällor kan ibland vara offline eller ha dålig prestanda och ibland vill man själv ha kontroll över tillgängligheten. Kan en applikation inte byggas så att den klarar av att fungera med otillgängliga datakällor, så kan det vara angeläget att duplicera data i sin egen infrastruktur med regelbundna uppdateringar. Detta förutsätter att det är tekniskt hållbart (dvs. datamängden går att hantera), samt att datakällans licensebestämmelser tillåter en sådan användning.

Caching servern LDCache har utvecklats av MetaSolutions för att hämta in och cacha viktiga länkade (öppna) data. Detta ger bättre kontroll över en datakällas prestanda och tillgänglighet. LDCache är ett Open Source projekt.

Hur integrerar man bäst med en CMS?

Det finns flera olika sätt att integrera länkade data i en CMS. En möjlighet är att låta CMS plattformen prata direkt med LD plattformen, t.ex. via specifika API:er eller direkt på databas nivån. Men i många fall kan en sådan integration vara krånglig, särskilt om plattformarna är skrivna i olika programmeringsspråk. Ett bättre alternativ är att utnyttja att länkade data i sig är ett slags API som exponeras över HTTP.

Idag erbjuder de flesta stora CMS:er ett kontrollerat sätt att utöka sin funktionalitet, typiskt genom att utveckla pluginner eller moduler. Beroende på CMS:en kan sådan ny funktionaltet införas enbart på serversidan eller också via javascript i browsern. Båda alternativen fungerar väl med integration med länkade data, gärna via färdiga bibliotek som hanterar parsning och bearbetning av länkade data uttryck.

Ibland kan också länkade data plattformar erbjuda färdiga gränssnittskomponenter, t.ex. för att lista, söka eller presentera enskilda resurser. Det är möjligt att sådana komponenter kan inkorporeras med en mindre insats (fixa enhetligt utseende via teman eller ren css) på samma sätt som man bäddar in t.ex. youtube klipp.

Vi summerar de olika integrationsmöjligheterna (där alla med fördel genomförs via någon form av plugin eller modul i respektive CMS):

1. CMS backend pratar med LD backend - ofta krångligt, undvik
2. CMS backend hämtar LD över HTTP - fungerar alltid
3. CMS frontend hämtar LD över HTTP - fungerar alltid
4. CMS frontend bäddar in färdiga LD frontend komponenter - bara om stöd finns i LD plattformen

Relaterad information

Allmänt om öppna data i Sverige

Sedan PSI-lagen antogs i Sverige till följd av motsvarande EU-direktiv har utvecklingen mot öppna data i Sverige accelererat. Nedan listar kort några relevanta initiativ som bidragit till utvecklingen sedan dess.

Öppnadata.se - nationell portal

Sedan slutet på 2012 finns enligt ett regeringsuppdrag en nationell portal för öppna data i Sverige. Portalen är att betrakta som en katalog med beskrivningar av olika dataset i Sverige som är tillgängliga för vidareanvändning. Under 2014/2015 kommer portalen att gå över till att skörda dataset beskrivningar i enlighet med standarden DCAT, mer specifikt en svensk variant av den europeiska profilen DCAT-AP. Portalen har inga krav på att öppna data ska publiceras på ett speciellt sätt, t.ex. som länkade data, däremot är DCAT en standard som bygger på principerna bakom länkade data. Det vill säga, dataset beskrivningar ska ske med hjälp av RDF där vissa i förväg specificerade vokabulärer är påbjudna.

Som en del i processen att följa PSI-lagen, se nedan, förväntas offentliga aktörer allteftersom öppna upp sina data och beskriva dessa så att de blir sökbara från öppnadata.se.

E-delegationens vägledning för vidareutnyttjande

E-delegationen har tagit fram en vägledning för vidareutnyttjande av offentlig information, som bygger på en checklista för att komma igång med att skapa och publicera öppna data. Vägledningen innehåller även rekommendationer för hur en myndighet kan göra information tillgänglig på olika sätt.

SKL:s ramverk för öppna data

SKL jobbar med att ta fram ett nationellt ramverk för öppna data som ska hjälpa kommuner och landsting i deras kontinuerliga arbete med öppna data.

PSI-lagen

Lag (2010:566) om vidareutnyttjande av handlingar från den offentliga förvaltningen (PSI-lagen) är en grundpelare för arbetet med att tillgängliggöra offentlig information.

Länkade data i Sverige

Konferenser och meetups

Konferensserien Länkade data i Sverige med meetup-karaktär har sedan 2012 anordnats varje år för att främja erfarenhetsutbytet kring aktiviteter med fokus på länkade data.

Agendor och presentationer av tidigare konferenser är tillgängliga via följande länkar:

• 2012 Stockholm
• 2013 Linköping
• 2014 Malmö

Inom Linked Data in Business anordnas oregelbundna meetups i Malmö.

Facebook-grupp "Semantiska webben i Sverige"

Den svenska Facebook-gruppen Semantiska webben i Sverige är en knutpunkt för intresserade personer som diskuterar och utbyter erfarenheter kring länkade data och den semantiska webben.

Projekt "Kompetensförstärkning kring länkade öppna data - dialog, webbinarier och vitbok"

Projektet Kompetensförstärkning kring länkade öppna data ligger bakom denna vitbok. Förutom att ta fram vitboken anordnade projektet även webbinarier med svenska aktörer som berättar hur de använder länkade data i sin organisation.

Alla webbinarier är inspelade och tillgängliga via följande länkar:

• Webbinarium Länkade data i läkemedelsforskningen
• Webbinarium Riksantikvarieämbetets erfarenheter kring länkade öppna data
• Webbinarium Kungliga bibliotekets arbete med länkade data
• Webbinarium Länkade nobelpris – att producera och konsumera länkade öppna data

Projekt "Länkade öppna data i Sverige - Portal och nationell statistik"

Det VINNOVA-finansierade projektet Länkade öppna data i Sverige - Portal och nationell statistik har tagit fram informationsmaterial kring länkade data och publicerat i form av en portal.

Länkade data internationellt

Linked Data: Evolving the Web into a Global Data Space

Boken Linked Data: Evolving the Web into a Global Data Space ger en ganska komplett introduktion till länkade data, samt behandlar designmönster och en rad recept för att publicera och konsumera länkade data.

Originalbeskrivning: "This book gives an overview of the principles of Linked Data as well as the Web of Data that has emerged through the application of these principles. The book discusses patterns for publishing Linked Data, describes deployed Linked Data applications and examines their architecture."

Linked Open Data: The Essentials. A Quick Start Guide for Decision Makers

Boken Linked Open Data: The Essentials ger en introduktion till länkade data utan att prata för mycket om teknik. Målgrupp är beslutsfattare.

Linked Data Patterns - A pattern catalogue for modelling, publishing, and consuming Linked Data

Boken Linked Data Patterns ät ett uppslagsverk med mönster för att modellera, publicera och konsumera länkade data.

Linked Data - Design Issues

Tim Berners-Lees samlade tankar kring Linked Data som design issue av webb arkitektur. Ett av de första dokumenten som beskriver idén bakom länkade data.

• http://www.w3.org/DesignIssues/LinkedData.html