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 geographic data e ciently 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 di erent modeling approaches used by the Geographic Information System (GIS) and the Linked Open Data (LOD) communities. Our aim is to contribute to the actual e orts in representing 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, LinkedGeoData, Foursquare, etc.) in order to enable interoperability while interconnecting 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 comparing them to the new GeoSPARQL standard. We conclude with some challenges to be taken into account when dealing with the descriptions of complex geometries.
The increasing number of initiatives for sharing geographic information on the web of data has signi cantly 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 information is required for rendering data on a map. In the current state of the art, di erent 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 de ned in the W3C Geo vocabulary. Other geometries from the OpenGIS standard (POLYGON, LINESTRING, etc.) are more rarely exploited (e.g. LinkedGeoData, GeoLinkedData) while negrained 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 descriptions of addresses, buildings, topographic information, occupied zones, etc. A few years ago, IGN has developed a core ontology named GeOnto for describing 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 Arrondissement 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 selection of the right vocabularies to represent the data and their alignment to ease future dataset interlinking. We rst analyze the use of geographical information in the web of data (Section 2). Then, we survey the existing approaches for modeling both the features and their geometries (Section 3). We de ne the scenario of modeling the 7th arrondissement 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 regarding 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 2.1
Geographic information in the Web of Data
The recent publication of statistics concerning the actual usage of vocabularies on the LOD cloud2 provides not only an overview of best practice usage recommended 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 the spatialrelations5 ontology 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 spatial relation, Geonames ontology and OS admin geography) where the number of datasets using these vocabularies and the actual number of triples are computed.
W3C Geo 21 15 543 105 LOD cache
Table 1. Statistics on the usage of the four main geographic vocabularies (LOD cache should be understood as http://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
So far, the Web of data has taken advantage of geocoding technologies for publishing 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 di erent providers the number of geodata available (resources, triples) and how the data can be accessed.
Modeling of features can be grouped into four categories depending on the structure 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 de ne high level codes (generally using a small nite set of codes) corresponding to speci c types. Further, sub-types are attached to those codes in the classi cation. This approach is used in the Geonames ontology6 for 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 de ned as gn:featureClass a skos:ConceptScheme, while codes are gn:featureCode a skos:Concept. { (ii): A second approach consists in de ning 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 LinkedGeoData 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, Tourism and Waterway. The same approach is used for the French GeOnto ontology (Section 5), which de ned two high-level classes ArtificialTopographyEntity and NaturalTopographyEntity with a total of 783 classes. { (iii): A third approach consists in de ning several smaller ontologies, one for each sub-domain. An ontology network is built with a central ontology used to interconnect the di erent 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 statements are used in the core ontology. Similarly, GeoLinkedData makes use of three di erent ontologies covering di erent domains. { (iv): A fourth approach consists in providing a nearly at 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
The geometry of a point of interest is also modeled in di erent ways. We complete
here the survey started by Salas and Harth [
Scenario: 7th Arrondissement of Paris The 7th arrondissement 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 Ei el Tower, some world famous museums (e.g: musee d'Orsay) and contains a number of French national institutions, including numerous 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 e ective boundaries. We assume the use of the WGS8416 geodetic system. 4.1
We provide below an excerpt of the DBpedia description for this resource. 13 http://www.fao.org/countryprofiles/geoinfo/geopolitical/resource/ 14 http://geovocab.org/doc/neogeo/ 15 http://en.wikipedia.org/wiki/7th_arrondissement_of_Paris 16 http://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:departement dbpedia:Paris ; dbpprop:region dbpedia:I^le-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 type gml: Feature and the property grs: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 de ned in the WGS84 vocabulary. For the geometry, the 7th arrondissement is a simple POINT de ned by a latitude and a longitude. 4.2
In Geonames, the 7th arrondissement is considered as a 3rd order 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 "7eme 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
In LinkedGeoData, the district is a lgdo: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
These samples from DBpedia, Geonames and LinkedGeoData give an overview of the di erent views of the same reality, in this case the district of the 7th Arrondissement in Paris. Regarding the \symbolic representation", two datasets opted for \Feature" (DBpedia and Geonames) while LGD classi es it as a \Suburb" or \Place". They all represent the shape of the district as a POINT which is not very e cient if we consider a query such as show all monuments located within the 7th arrondissement 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
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 the http://data.gouv.fr portal. 5.1
IGN has developed two complementary vocabularies (GeOnto and bdtopo) which di er in their provenance but have the same scope, which is to describe geographic entities in the French territory. GeOnto is the product of a research project17 aiming at building and aligning heterogeneous ontologies in the geographic domain. The \light" version of the nal ontology18 de nes 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 speci ed 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
The rst step towards interoperability of French geographic features and the
existing 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 ve OWL vocabularies (bdtopo, LGD,
DBpedia, Schema.org and Geonames) and two at taxonomies (Foursquare,
Google Place). For the latter, we have transformed the at list of types and
categories into an OWL ontology. For each alignment performed, we only
consider owl:equivalentClass axioms. We use the Silk tool [
Table 3 summarizes the result of the alignment process between GeOnto and the existing vocabularies/taxonomies. All the resources of this work are available at http://semantics.eurecom.fr/datalift/tc2012/.
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 ne-grained categories that are badly aligned (e.g. ign:Berge owl:equivalentClass schema:Park). 6 6.1
OGC has adopted the GeoSPARQL standard to support both representing and
querying geospatial data on the Semantic Web. The standard document [
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 relations. We nd that the NeoGeo (Spatial and Geometry) and OS Spatial vocabularies 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 e cient geospatial indexing 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
The alignment of GeOnto provided in the previous section enables interoperability 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 19 http://labs.mondeca.com/dataset/lov/vocabularySpace_Space.html Geo-vocabulary
Topological Func- GeoSPARQL Re- Standard Foltions quirements lowed
northing, Feature touches, within, contains
isContainedIn Req 4 Feature in, overlaps, Small part of Req 4 N/A bounded by
Req 10 - 14 N/A { { in the data; (ii) a rapid mechanism for connecting \features" to their respective \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-o should be taken depending on the technological infrastructure (e.g: data storage capacity, further reasoning on speci c 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 di erent GeoVocamps20 and the outcome of this approach is expressed in the modeling design of NeoGeo. The top level classes spatial:Feature and geom:Geometryare connected with the property geom:geometry. 20 http://www.vocamp.org { Serialization and Triple stores: We also advocate the use of properties 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, Virtuoso23 are WKT/GML-compliant with respectively 23 and 13 functions dealing with geodata. { Literal versus structured Geometry: Decomposing a LINE or a POLYGON into multiple results in an \explosion" in the size of the dataset and the creation of numerous blank nodes. However, sharing points between descriptions 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
compliance compliance supported Functions
We have presented in this paper a rst step towards interoperability of French geodata in the Semantic Web. The survey of existing modeling of points of interest and geometry shows the di erent vocabularies and modeling choices used 21 http://www.opensahara.com 22 http://geosparql.bbn.com 23 http://www.openlinksw.com 24 https://dev.opensahara.com/projects/useekm/wiki/IndexingSail 25 http://www.opengeospatial.org/standards/sfs to represent them. In France, there is a currently a joint e ort to publish geographic 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 domain. We have used Silk for schema mapping and we have evaluated the results. We studied how to extend the model to take into account e cient modeling for complex geometries. By doing so, we revisited current implementations of geovocabularies and triple stores to check out their compatibility with respect to the new GeoSPARQL standard . We nally 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.
This work has been partially supported by the French National Research Agency (ANR) within the Datalift Project, under grant number ANR-10-CORD-009.