Een technische toelichting op de demo, draaiend op http://erfgeo.nl/geosparql/geosparql-demo.html. CC-BY Rein van ‘t Veer/Erfgoed & Locatie, Versie 2.0 17-1-2014
Probleemstelling – de “geosemantische kwestie”
De wereld van geografische informatiesystemen (GIS) en die van semantische systemen (Linked Data) liggen nog ver uiteen. GIS-systemen zijn al veel langer in ontwikkeling dan semantische, waarbij stabiele productiesystemen ook in open source-vorm al ruimschoots en met groot succes worden toegepast – denk bijvoorbeeld aan het Nationaal Georegister. De semantische toepassingswereld kent weliswaar een aantal stabiele toepassingen (zie bijvoorbeeld het gebruik van OpenLink Virtuoso dat gedeeltelijk als open source wordt uitgebracht), maar deze strekken zich op moment van schrijven nog moeizaam uit in de richting van geografische doorzoekbaarheid. Waarom is dit nodig?
De noodzaak van goede geografische inbedding van semantische systemen ligt simpelweg in het feit dat veel data een geografische component heeft en een geografische functionele context vereist – ruimtelijke data moet door een functionele omgeving spatially enabled worden gemaakt om tot zijn recht te komen. Een veelgebruikte (maar moeilijk verifieerbare) claim is dat 80% van de data een locatieve component kent. Naast de mogelijkheden die dit aspect biedt, vormt dit ook een probleem, met name in de visualisatie hiervan op het web en de functionaliteit die het vereist om het te benutten.
Dit brengt ons bij de Geosemantische Kwestie, zoals we deze bij Erfgoed & Locatie hebben gedoopt. Open source web-GIS systemen zoals OpenLayers en Leaflet kennen beperkingen aan het aantal ongefilterde geografische entiteiten die in een kaart geladen én gevisualiseerd kunnen worden. Hiervoor zijn demo’s die dit onderzoeken, zie onder meer http://swingley.appspot.com/maps/olpts – Bron: http://gis.stackexchange.com/questions/8876/maximum-number-of-point-features-in-an-openlayers-vector-layer. De problemen treden bij volledige vlak-geometrieën (polygonen en multipolygonen) veel eerder op. Deze Javascript-gebaseerde componenten zijn echter hard nodig voor het tonen van grote hoeveelheden data – kaarttoepassingen kunnen veel grotere hoeveelheden informatie (althans de locatie ervan) inzichtelijk maken en de detail-informatie trapsgewijs ontsluiten via tekstballonnen, popups en informatie-balken, waar kaart-loze toepassingen het moeten hebben van lijsten waarin de gebruiker bij veel kleinere zoekresultaten het spoor bijster raakt. Daarbij komt dat het overpompen van geografisch ongefilterde en grote hoeveelheden data al snel uit de klauwen loopt, met name als de geometrieën wat complexer en data-intensiever worden. Kortom: de geosemantische kwestie ligt in het ontbreken van duidelijke strategieën die gevolgd kunnen worden om relevante semantische resultaten te filteren en in te perken op een relevant geografisch gebied – waar deze geografische relevantie uit iedere willekeurige polygoon kan bestaan, ook als resultaat van een andere zoek-operatie. Hierbij is een aantal richtingen denkbaar, ruwweg uiteenvallend in twee hoofdrichtingen:
- Een client-side filterstrategie – deze heeft echter als nadeel dat de cliënt eerst alle relevante semantische resultaten overgesluisd moet krijgen, wat tot onacceptabele laadtijden zou leiden;
- Een server-side filterstrategie – de serverkant zit dichtbij de brondata en de te filteren resultaten, zodat deze beter en sneller in staat is de zoekresultaten te filteren op een specifiek gebied.
GeoSPARQL
De behoefte aan server-side filtermogelijkheden heeft onder meer zijn weerslag gekregen in het opzetten van de GeoSPARL-standaard door het Open Geospatial Consortium: een tweetal vocabulaires als extensie van het SPARQL-bevragingsmodel. Algemeen idee is dat Linked Data beschreven met de GeoSPARQL-vocabulaire, geografisch geïndexeerd wordt door een “spatially enabled” triple store. Het ruimtelijke karakter van een dergelijke triple store ligt er dus in dat het:
- Ruimtelijke gegevens kan indexeren – waarvoor op het moment veelal een ruimtelijke database zoals PostGIS wordt gebruikt;
- Ruimtelijke SPARQL-queries als extensie van het SPARQL-bevragingsmodel met ruimtelijke functies kan bevragen en efficiënt kan terugleveren.
Aangezien GeoSPARQL door de belangrijkste geografische autoriteit is omarmd, namelijk het Open Geospatial Consortium, heeft dit ertoe geleid dat Erfgoed & Locatie deze richting wilde onderzoeken met een demo-applicatie teneinde de werking en toepasbaarheid ervan op kleine schaal te beproeven.
De Erfgoed & Locatie GeoSPARQL-demo: servercomponenten
GeoSPARQL-conforme triple stores hebben een hoop voordelen in vergelijking met hybride toepassingen. Het ondersteunt een zogenaamde monolithisch systeemontwerp dat zelfstandig opereert en alle noodzakelijke functies in zich herbergt, wat installatie en onderhoud enorm kan vereenvoudigen. Daarnaast bevraagt een monolithisch systeem vrijwel altijd slechts één databron – en dus maar een enkele single point of truth, dit in tegenstelling tot sommige hybride oplossingen. De zwakte van monolithische systemen is echter dat geen van de interne onderdelen van het systeem kan falen zonder de rest van de applicatie mee te trekken en dat het gehele systeem gepatcht moet worden om upgrades door te voeren. Een bijkomend probleem is dat er vaak weinig zicht is vanuit het blikveld van de systeem-administrator op de interne werking bij optredende problemen.
Bij aanvang van de demo-constructie was bovendien duidelijk dat de huidige implementaties van GeoSPARQL de nodige problemen kenden. Een studie van het Europees gefinancierde GeoKnow maakte duidelijk dat de complexere geografische filter- en zoekmogelijkheden die GeoSPARQL belooft, op Big Data-schaal slechts nog theoretisch mogelijk waren. Uit de studie is de triple store gekozen die het meest veelbelovend, volledig en stabiel leek (dit is een moeizame afweging): uSeekM, op basis van de PostGIS-configuratie. Er is geen praktische vergelijkende studie gemaakt door E&L van de verschillende huidige toepassingen onderzocht door GeoKnow, daarvoor is de onderzoekscapaciteit van E&L te beperkt. Er is op een gegeven momen gewoon een knoop doorgehakt op gut feeling, niet op een zorgvuldig afgewogen besluitvormingsproces.
uSeekM is een adaptatie van het bekende Sesame-framework, een veelgebruikte en geroemde open source triple-store en toolset. Het systeem draait in een Java-virtuele machine zoals Apache Tomcat of Jetty. Een dataset is geografisch te bevragen door deze te verrijken met GeoSPARQL-geannoteerde geometrieën – deze worden geografisch geïndexeerd. Deze Java virtuele machines zijn via een reverse proxy in Apache web server bereikbaar gemaakt op de standaard HTTP-poort 80. De complete stack draait op een virtual private server met 2×2.4 Ghz, 3 Gb werkgeheugen en 40 Gb schijfruimte. Aangezien er ook andere toepassingen op de server draaien (ook binnen dezelfde Tomcat Java Virtual Machine), kunnen op basis van de demo geen algemene conclusies over performance worden getrokken.
De data in de toepassing is afkomstig van de Archeologische Monumentenkaart (de AMK) in beheer door de Rijksdienst voor het Cultureel Erfgoed, zoals beschikbaar gesteld. Deze dataset is als shapefile integraal ingeladen in PostGIS, waarna een mapping is gemaakt met behulp van het D2RQ-platform, waarmee ook een RDF-dump is gemaakt en downloadbaar gemaakt. D2RQ is een essentiële schakel gebleken in het converteren naar linked data. Eveneens een Java-toepassing in een virtuele machine, biedt D2RQ een brug tussen de ‘klassieke’ relationele database-wereld en die van Linked Data, door een mapping-taal te bieden die de data in een tabel of set tabellen via een SPARQL-endpoint bevraagbaar maakt, naast de mogelijkheid deze data als RDF-dump dus te converteren. Deze conversie-dump was noodzakelijk, aangezien D2RQ zelf geen geografische zoekmogelijkheden ondersteunt. Een dergelijke toepassing bestaat wel maar is nog niet door E&L onderzocht: genaamd Sparqlify – een toepassing die voor zowel de RCE als voor E&L grote mogelijkheden biedt en het onderzoeken waard is. Waar D2RQ nog altijd zorg voor draagt in de E&L-demo is de resolvebaarheid van de geconverteerde data – een servercomponent die ervoor zorgt dat iedere entiteit en eigenschap een landing page krijgt. Dit is geen triviale dienst – het vormt onderdeel van de kerndoelen van het semantisch web, om (onderzoeks)data niet ophet web als download beschikbaar te maken, maar als webpagina’s, zowel machine- als menselijk leesbaar.
Al met al bestaat de server-side dus uit:
- USeekM 1.2.1 als GeoSPARQL-extensie van de OpenRDF Sesame 2.6 triple store
- D2RQ als resource resolver, SPARQL explorer en mapping/dump toepassing
- Apache Tomcat 7 als Java virtuele machine voor het draaien van USeekM en D2RQ
- Apache web server voor URI-mapping en reverse proxy
E&L GeoSPARQL-demo client-side componenten
Naar weten van de auteur zijn er momenteel geen servertoepassingen bekend die, naast de geosemantische triple store en wat onderhoudsapplicaties hiervoor, ook een geografische interface aanbieden met geïntegreerde kaartcomponent. Het zijn ‘uitgebreide’ standaard triple stores. Dit heeft een belangrijke consequentie: geen enkele triple store is fabrieksklaar voorbereid op geografische inbedding in web-componenten zoals OpenLayers of Leaflet, noch op inbedding in standaard GIS-pakketten zoals QGIS, ArcGIS of MapInfo. De meeste triple stores bieden SPARQL-enpoints die ofwel RDF/XML als response-resultaat leveren, ofwel RDF/JSON. Geen van deze formaten (en bijbehorende MIME-types) is rechtstreeks aan te sluiten op GIS-toepassingen. Om een werkende web-toepassing te bouwen, was er daarom een parser nodig die SPARQL-zoekresultaten vertaalde naar web-compatible objecten. Aangezien JSON voor web-ontwikkelaars vele malen gemakkelijker te verwerken is dan XML, is deze route gekozen.
De wijze waarop de geodata wordt verpakt – als Well Known Text (WKT) of als Geography Markup Language (GML) is af te vangen en te serialiseren door een javascript functiebibliotheek. Deze is door Erfgoed & Locatie samengesteld en onder GPLv3 gepubliceerd op Github op het adres https://github.com/erfgoed-en-locatie/sparql-geojson. Deze bibliotheek vertaalt het SPARQL-resultaat van MIME application/sparql-results+json, naar GeoJSON, een OGC-standaardformat dat veel in webtoepassingen wordt gebruikt, waaronder de demo. Dit doet het client-side in de vorm van een Javascript-functiebibliotheek. De opzet is nog beperkt – het converteert bijvoorbeeld nog geen GML en beschikt zodoende enkel over die functionaliteit die het bruikbaar maakt voor de demo. Ook is er geen ondersteuning voor het meer geaccepteerde JSON-LD format, dat onlangs tot W3C-aanbeveling is gepromoveerd.
De laatste stap aan de client-kant is de webtoepassing zelf. Deze leunt sterk op OpenLayers – een standaardcomponent met ondersteuning voor vele formaten, waaronder GeoJSON. Het geconverteerde zoekresultaat wordt rechtstreeks ingeladen in OpenLayers en als laag in de toepassing getoond. Er is enige custom scripting toegevoegd om de vormgeving van de popup-tekstballonnen op te bouwen en met content te vullen. Onder het kaartresultaat is een eenvoudige HTML-tabel opgenomen die de resultaten in een lijst presenteert.
Data
Archeologische Monumenten (AMK)
Als eerste dataset is het Archeologisch Monumentenregister opgenomen, zoals geadverteerd op http://services.rce.geovoorziening.nl/www/download/data/Archeologische_Monumenten_nl.xml, waar deze is gelinkt als shapefile in http://services.rce.geovoorziening.nl/www/download/data/Archeologische_Monumenten_28992.zip. De geconverteerde dataset (met behulp van D2RQ) is beschikbaar gesteld op http://erfgeo.nl/geosparql/archeologisch_monument_dump.ttlvoor reproduceerbaarheid. De dataset is van goede kwaliteit en viel relatief eenvoudig te converteren.
Sterktes – server side
USeekM
Het voordeel van het gebruik van deze servercomponent is dat het eigenlijk alle functionaliteit in zich herbergt die de toepassing en gebruik ervan vereist. De component kan data inlezen, parsen, indexeren (dus ook geografisch), converteren, exporteren en met SPARQL bevragen. Het enige ontbrekende element is de rechtstreekse conversie naar GeoJSON of inbedding in een ander gangbaar GIS-format die het ‘aansluiten’ van een geografische triple store op een (Web-)Gis mogelijk maakt. USeekM is gebouwd bovenop de triple store OpenRDF Sesame.
D2RQ
Van RDBMS naar RDF is D2RQ een sterk product en levert het een grote dienst door een brug te slaan tussen de database-geörienteerde GIS-wereld en de RDF triple-store geörienteerde linked data wereld. Conversie van ruimtelijke Postgresql tabellen naar RDF is de verkiezen route, aangezien de alternatieven weinig aanlokkelijk zijn. Voor shapefile of andere GIS-specifieke formaten zijn er weinig RDF-vertalers en het valt niet te verwachten dat die er binnen afzienbare tijd zullen komen. Er is nog het een en ander in ontwikkeling, zoals http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/technologies/151-geometry2rdf, maar is nog zeer experimenteel en slecht gedocumenteerd. D2RQ werkt als vertaler goed aangezien het niet specifiek op geodata is gericht, maar deze wel ondersteunt en bovendien gebruik maakt van vertrouwde Postgresql views en functies. Binair opgeslagen PostGIS-data kan dus in well-known tekst format worden getransformeerd door D2RQ gebruik te laten maken van PostGIS functies. Het heeft dus een breder gebruiksdoel, een grotere user base en is daardoor ook beter doorontwikkeld. De URI-resolver die de Snorql plugin in D2RQ levert biedt is basaal, maar goed bruikbaar.
Sterktes – client side
De SPARQL-GeoJSON Javascript adapter
Deze door E&L ontwikkelde Javascript-bibliotheek is eenvoudig van opzet en direct inzetbaar op vrijwel iedere SPARQL-endpoint die resultaten in MIME format application/sparql-results+json ondersteunt. De toepassing ervan is generiek, met beperkingen dat de brondata als RDF geometrieën in Well Known Text vereist en (nog) geen GML ondersteunt. De bibliotheek bestaat op moment van schrijven uit slechts 71 regels code.
De web-toepassing
De web-toepassing is eveneens in grote mate generiek, net als de javascript-bibliotheken die het ter ondersteuning gebruikt. OpenLayers is een wijd verspreid en algemeen gebruikte web-giscomponent. Er is geen doorslaggevende reden om voor OpenLayers te kiezen in plaats van bijvoorbeeld Leaflet – de auteur is eenvoudigweg beter bekend met OpenLayers.
Zwaktes – server side
uSeekM
Op USeekM is qua servercomponent een hoop aan te merken. Allereerst gaat het om een product dat experimenteel van aard is en eigenlijk niet geschikt voor productie-omgevingen, tenzij deze zeer beperkt van opzet is. GeoKnow heeft meer studie aan USeekM gedaan dan E&L ooit zal kunnen doen. Hun algemene indruk is:
“uSeekM was also problematic is some cases, […] when execution crashed unexpectedly some time after submission. Support for spatial joins should also be key challenge for improvement in the future. […] RDF engines than [sic] utilize a DBMS as their repository (e.g. uSeekM, Strabon) can really take advantage of its geospatial support for storing various geometries and answering mosty types of spatial queries. But they really suffer when it comes to bulk loading of spatial features, because the index (typically, an R-tree) is prebuilt to host all geometries and requires reorganization upon new entries (or deletions or updates on geometries). Instead, those with native support for storing triples in their own structures cope far better with massive insertions. Last, but no least, it was evident that performance of spatial operations in triple stores is poor compared to the one in geospatial DBMS’s; sometimes it is orders of magnitude worse, even without any use of inferencing.” Bron: Athanasiou et al. 2013: 91.
Spatial joins is een onderwerp dat nog wel enige aandacht verdient, aangezien het ook in de overleggen bij de RCE regelmatig naar voren is gekomen. Spatial joining houdt in dat er wordt gezocht of gefilterd op het voorkomen van het éne type object in (of in de buurt van, of niet in, etc.) het andere object, ruimtelijk gezien. In de GeoKnow test is geen enkele triple store in de test in staat gebleken in bulk data goede spatial joins te produceren. Het is daarom raadzaam een toepassing te selecteren – of dit nu uit één of meerdere componenten bestaat – die hier een betere query-planning op toe te passen dan de huidige triple stores doen. Op kleine schaal in de demo, filtering binnen een beperkt geografisch gebied, is uSeekM wel in staat gebleken spatial join SPARQL-queries uit te voeren, dit als belangrijke aanvulling op de GeoKnow studie. Schaalbaarheid is hier een groot probleem.
Tot zover de basale functionaliteit, wat verder stoorde was dat bij fouten in de in te laden dataset, de workbench van uSeekM geen regelnummers vermeldt, indien de importprocedure struikelt een fout in het bronbestand. Dit maakt het zeer lastig om in grote bestanden uit te zoeken waar de fout zich precies bevindt. Daarbij blijkt het ingebouwde workbench-queryscherm vaak niet te werken op geografische queries (de AJAX-query vanuit de demo-toepassing werkt gelukkig wel). De toepassing is daarnaast herhaaldelijk gecrasht, waarbij de toepassing weinig communicatief is over waar het fout liep.
D2RQ
Helaas is D2RQ niet in staat rechtstreeks ruimtelijke queries uit te voeren, dit zou de behoefte aan een aparte GeoSPARQL triple store op deze schaal wegnemen. In een berichtenwisseling met de Universiteit Leipzig heeft één van de programmaleiders echter gewezen op Sparqlify, dat dit mogelijk wel zou kunnen. Het is de moeite waard dit uit te zoeken en de performance en functionaliteit te vergelijken met uSeekM.
Zwaktes – client side
Zowel de javascript-bibliotheek als de demo-toepassing zelf zijn nog werk in uitvoering en derhalve gemankeerd. De javascript kent nog gebreken op het gebied van GML en geometrie-collecties. Ook ondersteunt het nog niet de http://www.w3.org/2003/01/geo/wgs84_pos# – notatie. Ook vereist het dat de aanbiedende data store SPARQL-queryresultaten kan opleveren in het MIME format application/sparql-results+json. Ondersteuning voor JSON-LD zou beter zijn.
De demo-applicatie is gemankeerd in dat het nog een onvolledige linked data-representatie geeft. Linked data dankt zijn nut er grotendeels aan in dat het schakels vormt die in web-bevraagbare links worden uitgedrukt – niet alleen in de brondata, maar ook in de toepassing. Dit doet de demo nog niet – het biedt nog geen hyperlinks naar de data waarnaartoe de data linkt, terwijl deze informatie wel allemaal als URL beschikbaar is. Ook kan de demo nog niet filteren, laat staan semantisch beredeneerd filteren. Ook de dataset die het gebruikt – de Archeologische Monumenten – zou nog aangevuld kunnen worden met extra links, bijvoorbeeld voor de plaatsnamen naar GeoNames.
Conclusie
Erfgoed & Locatie heeft een demo-applicatie op het web gepubliceerd op http://erfgeo.nl/geosparql/geosparql-demo.html. Hoofddoel van deze demo is het kleinschalig onderzoeken van de werkbaarheid en tekortkomingen van GeoSPARQL als bevragingsmodel in de vorm van uSeekM, een GeoSPARQL triple store.
Uit de demo is ons gebleken dat uSeekM aan de basale eisen en functionaliteit van GeoSPARQL voldoet, maar dat de grenzen van schaalbaarheid snel in zicht komen, bijvoorbeeld als er ruimtelijke joins worden toegepast waarin bijvoorbeeld wordt gezocht waar archeologische waarnemingen zich bevinden binnen archeologische monumententerreinen. De belangrijkste tekortkomingen zijn opgesomd door het GeoKnow project in hun Market and Research Overview. De conclusie is daarom dat uSeekM experimenteel is, en een zeer interessante kijk geeft op hoe het nut van GeoSPARQL zich bewijst en in welke richtingen de toepassing ontwikkeld zou kunnen worden.
Literatuur
Athanasiou, S./L. Bezati/G. Giannopoulos/et al. 2013: Deliverable 2.1.1. Market and Research Overview, Z.P. (geraadpleegd op 10-1-2014 op http://svn.aksw.org/projects/GeoKnow/Public/D2.1.1_Market_and_Research_Overview.pdf)