Linked Data

GeoTest 2013
Förstudie Linked Data
Linked Data
Rapport upprättad 2013-12-04
Författare:
Viktor Högberg – [email protected]
Prof. em. Anders Östman – [email protected]
1 Innehållsförteckning
1
2
3
4
5
6
7
Introduktion ............................................................................................................................. 3
1.1 Om GeoTest-projektet ....................................................................................................... 3
1.2 Länka relaterad data .......................................................................................................... 3
1.3 Länkade Data ..................................................................................................................... 3
Metod ....................................................................................................................................... 4
2.1 Lantmäteriets fastighetsregister ....................................................................................... 4
2.2 Myndigheten för samhällsskydd och beredskap (MSB) .................................................... 5
2.3 Länkade Data principer...................................................................................................... 5
2.4 Programvaror..................................................................................................................... 6
2.5 Analys och strukturering av källdata (MSB, LM) ............................................................... 6
2.6 Identifiera möjliga identifierare för källdata ..................................................................... 7
2.7 Transformation från befintlig datastruktur till RDF........................................................... 7
2.8 Matchning av datakällor .................................................................................................... 8
2.9 Testa frågeställningar mot den hoplänkade datamängden (SPARQL) .............................. 9
Resultat..................................................................................................................................... 9
Diskussion ............................................................................................................................... 12
Slutsatser och rekommendationer......................................................................................... 12
5.1 Hur kan standarder inom semantisk webb-teknik underlätta och förenkla hanteringen
av data och information? - Vad är fördelarna? .......................................................................... 13
5.2 Hur mycket går att matcha mellan dessa datakällor på automatiserad väg? ................. 14
5.3 Vilka problem och svårigheter uppstår, både tekniska och datarelaterade? ................. 14
Referenser .............................................................................................................................. 16
Bilaga A - Metod ..................................................................................................................... 17
2
1 Introduktion
1.1
Om GeoTest-projektet
Målet med GeoTest-projektet är att utveckla testtjänster inom geodataområdet, framför allt
relaterade till utvecklingen av den svenska SDI:n (Spatial Data Infrastructure).
GeoTest är en gemensam satsning i samverkan mellan Lantmäteriet, Högskolan i Gävle och
Future Position X (FPX), och bidrar till en kvalitetssäkrad infrastruktur för geodata.
1.2
Länka relaterad data
Syftet med denna förstudie är att identifiera problem som kan uppkomma när man länkar ihop
data från olika myndigheter. Som pilotfall länkas data om skolbränder från Insatsregistret
(Myndigheten för samhällsskydd och beredskap, MSB) med fastighetsregistret från
Lantmäteriet.
MSB har uppdrag från regeringen att kommunicera och analysera allvarliga händelser och
olyckor till andra myndigheter och organisationer. Via räddningstjänsten får man vid varje
händelse en position som lagras i insatsregistret. För analys och informationsspridning till andra
behövs mer information om händelsen. Genom att länka denna information med andra externa
databaser vill man förbättra de efterföljande analyserna av insatserna och mer effektivt utnyttja
den ökade informationsmängden.
Förstudien skall primärt ge svar på följande frågor:




1.3
Hur kan standarder inom semantisk webb-teknik underlätta och förenkla hanteringen av
data och information?
Hur mycket går att matcha mellan dessa datakällor på automatiserad väg?
Vilka problem och svårigheter uppstår, både tekniska och datarelaterade?
Vad är fördelarna med att använda sig av Länkade Data?
Länkade Data
Länkade Data, eller Linked Data, är ett koncept för att koppla ihop dokument och data från
exempelvis olika organisationer. Detta för oss närmare den semantiska webben, som för
närvarande utvecklas i full fart när allt fler publicerar sina data efter riktlinjerna för Länkade
Data.
3
En av riktlinjerna för länkade data är att använda standarder som RDF (Resource Description
Framework) för att publicera och länka sina data. RDF är en datamodell baserad på tripletter
och den är en av grunderna för den semantiska webben. Med RDF blir det flexibelt att beskriva
företeelser exempelvis människor, platser och abstrakta koncept – och hur dessa relaterar till
andra företeelser. RDF knyter ihop data och semantik, vilket medför att informationen är både
läsbar för människor och att den automatiskt kan läsas av maskiner. Med enkla frågor kan data
som finns i flera RDF-databaser på webben sammanställas som om allt fanns på samma ställe.
Detta leder till att stora mängder av data får ett högre värde. Standardiserad semantik bedöms
ha goda möjligheter till smartare lösningar, program och visualiseringar.
2 Metod
Utförandet av denna studie har gjorts i sex steg.
2.3 Analys och strukturering av källdata (MSB och LM)
Försöka få en bild av hur dessa data är beskrivet, strukturerat och dess betydelse.
2.4 Identifiera möjliga identifierare för källdata
Att se vilka av attributen passar som en unik identifierare för respektive objekt.
2.5 Transformation från befintlig datastruktur till RDF
Skapande av tripletter från källdata samt skapa en universell identifierare (URI) av
objektens identifierare. Val av programvara för att utföra förstudien
2.6 Matchning mellan dessa datakällor
Automatiserad matchning av strängar i Google Refine.
2.7 Testa frågeställningar mot den hoplänkade datamängden (SPARQL)
Testa frågeställningar mot SPARQL-endpoint samt traversera länkarna mellan data med
RDF browsers.
Metoden beskrivs i sin helhet i bilaga A.
2.1
Lantmäteriets fastighetsregister
Fastighetsregistret är Sveriges officiella register över hur marken i vårt land är indelad, dess
ägarförhållanden etc. Registret innehåller även information om adresser, byggnader och
fastighetstaxering. Den typ av information som användes i denna studie var ett så kallat
standarduttag från detta register. Det var fem filer, ALTNAMN_52B, ADRPL_90A, KOORD,09A,
REGBYG_50A samt REGENH_01A. Dessa filer innehåller information om adresser, koordinater,
byggnaden samt den mark där byggnaden står.
4
2.2
Myndigheten för samhällsskydd och beredskap (MSB)
Skolbränder uppskattas kosta samhället minst 300 miljoner kronor varje år. Hälften av alla
skolbränder är anlagda och det sker idag ungefär en anlagd skolbrand om dagen i Sverige. I
MSB’s insatsregister finns information som adress, byggnadstyp, namn, fastighetsbeteckning, tid
för olyckan, koordinater, referenssystem, orsak, orsaksförlopp och eventuell skada med mera.
2.3
Länkade Data principer
Länkad Data är ett sätt att publicera och länka strukturerad data på webben. Tim Berners-Lee
tog fram dessa principer och de kallas nu ’Linked Data principles’. Principerna är: (översatt till
svenska)
1. Använda URI:er1 (Uniform Resource Identifier) som namn för ting. (personer, saker,
abstrakta koncept, relationer m.m.)
2. Använda HTTP URI:er, så att man kan referera till dessa namn.
3. När någon refererar till en URI, tillhandahåll användbar information, genom att använda
standarder (RDF, SPARQL).
4. Inkludera länkar till andras URI:er, så man kan upptäcka mer saker.
Matt B
subjekt
knows
predikat
Scott M
objekt
Figur 1. URI:er används för att identifiera människor och relationerna mellan dem. Exempel från www.linkeddatabook.com
http://biglynx.co.uk/people/matt-b ___________________ http://exampl.com/people/scott-m
http://xmlns.com/foaf/0.1/knows
Länkarna ovan visar ett exempel på en triplett i RDF. Två personer är identifierade med unika
URI:er och de känner varandra via predikatet (relationen) knows, som också har en unik URI.1
Flera tripletter bildar en graf.
1
En Uniform Resource Identifier är en dataprogrammeringsterm. Den består av en sträng av tecken som används för att
identifiera eller namnge en resurs. Den huvudsakliga orsaken för denna identifiering är att ge möjlighet att med särskilda
protokoll referera till resursen över ett nätverk, typiskt World Wide Web
http://sv.wikipedia.org/wiki/Uniform_Resource_Identifier
5
2.4
Programvaror
Följande programvaror användes i studien.




2.5
Google Refine (numera Open Refine)
Fuseki SPARQL 1.1 Server
Tabulator till Firefox (RDF-data browser)
BrownSauce (RDF-data browser)
Analys och strukturering av källdata (MSB, LM)
Data från såväl Lantmäteriet som MSB levererades i CSV-format. Första steget var således att
konvertera dessa data till RDF. Detta gjordes i verktyget Google Refine.
Entiteterna i Lantmäteriets filer hade en struktur med 1:M-relationer (en till många) med
varandra. Detta betyder att en sådan relation inte går att skapa med endast en triplett, utan
flera tripletter måste skapas, en för varje fil. Därför blev det först nödvändigt att försöka länka
ihop LMs data till en egen graf. LMs filer är hoplänkade via identifierarna Fastighetsnyckel samt
Riksnyckel. Vissa filer är ihopkopplade av Riksnyckeln och vissa med Fastighetsnyckeln.
URI = http://www.geotest.se/ALTNAMN_52B.rdf#UUID
URI = http://www.geotest.se/REGBYG_50A.rdf#UUID
REGBYG_50A
Riksnyckelid
Fastighetsnyckel
Byggnadsstatus
..
ALTNAMN_52B
Riksnyckelid
Namn
..
URI = http://www.geotest.se/REGENH_01A.rdf#UUID
REGENH_01A
Fastighetsnyckel
Tomträtt
Status
..
KOORD_09A
Fastighetsnyckel
Lon, Lat
..
ADRPL_90A
Riksnyckelid
Fastighetsnyckel
Adress
..
URI = http://www.geotest.se/ADRPL_90A.rdf
URI = http://www.geotest.se/KOORD_09A.rdf#UUID
Figur 2. Lantmäteriets data med deras interna struktur. Varje skolas identifierare, Universally Unique Identifier
(UUID) gjordes om till HTTP URI:er enligt principerna för Länkad Data.
För data från MSB’s har det unika rapportnumret använts som URI. Deras struktur är uppbyggd
där en rapport innehåller en viss mängd attribut och data. Denna struktur är praktisk i detta fall,
eftersom övergången till RDF och tripletter då blir mer naturlig. Se figur 3 för MSB’s strukturerat
i RDF.
6
Figur 3. Google Refine RDF-skelett för MSBs datastruktur. Här läggs relationer in mellan rapportnummret och dess attribut, ex.
rapportnummer har name objektsnamn (skolnamn). Foaf står för Friend of a Friend och är ett vokabulär som skapades för att
maskiner skall förstå vad relationer mellan personer och objekt betyder. Foaf:name är också beskriven i RDF i triplettstruktur.
2.6
Identifiera möjliga identifierare för källdata
De identifierare som MSB använder internt är rapportsnummer. En identifierare som görs om
till en URI skall vara unik. Lantmäteriets struktur av identifierare är något mer komplex. Deras
interna id-struktur bygger på att flera olika unika identifierare används i fler filer, se Figur 2. Här
ser vi att ALTNAMN inte har någon koppling till REGENH och KOORD. En REGENH kan dock ha
flera REGBYG och en REGBYG kan ha flera ADRPL. Detta betyder att en enhet som byggnader
står på kan ha flera adresser beroende på storlek. Den kan även ha flera byggnader. Detta visas i
RDF-browsern BrownSauce i Figur 7.
2.7
Transformation från befintlig datastruktur till RDF
Olika arbetsflöden kan användas för transformation av data till RDF-form, I denna studie var
båda parters data statiska textfiler i filformatet CSV. Eftersom denna transformation skall vara
så automatisk som möjligt användes det högra arbetsflödet i Figur 4. Det verktyg som användes
i denna studie var Google Refine. Detta program stödjer bland annat transformation från XML
eller CSV till RDF. Innan transformationen görs måste ett RDF-skelett skapas manuellt som
specificerar den RDF-struktur som transformationen skall skapa. Här väljer man även vilka
predikat (relationer) olika subjekt/objekt skall ha och vilka vokabulär dessa relationer beskrivs
av. När man publicerar länkade data bör man så mycket som möjligt återanvända befintliga
7
vokabulärer. I denna studie har befintliga vokabulärer används som finns tillgängliga på nätet.
Verktyget Google Refine erbjuder även funktioner för automatiserad matchning (reconicle) och
den kan också användas för text/datahantering.
Figur 4: Linked Data Publishing Options and Workflows. [1]
2.8
Matchning av datakällor
Målet med att matcha två datakällor med varandra är att skapa en länk mellan två URI:er i
respektive datamängd. Detta skapar en brygga mellan datamängderna och man kan traversera
mellan dessa data. För att matcha en fil mot en befintlig datamängd måste datamängden finnas
som en SPARQL-endpoint. SPARQL är ett frågespråk för RDF-databaser. En SPARQL-endpoint
identifieras med en URI som innehåller en stor graf av alla tripletter man valt att lägga in från sin
informationskälla. Tripletterna är baserade på en grafstruktur och en SPARQL-endpoint kan
således beskrivas som en stor graf många tripletter. Mot denna endpoint kan man ställa
SPARQL-frågor som hämtar ut det data man söker. I denna studie lades Lantmäteriets data upp i
en endpoint. Detta gjordes på en maskin med Ubuntu 12.10 med programvaran Fuseki SPARQL
1.1 Server. Dess URL anges sedan i Google Refine vid matchningen och länkningen. När
endpointen är tillgänglig i Refine kan matchningen från kolumnerna i MSB’S data börja matchas
mot LM’s endpoint. I denna process finns möjligheten att ”förlika” data, d.v.s. att tillåta viss
variation mellan de textsträngar som skall matchas mot varandra. I programmet väljs kolumnen
8
som man vill matcha och programmet kan sedan automatiskt hitta länkar. Det går att förlita sig
helt på programmet där det via smarta beslut försöker hitta den bästa matchningen. En sådan
förlikning valdes i denna studie, men en manuell granskning gjordes efteråt. Eftersom
länkningen görs via matchning av strängar kan programmet missa ställen där tidigare manuell
inmatning har samma semantik men en annan syntax. Ett exempel är att resurs A innehåller
”Polhemsskolan – P1” och skall matchas med resurs B’s ”Polhemsskolan, P1-P2”.
2.9 Testa frågeställningar mot den hoplänkade datamängden
(SPARQL)
När MSB’s data har matchas mot LMs endpoint läggs MSB’s fil upp i en ny graf i endpointen. Nu
kan frågor ställas mot den sammanlänkade datamängden. Via villkor och filter i SPARQL kan en
fråga som berör två helt externa databaser ställas och svar returneras. Detta möjliggörs av att
objekt identifieras med URI:er. Dessa använder sig av standardprotokollet HTTP och all
travestering sker alltså via webben. De båda intressenternas URI:er ligger i endpointen men
eftersom det sker via webben traverserar SPARQL-frågorna över webben till intressenternas
URL:er (platsen på servern där data finns) via URI:erna och hämtar data och sedan skapar en ny
temporär graf av dessa tripletter. Denna graf som nu innehåller svaren från frågorna kan
givetvis sparas ner. Traverseringen behöver inte endast vara via SPARQL-frågor. Det kan även
göras via RDF-browser där användaren klickar sig fram mellan datakällor.
3 Resultat
Denna förstudie har haft som syfte att länka ihop externa datakällor via semantisk webb-teknik
och med användning av standarder inom området. Målet var att undersöka om detta förenklar
hanteringen av data och information men även samarbete mellan informationskällor. Studien
har genomförts hos Future Position X, FPX. Detta innebar att en ny miljö för både MSB och LM’s
data skapades. Denna miljö skapades med hjälp av Google Refine där data konverteras till RDF
och sedan länkades via strängmatchning. Inför strängmatchningen definierades ett set av regler
som den automatiska exekveringen sedan utför.
Det gjordes även manuella granskningar i efterhand för att fånga upp semantiska missar. För att
få dessa datakällor länkade måste en brygga byggas mellan dem. I detta fall användes relationen
owl:sameAs , från OWL-ontologin (Web Ontology Language). Denna relation är definierad i RDF
och säger att resurs A är samma sak som resurs B. Denna länkning var den grundläggande i
studien och detta gjordes på skolnamn från MSB och LM och adresser mellan MSB och LM. När
resurs A och B definieras som samma sak kan maskiner följa dessa bryggor och hämta mer
information om resursen. Resurs A, t.ex., Solängsskolan från Lantmäteriets filer innehåller
9
attribut i form av fastighetsinformation medan Resurs B från MSB’s filer innehåller attribut om
brand. I detta scenario får Resurs A tillgång till attribut från resurs B och vice versa.
Figur 5. Google Refine, översikt av MSB:s data
Figur 5 visar resultat av matchning av strängar mellan MSB och LM. 63 % av skolnamnen kunde
matchas och 67 % av gatuadresserna hade en matchning. Kolumnen ”objektsnamn” (skolnamn)
innehåller namnet på skolan från MSB. Kolumnen ”objektsnamn LM” skapas efter matchning på
skolnamn från LM’s filer. Där en match sker hämtas URI:er till resursen, t.ex. Solängsskolan från
LM. Detta syns även på kolumnerna ”adress” och ”Adress LMADRPL”.
Figur 6. RDF-browsern BrownSauce visar en rapport från MSB i RDF-format. Name och streetadress är URIer som
har owl:sameAs-länkar till LM’S URI:er. Se Figur 7 nedan.
10
Figur 7. Här ser vi att Kaserngatan är definierad som owl:sameAS som en fil hos LM, nämligen adresspl. Här går det
att klicka sig vidare och kolla på data ur Lantmäteriets adresspl. Vi ser även att denna adress har fler ”skolor” alltså
fler fastighetsdelar av Polhemsskolan, byggnad P1 och P5 med flera.
Via RDF-browser sker traversering mellan datakällor manuellt. Ett annat sätt är att använda sig
av standarden SPARQL.
Figur 8. Skärmdump av Fuseki SPARQL Servers interface för frågor.
SPARQL-frågan i Figur 8 skall från MSB hämta namn, olycksorsak och region. Från Lantmäteriet
hämtar vi URI:er om fastigheten med mer information och regionen (Gävleborg) hämtar vi
information från en annan extern datakälla, DBPedia. DBPedia innehåller nästan all data från
11
Wikipedia i RDF-format. Eftersom URI:en från MSB om Gävle är på webben definierar vi den
som owl:sameAs med DBPedia Gävle. Nu kan vi få all information om Gävle från Wikipedia och
även förklarad på 15 olika språk.
Figur 9. Svaren från SPARQL-frågan i Figur 8.
4 Diskussion
Resultatet av denna förstudie visar på vissa problem vid matchning av texter, men tydliggör
också effektivitetsvinster som uppkommer när standarder används med tillhörande uppsättning
av verktyg. Förutom textmatchning gjordes en undersökning angående geometrimatchning.
Tanken är att ha en punkt som identifierare där datakällor med information vid samma punkt
kan matchas. Detta går att åstadkomma med hjälp av mer avancerade skript. Ett sådan prov är
dock inte med i denna förstudie.
Ett annat publiceringssätt är till exempel en Länkad data-wrapper (se Figur 4) på en
relationsdatabas. Detta publiceringssätt, eller liknande, rekommenderas att användas vid
implementation. Det tillåter leverantören att ha liknande struktur som i sin relationsdatabas. I
avsnitt 5 behandlas detta ytterligare. Det blir även enkelt att publicera ut data. Ett scenario
skulle kunna vara att ha en databas för leverans, en för backup, en för nuvarande publicering
(t.ex. API:er) och en Länkad Data-databas.
Studien har ingått som ett testexempel inom Smart City Playground vid klusterorganisationen
FPX, där GeoTest ingått som ett delprojekt.
5 Slutsatser och rekommendationer
Förstudien skall primärt ge svar på följande frågor:
12




Hur kan standarder inom semantisk webb-teknik underlätta och förenkla hanteringen av
data och information?
Vad är fördelarna med att använda sig av Länkade Data?
Hur mycket går att matcha mellan dessa datakällor på automatiserad väg?
Vilka problem och svårigheter uppstår, både tekniska och datarelaterade?
5.1 Hur kan standarder inom semantisk webb-teknik underlätta och
förenkla hanteringen av data och information? - Vad är fördelarna?
Strukturerad data finns idag tillgängligt på webben, exempelvis som CSV, Excel spreadsheets,
och en hel del andra domänspecifika dataformat. Strukturerade data finns inbakade i HTMLsidor via t.ex. Microformats och en del dataleverantörer ger direktåtkomst till deras databaser
via Web API:er.
Fördelarna med att använda sig av Länkade Data istället är att RDF är en mer flexibel och
generisk modell som gör det lättare för konsumenter av data att hitta och integrera data från
många olika källor.
Länkad Data ger oss: [1]
En enande datamodell. RDF är en enhetlig datamodell. Genom användning av globalt unika
identifierare av resurser och genom att tillåta att olika scheman används parallellt för att
representera data är RDF speciellt lämpad för global datadelning.
En standardiserad mekanism för åtkomst av data. Länkade Data använder sig av httpprotokollet. Detta stöder åtkomst via databrowsers och tillåter hela datakällor att bli sökbara via
sökmotorer.
Hyperlänkbaserad data sökning. Genom att använda URI:er som globala identifierare kan
hyperlänkar sättas mellan entiteter vid olika datakällor. Dessa länkar binder samman all länkad
data till en enda global datarymd där applikationer kan upptäcka nya datakällor i run-time.
Detta i motsats med Webb API:er och datadumpar som med sitt låsta format förblir isolerade.
Självbeskrivande data. Länkade Data underlättar integration av data från olika källor genom att
förlita sig på delade vokabulärer, vilket gör semantiken delad och känd.
13
5.2 Hur mycket går att matcha mellan dessa datakällor på
automatiserad väg?
Som Figur 5 visar kunde 63% av skolnamnen matchas och 67% av gatuadresserna hade en
matchning. I Google Refine matchades MSBs data mot LMs data genom Refines
“förlikningsprocess”. LMs data ligger som en stor graf på en SPARQL-server i en endpoint. MSB
graf ställs mot LM’s och matchningen sker automatiskt efter att en kolumn har valts. Ett
intressant tillägg är att andras externa endpoints på webben också provades. Ett exempel är
DBPedias graf. Regionnamnet Gävle matchades mot DBPedias information om Gävle (se Figur 8
och 9). Ett till exempel är att ordet LMVK (Lantmäteriverket) , skapare av vissa entiteter i LM’s
filer, där LMVK matchades mot en definition av Land Survey från DBPedia. Detta provades även
på entiteter där Gävle Kommun var skapare, där Gävle Kommun matchades mot Gävle
Municipality från DBPedia.
5.3 Vilka problem och svårigheter uppstår, både tekniska och
datarelaterade?
En del tekniska svårigheter uppstod i arbetet. Strukturen på data från Lantmäteriet gör det svårt
att länka ihop dessa data med en annan datamängd , främst beroende på att Lantmäteriets data
är utspridda i olika filer. Problemet är att utdraget är från en relationsdatabas med
primärnycklar och främmande nycklar men det tillhandahålls i CSV-format i olika filer. Det är
samma struktur men inte samma miljö. Internt hos Lantmäteriet är data hoplänkad och det är
därför en rekommendation att vid implementering lägga ett Länkad data-lager ovanpå deras
miljö, exempelvis LD-wrapper (se Figur 4). Resultatet av förstudien visar att vi inte ännu har
lyckats nyttja den fulla potentialen hos Länkade data.
Om implementering sker i befintlig struktur, t.ex. en relationsdatabas-miljö, kan i princip samma
struktur användas i Länkade Data konceptet. Det blir då ett tillägg till ordinarie struktur. En
relationsdatabas som hanteras med SQL och en Länkad data-wrapper ovanpå
relationsdatabasen som gör det möjligt att sätta HTTP-URI:er på identifierarna och beskriva data
i tripletter men även möjliggöra frågeställning via SPARQL. Wrappern tar hand om SPARQLfrågor och gör om dem till SQL-frågor. Detta betyder att komplicerade JOIN-frågor i SQL i
relationsdatabasen körs via argumenten som SPARQL-frågorna letar efter.
I Länkade Data konceptet används vokabulär för att visa hur entiteter är relaterade till varandra.
En vokabulär är en definierad uppsättning predikat (relationer) som kan användas inom
exempelvis en viss domän. Vokabulär kan definieras genom att skapa en ontology file , vilket
också är ett RDF-dokument som beskriver alla predikat för ex. en datamängd . En ontologi
definierar inte bara predikaten själva men definierar även datatyp och om det finns, relationer
14
till andra predikat, för varje predikat. En vokabulär liknar således ett schema genom att den
definierar en uppsättning element som kan användas.
Eftersom URI:er även används för predikat är det möjligt att återanvända andras , mer kända,
vokabulär som kanske redan har definierat en relation som önskas användas. Men det går även
att skapa nya predikat inom en annan domän, t.ex. Lantmäteriets domän. Förutom
rekommendationen att implementera Länkad Data konceptet i sin egen miljö rekommenderas
att även definiera sina predikat (relationer) om det finns ett behov för det. Det finns ord och
relationer som är vanliga inom Lantmäteriet men mer eller mindre okända utanför. Dessa bör
därför beskrivas i RDF så att andra människor och maskiner förstår hur fastigheter och andras
specifika begrepp relateras till varandra.
Figur 10 nedan är ett exempel på en RDF ontology file. Den definierar en e-mailadress-relation.
Denna relation används inom en domän, UserInfo där en Organizational-Person är en User.
<rdf:Description rdf:about="#E-mail-Address">
<rdf:type>
<rdf:Description rdf:about="http://www.w3.org/2002/07/owl#DatatypeProperty"/>
</rdf:type>
<rdfs:domain>
<rdf:Description rdf:about="#UserInfo"/>
</rdfs:domain>
<rdfs:domain>
<rdf:Description rdf:about="#Organizational-Person"/>
</rdfs:domain>
<rdfs:range>
<rdf:Description rdf:about="http://www.w3.org/2001/XMLSchema#string"/>
</rdfs:range>
</rdf:Description>
Figur 10. RDF/XML-fil som definerar relationen ”E-mail-Address”.
15
6 Referenser
[1] http://linkeddatabook.com/editions/1.0/ - “Linked Data: Evolving the Web into a Global
Data Space” Tom Heath, Talis & Christian Bizer, Freie Universität Berlin
16
7 Bilaga A - Metod
Detta är en beskrivning av hur data har behandlats i Google Refine. Google Refine användes i
denna förstudie för att konvertera CSV-data till RDF-data med fungerande länkar mellan två
datakällor. För nedladdning och installation av Google Refine se deras hemsida:
https://code.google.com/p/google-refine/
Refine RDF-extension: http://refine.deri.ie/
Figur 7:1. Google Refine, MSB:s data inlagt och separerat (CSV)
Denna figur visar MSB:s data inlagt och strukturerat i Google Refine. Även utan RDF-extension
till Refine är det ett väldigt kraftfullt verktyg. Det stödjer kraftfulla konverteringar, kalkylationer,
massediteringar, sortering och sammanlänkning bara för att nämna några. Detta första steg
gjordes för både MSB:s data och LM:s data.
17
Figur 7:2. Google Refine RDF-skeleton
När RDF-extension installerats kan man börja strukturera upp en skelettstruktur och även
förhandsgranska hur RDF-filen kommer att se ut. Här kan man även sätta bas-URI till
identifierarna och även skapa länkar mellan attribut via relationer m. ha vokabulär.
18
Figur 7:3. Google Refine RDF-preview
Här är en tidig förhandsgranskning av RDF-filen. Rootelementet som innehåller bas-URI:n och
den unika identifieraren, MSB:s rapportnummer innehåller all info som valts att beskrivas i RDF.
Nu är data från en rapport (rapportnummer) unik identifierat och dess innehåll beskrivet i RDF.
Koordinaterna ligger nu i varje rapport (URI är rapportnummer) och beskrivna via vokabuläret
geo:lat och geo:long.
19
Figur 7:4. Google Refine, Skapade av ny SPARQL-endpoint.
Efter att LM:s data har beskrivits på detta sätt läggs allt upp på en SPARQL-server. SPARQL är ett
frågespråk som hanterar ett sätt att hämta data från grafer. Triplett-datastrukturen är uppbyggd
i grafstruktur. Det är mot denna graf vi ställer MSB:s graf och börjar matcha ihop data.
När både MSB:s och LM:s data beskrivits på detta sätt kan matchningen börja. Eftersom MSB:s
skolnamn är identiskt med LM:s skolnamn för den specifika skolan kan de då sägas vara samma
sak. Detta görs via vokabuläret owl:sameAs. Via denna länk kan data hämtas från båda källor.
20
Figur 7:5. Google Refine, manuell matchning av MSB:s skolnamn ”Kastet skola” mot Lantmäteriets URI:er
Här är ett exempel på matchning mellan två skolnamn. MSB:s data matchas mot LM:s data, mer
exakt LM:s graf av data. Denna graf är uppsatt på en server med programvaran Fuseki SPARQL
Server. Google Refine söker då på strängar i LM:s graf och visar om vi får en matchning. Detta
går att göra automatiskt där programmet tar bästa matchning baserat på olika algoritmer och
villkor. I detta fall gjordes detta automatiskt med en manuell påläggning efteråt.
21
Figur 7:6. Google Refine, skapade av ny kolumn baserat på uthämtade URI:er från strängmatchningen.
När matchningen är färdig är nästa steg att lägga in de nya länkarna i RDF-skelettet. Men innan
det måste vi hämta ut URI:erna från strängmatchningen så vi får identifieraren för den resursen.
Detta görs även i Refine med kommandot cell.recon.match.id. Nu kan vi lägga in owl:sameAs
länkar i skelettet, se Figur 3.
22
Figur 7:7. Google Refine, översikt av MSB:s data.
Figuren ovan visar procentuellt hur många skolnamn och gatuadresser som kunde matchas. I
detta fall var det 63% av skolnamnen och 67% av gatuadresser.
Figur 7:8. Fuseki SPARQL server, exempelfråga som hämtar data från både MSB och LM via owl:sameAs.
När båda graferna har länkats ihop har vi SPARQL till hjälp att ställa frågor som traverserar
mellan länkarna och hämtar det specifika data vi vill ha. För nedladdning och installation se
deras hemsida: http://jena.apache.org/documentation/serving_data/#download-fuseki
23
Figur 7:9. Fuseki SPARQL server, resultat av exempelfrågan.
Figur 7:10 BrownSauce RDF-browser.
För installation och nedladdning av RDF-browsern BrownSauce se deras hemsida:
http://brownsauce.sourceforge.net/
24