Linked Open Data Kartverkets praktiske erfaringer Thomas Ellett von Brasch elltho@kartverket.no
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
Hva er egentlig LOD, RDF, triples, graphs, sparql og ontologier?
LOD 3 ENKLE REGLER 1. HTTP NAMES 3. LINKING THROUGH RELATIONSHIPS http://data.geonorge.no/administrativeenheter/fylke/id/173157 2. STANDARD FORMAT
Resource Description Framework RAMMEVERK DATA MODELL 6 W3C Spesifikasjoner DATA FORMAT RDF 1.1 XML RDF 1.1 N-Triples
GRAPH DB / TRIPLE STORE SETT MED TRIPLES GEOSPATIAL SPØRRINGER MANGE VARIANTER Full Støtte Delvis Støtte Ingen Støtte
SPARQL W3C SPESIFIKASJON SPARQL is to a graph triple store, what SQL is to a relational database. OGC SPESIFIKASJON EKSEMPEL PREFIX ex: SELECT <http://example.com/exampleontology#>?capital?country WHERE {?x ex:cityname?capital ; ex:iscapitalof?y.?y ex:countryname?country ; ex:isincontinent ex:africa. }
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
ARKITEKTUR
Hvorfor bruker vi LOD?
EKSEMPLER https://data.gov.uk/organogram/ordnance-survey/2013-09-30 http://environment.data.gov.uk/bwq/profiles/profile.html?site=ukf1400-09750 NRK Origo I dag er Radioarkivet 790.000 metadataposter i en graph-basert database (OpenLink Virtuoso). NRK Autoritets register https://data.norge.no/sites/datanorge/files/semantisk_teknologi_i_nrk_datadelings forum_2016.pdf BBC Ontologier - https://www.bbc.co.uk/ontologies Ordnance Survey - http://data.ordnancesurvey.co.uk/datasets/os-linked-data
FORDELER DATA INTEROPERABILITET AUTORITATIVE DATA BLIR OPPBEVART BARE EN GANG EN GANG http://data.geonorge.no/administrativeenheter/fylke/id/173157 SEMANTISK FORSTÅELSE DATA DREVNE APPLIKASJONER
Administrative enheter fra Kartverket
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
Sentralkomponenter http://data.geonorge.no/{namepace}/id/{localid} Forenklet Datamodell Semantisk Forståelse Stabil dereferensable URI s Data iht spesifikasjonen Distribusjon/Tilgang
Infrastruktur 7 http://rdf.kartverket.no/onto/adm_enhet_4.0.owl 2 6 1 Adm_enhet.ttl 4 5 Adm_enhet.rdf 3
ONTOLOGI
Ontologier og Kodelister Web tilgjengelig vokabularer som definerer hvilke begreper er tilgjengelig og hvordan begrepene er relaterte. Alle ontologier og kodelister har URI er: http://rdf.kartverket.no/onto/adm_enhet_4.0.owl Alle Classes, Object properties og Data properties også har uri er: http://www.opengis.net/ont/geosparql#ehcontains RDFS og OWL gir enkelelementer for å beskrive ontologier SKOS (simple knowledge organisation system) brukes for kodelister
Ontologier og Kodelister Gjenbruk eksisterende ontologier Map til andre ontologier Bruk flerspråklighet eller Engelsk Enkelt er ofte bedre enn tung og kompleks
Opprettelse Opprinnelig ønsket vi å gå direkte fra den fulle UML-modellen til en delmengde. Dette var veldig vanskelig, komplisert og oppsvulmet. http://rdf.kartverket.no/onto/adm_enhet_4.0.owl 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.
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.
URI
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.
Dereferensable URI er (HTTP names/url) Eksempel av et vanlig mønster: http://<domene>/<autoritet/datasett>/<featureclass>/<ressurstype>/<lokalid> Eksempel fra Kartverket http://data.geonorge.no/administrativeenheter/fylke/id/173157 domene datasett FT RT lokalid
Konstruksjon Eksempel fra Kartverket http://data.geonorge.no/administrativeenheter/fylke/id/173157 domene datasett FT RT lokalid Eksempel fra Ordnance Survey http://data.ordnancesurvey.co.uk/id/4000000074577442 Eksempel fra Kadaster Nederlands http://brk.basisregistraties.overheid.nl/id/kadastrale-grens/240128610
Erfaringer http://data.geonorge.no/administrativeenheter/fylke/id/173157 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.
DATAKONVERTERING OG LASTING
Data iht RDF spesifikasjonen (triples) RDF som et rammeverk: 6 spesifikasjoner RDF som en data modell - triples: uri://people#mikesmith12 http://xmlns.com/foaf/0.1/knows uri://people#johndoe45 Mike Smith Knows John Doe RDF som et data serialisation format RDF/XML: http://nnriap523:5000/#!/adminstrative_unit/get_describe_county
DATA Opprinnelige data iht til nasjonal SOSI spesifikasjon Transformasjon med Protege og OnTop Plugin Data konvertert til RDF og lagres i Virtuoso
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.
Metoder Erfaringer Proxy over andre tjenester Alternativer RDF basert tilgang til RDBMS data RDF basert tilgang til RDBMS data med åpne standarder
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
Execution times in real workload Non topological construct functions Spatial selections Spatial joins Aggregate functions
Adding systems with limited geospatial functionalities
TILGANG
TILGANG Sparql Endpoint RDF/XML File Nedlasting Rest API er
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 (https://github.com/architolk/linked-data-theatre) 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.
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)
TO INFINITIY AND BEYOND..
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
Takk for meg!!!