“Place” is an important concept providing a useful dimension to explore, align and analyze data on the Linked Data Web. ough Linked Data datasets can use standardized geospatial predicates such as GeoSPARQL, access to SPARQL endpoints that supports these is not guaranteed. When not available, one needs to load the data into their own GeoSPARQL-enabled triplestores in order to avail of those predicates. Triple Paern Fragments (TPF) is a proposal to make clients more intelligent in processing RDF, thereby lessening the burden carried by servers. In this paper, we propose to extend TPF to support GeoSPARQL. e contribution is a minimal extension of the TPF client that does not rely on a spatial database such that the extension can be run from within a browser. Even though our approach will unlikely outperform GeoSPARQL-enabled triplestores in terms of query execution time, we demonstrate its feasibility by means of a couple of use cases using data provided by data.geohive.ie, an initiative to publish authoritative, highresolution geospatial data for e Republic of Ireland as Linked Data on the Web. is high-resolution data does cause a lot of network trac, but related work showed how extending the communication between a TPF client and server reduces the number HTTP calls and some network trac. e integration of our extension in one such optimization did reduce the overhead. We, however, decided to stick to our rst implementation as it only extended the client in a minimal way. Future work includes investigating how our approach scales, and its usefulness of adding and using a spatial component to datasets.
•Information systems ! Resource Description Framework (RDF); Geographic information systems; Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for prot or commercial advantage and that copies bear this notice and the full citation on the rst page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s).
LDOW 2017, Perth, Australia © 2017 Copyright held by the owner/author(s).
Geospatial data is an important part of the Linked Data [
GeoNames3 and LinkedGeoData4 are examples of datasets that
cover a vast part of the world. e Ordnance Survey Linked Data5
and data.geohive.ie [
Datasets can rely on standardized vocabularies for representing
and querying geospatial information. ese vocabularies allow
one to formulate queries with predicates that represent geospatial
relations such as overlapping, part-of, disjoint, etc. e OGC (Open
Geospatial Consortium) GeoSPARQL [
e execution of geospatial queries may be computationally
expensive; creating a load on the server and even disrupt it. In fact,
people oen provide data dumps and resolvable URIs as a “good
enough” practice on the Linked Data Web in general to avoid this
problem [
2hp://www.oracle.com/technetwork/database-options/spatialandgraph/overview/
spatialandgraph-1707409.html
3hp://www.geonames.org/
4hp://linkedgeodata.org/
5hp://data.ordnancesurvey.co.uk/
Some realized that query evaluation either happened on the
server or on the client side and that there is a lack of options within
that spectrum [
In this paper, we aim to investigate to what extent the notion of Triple Paern Fragments can be extended to allow agents to engage with geospatial data. e contributions of this paper are i) an extension of the TPF client to support client-side processing of GeoSPARQL functions, and ii) a demonstration of the idea using authoritative geospatial information provided by the Ordnance Survey Ireland (OSi), Ireland’s national mapping agency.
e remainder of this paper is organized as follows: Section 2 present data.geohive.ie, an initiative by the Ordnance Survey Ireland to publish authoritative high-resolution geospatial data as Linked Data on the Web the context in which the study in this paper has been conducted; Section 3 outlines our approach and implementation of client-side processing of GeoSPARQL queries by extending TPF; Section 4 is used to demonstrate our approach in the context of data.geohive.ie; Section 5 presents two initiatives within TCD where groups want to enrich their data with a geospatial component; in Section 6, we discuss some aspects of our study and look into integrating our approach with an optimized TPF server and client; and, nally, we conclude our paper in Section 7 and indicate the next steps. 2
In [
e platform was designed to support two use cases; i) providing dierent ”resolutions” of administrative boundaries and ii) providing the evolution of these boundaries as ordered by, for instance, Statutory Instruments. With ”resolutions” we mean the level of detail in the geometries that represent the boundaries; the higher the resolution, the bigger the string representing the boundary and, as a consequence, the higher the overhead.
e rst use case is supported by extending GeoSPARQL with
concepts and relations specic to the OSi (e.g., ”Townland” and
”Electoral Division”) and by using named graphs for each
resolution. For the second use case, we extended PROV-O [
One of the decisions made was to provide resolvable HTTP URIs
and timely RDF dumps of the datasets, but no public access to the
SPARQL endpoint. Availability is a concern for the OSi and we
would rather host a limited instead of an unstable service. ough
this is a situation we will reassess in the near future, we do recognize
the potential of allowing agents – both human and computer-based
– to explore the data with SPARQL. As a compromise, we provide
a Triple Paern Fragment (TPF [
A limitation, however, is that TPF does not provide support for geospatial predicates in SPARQL queries. is is because GeoSPARQL denes an extension of SPARQL that prescribes geospatial operators (such as “within”, “overlaps”, and “disjoint” – see Listing 1 for an example6) and these operators have not been implemented in TPF on either client or server side.
PREFIX o s i : <h t t p : / / o n t o l o g i e s . geohive . i e / o s i #> SELECT ? c 1 l ? c 2 l f ? c1 a o s i : County . ? c1 r d f s : l a b e l ? c 1 l . ? c1 geo : hasGeometry ? g1 . ? c2 a o s i : County . ? c2 r d f s : l a b e l ? c 2 l .
? c2 geo : hasGeometry ? g2 . g
FILTER ( ? c1 != ? c2 ) FILTER langMatches ( l a n g ( ? c 1 l ) , ” en ” ) FILTER langMatches ( l a n g ( ? c 2 l ) , ” en ” ) ? g1 geo : asWKT ?w1 . ? g2 geo : asWKT ?w2 .
FILTER ( g e o f : s f D i s j o i n t ( ? w1 , ?w2 ) )
It is thus unfortunate that agents cannot avail of these predicates without them relying on ingesting the data in their own GeoSPARQL-enabled triplestores. While we know that geospatial 6Note that the namespaces for GeoSPARQL and its functions are omied. predicates can be computationally expensive, we will propose and investigate an extension of a TPF client that supports client-side processing of GeoSPARQL queries. 3
OSi’s Linked Data relies on GeoSPARQL to represent features and
geometries. OSi uses the Well-known Text (WKT) markup language
for representing the geometries (such as polygons, multi-polygons,
points representing centroids, etc.).7 GeoSPARQL-enabled
triplestores, or Geographic Information Systems in general, use these
WKT representations of geometries to populate a database relying
on data structures suitable for geospatial data such as R-Trees [
Our goal is to provide client-side processing of GeoSPARQL queries, and more precisely, GeoSPAQRL functions. One possible approach would be to store the geometries in a simple geospatial database on the client-side to compute the geospatial predicates. We, however, wanted to provide a solution that allowed third parties not only to avail of the geospatial predicates, but also did not require those parties to rely on additional components such as geospatial databases. e Node.JS implementation of the TPF client can, in fact, be run within a browser by bundling all the code and its dependencies into one JavaScript library. is would help us leverage engagement with OSi authoritative geospatial data and this created the additional requirement that the extension should solely rely on (code that can be bundled into) JavaScript. Of course we are aware of the limitations of computing GeoSPARQL queries in a browser on commodity hardware; browsers are not suitable to replace special-purpose triplestores. We will, however, discuss some of the issues later on in Section 5.
e dierent functions where implemented by interpreting the OGC standard and using set operators on the geometries. e following functions, to name a few, were implemented as follows: geof:sf Touches. e intersection of the two geometries is not empty and only contains (a combination of) points or lines. If the intersection contains a polygon or a multipolygon, the two geometries share an area. geof:sfOverlaps. e intersection of the two geometries is not empty and should contain polygons or multi-polygons denoting areas. geof:sf Within. e intersection of the two geometries A and B is not empty, the dierence between A and the intersection is empty, and the dierence between B and the intersection contains geometries.
We note that the current implementation supports functions that we deem to occur oen in examples. GeoSPARQL, in fact, prescribes a whole range of functions, some of which are more ne-grained. e function geof:sfWithin, for instance, covers both cases of a geometry being completely within (nTPP) another geometry and a geometry being within and touching the border 7We note that GeoSPARQL also prescribes another popular markup language for expressing geographical features and their geometry is the Geography Markup Language, or GML, which is an XML grammar dened by the Open Geospatial Consortium (OGC). For the time being, however, the OSi only serves WKT. of another geometry (Tangential Proper Part – or TPP). Both are referred to with the predicates geof:rcc8ntpp and geof:rcc8tpp.
We extended V2.0.4 of the TPF Node.js Client [
For the purpose of our rst demonstration, we use the Triple Pattern Fragment server set up for data.geohive.ie10. It contains description for various types of administrative boundaries such as counties, county (and/or) city councils, electoral divisions11, etc.
Fig. 2 depicts a web client returning the English labels of 10 pairs of Irish counties who share a border, demonstrating that it supports the query listed in the previous section.
We have run the rst query without the LIMIT clause 10 times on at 3 dierent points in time; morning, aernoon and evening – assuming there might be dierent loads on the network at dierent times. e client ran on a MacBook Pro 12.1 with an Intel Core i5 processor (2.7 GHz) and a memory of 8 GB (1867 MHz DDR3). e execution of the queries averaged at 126.140, 121.069, and 115.792 seconds – or about two minutes. Most of the processing time,
9hp://theme-e.adaptcentre.ie/geo-tpf/ 10hp://vma01.adaptcentre.ie/ 11e smallest legally dened administrative areas in the State for which Small Area Population Statistics (SAPS) are published from the Census. however, went to computing the geospatial function instead of retrieving the data over the network.12
Fig. 3 shows the results of requesting ve townlands that lie within County Wicklow’s bounding box using the query from Listing 2 (in appendix). A (minimal) bounding box is a rectangle in which all points of that county’s boundary reside. e boundary box is represented in WKT below and ploed – together with the boundary of its county – on a map in Fig. 4.
Note that the query using the boundary box will also return townlands that are outside of County Wicklow, yet within its bounding box. 5
So far, the demonstrators used the data made available by the Ordnance Survey Ireland. We will now proceed with two initiatives that enrich datasets with a geospatial component, subsequently used in combination with data.geohive.ie for exploring and querying the data with client-side processing of GeoSPARQL. e following use cases will provide examples of consulting dierent Triple Pattern Fragment servers to answer a query, i.e., examples of federated queries. 12e query returned 82 solutions in the result set, which corresponds to 41 pairs. We note, however, that there are some errors in the generalized dataset (see Section 6.5), but that the solutions are correct with respect to these errors. Within Trinity College Dublin, the Library is investigating the adoption of Linked Data technologies to facilitate search, discovery and engagement with their collections and archives. Next to investigating appropriate methods and techniques for creating and managing Linked Data, they also investigate how their metadata can be enriched and contextualized geospatial data. Harry Clarke was an Irish stained-glass artist and book illustrator and many of his stained glasses can be admired in churches across Ireland. e Library’s “Clarke Stained Glass Studios Collection” contains a wide variety of documents from stained glass designs and blueprints to correspondence. e library is currently digitizing these assets and aims to leverage user engagement with the collection.
e metadata – stored as Metadata Object Description Schema (MODS) – about this collection was transformed into RDF and links where created with an incomplete dataset of (mainly catholic) churches in Ireland of which the location is indicated with a point. A location-aware mobile application is currently being developed (see Fig. 5) that uses these points to direct users to churches where they can admire the stained glasses while reading the descriptions created by the archivists.
Fig. 6 demonstrates how we are able to retrieve assets related to churches that are located in County Dublin, using the query from Listing 3. 5.2
Recently, the Chronic Disease Informatics Group (CDIG) in Trinity College Dublin is exploring ways to adopt semantic technologies to facilitate the combination and analysis of various heterogeneous data to, for instance, identify external factors that contribute to are-ups of particular diseases. Data about patients are recorded at a particular place and time, and the locations of sensors – such as weather stations or air pollution detectors – are also known beforehand. One of the aspects the group wants to investigate is the notion of “space” that is present in their datasets.
For this demonstrator, we transformed a part of their data into RDF using R2RML, and generated WKT literals for the points in their datasets. We then proceeded to show how to formulate queries with GeoSPARQL, eectively showing that is straightforward to add and avail of a geospatial dimension to their data on one’s machine, without the need to rely on bespoke triplestores.
Fig. 7 shows how one can retrieve observations in a particular County. Fig. 8 demonstrates how one can retrieve in which Electoral Divisions the weather stations are in, which may make sense if researchers want to relate observations with the smallest administrative unit used for the census. Listings 4 and 5 provides the queries used for aforementioned gures. 6 6.1
We established that we aimed to extend a TPF client in Section 2 and its implementation details were described in Section 3. In this section, we will elaborate on this decision as well discuss the possible implications of extending the TPF server.
First, a TPF server is a server that complies with the specication
laid out in [
TPF servers are dened as not to support SPARQL lter
functions, though a study has shown it to be feasible to extend a TPF
server with support for substring matching in lters with minimal
impact on a server’s load, though increase query response time [
e whole aim of this study was to propose a solution that would
enable clients to easily process GeoSPARQL where
GeoSPARQLenabled endpoints would not be available. e TPF client/server
architecture provided us with an ideal base the enable clients in
doing so, rendering clients more intelligent in processing such data.
We are, however, aware that computing these queries in JavaScript
is not as ecient as relying on bespoke data structures and storage,
especially if it was our goal to have such queries run in a browser
environment. In Section 6.4, we will elaborate on related work on
optimizing TPF on client and/or server side. But in future work, we
should investigate how this approach scales with respect to query
execution time and processing of large volumes of data, mainly
due to the large geometries. Benchmarks such as Geographica [
Using a Virtual Machine with 1GB of RAM and an Intel processor
of 2.2 GHz on which is running Debian GNU/Linux 8.7 (jessie),
we installed Parliament [
On Optimization
ough TPF allows for clients to become more intelligent by
processing simple result sets based on triple paerns that requires
minimal load for the server, bandwidth might become an issue;
[
OSi’s geometries are large. Using the county boundary dataset
(26 counties in total), the triples according to the paern f ?geom
geo:asWKT ?wkt g result in RDF documents that contain 2.1MB,
2.8MB and 4.8MB of data for generalizations up to 100, 50 and 20
meters respectively. One can see that the TPF setup can generate
a lot of trac if the result set for f ?c1 a geo:Feature g is
joined with f ?c1 geo:hasGeometry ?g1 g, where the laer
corresponds with more than 54,000 triples for each resolution. e
work presented in [
While working on the boundary datasets, we noticed some
topological inconsistencies currently hosted on data.geohive.ie. Where
there should be 58 pairs of counties that border, for instance, we
only have 41. e missing pairs shared some very small polygons
next to lines and multi-lines. e borders of counties Carlow and
Wicklow, for instance, share one tiny triangle of 0:000068034 square
nanometers. e OSi has been made aware of errors that have crept
13We used the implementation referred to in [
In this paper we presented a minimal extension of the Triple
Pattern Fragments [
e demonstrators presented in this paper all focused on the use of high-resolution data provided by data.geohive.ie, an initiative of the Ordnance Survey Ireland to publish their data as Linked Data. We furthermore elaborated on two initiatives, lead by dierent groups, in Trinity College Dublin aiming to add a geospatial component to their data. ese two initiatives provide evidence that one can easily expose and combine their data with other datasets using GeoSPARQL.
Because the geometries are of high-resolution, the literals that
capture these are large and network overhead is considerable.
Integrating our approach with related work on optimizing the TPF
client-server communication presented in [
Finally, we furthermore aim to complete the set of functions prescribed by GeoSPARQL and conduct studies to study the usability and usefulness of our approach, in the broadest sense of the word, involving dierent types of stakeholders.
We thank the Ordnance Survey Ireland (OSi) for permiing us to use their boundaries dataset for the purposes of this research project. Within OSi, we are especially grateful for the input and domain expertise provided by Lorraine McNerney. e 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 thank Brian Reddy, Mark Lile, and Bre Houlding from the Chronic Disease Informatics Group (CDIG) in Trinity College Dublin for allowing us to use their data as part of a demonstrator in this paper. We thank e Library of Trinity College Dublin and Peru Bhardwaj for access to their data and mobile application. Finally, we would like to thank the (anonymous) reviewers – and in particular Ruben Verborgh – for their valuable comments, and Olaf Hartig for clarifying some aspects of brTPF.
Here we list the queries we have used for our demonstration. eries listed in Listings 1 and 2 can be run against the TPF server set up for data.geohive.ie. e remaining queries, however, depend on data we cannot make available.
PREFIX o s i : <h t t p : / / o n t o l o g i e s . geohive . i e / o s i #> SELECT ? t l f ? t a o s i : Townland . ? t r d f s : l a b e l ? t l .
FILTER langMatches ( l a n g ( ? t l ) , ” en ” ) ? t geo : hasGeometry ? g1 . ? g1 geo : asWKT ?w1 .
FILTER ( g e o f : s f W i t h i n ( ? w1 , ”POLYGON( ( 6 . 7 9 2 1 7 7 1 2 5 0 0 8 9 4 5 2 . 6 8 1 9 6 2 2 8 8 5 3 8 1 , 6.79217712500894 5 3 . 2 3 4 4 0 9 8 0 4 9 2 8 7 , 5.99804552567386 5 3 . 2 3 4 4 0 9 8 0 4 9 2 8 7 , 5.99804552567386 5 2 . 6 8 1 9 6 2 2 8 8 5 3 8 1 , 6.79217712500894 5 2 . 6 8 1 9 6 2 2 8 8 5 3 8 1 ) ) ” ˆ ˆ geo : w k t L i t e r a l ) ) g LIMIT 5
PREFIX o s i : <h t t p : / / o n t o l o g i e s . geohive . i e / o s i #> PREFIX dcterms : <h t t p : / / p u r l . org / dc / terms /> SELECT ? a s s e t ? c h u r c h l a b e l ?w2 f ? c1 a o s i : County . ? c1 r d f s : l a b e l ” DUBLIN ”@en . ? c1 geo : hasGeometry ? g1 . ? g1 geo : asWKT ?w1 . ? ch a o s i : Church . ? ch r d f s : l a b e l ? c h u r c h l a b e l .
FILTER ( langMatches ( l a n g ( ? c h u r c h l a b e l ) , ” en ” ) ) ? a s s e t dcterms : s p a t i a l ? ch . ? ch geo : hasGeometry ? g2 . ? g2 geo : asWKT ?w2 .
FILTER ( g e o f : s f C o n t a i n s ( ? w1 , ?w2 ) ) g LIMIT 5
PREFIX o s i : <h t t p : / / o n t o l o g i e s . geohive . i e / o s i #> SELECT ? o ? d a t e ? p l a c e f ? c1 a o s i : County . ? c1 r d f s : l a b e l ” DUBLIN ”@en . ? c1 geo : hasGeometry ? g1 . ? g1 geo : asWKT ?w1 . ? o a <h t t p : / /www. example . org / ont / Observation > . ? o <h t t p : / /www. example . org / ont / recordedOn > ? d a t e . ? o <h t t p : / /www. example . org / ont / recordedAt > ? p l a c e . ? p l a c e geo : hasGeometry ? g2 . ? g2 geo : asWKT ?w2 .
FILTER ( g e o f : s f C o n t a i n s ( ? w1 , ?w2 ) ) g LIMIT 50 PREFIX o s i : <h t t p : / / o n t o l o g i e s . geohive . i e / o s i #> SELECT ? o ? e d l f ? ed a o s i : C e n s u s 2 0 1 1 E l e c t o r a l D i v i s i o n s . ? ed r d f s : l a b e l ? e d l .
FILTER ( langMatches ( l a n g ( ? e d l ) , ” en ” ) ) ? ed geo : hasGeometry ? g1 . ? g1 geo : asWKT ?w1 . ? o a <h t t p : / /www. example . org / ont / S t a t i o n > . ? o geo : hasGeometry ? g2 . ? g2 geo : asWKT ?w2 .
FILTER ( g e o f : s f C o n t a i n s ( ? w1 , ?w2 ) ) g LIMIT 5