Linked geo data

Versie door Pilod (overleg | bijdragen) op 6 mrt 2014 om 10:59
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)

Geonovum heeft jarenlang de standaardisatie en toegankelijkheid van geo-informatie in de publieke sector van Nederland gestimuleerd en inmiddels kunnen we daar de vruchten van plukken in de vorm van heel veel beschikbare geo-data, steeds vaker met een open gebruikslicentie. De geo-data is veelal beschikbaar in een gestandaardiseerd, gestructureerd formaat (GML) en via gestandaardiseerde web services.

We hebben vooral sinds het afgelopen jaar gemerkt dat het Semantic Web momentum begint te krijgen. In de Linked Data pilot is door een groot aantal partijen veel ervaring opgedaan met linked data standaarden. Hoewel er veel geo-data beschikbaar is, blijkt dit niet zomaar te betekenen dat dit ook binnen het Semantic Web gebruikt wordt. Er moeten nog stappen gezet worden om geo-data naar het Semantic Web te brengen en daar ten volle te kunnen benutten. Doel van dit pilotproject is om te ontdekken welke stappen dit zijn en hoe die het beste gezet kunnen worden.

Tijdens de PiLOD 2.0 kunnen verschillende vragen aan bod komen. Deze worden hier elk in een sectie uitgewerkt. Werkgroepleden worden uitgenodigd commentaar te leveren / toevoegingen te doen!

De onderwerpen hieronder vormen een vrij grote lijst; tijdens de pilot kan hierin een selectie worden gemaakt of kunnen andere vragen naar boven komen. Een deel van de vragen kan aan bod komen binnen Case 1 of vanuit een samenwerking met Case 1. Bijvoorbeeld vraag 1 moet een antwoord krijgen voordat geo-informatie in case 1 wordt ontsloten als linked data. Vraag 2 kan geheel binnen Case 1 aan bod komen.

Hoe neem je locatie-informatie (geometrie, coördinaten) het beste op in RDF?[bewerken]

Hiervoor bestaan verschillende vocabularia, zoals W3C Basic Geo , INSPIRE Core Location Vocabulary, NeoGEO, en OGC GeoSPARQL. Een inventarisatie en selecteren van een van de standaarden zijn nodig. Of zouden we aanbevelingen voor het verbeteren van deze standaarden kunnen doen?

Deze onderzoeksvraag valt voor een groot deel samen met de missie van de Geospatial Semantic Web Community Group van het W3C. Het zou leuk zijn onze bevindingen met die groep te delen.

Toekennen van URI’s als identificatie aan de dataobjecten[bewerken]

Dit moet natuurlijk gebeuren op basis van de concept URI strategie uit de LOD pilot fase 1. Dit kan in case 1 ipv case 3 gebeuren.

Automatische conversie van geo-data naar linked data[bewerken]

Hiervoor hebben we (Linda van den Brink, Wilko Quak en Paul Janssen) in de Linked Open Data pilot, fase 1, al een experimentele conversie geïmplementeerd en beschreven. Dit ging om een generieke conversie van GML naar RDF. Deze zou moeten worden uitgebreid met:

  1. in punt 1 geselecteerde uitdrukkingsvorm voor geometrie
  2. de juiste URI’s (punt 2)


Van het automatisch genereren van RDF op basis van GML kun je je echter afvragen of dat wenselijk is. Zo veel systemen zijn er toch niet die GML produceren? Ja, er is wel wat, maar dat komt voornamelijk door wetgeving, en niet doordat GML zo'n succesvolle standaard is. Het is wellicht zinvoller om RDF direct uit de brondata te publiceren, dus niet volgend op GML, maar er naast. Dan worden de beperkingen van GML omzeild en dan worden meteen de te verwachten prestatieproblemen vermeden. Maar ook dit zou eens in de praktijk getest kunnen worden, bijvoorbeeld door een geschikte dataset in een RDBMS te stoppen en daar dan een WFS en een SPARQL-endpoint op te zetten.

Het omzetten van de semantiek uit geo-informatiemodellen naar een linked data ontologie[bewerken]

In de Linked Open Data pilot is hier ervaring mee opgedaan en bleek dit geautomatiseerd te kunnen (op basis van een implementatie van OGC document 11-063r6 ), aangevuld met een door ons ontwikkelde methode om de UML te annoteren met een mapping naar aan bestaande linked data ontologieën.

Echter, hier zijn nog veel vragen bij. Automatische conversie van semantiek (van GML-applicatieschema's naar RDF-vocabularia) is mogelijk, maar je kan je afvragen waarom je dat zou willen en wat de voor- en nadelen zijn. Met automatische conversie zijn Linda van den Brink,Wilko Quak en Paul Janssen in PiLOD 1 bezig geweest. Zie artikel in het boek van vorig jaar: http://www.pilod.nl/wiki/Boek/BrinkEtAl-GML2RDF. We zijn nu bezig aan een vervolgartikel dat wat uitgebreider is en waarin we met name de automatische omzetting van UML naar RDFS/OWL uitbreiden. De omzetting doen we met ShapeChange waarin een vrij eenvoudige mapping van UML naar RDFS/OWL wordt gedaan. Deze lijkt sterk op wat nu aan regels voor de omzetting van UML modellen naar OWL ontologieën wordt beschreven in ISO 19150-2 (DIS). We zien zelf een drietal issues met UML > OWL mapping.

  1. het closed world uitgangspunt van UML vs open world. Als je een closed world model wilt omzetten naar een open world OWL ontologie zul je interpretatie moeten doen tijdens de omzetting, een handmatige stap dus. We denken dat je deze stap zou kunnen uitvoeren door vooraf in de UML aan te geven dat omzetting naar een open world model gewenst is (op het hele model of op klasse danwel property niveau). Dit hebben we nog niet geïmplementeerd en zou uitgeprobeerd moeten worden. Wellicht wordt het te ingewikkeld. Het is geen probleem om Shapechange aan te passen zodat het bv geen domain en range statements maakt bij properties, en de classname niet voor de propertyname te zetten; maar wat je doet met properties met dezelfde naam blijft toch een interpretatievraag. Misschien zijn ze hetzelfde; misschien is de een een subproperty van de ander, etc. Dit zou je dan allemaal in annotaties moeten zetten in de UML.
  2. het punt dat het in het semantic web good practice is om je ontologie/vocabulaire te koppelen aan al bestaande vocabulaires met dezelfde concepten. Dit lossen we op met annotaties (tagged values) in de UML om classes en properties uit het informatiemodel te koppelen (met equivalentClass/equivalentProperty) aan bestaande ontologieën en vocabulaires uit het semantic web.
  3. Sommige modelleerconventies en beperkingen in UML (bv het vermijden van multiple inheritance) leiden tot gekunstelde UML constructies. Bij automatische omzetting naar RDFS/OWL zouden deze gekunstelde constructies behouden blijven, terwijl het eigenlijk bedoelde in OWL misschien veel beter en ongekunsteld uitgedrukt kan worden. Hiervoor zien we geen geautomatiseerde oplossing.


Voor automatische omzetting van semantiek is een voor de hand liggende reden dat er al zo veel modellen zijn. Het zou heel jammer zijn als alle applicatieschema's die we nu hebben, nationaal en internationaal, niet meer gebruikt kunnen worden. Maar het gevaar ligt op de loer dat modellering via UML en GML dermate beperkend is dat een automatische conversie van zo'n model naar RDF een model zou opleveren dat geen goed recht doet aan de werkelijkheid. Het kan zelfs beter zijn terug te gaan naar de werkelijkheid en dan met de verbeterde middelen (RDFS/OWL) een beter model te maken. En daarbij kunnen de bestaande UML-klassediagrammen van groot nut zijn. Daar hebben de domeinexperts immers al veel over nagedacht en gesteggeld. Zou het niet een leuke test zijn om een GML-applicatieschema te kiezen (eentje van INSPIRE bijvoorbeeld) en die zowel automatisch als met de hand om te zetten naar een RDF-vocabularium, en dan te kijken wat de verschillen zijn, en wat de relatieve bruikbaarheid is?

Metadata over geo linked datasets[bewerken]

Geo-data is goed voorzien van allerlei gestandaardiseerde metadata, bijvoorbeeld eigenaar van de dataset, creatiedatum, en gebruiksbeperkingen, maar ook nauwkeurigheid van coördinaten. Voor Linked Data zijn er bijvoorbeeld VoID en DCAT. Onderzocht kan worden of bestaande vocabularia voor metadata geschikt zijn om geo-linked-datasets te metadateren, en of er misschien uitbreidingen voor nodig zijn.

Het publiceren, beschikbaar stellen, vindbaar maken van geo linked data[bewerken]

De Ordnance Survey linked data biedt een mooi voorbeeld.

subvraag hierbij is wat een handige aanpak is om tot een reductie van het datavolume te komen / om te gaan met het vaak grote datavolume van geodata. Dit speelt in nog grotere mate bij sensordata.

In de PiLOD case 3 zou een SPARQL endpoint gemaakt kunnen worden met geodata.

Een mogelijkheid is een samenwerking met het CERISE-SG project, een project over 'smart grids' waarin het de bedoeling is om geodata en energiedata te combineren. Geodan is verantwoordelijk voor het bouwen van een prototype van een datadienst voor dat doeleinde. Het idee is nu om dat een SPARQL-endpoint te maken en de te publiceren data dus volgens de principes van Linked Data te behandelen. Simpel gezegd gaat het om meterstanden en daaraan gekoppelde gegevens, waaronder locatie. De meetapparaten (energiemeters) zijn als sensoren te beschouwen, dus we (CERISE deelnemers) zien flinke overlap met de PiLOD en willen graag als CERISE-SG meedoen.

Maar ook in de Erfgoed en Locatie pilot wordt al geexperimenteerd met GeoSPARQL endpoints: http://erfgoedenlocatie.nl/2013/11/geosparql-demo-erfgoed-locatie/

Het aanbrengen van links tussen geo-datasets en andere linked data[bewerken]

Zo mogelijk geautomatiseerd, (bijvoorbeeld) op basis van locatie.

Het toepassen van locatie in zoekvragen aan linked data[bewerken]

Experimenteren met OGC standaard GeoSPARQL. Deze standaard uit 2012 is nog weinig toegepast. Het is interessant om hier ervaring mee op te doen. Is dit een standaard die waardevol is voor linked data toepassingen? Zijn er verbeteringen voor de standaard aan te dragen?

Resultaten[bewerken]

Resultaat zou kunnen zijn:

  • wetenschappelijk artikel over geo linked data in Nederland
  • Kennis opgedaan over geo in linked data. Deze kennis leggen we natuurlijk vast (in de vorm van?)
  • (Geo)SPARQL endpoint met geo linked data