linked open data · to infinitiy and beyond….. hva blir neste? returnere rdf/xml for alt bygg ut...
TRANSCRIPT
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
INNHOLD
Hva er egentlig LOD, RDF, triples, graphs, sparql og ontologier?
http://data.geonorge.no/administrativeEnheter/fylke/id/173157
HTTP NAMES
STANDARD FORMAT
LINKING THROUGH RELATIONSHIPS1. 3.
2.
LOD – 3 ENKLE REGLER
Resource Description Framework
6 W3C Spesifikasjoner
RDF 1.1 XML
RDF 1.1 N-Triples
RAMMEVERKDATA MODELL
DATA FORMAT
GRAPH DB / TRIPLE STORE
SETT MED TRIPLES
MANGE VARIANTER
GEOSPATIAL SPØRRINGER
Full Støtte
Delvis Støtte
Ingen Støtte
SPARQL
W3C SPESIFIKASJONSPARQL is to a graph triple store,
what SQL is to a relational database.
OGC SPESIFIKASJON
PREFIX ex: <http://example.com/exampleOntology#>
SELECT ?capital
?country
WHERE
{ ?x ex:cityname ?capital ;
ex:isCapitalOf ?y .
?y ex:countryname ?country ;
ex:isInContinent ex:Africa . }
EKSEMPEL
ONTOLOGIER
ClassesObject properties
Data properties
“models a domain with the definition of objects and/or concepts, and their properties and relations”
Feature ClassesIndividuals -> IndividualsIndividuals -> Literals
Byggeklosser
Definisjon Infer Informasjon
Språk
RDF Schema 1.1
( Man rdfs:subClassOf Person )
( Ole rdf:type Man )
( Ole rdf:type Person)
ARKITEKTUR
Hvorfor bruker vi LOD?
• 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
EKSEMPLER
DATA INTEROPERABILITET
EN GANG
http://data.geonorge.no/administrativeEnheter/fylke/id/173157
AUTORITATIVE DATA BLIR OPPBEVART BARE EN GANG
SEMANTISK FORSTÅELSE DATA DREVNE APPLIKASJONER
FORDELER
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.
Vi ønsket å bruke oppgaven som et pilot prosjekt og utvikle en metodologi og system som kan brukes til en generell LOD-
levering fra Kartverket
De ville kun lagre URI’en, men når URI’en er tilgjengelig for allmennheten bør det returnere all informasjon om det
objektet.
Sentralkomponenter
Forenklet Datamodell
Semantisk Forståelse
http://data.geonorge.no/{namepace}/id/{localId}
Stabil de-referensable URI’s
Data ihtspesifikasjonen
Distribusjon/Tilgang
Infrastruktur
http://rdf.kartverket.no/onto/adm_enhet_4.0.owl
Adm_enhet.ttl
Adm_enhet.rdf
1
2
3
45
6
7
ONTOLOGI
• 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
Ontologier og Kodelister
Gjenbruk eksisterende ontologier
‘Map’ til andre ontologier
Enkelt er ofte bedre enn tung og kompleks
Bruk flerspråkligheteller…Engelsk
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. Veldigkraftig, veldig fleksibel, veldig ustabil.
Ontologiene er tilgjengelige på Internett ogtilgjengelig via domenet rdf.kartverket.no/onto.
http://rdf.kartverket.no/onto/adm_enhet_4.0.owl
Erfaringer
Mest viktig og mest vanskelig del av prosessen. Vi har ikke nok kunnskap og erfaring for å vurdere metoden.
En enkel modell er mye lettere å bruke. Jo mindre hierarki du har, den bedre.
Lett å gjenbruke andre ontologier, må sørge for at disse er fra en ‘autoritativ’ kilde og vil forsette å være tilgjengelig over tid.
Bruke så mange predikater som mulig.
URI
• 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
Dereferensable URI’er (HTTP names/URL)
Konstruksjon
http://data.ordnancesurvey.co.uk/id/4000000074577442
Eksempel fra Ordnance Survey
http://brk.basisregistraties.overheid.nl/id/kadastrale-grens/240128610
Eksempel fra Kadaster Nederlands
http://data.geonorge.no/administrativeEnheter/fylke/id/173157
domene datasett FT RT lokalid
Eksempel fra Kartverket
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.
Erfaringer
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.
http://data.geonorge.no/administrativeEnheter/fylke/id/173157
domene datasett FT RT lokalid
DATAKONVERTERING OG LASTING
Data iht RDF spesifikasjonen (triples)
• 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
• RDF som et rammeverk: 6 spesifikasjoner
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 RDF basert tilgang til RDBMS data
Alternativer
RDF basert tilgang til RDBMS data med åpne standarder
Verktøy Erfaringer
Veldig kraftig, veldig fleksibel, veldigustabil.
Fleksibel, kraftig, stabil, bredt bruktTriplestore + sparql endpoint+faceted search+bulk
upload + adminsitrationAlternativer
Semafora
TopQuadrant
Strabon Stardog
Allegrograph
BrightstarDB
Parliament
Oracle
Execution times in real workload
Non topologicalconstructfunctions
Spatialselections
Spatialjoins
Aggregatefunctions
Adding systems with limited geospatial functionalities
TILGANG
TILGANG
SparqlEndpoint
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?
Returnere RDF/XML for alt
Bygg ut funksjonalitet - Konfigurer swagger
Tilpasse for flere datasett
Sette opp ‘content negotiation’
‘Doc’ representasjon – xslt eller Linked Data Theatre
Bedre integrasjon med eksisterende produkter
Legge til beskrivelser og annen meta-informasjon
Ontology mapping - owl:equivalentPropertySchema.org for ‘crawlability’
Nytt API for geocoding
Takk for meg!!!