GeoSPARQL 1.1: An Almost Decadal Update to the Most Important Geospatial LOD Standard

. 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.


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 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 SPARQL 5 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 SKOS 6 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.

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 Practices [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 GeoSPARQL 7 , 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 nongeographical 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 different 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 within the SWG's working online code repository 8 . 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 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 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 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 [5] catering for very different SRSes, such as Discrete Global Grid Systems 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 different goals: 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 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.

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 discover, so some GeoSPARQL users were unaware of some resources and some resources were accidentally duplicated or partly re-implemented. Profile declarations 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 repository 9 . 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

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 2. KML (Keyhole Markup Language) 3. DGGS (Discrete Global Grid System) [11] An example of a point's GeoJSON geometry serialization is given below, followed by an unrelated simple polygon AusPIX 11 DGGS geometry serialization. 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.

New spatial functions
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 [13]. Spatial aggregation functions similar to traditional (relational database), aggregation functions 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 advantages: 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. Coincident with GeoSPARQL 1.1 development, the OGC API Features standard [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.

Ontology extensions
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 [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.

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 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 [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.