=Paper=
{{Paper
|id=Vol-2977/paper4
|storemode=property
|title=GeoSPARQL 1.1: An Almost Decadal Update to the Most Important Geospatial LOD Standard (short paper)
|pdfUrl=https://ceur-ws.org/Vol-2977/paper4.pdf
|volume=Vol-2977
|authors=Nicholas John Car,Timo Homburg
|dblpUrl=https://dblp.org/rec/conf/esws/CarH21
}}
==GeoSPARQL 1.1: An Almost Decadal Update to the Most Important Geospatial LOD Standard (short paper)==
https://ceur-ws.org/Vol-2977/paper4.pdf
GeoSPARQL 1.1: An Almost Decadal Update to
the Most Important Geospatial LOD Standard
Nicholas J. Car1[0000−0002−8742−7730] and
Timo Homburg2[0000−0002−9499−5840] ⋆
1
Australian National University, Australia
nicholas.car@surroundaustralia.com
2
Mainz University Of Applied Sciences, Germany
timo.homburg@hs-mainz.de
Abstract. 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 stan-
dard, 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 on-
tologies, handling of new spatial referencing systems, new geometry rep-
resentations, 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.
· · · ·
· · · · ·
Keywords: GeoSPARQL GeoSPARQL 1.1 spatial geospatial Se-
mantic Web RDF OWL OGC Open Geospatial Consortium stan-
dard.
1 Introduction
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 Com-
mons 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 [6] suggests it is popular, as do the
incoming links in Linked Open Vocabularies https://lov.linkeddata.es/dataset/lov/
2 Car N.J. et al.
The original release - GeoSPARQL 1.0 - contained a specification document,
a main “GeoSPARQL” ontology in an RDF file and a “Simple Features Vocab-
ulary” 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 Sec-
tion 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 Motivation to update GeoSPARQL
The OGC & World Wide Web Consortium’s (W3C) Spatial Data On The Web
Working Group (SDWWG) established Spatial Data On The Web Best Prac-
tices [4] which noted shortcomings with then current spatial data standards:
“A best practice for returning geometries in a specific requested CRS has not
yet emerged”. The group also informally captured specific suggested updates for
GeoSPARQL7 , however no updates to GeoSPARQL were then made.
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
fixes and proposed extensions to GeoSPARQL 1.0 are captured in an OGC White
Paper [1]. Some, but not all, of the SDWWG’s ideas have been taken up by the
SDW, for example the Best Practices [4] aspiration that “A possible way forward
is an update for the GeoSPARQL spatial ontology. This would provide an agreed
spatial ontology, i.e., a bridge or common ground between geographical and non-
geographical spatial data...”. This point has been considered by the SWG and
included in future releases’ scope.
Another Best Practices issue raised is that “it makes sense to publish differ-
ent geometric representations of a spatial object that can be used for different
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 [2] and
this guides the SWG’s activities. Specific actions of the SWG and their staging
are explained through the use of a publicly-available online task tracking system
vocabs/gsp and the list of implementers that includes most of the popular triplestore
vendors, a list of which has been compiled here: https://github.com/opengeospatial/
ogc-geosparql/issues/59
5
https://www.w3.org/TR/sparql11-query/
6
https://www.w3.org/TR/skos-reference/
7
https://www.w3.org/2015/spatial/wiki/Further development of GeoSPARQL
GeoSPARQL 1.1 3
within the SWG’s working online code repository8 . At a high-level, proposed
updates to GeoSPARQL by both the SDWWG and the SWG may be categorised
as one of the following:
– new geometry serializations
• 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 sys-
tems
– 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 different 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 ge-
ometry 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 [5]
– catering for very different SRSes, such as Discrete Global Grid Systems
Specifically ruled out of scope was any investigation of property graphs. Re-
cent (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 different 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 ontol-
ogy 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, how-
ever initial SWG attendees’ intuition is that a future GeoSPARQL 2.0 might
8
https://github.com/opengeospatial/ogc-geosparql/projects/1
4 Car N.J. et al.
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. Moti-
vatied by conceptual work within the W3C and OGC for multi-part standards,
this has resulted in profile declarations explained in the next section.
3 Updates in GeoSPARQL 1.1
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 [10]. The next sections foreshadow likely 1.2 and 2.0 updates.
3.1 Profile Declaration
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 [3]. Motivation for this was the SWG’s recognition that
GeoSPARQL 1.0 consisted of multiple parts, not all of which were easy to dis-
cover, so some GeoSPARQL users were unaware of some resources and some
resources were accidentally duplicated or partly re-implemented. Profile decla-
rations of this sort are anticipated, by the OGC, as being the best practice way for
multi-part standards delivery. The profile declaration for GeoSPARQL 1.0 will
be published as a stand-alone resource along with some updated GeoSPARQL
1.0 resources and at the same time as the 1.1 releases, currently expected in
mid-2021. All 1.0 and 1.1 release resources are currently available in draft form
in the SWG’s online code repository9 . The 1.1 releases’ resources are:
1. a profile declaration
2. a specification document
3. an RDF/OWL ontology document
4. a Functions & Rules vocabulary, derived from the ontology
5. a Simple Features feature types vocabulary
6. a set of Rules Interchange Format rules
7. SHACL [9] shapes for RDF data validation
3.2 New geometry literals
Three new geometry serializations are introduced:
1. GeoJSON (Geo-JavaScript Object Notation)10
9
https://github.com/opengeospatial/ogc-geosparql
10
https://geojson.org
GeoSPARQL 1.1 5
2. KML (Keyhole Markup Language)
3. DGGS (Discrete Global Grid System) [11]
An example of a point’s GeoJSON geometry serialization is given below, fol-
lowed by an unrelated simple polygon AusPIX 11 DGGS geometry serialization.
Listing 1.1. GeoJSON geometry serialization example
" " " { " type " : " Point " , " coordinates " :[ -83.38 ,33.95]} " " "
^^ < http :// www . opengis . net / ont / geosparql # geoJSONLiteral >
Listing 1.2. AusPIX DGGS geometry serialization example
" " " < https :// w3id . org / dggs / auspix > DirectedOrdinateList
( R3231 R3234 R3235 R3238 R3243 R3246 ) " " "
^^ < http :// www . opengis . net / ont / geosparql # 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 - different DGGSes will likely implement
very different 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 New spatial functions
While spatial aggregation functions are the norm in many non-semantic geospa-
tial 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 [13]. Spatial aggre-
gation functions similar to traditional (relational database), aggregation func-
tions such as AVG, MAX, or MIN allow aggregated results of geometry queries,
for example, to create the union of a set of selected serialized geometries. While
calculating these aggregates is certainly possible outside of a semantic database,
and thus GeoSPARQL, the inclusion of the functions provides distinct advan-
tages:
1. No client-side library is needed to create an aggregated geometry result
2. Fewer/more appropriate results returned, for example a union result
3. Federated SPARQL queries can aggregate results from multiple endpoints
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
6 Car N.J. et al.
Listing 1.3. Aggregation Function example SPARQL query
# returns circle bounding all geometries of Feature
SELECT ( geof : BoundingCircle (? geo ) AS ? circ )
WHERE { 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 stan-
dard [12] is being developed that proposes feature collections functions filtering.
While it proposes the use of the Common Query Language (CQL) for filtering,
it is also open to other query language implementations such as GeoSPARQL.
When comparing the filter capabilities of CQL to GeoSPARQL, one can observe
that the two query languages provide comparable spatial functionality, however
the CQL proposed supports spatiotemporal operators, which may be an addition
to GeoSPARQL to be further explored in its contiuous development process.
3.4 Ontology extensions
GeoSPARQL 1.1 - see Figure 1 for an overview - extends the GeoSPARQL ontol-
ogy 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 [7]. Similarly, the
1.1 release addition of property geo:inSRS, allows declarations of a geometry’s
SRS, independent of serializations and paves the way for future definition of
SRSes in RDF, anticipated for GeoSPARQL 2.0.
Fig. 1. Excerpt of the GeoSPARQL 1.1 ontology including one example feature
GeoSPARQL 1.1 7
4 Conclusions and Outlook
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 for-
malization 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 stan-
dard. Changes proposed for GeoSPARQL 2.0 include to broaden the scope of
GeoSPARQL to further kinds of spatial data. To that end, full-featured sup-
port 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 build-
ing modeling information [14] and coverage data [8]. More requirements might
also be introduced once feedback has been received from the GeoSPARQL 1.1
and 1.2 releases.
References
1. Abhayaratna, J., van den Brink, L., Car, N., Atkinson, R., Homburg, T., Knibbe,
F., ..., Thiery, F.: OGC Benefits of Representing Spatial Data Using Semantic and
Graph Technologies. OGC White Paper, Open Geospatial Consortium (Oct 2020),
http://docs.ogc.org/wp/19-078r1/19-078r1.html
2. Abhayaratna, J., van den Brink, L., Car, N., Homburg, T., Knibbe, F.: OGC
GeoSPARQL 2.0 SWG Charter. Ogc swg charter, Open Geospatial Consortium
(Aug 2020), https://portal.ogc.org/files/93345
3. Atkinson, R., Car, N.J.: The Profiles Vocabulary. W3C Working Group Note,
World Wide Web Consortium (May 2020), https://www.w3.org/TR/dx-prof/
4. van den Brink, L., Barnaghi, P., Tandy, J., Atemezing, G., Atkinson, R.,
Cochrane, B., Fathy, Y., ... Troncy, R.: Best practices for publishing, retriev-
ing, and using spatial data on the web. Semantic Web 10(1), 95–114 (Dec 2018).
https://doi.org/10.3233/SW-180305
5. Cox, S., Little, C.: Time Ontology in OWL. W3C Recommendation, World Wide
Web Consortium (Oct 2017), https://www.w3.org/TR/owl-time/
6. Doerr, M., Hiebel, G., Eide, Ø.: Crmgeo: Linking the cidoc crm to geosparql
through a spatiotemporal refinement. Tech. rep., Citeseer (2013)
7. Haller, A., Janowicz, K., Cox, S., Le Phuoc, D., Taylor, K., Lefrançois, M.: Seman-
tic Sensor Network Ontology. W3C Recommendation, World Wide Web Consor-
tium (Oct 2017), https://www.w3.org/TR/vocab-ssn/
8. Homburg, T., Staab, S., Janke, D.: Geosparql+: Syntax, semantics and system for
integrated querying of graph, raster and vector data. In: International Semantic
Web Conference. pp. 258–275. Springer (2020)
9. Knublauch, H., Kontokostas, D.: Shapes Constraint Language (SHACL). W3C
Recommendation, W3C (2017), https://www.w3.org/TR/shacl/
10. Perry, M., Herring, J., Car, N.J., Homburg, T., J.D. Cox, S.: OGC GeoSPARQL
- A geographic query language for RDF data: 1.1. OGC implementation standard
draft (2012), https://opengeospatial.github.io/ogc-geosparql/
8 Car N.J. et al.
11. Sahr, K., White, D.: Discrete Global Grid Systems. Computing Science and Statis-
tics pp. 269–278 (1998)
12. Vretanos, P.A., Portele, C.: OGC API - Features - Part 3: Filtering and the Com-
mon Query Language (CQL). Open geospatial consortium standard draft, Open
Geospatial Consortium (2021), https://portal.ogc.org/files/96288
13. W3C SPARQL Working Group: SPARQL 1.1 Overview. W3C Recommendation,
World Wide Web Consortium (2013), http://www.w3.org/TR/sparql11-overview/
14. Zhang, C., Beetz, J., de Vries, B.: Bimsparql: Domain-specific functional sparql
extensions for querying rdf building data. Semantic Web 9(6), 829–855 (2018)