In 2012 the Open Geospatial Consortium published GeoSPARQL defining “SPARQL extension functions”, “RIF rules” and “an RDF/OWL ontology for [spatial] information”. In the 8+ years since its publication, GeoSPARQL has become the most important spatial Semantic Web standard, as judged by references to it in other Semantic Web standards and its wide use in Semantic Web data. An update to GeoSPARQL was proposed in 2019 to deliver 1.1 in 2021 with a charter to: handle outstanding change requests and source new ones from the user community and to “better present” the standard, that is to better link all the standard's parts and better document & exemplify elements. Expected updates included alignments to other ontologies, handling of new spatial referencing systems, new geometry representations, and new artifact presentation. In this paper, we will discuss the submitted change requests and resulting updates to the standard. We will also discuss the theory behind updates and our expectations for GeoSPARQL 1.1's use.
The GeoSPARQL standard, issued in 2012 by the Open Geospatial Consortium
(OGC)3 is one of the most popular Semantic Web standards for spatial data.4
⋆ Copyright '2021 for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0).
3 https://www.ogc.org
4 References to GeoSPARQL in other well-known standards, such as DCAT2 (https://
www.w3.org/TR/vocab-dcat/) and CIDOC-CRM [
The original release - GeoSPARQL 1.0 - contained a specification document, a main “GeoSPARQL” ontology in an RDF file and a “Simple Features Vocabulary” ontology also in an RDF file. The “GeoSPARQL” ontology content, as well as lists of geospatial functions that could be performed on RDF data via SPARQL5 queries were defined in the specification document, as were entailment rules and requirements & abstract tests for testing ontology data and function implementations. Function lists from the specification have been extracted into SKOS6 vocabularies.
Here we discuss the motivations behind updating GeoSPARQL 1.0 in Section 2, content of the planned GeoSPARQL 1.1 release in Section 3 and finally in Section 4 provide an outlook to further feature requests which are likely to be tackled in future GeoSPARQL 1.2 and 2.0 releases. 2
The OGC & World Wide Web Consortium’s (W3C) Spatial Data On The Web
Working Group (SDWWG) established Spatial Data On The Web Best
Practices [
Recently, in 2019, the OGC reconstituted a GeoSPARQL Standards Working
Group (SWG) to update GeoSPARQL. The general motivation for work within
the area of GeoSPARQL, that of Semantic Web spatial data, and a series of fault
ifxes and proposed extensions to GeoSPARQL 1.0 are captured in an OGC White
Paper [
Another Best Practices issue raised is that “it makes sense to publish diferent geometric representations of a spatial object that can be used for diferent purposes”. This is being considered by the SWG with initial thoughts centering on defining roles of geometries with respect to features.
The SWG’s charter - final scope of work - is also published by the OGC [
• GeoJSON, KML and other popular formats – new ontology classes to cater for more nuanced spatial information – more spatial functions • implementing functions well-known in non Semantic Web spatial systems – scalar spatial properties (area, volume etc. alongside geometries) – better handling of Spatial (Coordinate) Reference Systems (SRS) • potentially allowing for automated coordinate serialization conversions – Internet protocol-based selection of diferent geometries for features
Some of these proposed updates were predicted in GeoSPARQL 1.0, with the
Future Work section listing several of the points above as expected or potential.
The SWG’s Charter, anticipating that the more obvious updates such as new
geometry serializations would certainly be implemented, listed the following areas
of investigation that emerged from SWG proponent’s discussions:
– revising “upper ontology” GeoSPARQL structure - how its classes relate to
fundamental concepts in ontology
– alignments to other ontologies, perhaps W3C Time Ontology in OWL [
Specifically ruled out of scope was any investigation of property graphs. Recent (last several years) discussion in the OGC and elsewhere about property graphs motivated a consideration of them, however, the SWG proponents felt that while property graphs might be important for future Semantic Web spatial data systems, there was more than enough work scoped for initial SWG work (several revisions of the standard) to initially exclude this area of investigation.
After initial meetings, the SWG determined to make multiple releases of GeoSPARQL updates with diferent goals: – 1.1: extensions that are fully compatible with GeoSPARQL 1.0 – 1.2: fully or mostly compatible extensions but which are larger additions to the standard’s conceptual coverage – 2.0: future GeoSPARQL likely incompatible with GeoSPARQL 1.0
The reason for expecting a future, incompatible, GeoSPARQL 2.0 is that early SWG attendees thought spatio-temporal relations and fundamental ontology elements in GeoSPARQL either could or should be remodelled, which might break the current, familiar, Feature/Geometry class relations. Details of these potential changes haven’t been fully expounded, at the time of this paper, however initial SWG attendees’ intuition is that a future GeoSPARQL 2.0 might
generalise spatial concepts and move away from only, or primarily, geospatial, or perhaps focus not just on Feature/Geometry relations but look to generalised mechanisms for describing dimensions of features of which geometry is just one of many, and temporality might be another.
Originally unexpected, an area of updates to standard presentation. Motivatied by conceptual work within the W3C and OGC for multi-part standards, this has resulted in profile declarations explained in the next section. 3
So far (April, 2021) the GeoSPARQL SWG has triaged change requests for
GeoSPARQL and has addressed many 1.1 requests - the only ones we report
here and which are accessible through the living document for the GeoSPARQL
1.1 standard [
One of the first SWG actions was to link GeoSPARQL 1.0 elements through
a profile declaration, where a profile is a type of specification , as defined by
The Profiles Vocabulary [
Three new geometry serializations are introduced: 1. GeoJSON (Geo-JavaScript Object Notation)10
2. KML (Keyhole Markup Language)
3. DGGS (Discrete Global Grid System) [
An example of a point’s GeoJSON geometry serialization is given below, followed by an unrelated simple polygon AusPIX 11 DGGS geometry serialization.
Listing 1.1. GeoJSON geometry serialization example " " " { " type " : " Point " , " c o o r d i n a t e s " :[ -83.38 ,33.95]} " " " ^^ < http :// www . opengis . net / ont / g eo sp ar ql # geoJSONLiteral >
Listing 1.2. AusPIX DGGS geometry serialization example " " " < https :// w3id . org / dggs / auspix > D i r e c t e d O r d i n a t e L i s t ( R3231 R3234 R3235 R3238 R3243 R3246 ) " " " ^^ < http :// www . opengis . net / ont / g eo sp ar ql # dggsWktLiteral >
GeoJSON & KML have been much anticipated and were requested by the SDWWG and many users of GeoSPARQL, due to those formats’ popularity. The DGGS format is more forward-looking in that it is not driven by user demand but by predicted demand. DGGS does not have a single, concrete format standard as the others do, nor is it ever likely to - diferent DGGSes will likely implement very diferent data formats - so GeoSAPRQL 1.1 makes generalized provisions for DGGS serializations but presents no detailed requirements for them, only stating that the specific DGGS must be identified. 3.3
While spatial aggregation functions are the norm in many non-semantic
geospatial databases such as PostGIS or Oracle Spatial, at the time of defining the
GeoSPARQL 1.0 standard, aggregation functions had not yet been introduced
into the SPARQL standard, but have been with SPARQL 1.1 [
In addition to geof:union, geof:envelope and geof:convexHull defined in GeoSPARQL 1.0 for use within SPARQL FILTER operations, 1.1 defines geof:union2 and as well as geof:boundingCircle, geof:centroid , geof:ConcatLines - concatenating a set of overlapping linestrings that overlap - and geosf:ConcaveHull that can return aggregated results. Listing 1.3 shows one new function in use. 11 https://w3id.org/dggs/auspix
Listing 1.3. Aggregation Function example SPARQL query # returns circle bounding all geometries of Feature <x > SELECT ( geof : BoundingCircle (? geo ) AS ? circ ) WHERE {<x > geo : hasGeometry / geo : asWKT ? geo .}
Functions to retrieve min/max values of geometries’ coordinates are added: geof:minX & geof:maxX , geof:minY & geof:maxY and geof:minZ & geof:maxZ .
Coincident with GeoSPARQL 1.1 development, the OGC API Features
standard [
GeoSPARQL 1.1 - see Figure 1 for an overview - extends the GeoSPARQL
ontology by adding a new class, geo:SpatialMeasure. This class represents a spatial
measurement such as a volume, length, or area associated with a measurement
amount and a unit of measure. It is the range of three newly-defined properties:
geo:hasArea, geo:hasLength and geo:hasVolume which make these attributes
of a geometry better accessible using SPARQL. These additions address requests
from the SDWWG & SWG but also open up GeoSPARQL to general patterns
of measurement present in ontologies such as the W3C’s SOSA [
A staged schedule of updates to this important Semantic Web spatial standard
has been initiated with simple and strictly backwards-compatible changes now
in GeoSPARQL 1.1. Features discussed for GeoSPARQL 1.2 include the
formalization of coordinate reference systems in RDF, the depiction of accurracies
and level of detail and the addition of further - possibly also binary - literal
types. Work on GeoSPARQL 1.2 will start later in 2021. GeoSPARQL 2.0, as
yet un-specified, is likely to introduce more substantial changes to the
standard. Changes proposed for GeoSPARQL 2.0 include to broaden the scope of
GeoSPARQL to further kinds of spatial data. To that end, full-featured
support for 3D geometries and support for coverages are discussed on the level of
data representations. These proposals are related to some growing interest in the
semantic web community in representing further geospatial data related to
building modeling information [