Linked Open Data Kartverkets praktiske erfaringer

Transkript

1 Linked Open Data Kartverkets praktiske erfaringer Thomas Ellett von Brasch

2 INNHOLD 1 - Hva er egentlig LOD, RDF, triples, graphs, sparql og ontologier? 2 - Hvorfor bruker vi LOD? 3 Administrative enheter fra Kartverket 4 Fremtiden 5 - Diskusjon

3 Hva er egentlig LOD, RDF, triples, graphs, sparql og ontologier?

4 LOD 3 ENKLE REGLER 1. HTTP NAMES 3. LINKING THROUGH RELATIONSHIPS 2. STANDARD FORMAT

5 Resource Description Framework RAMMEVERK DATA MODELL 6 W3C Spesifikasjoner DATA FORMAT RDF 1.1 XML RDF 1.1 N-Triples

6 GRAPH DB / TRIPLE STORE SETT MED TRIPLES GEOSPATIAL SPØRRINGER MANGE VARIANTER Full Støtte Delvis Støtte Ingen Støtte

7 SPARQL W3C SPESIFIKASJON SPARQL is to a graph triple store, what SQL is to a relational database. OGC SPESIFIKASJON EKSEMPEL PREFIX ex: SELECT < WHERE {?x ex:cityname?capital ; ex:iscapitalof?y.?y ex:countryname?country ; ex:isincontinent ex:africa. }

8 ONTOLOGIER Definisjon models a domain with the definition of objects and/or concepts, and their properties and relations Infer Informasjon ( Man rdfs:subclassof Person ) ( Ole rdf:type Man ) ( Ole rdf:type Person) Byggeklosser Språk Classes Object properties Data properties Feature Classes Individuals -> Individuals Individuals -> Literals RDF Schema 1.1

9 ARKITEKTUR

10 Hvorfor bruker vi LOD?

11 EKSEMPLER NRK Origo I dag er Radioarkivet metadataposter i en graph-basert database (OpenLink Virtuoso). NRK Autoritets register forum_2016.pdf BBC Ontologier - Ordnance Survey -

12 FORDELER DATA INTEROPERABILITET AUTORITATIVE DATA BLIR OPPBEVART BARE EN GANG EN GANG SEMANTISK FORSTÅELSE DATA DREVNE APPLIKASJONER

13 Administrative enheter fra Kartverket

14 PROSJEKT PLAN Opprinnelig kom forespørselen gjennom GeoNorge-prosjektet og var for et bestemt brukstilfelle - DIFI ønsket at KV skulle opprette en lokasjonsbasert tjeneste som returnerer URI og en geografisk referanse for administrative enheter. De ville kun lagre URI en, men når URI en er tilgjengelig for allmennheten bør det returnere all informasjon om det objektet. Vi ønsket å bruke oppgaven som et pilot prosjekt og utvikle en metodologi og system som kan brukes til en generell LODlevering fra Kartverket

15 Sentralkomponenter Forenklet Datamodell Semantisk Forståelse Stabil dereferensable URI s Data iht spesifikasjonen Distribusjon/Tilgang

16 Infrastruktur Adm_enhet.ttl 4 5 Adm_enhet.rdf 3

17 ONTOLOGI

18 Ontologier og Kodelister Web tilgjengelig vokabularer som definerer hvilke begreper er tilgjengelig og hvordan begrepene er relaterte. Alle ontologier og kodelister har URI er: Alle Classes, Object properties og Data properties også har uri er: RDFS og OWL gir enkelelementer for å beskrive ontologier SKOS (simple knowledge organisation system) brukes for kodelister

19 Ontologier og Kodelister Gjenbruk eksisterende ontologier Map til andre ontologier Bruk flerspråklighet eller Engelsk Enkelt er ofte bedre enn tung og kompleks

20 Opprettelse Opprinnelig ønsket vi å gå direkte fra den fulle UML-modellen til en delmengde. Dette var veldig vanskelig, komplisert og oppsvulmet. Vi endte opp med å skape separate ontologier basert på featuretyper, attributter og datatyper av den fulle modellen. Vi importerte andre ontologier hvor det var nødvendig. Vi brukte Protégé fra Stanford University. Veldig kraftig, veldig fleksibel, veldig ustabil. Ontologiene ertilgjengelige på Internett og tilgjengelig via domenet rdf.kartverket.no/onto.

21 Erfaringer Mest viktig og mest vanskelig del av prosessen. Vi har ikke nok kunnskap og erfaring for å vurdere metoden. Lett å gjenbruke andre ontologier, må sørge for at disse er fra en autoritativ kilde og vil forsette å være tilgjengelig over tid. En enkel modell er mye lettere å bruke. Jo mindre hierarki du har, den bedre. Bruke så mange predikater som mulig.

22 URI

23 Dereferensable URI er (HTTP names/url) Alle objekter som leveres ut som LOD må har en stabil URI slik at når folk begynner å inkludere vår data (uri er) i deres data, de vet at lenken vil alltid fungere og de kan stole på vår datasett. Uri ene bør være HTTP URL s slik at vanlig web klienter kan hente informasjon fra uri ene fantes i dataene. URI ene bør også være globalt unik. Derfor er det good practice for å definere et URI mønster og registrere det.

24 Dereferensable URI er (HTTP names/url) Eksempel av et vanlig mønster: Eksempel fra Kartverket domene datasett FT RT lokalid

25 Konstruksjon Eksempel fra Kartverket domene datasett FT RT lokalid Eksempel fra Ordnance Survey Eksempel fra Kadaster Nederlands

26 Erfaringer domene datasett FT RT lokalid Ikke lett å skape et mønster som dekker alle behov og at alle er enig om. Må håndtere; unikhet, stabilitet, versjoner og kanskje lesbarhet. Største utfordringen var en avgjørelse om datasett/featuretype seksjonene. Bør vi følge gml applikasjon skjemaet, bruke navn fra modellen i EA, andre navn osv. Lokalid biten var også vanskelig siden dataene opprinnelig kommer fra flere kilder, med kun lokalid på et geometri nivå. Derfor bruker vi konkatenering for å skape en lokalid per enhet.

27 DATAKONVERTERING OG LASTING

28 Data iht RDF spesifikasjonen (triples) RDF som et rammeverk: 6 spesifikasjoner RDF som en data modell - triples: uri://people#mikesmith12 uri://people#johndoe45 Mike Smith Knows John Doe RDF som et data serialisation format RDF/XML:

29 DATA Opprinnelige data iht til nasjonal SOSI spesifikasjon Transformasjon med Protege og OnTop Plugin Data konvertert til RDF og lagres i Virtuoso

30 DATA Brukt nasjonale data, som ble opprettet i forhold til en produktspesifikasjon med UML-modellen. Data ble filtrert og konvertert til rdf iht ontologien ved hjelp av et protégé-plugin kalt 'ontop'. Denne plugin lager en kartleggingfil og trekker ut, konverterer og lagrer dataene i rdf / xml som en fil. Disse dataene lastes deretter inn i Virtuoso slik at den er tilgjengelig i en graf db. Data geometrien er bare en avgrensningsboks og er kodet som WKT, geojson. Det er planlagt at full geometri bare vil være tilgjengelig fra en wfs, hvor objektene inneholder samme lokale id i gml id en.

31 Metoder Erfaringer Proxy over andre tjenester Alternativer RDF basert tilgang til RDBMS data RDF basert tilgang til RDBMS data med åpne standarder

32 Verktøy Erfaringer Veldig kraftig, veldig fleksibel, veldig ustabil. Fleksibel, kraftig, stabil, bredt brukt Triplestore + sparql endpoint+faceted search+bulk upload + adminsitration Alternativer Semafora Strabon Stardog Parliament Allegrograph TopQuadrant BrightstarDB Oracle

33 Execution times in real workload Non topological construct functions Spatial selections Spatial joins Aggregate functions

34 Adding systems with limited geospatial functionalities

35 TILGANG

36 TILGANG Sparql Endpoint RDF/XML File Nedlasting Rest API er

37 TILGANG Foreløpig gjennom sparql, faceted søk og en webtjeneste bygget på toppen av sparql-endepunktet. Også interessert i et geokoding / resolverprodukt for å gjøre det lettere for folk å bruke våre URI-er og spatial data og inkludere dem i deres data. Neste steg, er en doc representasjon som viser all informasjon om et objekt i en html side. Skal enten bruke xslt type løsning eller Linked Data Theatre fra Netherlands Kadaster ( Startet med adm_enheter, men har også jobbet med stedsnavn og er nesten ferdig. Mest sannsynlig blir det deretter adresser, men må først være enig med resten av organisasjonen om de generelle prinsippene.

38 Erfaringer SPARQL er nesten ikke brukbart for noen En REST API er viktig for vanlig brukere En doc leveranse er nødvendig for publikum (se OS og Kadaster)

39 TO INFINITIY AND BEYOND..

40 Hva blir neste? Legge til beskrivelser og annen meta-informasjon Ontology mapping - owl:equivalentproperty Schema.org for crawlability Returnere RDF/XML for alt Bygg ut funksjonalitet - Konfigurer swagger Tilpasse for flere datasett Nytt API for geocoding Sette opp content negotiation Doc representasjon xslt eller Linked Data Theatre Bedre integrasjon med eksisterende produkter

41 Takk for meg!!!