1. Client-side Processing of GeoSPARQL
Func9ons with Triple Pa?ern Fragments
Christophe Debruyne (Trinity College Dublin)
Éamonn Clinton (Ordnance Survey Ireland)
Declan O’Sullivan (Trinity College Dublin)
2017-04-03 @ Linked Data on the Web (LDOW2017)
The ADAPT Centre is funded under the SFI Research Centres Programme (Grant 13/RC/2106) and is co-funded under the European Regional Development Fund.

2. www.adaptcentre.ieIntroduc9on
Geospa9al informa9on is an important part of the LD Web
Some geographic LD datasets are authorita9ve
• Ordnance Survey Linked Data (UK) , data.geohive.ie (IE)
Not all geographic LD datasets adopt standards
• Ordnance Survey Linked Data uses their own vocabulary, and
provides no support for spaXal funcXons
Not all endpoints serving GeoSPARQL support its func9ons
• GeospaXal funcXons are computaXonal expensive; server load
• One o[en provides data dumps and resolvable URIs as a “good
enough” pracXce to avoid this problem (Verborgh et al. 2016)
R. Verborgh, M. Vander Sande, O. HarXg, J. Van Herwegen, L. De Vocht, B. De Meester, G.
Haesendonck, and P. Colpaert. 2016. Triple Pacern Fragments: A low-cost knowledge graph
interface for the Web. J. Web Sem. 37-38 (2016), 184–206

3. www.adaptcentre.ieIntroduc9on – data.geohive.ie
data.geohive.ie is an ongoing
collaboraXon between ADAPT
and the Ordnance Survey Ireland
to publish OSi’s authoritaXve
geospaXal informaXon as Linked
Data.
StarXng from publicly available
boundary data, supporXng two
use cases: provision of different
geometries for features, and
provenance and evoluXon of
features and their geometries

4. www.adaptcentre.ieIntroduc9on – data.geohive.ie
data.geohive.ie
• Provides resolvable URIs, dumps and a LD frontend
• Decided against providing a public SPARQL endpoint
• Triple Pacern Fragments were adopted instead
Triple Pa?ern Fragments (TPF)
• Distribute load between a TPF client and server
• Less load on the server at the cost of increased bandwidth

5. www.adaptcentre.ieIntroduc9on – data.geohive.ie
But, TPF has no support for GeoSPARQL
• Non-implementaXon rather than limitaXon
• GeoSPARQL is an extension of SPARQL (scope)
Agents cannot apply GeoSPARQL func9ons on OSi’s authoritaXve
geospaXal Linked Data, or they have to load the data in
GeoSPARQL-enabled triplestores
Would it be feasible to extend TPF with GeoSPARQL?
Feasible as in a viable approach to process GeoSPARQL

6. www.adaptcentre.ieApproach
Two possible approaches:
A) Extending a TPF Client
• TPF server specificaXon intact (backwards compaXble)
• Possibly more network overhead
B) Extending the TPF server
• Outside server specificaXon, but proven to be viable for
substring filtering (Van Herwegen et al. 2015)
Addi9onal requirement: a pure JavaScript implementa9on
• Allows one to run the client in a browser and hence facilitate
stakeholders in formulaXng GeoSPARQL queries
J. Van Herwegen, L. De Vocht, R. Verborgh, E. Mannens, and R. Van de Walle. 2015. Substring Filtering for Low-Cost
Linked Data Interfaces. In The SemanXc Web - ISWC 2015 - 14th InternaXonal SemanXc Web Conference,
Bethlehem, PA, USA, October 11-15, 2015, Proceedings, Part I (LNCS), Vol. 9366. Springer, 128–143.

7. www.adaptcentre.ieApproach
Implementa9on
• We extended V2.0.4 of the TPF Node.js Client
(Available at hcps://github.com/chrdebru/Client.js)
• Made available a web-client using this extension
(At hcp://theme-e.adaptcentre.ie/geo-tpf/)
GeoSPARQL coverage
• Support for GeoSPARQL FILTER funcXons that we deem to occur
o[en in examples (sfTouches, sfWithin, …)
Func9ons are implemented in terms of set opera9ons
• E.g., sfOverlaps: The intersecXon of the 2 geometries is not
empty and should contain polygons or mulX-polygons denoXng
areas.

8. www.adaptcentre.ieDemonstra9on
Paper provides
details on use
within the
context of a TCD
Library Linked
Data and Sensor
Data analysis
projects.

9. www.adaptcentre.ieDiscussion (condensed)
On performance
• Based on iniXal experiments. Most Xme went to processing of GeoSPARQL
FILTER funcXons. Slightly worse results in terms of Xme compared to
running queries in a triplestore. We thus deem our approach viable.
• However, our approach using JavaScript (in a browser) will unlikely
outperform such triplestores in terms of performance
On Op9miza9on
• OSi provides high-res polygons, which causes a lot of network traffic.
• br-TPF (HarXg and Buil Aranda, 2016) did reduce the number of HTTP calls,
but not really the amount of traffic for the polygons.
• Server-side support for GeoSPARQL funcXons could tackle that problem
O. HarXg and C. Buil Aranda. 2016. Bindings-Restricted Triple Pacern Fragments. In On the Move to Meaningful
Internet Systems: OTM 2016 Conferences - Confederated InternaXonal Conferences: CoopIS, C&TC, and ODBASE
2016, Rhodes, Greece, October 24-28, 2016, Proceedings (LNCS), Vol. 10033. Springer, 762–779.

10. www.adaptcentre.ieConclusions and Future Work
Conclusions
• We extended a TPF client to support GeoSPARQL funcXons
• The paper illustrates how we used it for different projects
Lessons Learned
• IniXal results showed our approach is viable
• Though network overhead may sXll be an issue, an extension of the TPF
server is worthwhile exploring (future work)
• How to deal with GeoSPARQL predicates and funcXons?
Future work
• Complete implementaXon and test with funcXonal benchmarks, e.g.,
Geographica (Garbis et al, 2013)
• Experiments involving stakeholders, and idenXfy the limitaXons of our
approach to characterize, for instance, “sensible” queries
G. Garbis, K. Kyzirakos, and M. Koubarakis. 2013. Geographica: A Benchmark for GeospaXal RDF Stores (Long
Version). In the SemanXc Web - ISWC 2013 - 12th InternaXonal SemanXc Web Conference, Sydney, NSW, Australia,
October 21-25, 2013, Proceedings, Part II (LNCS), Vol. 8219. Springer, 343–359.