GeoSPARQL kennispagina

category:case3
Momenteel bevat deze pagina een paar specifieke vragen en antwoord over GeoSPARQL, en gebruikerservaringen met een GeoSPARQL triple store. Het is de bedoeling om hier meer kennis over GeoSPARQL vast te leggen!
= GeoSPARQL as a vocabulary for describing geometries =
Rephrasing Christophe Gueret in his presentation at the PilOD kickoff: it is preferable to represent geometries as resources/identified objects, instead of as string values of properties, because then the geometries are stored as resources and are therefore reusable, and can be referenced by other resources. 
 
GeoSPARQL offers two options for encoding geometry in RDF: asWKT and asGML. WKT is a string representation of geometries, and the as GML option would be the representation of geometry as a resource. But is this really the case? The asGML property is described as a text serialization of GML geometries. 
 
geo:asGML a rdf:Property;
rdfs:subPropertyOf geo:hasSerialization;
rdfs:isDefinedBy <http://www.opengis.net/spec/geosparql/1.0>;
rdfs:label "as GML"@en;
rdfs:comment "The GML serialization of a geometry."@en;
rdfs:domain geo:Geometry;
rdfs:range geo:gmlLiteral .
 
geo:gmlLiteral a rdfs:Datatype;
rdfs:isDefinedBy <http://www.opengis.net/spec/geosparql/1.0>;
rdfs:label "GML literal"@en;
rdfs:comment "The datatype of GML literal values"@en .
 
A sample geometry: 
:spatialextent
a geosparql:Geometry;
geosparql:asGML "<gml:Polygon srsName="EPSG:28992"><gml:exterior><gml:LinearRing>
 <gml:posList srsDimension="2">97372 487153 97372 580407 149636 580407 149636 487153 97372 487153</gml:posList>
</gml:LinearRing></gml:exterior></gml:Polygon>"^^geosparql:gmlLiteral;
.
= Completeness = 
Is GeoSPARQL missing something here? Should gml:Polygon and gml:LinearRing from this example be resources instead of just embedded literal text? 
 
(answer by Christophe Gueret) 
What GeoSPARQL recommends is a sound choice. They create a resource for the geometry and then describe this geometry using one of the two possible serialisations. Those that want to say something about this geometry can refer to the geometry resource. It is still not possible to refer to individual points in the contour but I don't think anyone would really need that.
Here are the different modelling choices I see to say that "A has a contour X", with X being a literal in WKT.
1) Contour as a property
A hasWKTContour "X"
2) Contour as an object
A hasContour Contour
Contour asWKT "X"
3) Contour as list of points within an object
A hasContour Contour
Contour type Polygon
Contour hasPoint X1
X1 type Point
X1 hasLat "X1lat"
X1 hasLong "X1long"
Contour hasPoint X2
...
2) is what GeoSPARQL recommends, 1) is the thing I said make it harder to refer to the contour. As you see, you would also need one specific property for every property of the contour itself. It is like for events: to refer to a birth event one may link an object to an event of type death or list all the relevant properties (birthDate, birthPlace, ...) as describing the subject of the event. There are pro and cons to both approach but generally people tend to prefer creating dedicated objects like in 2)
3) would make it possible to comment on every specific point of the contour by making triples about "X1" for instance. But this would generate a lot of triples and be harder to process. Furthermore, RDF has a problems keeping an ordered list of things. There are (not so elegant sometimes) solutions to it but, by default, you can expect the order of the points to be randomized. In that case, the contour won't be rendered so nicely on the screen ;-)
So 2) definitely gets a +1 from me.
To be still a bit picky, I would say that creating a "geosparql:gmlLiteral" literal type is not necessary and can be problematic sometimes. There are RDF parsers that really don't like custom data types and I think, but I would have to double check that, that the official best practice nowadays is to not use them at all. So they could/should have just used a plain literal and rely on the description of "geo:asGML" to explain that the literal has to be parsed as a GML string (but without setting the domain to a specific data type).
= Ervaringen met GeoSPARQL vanuit een demo door Erfgoed & Locatie = 
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 2x2.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 op het 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.ttl voor 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)