We present data.geohive.ie, which aims to provide an authoritative platform for serving Ireland's national geospatial data, including Linked Data. Currently, the platform provides information on Irish administrative boundaries and was designed to support two use cases: serving boundary data of geographic features at various level of detail and capturing the evolution of administrative boundaries. We report on the decisions taken for modeling and serving the data such as the adoption of an appropriate URI strategy, the development of necessary ontologies, and the use of (named) graphs to support aforementioned use cases.
1 https://www.oracle.com/database/spatial/ 2 Some of this data is also available via the Irish Government portal via data.gov.ie, but is currently not available as Linked Data. The goal is furthermore to investigate the feasibility of having a portal refer to OSi’s data rather than hosting (and therefore also duplicating) it. have been made available by OSi's Open Data release3, taking into account two use cases: i) providing different “generalizations” (i.e. different levels of detail) of the boundaries and ii) capturing the evolution of boundaries, e.g. as ordered by Statutory Instruments. The main contributions of this paper are the decisions made for capturing and representing aforementioned information in RDF. 2
With Prime2, OSi adopted an object-oriented model for capturing geospatial data. In
this model, a clear distinction is made between a geographical object (identified by a
GUID) and their representations. The distinction between objects and their
representations is argued to be important [
Unlike datasets that have been created at a specific time and for a specific purpose, such as CENSUS data, OSi’s geospatial information is not static in nature; it does not make sense to include variables such as a creation date in the URIs of resources. Since each object is assigned a GUID, these can be used to create opaque URIs. We, however, have decided to include the type of geographical feature in the URI as to provide developers and consumers some idea of the nature of the entity the URI is referring to. This will not pose a problem as Prime2 prescribes that features that change of type (e.g. a convent becoming a hospital) are considered as new features and are therefore assigned new GUIDs. 2.2
Since we have not found suitable ontologies for appropriately annotating the different
boundaries (11 types in total; Baronies, Counties, County Councils, etc.), we decided
to create a new ontology4 that extends GeoSPARQL5. Ryan et al. noted some
differences between concepts related to Ireland's geographic features and Linked Data
datasets such as DBpedia and GeoNames [
GeoSPARQL supports the distinction between features and geometries. Since a 3 http://www.osi.ie/about/open-data/ 4 http://ontologies.geohive.ie/osi 5 http://www.opengeospatial.org/standards/geosparql geometry is an attribute of a feature in the same way a name is an attribute of a person, we have, for the time being, chosen not to provide a URI for geometries. The geometries of a feature have thus to be accessed via a feature with geo:hasGeometry. Geometries are available in three levels of detail: generalized up to 100, 50 and 20 meters, which are stored in different (named) graphs. The default graph contains the features, labels in English and Gaelic (whenever available), and their representations generalized up to 100 meters (and are thus smaller in bandwidth). The generalizations up to 50 and 20 meters each have their own named graph.
Finally, Prime2 captures the geometries using the Irish Transverse Mercator (ITM) coordinate system. At an international level, however, World Geodetic System 84 (or WSG 84) is the standard used in cartography and navigation (amongst others). As OSi wishes to encourage the uptake of WGS 84 within Ireland, a decision was made to serve the geometries in WSG 84 only; third parties can themselves rely on services to transform the data between coordinate systems. 2.3
Next we aim to capture the evolution of boundaries. Though rare, administrative boundaries can change with so called Statutory Instruments.6 Statutory Instruments are available on the Web and are accessible via a URI, making it possible to relate the evolution of boundaries with these instruments. To capture the evolution of boundaries, we have chosen to extend PROV-O7 with a new prov:Activity called “Boundary Change”, which is informed by a new prov:Entity called “Statutory Instrument”.8 Prior versions of features and their geometries are captured in a separate graph. Note that geometries do not have a URI, but can be discovered via the feature. 3
Objects are stored in an Oracle Spatial and Graph instance according to the Prime2
data model. RDF graphs are created by means of several R2RML9 mappings that
relate tables of the database with predicates in aforementioned ontologies. Those
triples, currently 831,562 in total, are then loaded into a triplestore that supports
GeoSPARQL. To avoid an excessive load on the server, we have currently chosen to limit
access to the SPARQL endpoint and set up a Triple Pattern Fragments (TPF) server
[
One of the main limitations of this platform is that it does not yet serve meaningful data for the latter. This is due to the fact that the boundary dataset is quite static and prior versions of administrative boundaries have not (yet) been entered in the Prime2 data model. Though simulated, we should have access to such data to validate that aspect of our approach. Future work described below would provide datasets to validate our approach to capturing the evolution of geometries. Another limitation is that users are currently unable to use the spatial predicates via Triple Pattern Fragments, as the SPARQL endpoint is not (yet) made available to the public. The OSi will first monitor the use of the platform before deciding whether this can be made available.
We aim to incorporate other administrative boundaries and other types of features in the future. For the first, we are looking at small areas that have been used for the 2011 CENSUS, allowing us to create links with CENSUS 2011 information published at data.cso.ie. For the latter, we will look into the inclusion of features that are not open and are made available via commercial licenses to certain parties, such as the geometries of buildings. Serving these datasets as Linked (Closed) Data would thus require the investigation of access control mechanisms. Approved construction works may change the geometry of buildings and are captured in the Prime2 model. This dataset could thus be used to validate our approach to capturing geometry evolution. Acknowledgements. The ADAPT Centre for Digital Content Technology is funded under the SFI Research Centres Programme (Grant 13/RC/2106) and is co-funded under the European Regional Development Fund. We furthermore would like to acknowledge the Department of Public Expenditure and Reform (DPER) and the Central Statistics Office (CSO) for their input as a stakeholder.