Geographical Features and Their Geometry
Ghislain Auguste Atemezing, Rapha¨el Troncy EURECOM, Sophia Antipolis, France, {auguste.atemezing, raphael.troncy}@eurecom.fr
Abstract. The need for geolocation is crucial for many applications for both human and software agents. More and more data is opened and interlinked using Linked Data principles, and it is worth modeling ge- ographic data efficiently by reusing as much as possible from existing ontologies or vocabularies that describe both the geospatial features and their shapes. In this paper, we survey different modeling approaches used by the Geographic Information System (GIS) and the Linked Open Data (LOD) communities. Our aim is to contribute to the actual efforts in rep- resenting geographic objects with attributes such as location, points of interest (POI) and addresses in the web of data. We focus on the French territory and we provide examples of representative vocabularies that can be used for describing geographic objects. We propose some alignments between various vocabularies (DBpedia, Geonames, Schema.org, Linked- GeoData, Foursquare, etc.) in order to enable interoperability while in- terconnecting French geodata with other datasets. We tackle the complex geometry representation issues in the Web of Data, describing the state of implementations of geo-spatial functions in triple stores and compar- ing them to the new GeoSPARQL standard. We conclude with some challenges to be taken into account when dealing with the descriptions of complex geometries.
Keywords: Geodata, GeoSPARQL, Geographic information, Schema Alignment, Datalift
1 Introduction
The increasing number of initiatives for sharing geographic information on the web of data has significantly contribute to the interconnection of many data sets exposed as RDF based on the Linked Data principles. Many domains are represented in the web of data (media, events, academic publications, libraries, cultural heritage, life science, government data, etc.) while DBpedia is the most used dataset for interconnection. For many datasets published, geospatial infor- mation is required for rendering data on a map. In the current state of the art, different approaches and vocabularies are used to represent the “features” and their geometric shape although the POINT is the most common representation making use of the latitude/longitude properties defined in the W3C Geo vocabu- lary. Other geometries from the OpenGIS standard (POLYGON, LINESTRING,
etc.) are more rarely exploited (e.g. LinkedGeoData, GeoLinkedData) while fine- grained geometry representations are often required.
In France, the National Geographic Institute (IGN) has started to publish more and more data in RDF, as illustrated by the recent experimental LOD service http://data.ign.fr. IGN maintains large databases composed of de- scriptions of addresses, buildings, topographic information, occupied zones, etc.
A few years ago, IGN has developed a core ontology named GeOnto for de- scribing all types of buildings located in the French territory. Integrating these databases will enable answering more complex queries than current GIS systems can handle, such as: “show all buildings used as tribunal courts in the 7th Ar- rondissement of Paris”. Another use-case is the possibility to reason over parts of a structure: “show the points where the river Seine touches a boundary of a district in Paris that contain an activity zone”.
In this paper, we address some of these uses cases, starting from the selec- tion of the right vocabularies to represent the data and their alignment to ease future dataset interlinking. We first analyze the use of geographical informa- tion in the web of data (Section 2). Then, we survey the existing approaches for modeling both the features and their geometries (Section 3). We define the scenario of modeling the 7tharrondissement of Paris to highlight the diversity of these approaches (Section 4). We then propose alignments between vocabularies to describe features or points of interest using GeOnto as our pivot ontology (Section 5). To address geometry modeling, we also survey existing approaches, leading to an extension of GeOnto to support geometry. We look at the triple stores supporting all types of geometry and discuss some challenging issues re- garding geodata as the GeoSPARQL1 standard has recently been adopted by the Open Geospatial Consortium (Section 6). Finally, we give our conclusions and outline future work (Section 7).
2 Geographic information in the Web of Data
2.1 LOD Cloud Review
The recent publication of statistics concerning the actual usage of vocabularies on the LOD cloud2 provides not only an overview of best practice usage recom- mended by Tim Berners-Lee3, but also provides a rapid view of the vocabularies re-used in various datasets and domains. Concerning the geographic domain, the results show that W3C Geo4 is the most widely used vocabulary, followed by thespatialrelations5ontology of Ordnance Survey (OS). At the same time, the analysis reveals that the property geo:geometry is used in 1,322,302,221 triples, exceeded only by the properties rdf:type (6,251,467,091 triples) and
1 http://www.opengeospatial.org/standards/geosparql
2 http://stats.lod2.eu
3 http://www.w3.org/DesignIssues/LinkedData.html
4 http://www.w3.org/2003/01/geo/wgs84_pos
5 http://data.ordnancesurvey.co.uk/ontology/spatialrelations
rdfs:label(1,586,115,316 triples). This shows the importance of geodata on the web. Table 1 summarizes the results for four vocabularies (WGS84, OS spa- tial relation, Geonames ontology and OS admin geography) where the number of datasets using these vocabularies and the actual number of triples are computed.
Ontologies #Datasets using #Triples SPARQL endpoint
W3C Geo 21 15 543 105 LOD cache
OS spatialrelations 10 9 412 167 OS dataset
Geonames ontology 5 8 272 905 LOD cache
UK administrative-geography 3 229 689 OS dataset Table 1.Statistics on the usage of the four main geographic vocabularies (LOD cache should be understood ashttp://lod.openlinksw.com/sparql/). There are many more vocabularies used in the LOD cloud that contain also geographical information but that are never re-used.
2.2 Geodata Provider and Access
So far, the Web of data has taken advantage of geocoding technologies for pub- lishing large amounts of data. For example, Geonames provides more than 10 millions records (e.g. 5,240,032 resources of the form http://sws.geonames.
org/10000/) while LinkedGeoData has more than 60,356,364 triples. All the above mentioned data are diverse in their structure, the access point (SPARQL endpoint, web service or API), the entities they represent and the vocabularies used for describing them. Table 2 summarizes for different providers the number of geodata available (resources, triples) and how the data can be accessed.
Provider #Geodata Data access
DBpedia 727 232 triples SPARQL endpoint
Geonames 5 240 032 (feature). API
LinkedGeoData 60 356 364 triples SPARQL endpoint, Snorql
Foursquare n/a API
Freebase 8,5MB RDF Freebase Service
Ordnance Survey(Cities) 6 295 triples Talis API GeoLinkedData.es 101 018 triples SPARQL endpoint
Google Places n/a Google API
GADM project data 682 605 triples Web Service NUTS project data 316 238 triples Web Service IGN experimental 629 716 triples SPARQL endpoint
Table 2.Geodata by provider and their different access type
3 Geodata Modeling Approach
3.1 Vocabularies for Features
Modeling of features can be grouped into four categories depending on the struc- ture of the data, the intended purpose of the data modeling, and the (re)-use of other resources.
– (i): One way for structuring the features is to define high level codes (gener- ally using a small finite set of codes) corresponding to specific types. Further, sub-types are attached to those codes in the classification. This approach is used in the Geonames ontology6for codes and classes (A, H, L, P, R, S, T, U, V), with each of the letter corresponding to a precise category (e.g: A for administrative borders). Classes are then defined asgn:featureClass a skos:ConceptScheme, while codes aregn:featureCode a skos:Concept.
– (ii): A second approach consists in defining a complete standalone ontology that does not reuse other vocabularies. A top level class is used under which a taxonomy is formed using the rdfs:subClassOf property. The Linked- GeoData ontology7 follows this approach, where the 1294 classes are built around a nucleus of 16 high-level concepts which are:Aerialway, Aeroway, Amenity, Barrier, Boundary, Highway, Historic, Landuse, Leisure, ManMade, Natural, Place, Power, Route, TourismandWaterway. The same approach is used for the French GeOnto ontology (Section 5), which defined two high-level classesArtificialTopographyEntityandNatural- TopographyEntitywith a total of 783 classes.
– (iii): A third approach consists in defining several smaller ontologies, one for each sub-domain. An ontology network is built with a central ontology used to interconnect the different other ontologies. One obvious advantage of this approach is the modularity of the conceptualizing which should ease as much as possible the reuse of modular ontologies. Ordnance Survey (OS) follows this approach providing ontologies for administrative regions8, for statistics decomposition9 and for postal codes10. The owl:imports state- ments are used in the core ontology. Similarly, GeoLinkedData makes use of three different ontologies covering different domains.
– (iv): A fourth approach consists in providing a nearly flat list of features or points of interest. This is the approach followed by popular Web APIs such as Foursquare types of venue11 or Google Place categories12. For this last approach, we have built an associated OWL vocabulary composed of alignments with other vocabularies.
3.2 Vocabularies for Geometry Shape
The geometry of a point of interest is also modeled in different ways. We complete here the survey started by Salas and Harth [8]:
– Point representation: the classical way to represent a location by providing the latitude and longitude in a given coordinate reference system (the most
6 http://geonames.org/ontology/ontology_v3.0.rdf
7 http://linkedgeodata.org/ontology
8 http://www.ordnancesurvey.co.uk/ontology/admingeo.owl
9 http://statistics.data.gov.uk/def/administrative-geography
10http://www.ordnancesurvey.co.uk/ontology/postcode.owl
11http://aboutfoursquare.com/foursquare-categories/
12https://developers.google.com/maps/documentation/places/supported_types
used on the web is the WGS84 datum represented in RDF by the W3C Geo vocabulary). For example, Geonames defines the class gn:Feature a skos:ConceptSchemeas aSpatialThingin the W3C Geo vocabulary.
– Rectangle(“bounding box”): which represents a location with two points or four segments making a geo-referenced rectangle. In this way of modeling, the vocabulary provides more properties for each segment. The FAO Geopolitical ontology13 uses this approach.
– List of Points: the geometry shape is a region represented by a collection of points, each of them being described by a unique RDF node identified by a lat/lon value. TheNodeclass is used to connect one point of interest with its geometry representation. The POI are modeled either asNodeor asWaynode (surfaces). This approach is followed by LinkedGeoData [1].
– Sequence of Points: the geometry shape is represented by a group of RDF resources called a “curve” (similar to LineString of GML). The POI is con- nected to its geometry by the propertyformedByand an attributeorderto specify the position of each node in the sequence. This approach is the one used in GeoLinkedData [3].
– Literals: the vocabulary uses a predicate to include the GML representation of the geometry object, which is embedded in RDF as a literal. This approach is followed by Ordance Survey [4].
– Structured representation: the geometry shape is represented as a typed re- source. In particular, polygons and lines are represented with an RDF col- lection of basic W3C Geo points. This approach is used by the NeoGeo vocabulary14.
4 Scenario: 7
thArrondissement of Paris
The 7tharrondissement of Paris is one of the 20 arrondissements (administrative districts) of the capital city of France. It includes some of Paris’s major tourist attractions such as the Eiffel Tower, some world famous museums (e.g: mus´ee d’Orsay) and contains a number of French national institutions, including nu- merous government ministries15. We use it throughout this paper to highlight the diversity of representations one can use for this geographical entity. We assume that this district should be modeled as a POLYGON composed of a number of POINTs needed to “interpolate” its effective boundaries. We assume the use of the WGS8416geodetic system.
4.1 DBpedia Modeling
We provide below an excerpt of the DBpedia description for this resource.
13http://www.fao.org/countryprofiles/geoinfo/geopolitical/resource/
14http://geovocab.org/doc/neogeo/
15http://en.wikipedia.org/wiki/7th_arrondissement_of_Paris
16http://en.wikipedia.org/wiki/World_Geodetic_System
dbpedia:7th_arrondissement_of_Paris a gml:_Feature ; a <http://dbpedia.org/class/yago/1900SummerOlympicVenuEs>
rdfs:label "7. arrondissementti (Pariisi)"@fi; (14 different languages) dbpprop:commune "Paris" ;
dbpprop:d´epartement dbpedia:Paris ;
dbpprop:r´egion dbpedia:^Ile-de-France_(region) ; grs:point "48.85916666666667 2.312777777777778" ; geo:geometry "POINT(2.31278 48.8592)" ;
geo:lat "48.859165"^^xsd:float;
geo:long "2.312778"^^xsd:float.
First, we observe that the typegml: Feature and the propertygrs:point are not resolvable since there are no OWL ontologies that provide a description of them. Second, the property geo:geometry used by DBpedia is not defined in the WGS84 vocabulary. For the geometry, the 7tharrondissement is a simple POINT defined by a latitude and a longitude.
4.2 Geonames Modeling
In Geonames, the 7tharrondissement is considered as a 3rdorder administrative division, represented by a POINT for the geometry model. The RDF description of this resource gives other information such as the alternate name in French, the country code and the number of inhabitants.
gnr:6618613 a gn:Feature ; gn:name "Paris 07";
gn:alternateName "7`eme arrondissement";
gn:featureClass gn:A [ a skos:ConceptScheme ;
rdfs:comment "country, state, region ..."@en . ] ;
gn:featureCode gn:A.ADM4 [ a skos:Concept ;
rdfs:comment "a subdivision of a third-order administrative division"@en . ];
gn:countryCode "FR";
gn:population "57410";
geo:lat "48.8565";
geo:long "2.321".
4.3 LinkedGeoData Modeling
In LinkedGeoData, the district is algdo:Suburb rdfs:subClassOf ldgo:Place.
Its geometry is still modeled as a POINT and not as a complex geometry of type POLYGON as we could have expected for this type of spatial object.
lgd:node248177663 a lgdo:Suburb ;
rdfs:label "7th Arrondissement"@en , "7e Arrondissement" ; lgdo:contributor lgd:user13442 ;
lgdo:ref%3AINSEE 75107 ;
lgdp:alt_name "VIIe Arrondissement" ; georss:point "48.8570281 2.3201953" ; geo:lat 48.8570281 ;
geo:long 2.3201953 .
4.4 Discussion
These samples from DBpedia, Geonames and LinkedGeoData give an overview of the different views of the same reality, in this case the district of the 7th Ar- rondissement in Paris. Regarding the “symbolic representation”, two datasets
opted for “Feature” (DBpedia and Geonames) while LGD classifies it as a “Sub- urb” or “Place”. They all represent the shape of the district as a POINT which is not very efficient if we consider a query such as show all monuments located within the 7tharrondissement of international importance. To address this type of query and more complicated ones, there is a need for more advanced modeling as we describe in the next section.
5 Aligning Geo Vocabularies
IGN is a public service in France in charge of describing, from the physical and geometry point of view, the surface of the French territory and the occupation of the land, and to elaborate and update continuously the forestal resources. They are also experimenting in exposing some of their data as Linked Data and act as an important provider in thehttp://data.gouv.frportal.
5.1 Existing Vocabularies
IGN has developed two complementary vocabularies (GeOnto and bdtopo) which differ in their provenance but have the same scope, which is to describe geo- graphic entities in the French territory. GeOnto is the product of a research project17 aiming at building and aligning heterogeneous ontologies in the ge- ographic domain. The “light” version of the final ontology18 defines two top classes for a total of 783 classes and 17 properties (12 DP / 5 OP). GeOnto has labels in both French and English, but has no comments specified for the resources. The bdtopo ontology is derived from a geospatial database with the same name. It contains 237 classes and 51 properties (47 DP / 4 OP). All the labels and comments are in French.
5.2 GeOnto Alignment Process
The first step towards interoperability of French geographic features and the ex- isting vocabularies is to align GeOnto to other vocabularies. We choose GeOnto because it covers a large number of categories and also has labels in English.
We have performed the alignment with five OWL vocabularies (bdtopo, LGD, DBpedia, Schema.org and Geonames) and two flat taxonomies (Foursquare, Google Place). For the latter, we have transformed the flat list of types and categories into an OWL ontology. For each alignment performed, we only con- sider owl:equivalentClass axioms. We use the Silk tool [9] to compute the alignment using two metrics for string comparison: thelevenshteinDistance and jarodistances. They work on the English labels except for the alignment with bd- topo where we use the French labels. We apply the average aggregation function on these metrics with an empirically derived threshold. However, for generating
17http://geonto.lri.fr/Livrables.html
18http://semantics.eurecom.fr/datalift/tc2012/vocabs/GeoOnto/
the final mapping file for vocabularies of small size, we manually validate and insert relations of typerdfs:subClassOf. The threshold to validate the results is set to 100% for links considered to be correct and greater than 40% for links to be verified. The alignment with Geonames is special, considering the property restriction used in the ontology for codes.
Table 3 summarizes the result of the alignment process between GeOnto and the existing vocabularies/taxonomies. All the resources of this work are available athttp://semantics.eurecom.fr/datalift/tc2012/.
Vocabulary #Classes #Aligned Classes
LGD owl:Class:1294 178
DBpedia owl:Class:366 42
Schema.org owl:Class:296 52
Geonames skos:ConceptScheme:12 –
skos:Concept:699 287
Foursquare 359 46
Google Place 126 41
bdtopo owl:Class:237 153
Table 3. Results of the alignment process between GeOnto and existing vocabular- ies/taxonomies.
In general, we obtain good results with Silk, with precision beyond 80%:
Google Place: 94%, LGD: 98%, DBpedia: 89%, Foursquare: 92% , Geonames:
87% and bdtopo: 92%. We obtained a precision of only 50% with schema.org due to numerous fine-grained categories that are badly aligned (e.g.ign:Berge owl:equivalentClass schema:Park).
6 Challenges
6.1 GeoSPARQL
OGC has adopted the GeoSPARQL standard to support both representing and querying geospatial data on the Semantic Web. The standard document [7] con- tains 30 requirements. It also defines a vocabulary for representing geospatial data in RDF and provides an extension to the SPARQL query language for pro- cessing geospatial data. The proposed standard follows a modular design with five components: (i) Acore componentdefining top-level RDFS/OWL classes for spatial objects; (ii) ageometry component defining RDFS data types for serial- izing geometry data, RDFS/OWL classes for geometry object types, geometry- related RDF properties, and non-topological spatial query functions for geometry objects; (iii) ageometry topology componentdefining topological query functions;
(iv) a topological vocabulary component defining RDF properties for asserting topological relations between spatial objects; and (iv) aquery rewrite component defining rules for transforming a simple triple pattern that tests a topological
relation between two features into an equivalent query involving concrete geome- tries and topological query functions. Each of the components described above has associated requirements. Concerning the vocabulary requirements, Table 4 summarizes the seventeen requirements presented in the GeoSPARQL draft doc- ument.
Geographic Aspect
RequirementImplementation Definition
Req 2 The ClassSpatialObjectshould be defined & accepted Req 3 DefinesFeature rdfs:subClassOf SpatialObject Feature Req 4 Defines 8 Simple Features Object Properties(OP)
Req 5 Defines 8 Egenhofer OP with domain and range Req 6 Defines 8 RCC OP with domain and range
Req 7 DefinesGeometry rdfs:subClassOf SpatialObject Geometry Req 8 Defines OPhasGeometryanddefaultGeometry
Req 9 Defines 6 Data Properties: e.g:dimension, isEmpty, etc.
Req 10-13 wktLiteraldefinitions & URI encoding Serialization Req 14 DefinesasWKTto retrieve WKTLiteral
Req 15-17 GMLLiteral should be accepted Req 18 DefinesasGMLto retrieve GMLLiteral
Table 4. Requirements and implementations for vocabulary definitions in GeoSPARQL.
Based on the GeoSPARQL requirements, we were interested in comparing some geospatial vocabularies19 to see how far they take already into account topological functions and which are the standard they followed among OpenGIS Simple Features (SF), Region Connection Calculus (RCC) and Egenhofer rela- tions. We find that the NeoGeo (Spatial and Geometry) and OS Spatial vocab- ularies have integrated in their modeling partial or full aspects of topological functions as summarized in Table 5.
As geodata has to be stored in triple stores with efficient geospatial index- ing and querying capabilities, we also survey the current state of the art in supporting simple or complex geometries and topological functions compatible with SPARQL 1.1. Table 6 shows which triple stores can support part of the GeoSPARQL standard regarding serialization and spatial functions.
6.2 Some Recommendations
The alignment of GeOnto provided in the previous section enables interoperabil- ity of symbolic descriptions. The need for a better choice of geometric structure, typically the choice between literal versus structured representations depends on three criteria: (i) the coverage of all the complex geometries as they appear
19http://labs.mondeca.com/dataset/lov/vocabularySpace_Space.html
Geo-vocabulary Topological Func- tions
GeoSPARQL Re- quirements
Standard Fol- lowed
Ordnance Survey Spatial
easting, northing, touches, within, contains
Part of Req 4 OpenGIS Simple Feature
Ordnance Survey Topography
contains, isContainedIn
Very small part of Req 4
OpenGIS Simple Feature
Place Ontology in, overlaps, bounded by
Small part of Req 4 N/A
NeoGeo Spatial All RCC8 relations Part of Req 3; Req 6 Region Connection Calculus (RCC)
NeoGeo Geometry — Req 10 - 14 N/A
FAO Geopolitical isInGroup, hasBorderWith
– –
OntoMedia Space adjacent-below, adjacent-above, orbit-around, is boundary-of, has-boundary
– –
Table 5.Comparison of some geo-vocabularies with respect to the GeoSPARQL re- quirements.
in the data; (ii) a rapid mechanism for connecting “features” to their respec- tive “geometry”; (iii) the possibility to serialize geodata into traditional formats used in GIS applications (GML, KML, etc.) and (iv) the choice of triple stores supporting as many as possible functions to perform quantitative reasoning on geodata. It is clear that a trade-off should be taken depending on the techno- logical infrastructure (e.g: data storage capacity, further reasoning on specific points on a complex geometry).
– Complex Geometry Coverage: We have seen that on the Web of Data, there are few modeling of geodata with their correct shape represented as a LINE or POLYGON. However, some content providers (e.g. IGN) need to publish all types of geodata including complex geometries representing roads, rivers, administrative regions, etc. Two representations are suitable:
OS Spatial and NeoGeo ontologies (Table 4). Direct representation of the GeoSPARQL vocabulary is also suitable.
– Features connected to Geometry:In modeling geodata, we advocate a clear separation between the features and their geometry. This is consistent with the consensus obtained from the different GeoVocamps20and the out- come of this approach is expressed in the modeling design of NeoGeo. The top level classes spatial:Feature and geom:Geometryare connected with the propertygeom:geometry.
20http://www.vocamp.org
– Serialization and Triple stores: We also advocate the use of proper- ties that can provide compatibility with other formats (GML, KML, etc.).
This choice can be triple store independent, as there could be ways to use content-negotiation to reach the same result. In Table 6, Open Sahara21, Parliament 22,Virtuoso23are WKT/GML-compliant with respectively 23 and 13 functions dealing with geodata.
– Literal versus structured Geometry:Decomposing a LINE or a POLY- GON into multiple results in an “explosion” in the size of the dataset and the creation of numerous blank nodes. However, sharing points between de- scriptions is a use case with such a need. IGN has such use-cases and the natural solution at this stage is to consider reusing the NeoGeo ontology in the extended version of GeOnto. The choice of the triple store (e.g.,Virtuoso vs Open Sahara) is not really an issue, as the IndexingSail24 service could also be wrapped on-top of Virtuoso to support full OpenGIS Simple Features functions25.
Triple store
WKT- compliance
GML- compliance
Geometry supported
Geospatial Functions
GeoVocab
Virtuoso Yes Yes Point 13 func-
tions
W3C Geo + Typed Literal Allegro-
Graph
- – Point 3 functions “strip” mapping data OWLIM-
SE
– – Point 4 functions W3C Geo
Open Sa- hara
Yes Yes Point,
Line, Polygons
23 func- tions
Typed Literal
Parliament Yes Yes Point, Line, Polygons
23 func- tions
GeoSPARQL vocabulary
Table 6.Triple stores survey with respect to geometry types supported and geospatial functions implemented.
7 Conclusions and Future Work
We have presented in this paper a first step towards interoperability of French geodata in the Semantic Web. The survey of existing modeling of points of in- terest and geometry shows the different vocabularies and modeling choices used
21http://www.opensahara.com
22http://geosparql.bbn.com
23http://www.openlinksw.com
24https://dev.opensahara.com/projects/useekm/wiki/IndexingSail
25http://www.opengeospatial.org/standards/sfs
to represent them. In France, there is a currently a joint effort to publish geo- graphic information in RDF and interlink them with relevant datasets. GeOnto is an ontology describing geospatial features for the French territory. We have proposed to align GeOnto with other popular vocabularies in the geospatial do- main. We have used Silk for schema mapping and we have evaluated the results.
We studied how to extend the model to take into account efficient modeling for complex geometries. By doing so, we revisited current implementations of geo- vocabularies and triple stores to check out their compatibility with respect to the new GeoSPARQL standard . We finally made some recommendations and advocate for the reuse of the NeoGeo ontology within GeOnto to better address the IGN requirements. Our future work includes the conversion and publication of a large RDF dataset of geographic information of the French territory together with alignments with other datasets at the instance level.
Acknowledgments
This work has been partially supported by the French National Research Agency (ANR) within the Datalift Project, under grant number ANR-10-CORD-009.
References
1. S. Auer, J. Lehmann, and S. Hellmann. LinkedGeoData - Adding a Spatial Dimen- sion to the Web of Data. In International Semantic Web Conference (ISWC’09), 2009.
2. C. Bizer, T. Heath, and T. Berners-Lee. Linked Data - The Story So Far. Interna- tional Journal on Semantic Web and Information Systems, 5:1–22, 2009.
3. A. de Le´on, L. M. Vilches, B. Villaz´on-Terrazas, F. Priyatna, and O. Corcho. Geo- graphical linked data: a Spanish use case. InInternational Conference on Semantic Systems (I-SEMANTICS’10), Graz, Austria, 2010.
4. J. Goodwin, C. Dolbear, and G. Hart. Geographical Linked Data: The Adminis- trative Geography of Great Britain on the Semantic Web. Transactions in GIS, 12:19–30, 2008.
5. K. Janowicz, S. Schade, A. Br¨oring, C. Kessler, C. Stasch, P. Mau´e, and T. Diekhof.
A transparent semantic enablement layer for the geospatial web. InTerra Cognita Workshop, 2009.
6. S. Musti`ere, N. Abadie, N. Aussenac-Gilles, M.-N. Bessagnet, M. Kamel, E. Ker- gosien, C. Reynaud, and B. Safar. G´eOnto : Enrichissement d’une taxonomie de concepts topographiques. In Spatial Analysis and GEOmatics (Sageo’09), Paris, France, 2009.
7. M. Perry and J. Herring. OGC GeoSPARQL- A Geographic Query Language for RDF Data. InOGC Implementation Standard, ref: OGC 11-052r4, 06 2012.
8. J. Salas and A. Harth. Finding spatial equivalences accross multiple RDF datasets.
InTerra Cognita Workshop, pages 114–126, Bonn, Germany, 2011.
9. J. Volz, C. Bizer, M. Gaedke, and G. Kobilarov. Discovering and Maintaining Links on the Web of Data. InInternational Semantic Web Conference (ISWC’09), 2009.
