Linked Data. Förstudie Linked Data. GeoTest Rapport upprättad Viktor Högberg - GeoTest

Transkript

1 Förstudie Linked Data GeoTest 2013 Linked Data Rapport upprättad Viktor Högberg - GeoTest

2 1 Innehållsförteckning 1 Introduktion Om GeoTest-projektet Länka relaterad data Länkade Data Metod Lantmäteriets fastighetsregister Myndigheten för samhällsskydd och beredskap (MSB) Länkade Data principer Programvaror Analys och strukturering av källdata (MSB, LM) Identifiera möjliga identifierare för källdata Transformation från befintlig datastruktur till RDF Matchning av datakällor Testa frågeställningar mot den hoplänkade datamängden (SPARQL) Resultat Diskussion Slutsatser och rekommendationer Hur kan standarder inom semantisk webb-teknik underlätta och förenkla hanteringen av data och information? - Vad är fördelarna? 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? Referenser Bilaga A - Metod

3 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: 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? 1.3 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

4 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

5 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:er 1 (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. knows Matt B Scott M subjekt predikat objekt Figur 1. URI:er används för att identifiera människor och relationerna mellan dem. Exempel från 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 5

6 2.4 Programvaror Följande programvaror användes i studien. Google Refine (numera Open Refine) Fuseki SPARQL 1.1 Server Tabulator till Firefox (RDF-data browser) BrownSauce (RDF-data browser) 2.5 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 = ALTNAMN_52B Riksnyckelid Namn.. URI = REGBYG_50A Riksnyckelid Fastighetsnyckel Byggnadsstatus.. URI = REGENH_01A Fastighetsnyckel Tomträtt Status.. KOORD_09A Fastighetsnyckel Lon, Lat.. ADRPL_90A Riksnyckelid Fastighetsnyckel Adress.. URI = URI = 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

7 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 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

8 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 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

9 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-P 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

10 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

11 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

12 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

13 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

14 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

15 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 adress-relation. Denna relation används inom en domän, UserInfo där en Organizational-Person är en User. <rdf:description rdf:about="# -address"> <rdf:type> <rdf:description rdf:about=" </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=" </rdfs:range> </rdf:description> Figur 10. RDF/XML-fil som definerar relationen -Address. 15

16 6 Referenser [1] - Linked Data: Evolving the Web into a Global Data Space Tom Heath, Talis & Christian Bizer, Freie Universität Berlin 16

17 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: Refine RDF-extension: 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

18 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

19 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

20 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

21 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

22 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

23 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: 23

24 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: 24