GEOYASGUI: THE GEOSPARQL QUERY EDITOR AND RESULT SET VISUALIZER

: The Netherlands’ Cadastre, Land Registry and Mapping Agency – in short Kadaster – collects and registers administrative and spatial data on property and the rights involved. This includes for ships, aircraft and telecommunications networks. Doing so, Kadaster protects legal certainty. The Kadaster publishes many large authoritative datasets including several key registers of the Dutch Government (Topography, Addresses and Buildings). Furthermore Kadaster is also developing and maintaining the PDOK shared service, in which about 100 spatial datasets are being published in several formats, including an incredible amount of detailed geospatial objects. Geospatial objects include all plots of land, all buildings, all roads and all lampposts. These objects are spatially and/or conceptually related, but are maintained by different data curators. As a result these datasets are syntactically and architecturally disjoint, and using them together currently requires non-trivial human labor. In response to this, Kadaster is currently publishing its geo-spatial data assets as Linked Open Data. The standardized query language for Linked Open Geodata is GeoSPARQL. Unfortunately, current tooling does not support writing and evaluating GeoSPARQL queries. This paper presents GeoYASGUI, a GeoSPARQL editor and result-set viewer with IDE capabilities. GeoYASGUI is not a new software product, but an integration of and a collection of updates to existing Open Source libraries. With GeoYASGUI it becomes possible to query the rich


INTRODUCTION
The Netherlands' Cadastre, Land Registry and Mapping Agency -in short Kadaster 1 -is undertaking the ambitious development of an integrated approach towards publishing many of its data assets as Linked Open Data.Linked Data is used to integrate heterogeneous geospatial datasets, and make the available through the Kadaster Data Platform (https://data.pdok.nl).The primary query language for accessing such Linked Geospatial data is GeoSPARQL (Perry and Herring, 2012), a query language that is standardized by the OGC 2 and that extends the SQL-inspired SPARQL query language for RDF data (Garlik et al., 2013).
Needless to say, most of the SPARQL queries that are run over the enormous Kadaster Linked Data collection include at least several geospatial objects and at least some geo-spatial relations and/or functions.Unfortunately, there is no existing tooling that allows such GeoSPARQL queries to be edited, run, evaluated, and then re-edited and re-run.Several tools exist that support this kind of interaction for SPARQL, but these solutions do not deal with the idiosyncrasies of geo-spatial data (syntax) formats, and they do not support the geo-spatial extensions that GeoSPARQL adds to the SPARQL query language.
We present GeoYASGUI, a combined REPL for GeoSPARQL that reuses and extends existing Open Source libraries.We show how GeoYASGUI is used by the Kadaster to disseminate its Linked Open Data assets through a standards-compliant GeoSPARQL endpoint that is fully powered by Open Source software.
1 See http://kadaster.nl 2 See http://www.opengeospatial.org/ogcThe rest of this paper is structured as follows.In Section 2 we discuss our approach towards supporting the iterative process of query writing.Section 3 explains how our approach is concretely implemented in a collection of Open Source libraries.Section 4 sketches the context in which GeoYASGUI is being used by the Kadaster.Section 5 discusses the impact of (Geo)YASGUI and why we believe that the here presented implementation will result in uptake by the Linked Open Geodata community.Section 6 concludes.

APPROACH
Typical interaction with a (Geo)SPARQL endpoint follows the read-eval-print loop (REPL) principle.The endpoint first reads a query string sent by a client and parses it into an algebraic object (in a formalism akin to relational algebra).Queries are sent in a standards-compliant way, according to the SPARQL 1.1 Protocol specification (Feigenbaum et al., 2013).Secondly, the endpoint evaluates the query algebra against its data collection, preferable using indices that are pre-computed over the data and a heuristicsbased query planner, in order to ensure a speedy query evaluation (Schmidt et al., 2010).Thirdly, the endpoint writes the results in a standardized result-set format.This includes standardized formats for XML, JSON, and CSV/TSV (Hawke et al., 2013, Seaborne et al., 2013, Seaborne, 2013).
A query typically does not return the intended result immediately.Indeed, writing queries is a form of declarative programming, and is an inherently iterative practice.As a result, the user has to go The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLII-4/W2, 2017FOSS4G-Europe 2017 -Academic Track, 18-22 July 2017, Marne La Vallée, France through the query evaluation loop several times before the final query is written.
The problems with existing SPARQL query editors is that they provide only little support to the user.Even simple features like syntax checking, that are widely available for programming languages, are not broadly implemented in SPARQL endpoints.As a result, the user often has to go through multiple iterations just to make the query syntactically conforming.For this reason Triply 3 develops three products that support the use of SPARQL endpoints: YASQE, a query editor that provides direct feedback to the user; YASR, a versatile query results visualizer; and YAS-GUI, an integrated web service that combines YASQE and YASR (Rietveld and Hoekstra, 2017).
GeoSPARQL (Battle and Kolas, 2011) extends the SPARQL query language in several ways.Specifically, it adds the following components: Core High-level schema for spatial objects (e.g., geo:SpatialObject).
Topology Vocabulary Properties for asserting and querying topological relations between spatial objects (e.g., geo:sfIntersects).
Geometry RDFS datatypes that allow geometry data to be serialized, RDF properties for geometric relationships, and nontopological spatial query functions that can be applied to geometry objects.

RDFS Entailment
Calculates entailment results under the class hierarchy closure for geometries.For example, a WKT triangle is also a WKT polygon, surface, and geometry.
Query Rewrite Allows expressions that contain GeoSPARQL relations to be translated to and from expressions that contain GeoSPARQL functions.

IMPLEMENTATION
The here presented GeoYASGUI is not a new library that is built from scratch.Rather, it is a collection of updates to existing libraries, together with the necessary cross-library integration, that results in a GeoSPARQL editor with IDE-like capabilities.
The existing libraries that are extended are YASQE (Section 3.1) and YASR (Section 3.2).In the following we give a detailed explanation of how these two libraries are updated to support GeoYASGUI.

GeoYASQE
YASQE (Figure 1) is a JavaScript library that, when added to a web page, takes native HTML text areas, and turns them into full-featured, IDE-like SPARQL query editors.
YASQE is based on the CodeMirror JavaScript library 4 for advanced HTML-based text editing.Using CodeMirror and the JavaScript SPARQL grammar from the Flint SPARQL Editor of the query prefixes that are used in the rest of the query are declared.The projection clause (select) states that each result row consists of a shape (?wkt), a label (?wktLabel), and a color (?wktColor).The drop-down list shows auto-completion options for the property the user is currently typing.
errors of their queries, together with information about the type of validation error.In addition, YASQE provides several completion services, where completions are automatically suggested while typing.Firstly, because IRIs can be long and difficult to read, YASQE supports IRI prefix aliasing.Common alias-to-IRI mappings are retrieved from the Prefix.ccweb service 6 .Secondly, properties and classes are auto-completed by using the Linked Open Vocabularies API (Vandenbussche et al., 2015).
Because a user should not loose her work when a browser tab (accidentally) closes, YASQE uses HTML 5 functionality to store the application state.This makes the editing experience persistent between user sessions.As a result, a returning user will always see the screen as it was when the browser page was last closed.
YASQE was extended in the following ways to support the editing of GeoSPARQL queries: • Prefix auto-completion mappings for GeoSPARQL namespaces were added.For example, geof aliases the IRI namespace http://www.opengis.net/def/function/geosparql/.
• Syntax highlighting was extended to cover GeoSPARQL terms.
• A simple templating language was devised that allows geometric concepts to be styled.The templating language uses standard SPARQL 1.1 and GeoSPARQL constructs exclusively and links each shape variable (?wkt) to a label value (?wktLabel) with a particular color (?wktColor).Use of the templating language is optional.The shapes denote areas where different protected species are living.The colors denote the kind of species that are living there.For example, red area only contain mussels, but green areas contain mussels and oysters.

GeoYASR
YASR (Figure 2) is a JavaScript library that parses and visualizes any SPARQL query response.The W3C specifies several SPARQL result formats, including XML, JSON, CSV, and TSV.
To decrease the load on the publisher or developer, YASR consumes any of these data formats, by parsing the results and wrapping them in an internal data representation.A first parse attempt is based on the Media Type that is described by the Content-Type header of the HTTP response message.When this Media Type is missing or erroneous, YASR tries to parse the SPARQL results based on heuristics and on a best-effort basis.
YASR was extended in the following ways to support the visualization of GeoSPARQL result-sets: • Literals with datatype IRI geo:wktLiteral are now parsed according to the Well-Known Text (WKT) grammar into (nested) JavaScript arrays.For this the Wicket library7 for parsing WKT strings is used.
• A map view was added that shows the parsed WKT geometries on a map.For this the popular web-based map widget Leaflet8 is used.The map view supports the default tiles from Open Street Maps9 , but also allows the high-quality tiles of the Kadaster to be used instead.
• For label expressions in the YASQE templating language (Section 3.1), the map view displays markers at the centroid of shapes.Clicking a marker displays an HTML popup that shows additional content for the selected geometry.
• Similarly, color expressions in the YASQE templating language (Section 3.1) are used to style markers and polygons on the map.The color expressions are parsed using the Color10 library, which supports the set of color definitions that are supported by the CSS standard.
• Geometry serializations, i.e., nested sequences of floatingpoint numbers, can be lengthy.Specifically, geometry serializations can be much longer than regular RDF data expressions.For this reason several tweaks need to be made, especially to the tabular views, in order to be able to conveniently display and browse result-sets that include geospatial terms.

CONTEXT
The Kadaster 11 manages an enormous collection of heterogeneous datasets that describe every stationary geospatial object in the Netherlands in great detail.Geospatial objects include all plots of land, all buildings, all roads and all lampposts.These objects are spatially and/or conceptually related, but are maintained by different data curators.As a result these datasets are syntactically and architecturally disjoint, and using them together currently requires non-trivial human labor.
For these reasons, the Kadaster is now publishing its data assets as Linked Open Data.This makes it possible to query multiple datasets at once, without requiring query-specific and manual data integration.Datasets are published as RDF in according with the most recent standards and best practices, and by reusing existing Linked Vocabularies.In line with the GeoSPARQL standard, Linked Geospatial data is serialized as Well-Known Text (WKT).Figure 3 gives an example of how the integrated GeoYASGUI solution is currently being used by the Kadaster.The figure shows the YASR result-set visualizer in map mode.For GeoSPARQL results that are geometries, the WKT polygons of those geometries are displayed.Other properties that are part of the projection are displayed in a popup.In this example the popup includes the population of the selected municipality, together with its area and population density.Moreover, the title of the popup is a link that refers to the full RDF description of the resource that is served by the Linked Data Theater 12 .The user can also view the same result-set as a (regular) table, a pivot table, or a Google Chart (see the corresponding buttons in Figure 3).If the user knows GeoSPARQL, she can also click the "Show query" button, to 'fold out' the YASQE query editor.The combination of YASR and YASQE in the same widget is very powerful, because it allows a user to alter the query and immediately observe the results of running it.use it as the SPARQL entry point to their online data collection.This includes HealthData.gov21 , Smithsonian American Art Museum 22 , German National Library of Economics 23 , Linked Open Vocabularies 24 , LOD Laundromat 25 , MetaLex 26 , and CEDAR 27 .
Because GeoYASGUI integrates GeoSPARQL support into existing libraries that are already widely used, it will become available to will become available to a large number of users relatively quickly.A concrete example of this is the Swiss Federal Office of Topography 28 who are already using these GeoYASGUI features in their SPARQL endpoint.

CONCLUSION
The GeoYASGUI integration, the underlying libraries (YASQE, YASR), as well as the support services and libraries that are used are all published as Open Source code.(Geo)YASGUI, YASQE, and YASR are distributed under the MIT License.The Kadaster hosts a deployment of the GeoYASGUI web service through which its rich data assets can be queried.It currently exposes a data collection that consists of billions of triples and that describes tends of millions of geo-spatial objects.Please visit https://data.pdok.nl/yasgui to write your GeoSPARQL query and try out the GeoYASGUI query editor and result-set visualizer!

Figure 2 .
Figure2.The YASR result-set viewer for GeoSPARQL.The map view shows WKT shapes that are displayed on a Leaflet map.The shapes denote areas where different protected species are living.The colors denote the kind of species that are living there.For example, red area only contain mussels, but green areas contain mussels and oysters.

Figure 3 .
Figure 3. Example of a GeoYASGUI widget that is used by the Kadaster.The widget appears in an HTML page about Dutch municipalities and their population size.The user can browse the data by clicking municipalities on the map.A popup displays the population size, area, and population density of each municipality (Amsterdam in this example).Clicking the name of the municipality traverses to the full RDF resource description for that municipality (implementing IRI dereferencing).