Geospatial data on the Semantic Web historically stems from using point geometries to represent the geographic locations of places. As the practice evolved in the Semantic Web community, a demand for more complex geometries and geospatial query capabilities came about as a consequence of integrating traditional GIS and geo-data into the Linked Data cloud. However, recent projects have revealed that, in practice, these established techniques have major shortcomings that limit their storage, transmission, and query potential. In this position paper, we examine these shortcomings, propose to treat geometries similar to how other binary data are stored and referenced on the Semantic Web, namely by representing them as resources via URIs instead of RDF literals, and demonstrate the utility of precomputing topological relations rather than computing them on-demand by arguing that end users are most oen interested in topology and not raw geometries. Looking back to the origins of publishing geospatial data on the Semantic Web, the W3C Semantic Web Interest Group (SWIG) introduced the Basic Geo Vocabulary1 circa 2003 in order to “explore the possibilities of representing mapping/location data in RDF.” Initially, this vocabulary was considered good enough for annotating web documents and XML resources with basic location metadata (e.g., <pos:lat>51.46</pos:lat> <pos:long>-0.45</pos:long>2). It even brought about an immediate linking of resources via services such as GeoURL3, which allowed users to nd URLs by their proximity to a given location such as “your neighbor's blog” or “restaurants near you”. e establishment and subsequent widespread usage of such a W3C vocabulary made it an obvious choice for early contributors of geospatial data on the Semantic Web. Among the rst major contributors were gazeeers, such as GeoNames, who housed spatial databases comprised entirely of latitude/longitude coordinate pairs of geocoded places. To this extent, the Basic Geo Vocabulary was still sucient. However, it soon became clear to the growing Semantic Web community that a more comprehensive geospatial vocabulary was needed in order to deal with geometries beyond
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’17, Perth, Australia © 2016 Copyright held by the owner/author(s). 978-x-xxxx-xxxx-x/YY/MM. . . $15.00 DOI: 10.1145/nnnnnnn.nnnnnnn single points, as well as a general support for coordinate reference systems, and most importantly the distinction between the entity on the surface of the Earth and the many possible geometries one can use to represent it given various contexts, granularities, use cases, and so forth. In fact, the authors of the Basic Geo Vocabulary explicitly acknowledged that it “does not aempt to address many of the issues covered in the professional GIS world”:1
Between 2006 and 2011, prior to the standardization of OGC’s
GeoSPARQL[
While such a serialization certainly follows the Linked Data
paradigm’s call for raw data, it also drew criticisms for its excessive
creation of blank nodes[
One solution that addressed these criticisms for geographic
data was to store the entire geometry in a single RDF literal, thus
eliminating any issues brought on by embedding complex
structures as RDF. Serialized geographic formats such as Geographic
Markup Language (GML) and Well-Known Text (WKT) oered
accessible means to encode geometries in a human-readable form.
GeoSPARQL [
Serializing geometries as WKT literals may be suitable in some
cases but prohibitive in others. Consider, for example, the notable
Lake of the Woods body of water (Fig. 1) and its nearly 15,000
islands. A geometric representation of the lake consists of 4,484
rings formed by 487,505 nodes. e resulting WKT literal5 is 11
MB large, not human-readable, and is too cumbersome to be used
directly as input for reasoning, e.g., to compute topological relations.
ese problems become apparent when dealing with a multitude
of complex geometries[
In light of these issues and the responses they have precipitated, we reconsider the techniques set forth by GeoSPARQL in favor of two proposed alternatives that are driven by practicality. Specically, we argue that (1) serialized geometry data beyond points and bounding boxes do not need to be expressed in RDF and that (2) geospatial queries on Linked Data will benet from storing precomputed topological relations instead of, or in addition to, raw geometries. We will refer to our approach here as ‘AGO’. 5Available at: hp://stko-testing.geog.ucsb.edu/blake/resource/lake-of-the-woods.txt 6hps://lta.cr.usgs.gov/DLGs
In our approach, rather than storing geometry as RDF literals in the triples of blank nodes (as is common with GeoSPARQL), we opt to use Uniform Resource Identiers (URIs) to represent the geometry as a resource. is approach is compatible with existing GeoSPARQL datasets and implementations because it still allows for statements about a geometry (e.g., geosparql:asWKT), however it relieves the triplestore from having to bear responsibility for the entire geographic dataset. Instead, geometry data can persist elsewhere, such as within a local geodatabase or on a remote server.
e broader line of reasoning we emphasize here is that given the complexity of high-resolution geometries used by production-level Geographic Information Systems and many of the most prominent science datasets, e.g., provided by USGS National Map, raw geometries hold lile value in a human-readable medium when compared to their more ecient binary formats. Without an application layer to render them on a map or perform some geospatial analysis, the only discernible information that complex geometries (e.g., WKT strings) can convey to humans are the types of features they contain (e.g., point, linestring, or polygon). erefore, we believe geometry data should be treated similarly to how other binary data is stored and referenced on the Semantic Web, namely via URIs. Just as with other binary resources on the web, we envision the client having the option to download geometry data by dereferencing their URIs. Coupled with content negotiation, such an approach allows clients to fetch geometry in a format that suits their needs (in addition to being able to negotiate for its RDF). To give an example, we implemented an HTTP server that supports various ‘Accept’ header media (MIME) types for geometries as shown in Table 1.
When dereferencing a geometry’s URI in a web browser (MIME type text/html), we designed a simple interface to display the geometry on a map and provide access to the actual data by triggering one of the other four supported content-types as shown in Fig. 2.
We mint each URI with human-readable metadata about the geometry it represents; this includes the geometry type, its unique ID, and the bounding box coordinates of the geometry (in the WGS84 coordinate reference system). For point geometries, this bounding box metadata is reduced to just the single coordinate pair, eectively encoding the entire geometry within the text of the URI. While such practice is not (yet) standardized, it enables clients to lter geometries by type and to begin building a spatial index if their application supports it. In our experiment, we encoded URIs for 2.2 curl "http://ex.co/geometry/polygon/12345" -H "Accept: $MIME TYPE"
text/html text/plain application/gml+xml application/json application/octet-stream
Web interface Well-Known Text GML GeoJSON Well-Known Binary
<!DOCTYPE html><html lang="en">...
POLYGON((113.1016 -38.062 ...)) <gml:Polygon><gml:Exterior>... f"type":"Polygon","coordinates":...g 01 06 00 00 20 E6 10 00 00 01... million geometries from the USGS Geographic Names Information System (GNIS) using this scheme (Listing 2).
base uri geometry ID http://ex.co/geometry/polygon/12345#113.05281,-38.11945/153.30671,-11.15957 geometry type WGS84 bounding box coordinates Listing 2 Encoding scheme used to mint URIs representing a geometry.
When the GeoSPARQL specication succeeded NeoGeo’s vocabulary and related approaches, a few resourceful concepts were unfortunately sacriced in the process that were among the strengths of NeoGeo. Most notably, reusing existing geometries to create socalled ‘Composite Geometries’ was a promising way to derive new features while tracking the provenance of its constituents – something that is not practical to achieve with RDF literals and that we would therefore consider a shortcoming of the current GeoSPARQL specication. is idea is expanded even further when considering geometric operations such as creating a union, intersection, dierence, buer, convex hull, and so forth. With the use of URIs, however, the option to reuse geometries is feasible once again. For example, one could describe the geometry of a university’s spatial extent by the union of the geometries for its constituent features such as its campus, sports stadium, and o-campus housing areas.
To summarize, we compare the strengths and weaknesses of three dierent approaches to storing and querying geospatial information as Linked Data for GeoSPARQL, NeoGeo, and our AGO proposal in Table 2.
While the last row in Table 2 indicates a weakness of using URIs to represent geometries, this is only from the perspective of an inactive client. If one considers the broader perspective of an application, this weakness is replaced by a strength. For instance, rather than downloading the geometry in a prescribed format, the client application can strategically schedule a bulk download of just the geometries it wants (e.g., of a certain type or within a given bounding box) in either a compact binary format (e.g., Well-Known Binary) or a ready-on-arrival format (e.g., GeoJSON for JavaScript applications). e ability to download multiple geometries in a single HTTP request certainly has its advantages, and we concede that coming up with an HTTP-friendly solution for doing this with geometry resource URIs needs discussion.
With the advent of GeoSPARQL and other means to perform spatial
and spatiotemporal queries [
Replacing the simple geometries that dominate knowledge
graphs and search engines today with more complex geometries
will be of limited use (beyond applications such as routing and
visualization). Instead, we believe that knowledge graphs and Linked
Data more concretely will see a greater benet from storing
topological relations. One could argue that such topological relations
can be computed using geometries but not the other way around.
While this is true in an abstract mathematical sense, it does not
hold for actual data. In fact, topological relations between places
cannot be easily computed based on geometry alone. While there
are many reasons for this [
To understand how topology is handled in GIS, it is important to note that data collection, modeling, and pre-processing take about 80% of the time budget of a typical GIS project. When data are loaded into a GIS, the analyst uses a sequence of toolboxes to rst correct common errors such as so-called sliver polygons and then applies domain-specic topological consistency rules.7 Neither the pre-processing steps nor the domain-specic topological rules are available when computing topological relations on-demand using GeoSPARQL over Linked Data. In addition, the datasets used for any given GIS task that involves topological relations are orders of magnitude smaller than querying such relations over Linked Data hubs such as DBpedia, i.e., they involve dozens of hundreds of polygons or linestrings but not hundreds of thousands. eries such as nding cities along the Mississippi River or counties along state borders cannot be eectively answered over Linked Data today.
Consider the following illustrative example. Given that Lynchburg, Tennessee is a consolidated city-county whose boundaries coincide with Moore County, Region Connection Calculus 8 (RCC8) dictates that the true topological relation between the city and the county must be equal (EQ). Computing the relation using the GeoSPARQL-enabled Apache Marmoa triplestore, however, will return a partial overlap; see Fig. 3. e reason for this is due in large part to digitization errors. More concretely, the so-called doubledigitized boundaries problem in which the blue boundary has been digitized to a greater degree of detail compared to the red boundary.
While such dierences in granularity are common sources of error, diculties arising from uncertainty and vagueness are even more troublesome. Whereas uncertainty stems from a lack of precise 7See, for example, the following overview of geodatabase topology rules by ArcGIS hp://resources.arcgis.com/en/help/main/10.2/01mm/pdf/topology rules poster.pdf. Trait GeoSPARQL NeoGeo AGO Uniform RDF structure 3 3 Ecient geometry storage 3 Content-negotiation for geometry format 3 3 Composite geometries 3 3 Geometry can persist externally 1 3 Determine geometry type 2 3 3 3 Access bounding box 2 3 Access raw geometry 2 3 3 1 = Geometry can persist in a local geodatabase or even on a remote system and without copies.
2 = From the triples’ RDF data alone (e.g., without using SPARQL).
knowledge, vagueness is caused by intrinsically underdetermined
concepts that do not have clear borders [
To experiment with the eect of precomputed relations on a linked dataset, we took a geospatial dataset consisting of counties, cities, parks, streams, and so on from the United States and computed several topological relations among polylines and polygons. Out of 18:6k polygons and 7:7k polylines, we extracted a total of 68:6k distinct relations to be materialized before querying takes place. We only materialize a relation in one direction and use reasoning to handle symmetric, transitive and disjoint properties. ese strict relations represent the topology of polygons aer being cleaned of digitization errors. We show the counts and statistics for this precomputed set in Table 3.
To give an example of the impact this practice can have on querying, we compared a topological GeoSPARQL query to its equivalent topological AGO (precomputed) query. e two SPARQL queries are shown in Listing 3. A simple trial shows that where a GeoSPARQL query takes 1318ms to complete due to the need for on-demand computation, an equivalent precomputed topological query takes 112ms, approximately 11 faster for our dataset. e other dierence to our topological query is that it also returns more results since it has cleaned the digitization errors, an important step to GIS analysis that GeoSPARQL does not currently support. # a) GeoSPARQL select ?place where { <http://dbpedia.org/resource/Tulsa,_Oklahoma>
geosparql:hasGeometry [geosparql:asWKT ?wktA]. ?place geosparql:hasGeometry [geosparql:asWKT ?wktB]. filter(geof:sfTouches(?wktA, ?wktB)) } # b) Our AGO approach prefix agt: <http://awesemantic-geo.link/topology/> . select ?place where { <http://dbpedia.org/resource/Tulsa,_Oklahoma>
agt:touches ?place. } Listing 3 Comparison of a topological SPARQL query for places that touch the city of Tulsa, Oklahoma using (a) GeoSPARQL and (b) AGO. 3.3
As we discussed above, strict/crisp topological relations (i.e., those
derived from an intersection-matrix of source geometries) alone
do not account for the vagueness and uncertainty principles that
exist for geographic data. erefore, we propose a multi-layered
topological relations framework to encompass these principles in
aempt to bring clarity to the fuzzy nature surrounding spatial
relations for regions. In other words, we supplement the set of
strict topological relations by computing additional topology for
features that may have broad boundaries [
e challenges of computing topological relations for features with broad boundaries are not limited to designing an ontology
relation
polygon touches polygon
polygon overlaps polygon
polygon tpp polygon
polygon ntpp polygon
polygon equals polygon
polyline touches polygon
polyline crosses polygon
polyline within polygon
polyline crosses polyline
that determines which features should be considered to have a
broad boundary and what types of relations may ensue, but also
deciding on a mathematical framework to use for calculating the
boundaries [
Our method for calculating broad boundaries is to use the isoperimetric quotient of a polygon, given by Q = P e4rπimAreetaer 2 . Aer computing a polygon-to-polygon distance matrix for each combination of feature types (e.g., city-to-city, city-to-park, etc.) we sort the distances to create a cumulative distribution function and select the 0.05 percentile value as p. en, a polygon’s broad boundary radius R (i.e., buer radius) is given by R = Q p. is model follows the rationale that simpler polygons deserve broader boundary radii than polygons having more complex structure because a ner resolution might generally imply a more precise digitization.
In this work we have revisited two pressing issues, how to store geometries and what role do they play in querying Linked Data. We showed that the established practices of storing complex geometries (beyond points and bounding boxes) as RDF literals, while suitable in some cases, should be reconsidered for other GIS applications and the many domain datasets that make use of complex geometries. We proposed an alternative method for storing geometry data by representing them via URIs in RDF and allowing the client to obtain data in the desired format by dereferencing the URI via content negotiation. We then argued that many GIS and geographic information retrieval queries do not utilize geometries directly but rely on topological relations, and that this may hold for Linked Data usage as well, i.e., users oen want to know whether two places are adjacent rather than what their exact geometries are. Computing such topological relations on-demand using GeoSPARQL is possible but leads to very common data quality errors. Furthermore, we suggest that even with today’s geospatial query tools that supplement Linked Data, supporting strict topological relations alone is not enough to satisfy the spectrum of user-driven topology queries about relations between regions due to uncertainty and vagueness.
Acknowledgments: We acknowledge support from USGS from the Linked Data for the National Map award.