GeoSPARQL 1.1: Motivations, Details and Applications of the Decadal Update to the Most Important Geospatial LOD Standard †

: In 2012, the Open Geospatial Consortium published GeoSPARQL defining “an RDF/OWL ontology for [spatial] information”, “SPARQL extension functions” for performing spatial operations on RDF data and “RIF rules” defining entailments to be drawn from graph pattern matching. 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 for Semantic Web data. An update to GeoSPARQL was proposed in 2019 to deliver a version 1.1 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 and exemplify elements. Expected updates included new geometry representations, alignments to other ontologies, handling of new spatial referencing systems, and new artifact presentation. This paper describes motivating change requests and actual resultant updates in the candidate version 1.1 of the standard alongside reference implementations and usage examples. We also describe the theory behind particular updates, initial implementations of many parts of the standard, and our expectations for GeoSPARQL 1.1’s use. data sourced from a GeoSPARQL RDF dataset. dialog on the map features related to the ‘Queensland’ feature via Simple Features relations such as geo:sfWithin that the National Map software been to


Introduction and Motivation
The GeoSPARQL standard, issued in 2012 by the Open Geospatial Consortium (OGC) (https://www.ogc.org, accessed on 30 October 2021) is one of the most popular Semantic Web standards for spatial data. References to GeoSPARQL in other well-known standards, such as DCAT2 [1] and CIDOC-CRM [2,3] suggests it is popular, as do the incoming links in Linked Open Vocabularies (https://lov.linkeddata.es/dataset/lov/vocabs/gsp, accessed on 30 October 2021) and the list of implementors that includes most of the popular triplestore vendors, a list of which has been compiled here: https://github.com/ opengeospatial/ogc-geosparql/issues/59, accessed on 30 October 2021. The original release-GeoSPARQL 1.0 [4]-contained: • A specification: document:

-
The main GeoSPARQL document defining, in human-readable terms and with code snippets, most elements of the standard including ontology elements, geospatial functions that may be performed on Resource Description Format (RDF) [5] data via SPARQL [6,7] queries, entailment rules in the Rules Interchange Format (RIF) [8] for RDF reasoning and requirements and abstract tests for testing ontology data and function implementations.
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 serialisations: -GeoJSON, KML and other now-popular formats missing from GeoSPARQL 1.0.

-
The possibility to convert between literal formats in-query.
• New and specialised ontology classes and properties: -More nuanced spatial data representation and alignment with other systems.
• More spatial functions: -Implementing functions well-known in non-Semantic Web spatial systems.
• Better handling of Spatial (Coordinate) Reference Systems (SRS) -Allowing for automated coordinate serialisation 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. The SWG's Charter, anticipating that the more obvious updates such as new geometry serialisations would certainly be implemented, listed the following extra 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 [19]; • Catering for very different SRSes, such as Discrete Global Grid Systems.
Specifically ruled out of scope in the Charter was any investigation of property graphs. Recent (last several years) discussions in the OGC and elsewhere about property graphs motivated their consideration. 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 versioned 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 remodeled, which might break the current, familiar, feature/geometry class relations. Details of these potential changes have not been fully expounded at the time of this paper, however initial SWG attendees' intuition is that a future GeoSPARQL 2.0, or perhaps a renamed GeoSPARQL replacement, 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. See Section 5 for further details.
Originally unexpected, an area of updates to standard presentation was considered by the SWG. Motivation from conceptual work within the W3C and OGC for the presentation of multi-part standards and the desire by the OGC's "Naming Authority". (the Naming Authority (https://www.ogc.org/projects/groups/ogcnasc, accessed on 30 October 2021) has the remit to ". . .ensure an orderly process for assigning URIs for OGC resources, such as OGC documents, standards, XML namespaces, ontologies" and also acts as a process evangelist, promoting, as it sees, better standards publication practice) to publish standards more systematically and in more machine-readable forms, as well as programs of work such as the OGC's "Test Bed 17: Model Driven-Standards" (The Testbed 17 work package "Model Driven Standards" (https://portal.ogc.org/files/?artifact_id= 95726#ModelDrivenStandards, accessed on 30 October 2021) focused on generating documents from models but also partly developed test implementations of formally-defined, multi-part, standards, such as GeoSPARQL 1.1), this has resulted in the profile declaration explained in the next section.

Updates in GeoSPARQL 1.1
In 2021, the GeoSPARQL SWG addressed many of the GeoSPARQL change requests in the 1.1 release. All of the changes reported here are now visible in the current working draft of the GeoSPARQL 1.1 standard, the specification document, and the other standard parts [20]. It is expected that the candidate standard will remain essentially unchanged through to final publication, barring perhaps minor updates due to wider implementation feedback. This section lists work completed only (see Section 5.1 for further notes on final GeoSPARQL 1.1 work) and will point out new features, possibilities, and applications of the elements included in the GeoSPARQL 1.1 update. At first, we discuss the new structure of the standard's specification (Section 2.1), describe relevant extensions to the ontology model and query language in Sections 2.4 and 2.9.

Profile Declaration
One of the first SWG actions was to link GeoSPARQL 1.0 elements through a profile declaration, where a profile is a formally-defined variant of a standard. profile and standard, as well as relations between them and their parts, are defined by The Profiles Vocabulary [21].
The initial motivation for this was twofold: 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 GeoSPARQL resources, some of which have been accidentally duplicated or partly re-implemented, and the desire for machine-readable forms of as many of the standard's parts as possible.
Descriptions of multi-part standards using the Profiles Vocabulary are anticipated by the OGC as being their future best practice method for standards delivery (This is ascertained through personal communication with the OGC's Naming Authority staff, one of whom was a co-editor of The Profiles Vocabulary).
As the elements of GeoSPARQL 1.1 have been created, they too have been described using the Profile Vocabulary, and GeoSPARQL 1.0 has been indicated as being a profile of, that is, a subset of, GeoSPARQL 1.1 since all GeoSPARQL 1.0 elements are present in GeoSPARQL 1.1.
The profile declaration for GeoSPARQL 1.0 and all of its parts will be published alongside those of GeoSPARQL 1.1, currently expected in early 2022. Currently, all draft 1.0 and 1.1 resources are available in the SWG's online code repository (https://github.com/ opengeospatial/ogc-geosparql, accessed on 30 October 2021). The 1.1 releases' profile resources, described using roles given in the Profiles Vocabulary are:

Ontology Extensions
GeoSPARQL 1.1 extends the GeoSPARQL ontology by adding multiple new properties and three collection classes. Initially, the SWG proposed a SpatialMeasure class to represent scalar spatial measurements too, but this was ultimately not added in favour of a series of 'size' properties only. See Figure 1 for an overview of the current, which is a redrawing of GeoSPARQL 1.1's ontology overview diagram.

Scalar Spatial Properties
Scalar properties of spatial objects, such as a volume, length, can now be indicated in GeoSPARQL 1.1 with either a 'metric' property-one that indicates a literal value in meters-or a non-metric property that may indicate a measurement value and a unit of measure. The metric/non-metric property pairs are all sub properties of a generic 'size' property and have the domain of geo:SpatialObject meaning they can be used with either geo:Feature or geo:Geometry instances. Properties pairs defined are: The dual definition of metric and non-metric properties is aimed at allowing both simple and more detailed use. The metric properties are informally preferred for use. The SWG considered their inclusion only; however, the non-metric options were ultimately included to allow for the use of historic units for which no conversion to the metric system is known. Listing 1 shows two metric/non-metric pairs in use for the area and perimeter length, and Inclusion of scalar spatial measurements within GeoSPARQL itself addresses concerns raised by the user community (see the SWG's Charter) that scalar spatial use with GeoSPARQL was occurring but that it was un-standardised or unguided and thus not necessarily interoperable. The particular pattern of non-metric scalar spatial measure chosen emulates common patterns for such measurements in ontologies such as the W3C's SOSA [24,25].    Figure 3 shows multiple geometries for a single feature and Listing 2 shows a representation of them in RDF with these new properties used. The SWG recognised that there could be many more subproperties of geo:hasGeometry added to GeoSPARQL 1.1 than the few they did ultimately add. However, no inclusion/exclusion logic was determined by the group nor properties deliberately excluded. One path for future exploration in this area mooted but not implemented for GeoSPARQL 1.1 was the concept of geometry roles-the nature of a geometry's role with respect to a feature-and the SWG discussed creating a geometry roles vocabulary. This is noted again in Section 5.

Topological Relations
GeoSPARQL 1.1 does not define any new topological relations or properties for them as compared to GeoSPARQL 1.0 (cf . Table A1), however, the new specification version does include much more supporting material for users of these relations and GeoSPARQL in general, in particular examples of real-world geometry data represented in RDF according to GeoSPARQL 1.1.  Brisbane is also the same as in Figure 3. Topological spatial relations that may be declared either between these geometries directly or between the features that these are geometries for.

Support for Collections
GeoSPARQL 1.1 introduces support for collections of Features (geo:FeatureCollection) and Geometries (geo:GeometryCollection) which are both subclasses of the more general class geo:SpatialObjectCollection. This allows for the grouping of features and geometries by specific attributes, and defined object collections in data are also required by standards such as the OGC's Features API [26].
While the GIS community commonly organises geospatial features in the form of collections, including in software such as ArcGIS (https://www.arcgis.com/, accessed on 30 October 2021) or QGIS (https://www.qgis.org/, accessed on 30 October 2021), before the inclusion of specific collection classes in GeoSPARQL 1.1., GeoSPARQL data users had to implement virtual collections from the results of SPARQL queries for compatibility with many of their tools. This required more work on behalf of tool maintainers for tools such as the SPARQLing Unicorn QGIS plugin (https://github.com/sparqlunicorn/ sparqlunicornGoesGIS, accessed on 30 October 2021).

Ontology Alignments
GeoSPARQL may be the most widely used ontology to represent spatial data, but there are many other vocabularies in use which try to encode geospatial locations. Many of these ontologies, such as W3CGeo, Geonames or Wikidata representations of geolocations may only be used to encode point geometries. However, some vocabularies such as NeoGeo or schema.org, also allow for the representation of more complex geometries, for example in Well-Known-Text literals. Alignments with GeoSPARQL 1.1 and 15 other vocabularies containing spatial elements are presented in an Annex of the upcoming standard. In addition to written statements and tables of alignments, alignments have also been presented as RDF files for direct reuse in RDF databases. Listing 5 shows two individual alignments-from schema.org and from the Provenance Ontology-to exemplify their presentation in the standard: a direct class mapping and a property for which there is no mapping mapping. The PROV property indicates a prov : Location , so perhaps a geo : Feature , but~GeoSPARQL has no property to indicate a geo : Feature

New Geometry Literal Types
Three new geometry serializations are introduced in GeoSPARQL 1.1:

GeoJSON & KML
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.
An example GeoJSON geometry, a point, representing the location of the centroid of the Brisbane electoral district from Figure 3 is given in Listing 6, Listing 7 shows the same geometry in KML for comparison, and that geometry's inclusion in GeoSPARQL 1.1. RDF is given in Listing 8. In GeoSPARQL 1.1, geometry data formats that allow for feature information, such as GeoJSON, are limited to representing geometries only, to avoid possibly conflicting literal and RDF information. This is in keeping with GeoSPARQL 1.0, which imposed the same restriction on GML data. In the example in Figure 3, GeoJSON is used to indicate the geometry type-"type":"Point"-as well as give the geometry's coordinates, but not feature annotations, such as name.
Keyhole Markup Language (KML) is a well-known, XML-based, GML-like geometry format. Its use in GeoSPARQL 1.1 is straightforward.  Figure 3. The generic predicate for indicating a DGGS serialization-geo:asDGGS-is used and the specific DGGS-AusPIX-is indicated via use of a custom datatype ex:auspixLiteral.
To assist with understanding what DGGS data is, Figure 5 shows the data from Listing 9 as well as finer DGGS approximations of the Brisbane electoral district's boundary polygon. DGGS such as AusPIX represent areas, points, lines and other geometric shapes with collections of 'cells' of different sizes at different 'levels'. There is no theoretical limit as to how many levels, and thus fine cells AusPIX may use, thus too, no theoretical resolution limit.

Appropriateness of DGGS Data as Geometry Literals
The appropriateness of the addition of GeoJSON and KML to GeoSPARQL 1.1 as new geometry literal formats was uncontroversial, with the single consideration of substance being the exclusion of information other than geometry information from GeoJSON, as indicated above.
The inclusion of a placeholder or abstract property and datatype for DGGS literals was quite controversial due to differing perceptions of what DGGS data represents. The SWG members do not all agree that DGGS data represent geometries or features, and there is no straightforward theoretical case to be made for either due to DGGS' novelty and mechanisms that are vastly different from traditional spatial data systems. The SWG decided that the criteria for geometry representation in GeoSPARQL 1.1 were that the literals had to be able to act as geometry objects in order to satisfy at least some major proportion of the GeoSPARQL functions. Essentially, anything that could be used for spatial relations calculation and spatial aggregates could be treated, at least by GeoSPARQL 1.1, as a geometry literal.
During the first half of 2021, within the lifetime of the SWG, a software library was produced that implemented all the Simple Features functions, except for geof:sfCrosses (see Section 3.1 for the implementation description). While not all Simple Features functions were implemented for, nor were functions for the other families of spatial relations, the SWG determined that, given the implementation evidence so far, AusPIX DGGS data could indeed act as geometry literals, from GeoSPARQL's point of view. Thus, DGGS literals could satisfactorily act as geometries, at least from GeoSPARQL's point of view. The SWG's discussion on this matter is captured in their online code repository's Issue 112.

New Geometry Conversion Functions
GeoSPARQL 1.1 provides the conversion functions geof:asWKT, geof:asGML, geof:asKML, geof:asGeoJSON and geof:asDGGS to convert between different literal types while considering the literal types capabilities. For example, a conversion of a WKT literal in the EPSG:25832 coordinate system to either KML or GeoJSON will result in the geometry being converted to the World Geodetic System 1984, as this is the only coordinate reference system valid in the two respective literal types. Hence, a conversion from GeoJSON or KML to WKT will stay in the World Geodetic System 1984 coordinate reference system. To still be able to convert geometries to other coordinate reference systems, GeoSPARQL 1.1 adds the geof:transform function, which converts a geometry literal to another coordinate reference system if the literal formats allow such a transformation.
With these additions, future triplestore implementations become very flexible in providing a variety of geometry conversions even without being dependent on another intermediate web service for coordinate/format conversions.

Spatial Aggregate 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 [6]. 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 serialised 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 are 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

Comparison of Query Capabilities
It makes sense to determine how the new version GeoSPARQL 1.1 compares to other, also non-semantic query languages dealing with geospatial representations. We discuss the comparable query languages CQL [31], Simple Features for SQL specification, and the PostGIS implementation extensions as the most typical representatives of spatial data query languages besides GeoSPARQL.

Common Query Language CQL
The Common Query Language CQL was developed for usage with OGC Web Services and provides filter capabilities for feature collection or coverage data. The CQL query language is also part of the currently in-development OGC API Features standard [31], the successor specification to OGC web services. OGC API Features proposes using the Common Query Language (CQL) for filtering but 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 (cf. Table 1). However, the CQL proposed supports spatiotemporal operators, which may be an addition to GeoSPARQL to be further explored in its continuous development process. To exemplify the relationship between CQL and the GeoSPARQL query language, the SWG will release a Best Practice document (https://opengeospatial.github.io/ogcgeosparql/bestpractice/bestpractice_cql.html, accessed on 30 October 2021), which includes detailed descriptions of the equivalences between the two query languages.

Simple Features for SQL
Another interesting comparison can be made between the query capabilities of GeoSPARQL and the Simple Features for SQL specification [10]. To date, we can conclude that feature parity with the Simple feature specification has been reached with regards to the expression of geospatial relations using properties and using filter functions. Features still missing in the GeoSPARQL 1.1 standard are functions that specifically address attributes of particular geometry types. In that way, it is impossible to access specific points of LineStrings (such as start and end points) and their closedness in-query and the access of polygonal rings and single coordinates of points using query functions. These functions are planned to be implemented in an upcoming, possibly minor update to GeoSPARQL 1.1. We include a comparison table between SQL and the GeoSPARQL specification to highlight the differences in detail.

PostGIS Query Capabilities
In relational spatial databases, one may observe more types of spatial functions as compared to the Simple Features for SQL specification. In addition, more types of geospatial representations can be processed. Finally, one can look at comparable implementations in relational database systems, such as PostGIS. In particular, this is true for representing coverage data, i.e., rasters in PostGIS. The database features comparing raster data to vector data representations, raster algebra operations on raster, and further raster-specific modifications. These query capabilities are currently far beyond the capabilities of GeoSPARQL 1.1 and might be tackled in further development.

Shacl Shapes for Graph Validation
Since the adoption of SHACL [23] as the recommended way to represent constraints on RDF graphs by W3C, the semantic web community has created shapes for various knowledge domains. These shapes fulfill different purposes, from checking the graph structure for consistency to checking the contents of the graph. Included with GeoSPARQL 1.1, there are SHACL shapes that validate the graph structure as defined in GeoSPARQL 1.1 in the following aspects:

1.
Encouragement of a unified Geometry instance structure: GeoSPARQL 1.1 encourages geo:Geometry instances to only link to one serialisation. The intention behind this rule is that not all Geometry serialisations that GeoSPARQL 1.1 supports are 1:1 convertible.
Users are still free to use more than one serialisation attached to a Geometry but should be warned about the fact that serialisations may not be 100% equivalent. A simple example of this non-equivalence can be seen when a geometry is associated with a WKT literal in a non CRS84 coordinate reference system and a GeoJSON literal. Because of a limitation of the GeoJSON literal to only accept one coordinate reference system, the literal values of these to literals cannot be equivalent.

2.
Rudimentary checks of literal contents: Geometry literal contents are checked for plausibility. These checks do not contain the parsing of geometry literals and its validation but aim to check whether the contents of the geometry literal seem to be correct according to its literal type.

3.
Correct usage of GeoSPARQL classes: Several SHACL shapes test the proper usage of GeoSPARQL classes. In particular, SpatialObjectCollections are expected to have at least one member relation, and geo:Feature instances are expected to be associated to at least one geo:Geometry instance, whereas each Geometry instance is expected to relate to at least one Geometry serialisation.

4.
Geometry property consistency: Further SHACL shapes test for the consistency of values and cardinality of properties of a geo:Feature or geo:Geometry. For example, one SHACL shape tests the consistency of dimensionality properties of a geo:Geometry.
For the scope of the standard, GeoSPARQL 1.1 stops at the definition of the aforementioned SHACL shapes. However, the SWG has identified the need for various research communities to define checks of geometry relations and further consistency checks of Geometry contents and their relations to each other. Independently of the efforts of the SWG [32] introduced GeoSHACL for exactly this purpose and the SWG intends to found a community group for the collection of further useful validation shapes. Shapes will be created in a new Github Repository (https://github.com/opengeospatial/ogc-geosparql-shapes, accessed on 30 October 2021).
The example shows possible common mistakes in GeoSPARQL graphs with respect to the aspects mentioned previously. Each mistake cannot be detected using OWL reasoning approaches. While an empty geo:FeatureCollection and a non-connected feature instance are not necessarily wrong instances in a graph, we deem these as useless; hence they produce violations in a SHACL validation. Compared to this, using the wrong literal type (xsd:string) or a wrong literal content (geo:kmlLiteral for WKT content) is a clear error in applying the standard specification. The last issue, representing two serialisations connected to a geometry, is something noteworthy. Either the author of the given data is aware that geometries in different serialisations are not necessarily equivalent as precisions and CRS conversions might differ, or the author should consider creating different instances of geometry that can represent different aspects of geospatial data quality.

JSON-LD Contexts
GeoSPARQL 1.1 provides JSON-LD [33] contexts for the Simple Features and GeoSPARQL vocabularies allowing for the publication of simpler representations of GeoSPARQL data. Listing 3 provides example data as context-less JSON, which can still be interpreted as RDF through its linking to the GeoSPARQL 1.1 JSON-LD context resource. Context-less JSON is simpler than the more verbose JSON-LD for systems to produce and for developers to understand. Presentation of a JSON-LD context for GeoSPARQL is also aimed at assisting implementors of APIs that wish to present both Linked Data API and OGC API Features [26] interfaces: the context-less JSON will be far easier to incorporate into both required specifications' outputs. Tests of such systems are in development (see https://github.com/surroundaustralia/ogcldapi, accessed on 30 October 2021) for a combination of a Linked Data and OGC API framework and (http://floods.surroundaustralia.com, accessed on 30 October 2021) for an instance of its use. This system plans to move its RDF payloads to context-less JSON).

Requirements and Conformance Class Vocabulary
As the OGC mandates, all GeoSPARQL requirements and conformance classes are described using a URI. However, in the GeoSPARQL 1.1 specification, these unique identifiers are also modeled in RDF as part of the standard's profile specification. This allows the combination of said vocabularies with different other RDF resources.
To date, we can see the usefulness of this design in two cases.

Compliance Benchmarking
Good practices of standards of any kind are that they are first defined and then implemented in reference implementations. To test whether the reference implementation and all following implementations fulfil the criteria that the given standard sets, compliance benchmarking can be used. [13] created the first compliance benchmark for GeoSPARQL 1.0 using the HOBBIT benchmarking platform [34]. Once an execution of the GeoSPARQL compliance benchmark is finished, it may produce a benchmark result in RDF (https: //github.com/hobbit-project/platform/issues/531, accessed on 30 October 2021). Since the definition of the GeoSPARQL 1.1 requirements and conformance class vocabulary, these results can now be related to the actual definitions of GeoSPARQL requirements in RDF as shown in Figure 6.
The provision of benchmark results connected to requirements of a standard in RDF makes these results accessible as a machine-readable resource.

Partial Data Conformance Claims
In addition to systems claiming to implement GeoSPARQL functions, data may claim conformance to GeoSPARQL's ontology. Such claims may be tested both with RDF reasoners and also with the use of the SHACL validators that GeoSPARQL 1.1 provides (see Section 2.8). Since GeoSPARQL contains many parts, useful data may be created that is conformant to only part of GeoSPARQL, and the vocabulary of conformance classes allows for the indication of conformance of data to parts of GeoSPARQL, not just the whole.
Additionally, particular GeoSPARQL user communities might create more constrained SHACL validators to ensure that GeoSPARQL data conforms to a particular implementation pattern from a set of possible patterns. One example is the pattern whereby each geo:Feature is only associated with at most one geo:Geometry. In this case, a community could define additional conformance classes, like those in GeoSPARQL, and indicate data conformance to them too. Listing 12 shows a custom validator enforcing a restriction on GeoSPARQL 1.1 Features: that they must have one and only one GeoJSON geometry serialization. Figure 6. Requirements vocabulary applied to benchmark results of the GeoSPARQL compliance benchmark applied in the HOBBIT platform. Benchmark results can be mapped to RDF concepts representing requirements and conformance classes of the to-be-tested specification. <hasGeometry-hasSerialization-specialized> a sh:NodeShape ; sh:targetObjectsOf geo:hasGeometry ; sh:property [ a sh:PropertyShape ; sh:path geo:asGeoJSON ; sh:minCount 1 ; sh:maxCount 1 ; sh:message "Each node with an incoming geo:hasGeometry, or a specialization of it, must have one and only one outgoing relation of geo:asGeoJSON"@en ; ] ; .

Reference Implementations
This section describes reference implementations that implement the GeoSPARQL 1.1 specification either entirely or to a certain extent.

RDFLib DGGS
The rHEALPix DGGS Simple Feature functions Python package [35] is a library of functions built in mid-2021 to demonstrate that DGGS geometries within the rHealPix DGGS family [36], of which AusPIX is a member, could be used in the calculation of Simple Features topological relations. Using these functions and RDF and SPARQL capability from the RDFlib (RDFlib is a widely-used, open source, Python programming language, RDF manipulation toolkit: https://github.com/RDFLib/rdflib, accessed on 30 October 2021) Python package, the RDFlib GeoSPARQL Functions for DGGS [37] was then built that exposes DGGS geometry-based Simple Features calculation functions to RDFlib's SPARQL interpreter via SPARQL extension functions. Listing 13 shows Python application code demonstrating the use of RDFlib GeoSPARQL Functions for DGGS with some AusPIX data.
At the time of writing, all Simple Features topological relations functions were implemented except for sfCrosses, but this is expected to be implemented soon: this appears to be held up by programming issues only, not theoretical issues. While only the rHealPix DGGS family has currently been catered for, there appears to be no theoretical reason why other DGGSes, such as H3 (https://eng.uber.com/h3/, accessed on 30 October 2021) could not also be catered for.

GeoSPARQL-Jena
The GeoSPARQL implementation of the Apache Jena software library GeoSPARQL-Jena [38] provides, according to recent benchmarks [13], the only complete implementation of the GeoSPARQL 1.0 specification. In addition, GeoSPARQL-Jena has been extended in a prototypical use case to support raster data in [39]. This implementation featured prototypical raster support in GeoSPARQL-Jena and aimed at implementing a variety of functions defined in the Simple Features implementation standard. Work is underway by members of the SWG to implement DGGS topological relations functions in Jena in a mirror implementation to that in RDFlib described above. A combination of the DGGS algorithms from the RDFlib implementation and the raster handling from [39] will likely provide the first implementation of an RDF library and accompanying triple store to provide full support of the GeoSPARQL 1.1 specification within Jena.

SPARQLing Unicorn QGIS Plugin
Another implementation already making use of the GeoSPARQL 1.1 specification is the SPARQLing Unicorn QGIS Plugin [40]. This plugin is, to the authors' knowledge, the only client library to make geospatial vector data accessible as vector layers in the popular, open source, QGIS desktop GIS software (https://qgis.org/en/site/, accessed on 30 October 2021). The plugin aims to provide three main functions: (1) Querying Linked Data; (2) preparing geodata for publication as Linked Data resources; and (3) the enrichment of geospatial data from Linked Data resources.
To extend the query capabilities of the plugin for GeoSPARQL 1.1, support for KML and GeoJSON literals has been added, as has support for the processing and review of geo:FeatureCollection and geo:GeometryCollection instances (cf. Figure 7) in a given triplestore.
As an aspect of data processing and integration, the plugin implements the newly defined literal formats in its Linked Data conversion dialogue (cf. Figure 8). This dialogue allows converting geometry literals in Linked Data to other CRS supported by QGIS or to other geometry literal formats within the specifications of GeoSPARQL 1.1, as mentioned in Section 2.4.
With this implementation, the general public can discover, access, prepare and convert GeoSPARQL1.1-prepared data.

Examples of Usage of GeoSPARQL 1.1
In this section, we illustrate the use of the new parts of GeoSPARQL 1.1.

Profile Declaration
The Australian government is currently conducting a project defining a "National Data Exchange Standard" (NDES) for biodiversity data, validators which are used in an online Application Programming Interface (API) system (The API is online in test form at http://ndesgateway.surroundaustralia.com/, accessed on 30 October 2021. This location will likely remain live until July 2022, at which point it will move to a long-term departmental web location). The system obtains the multiple validators required for use from the many standards that the NDES profiles, including GeoSPARQL, via Linked Data link-following methods which require that standards are made available online in machinereadable form (RDF), with RDF predicates linking to any resources with the role validator that they define and also that standards are linked together forming a dependency-based profile hierarchy. With such information online, the NDES API is able to recurse through the profile hierarchy, retrieve all defined validation resources and then compound them for use automatically, saving system update and maintenance time if/when standards update validators.
Even in the current draft form, the NDES system polls the GeoSPARQL 1.1 publication for validators. Polling has proved useful to retrieve the latest versions of the validators as the SWG has continued to develop them.

Use of New Geometry Formats
The Australian government's "National Map" (https://nationalmap.gov.au/, accessed on 30 October 2021) is a web-based globe that can display spatial data in a number of formats but none that GeoSPARQL supported until this 1.1 version. Now, with GeoJSON geometry literal support, triplestores can be used to store and filter spatial data, which the globe can now easily consume and display. A triplestore/Globe implementation is now operational (https://globe.surroundaustralia.com/, accessed on 30 October 2021) that reads data from a triplestore, within which the geometries of features are stored as GeoJSON. With geometries in that format, only very simple translations of a few RDF properties to JSON for geo:Feature instances are necessary for the Globe can display feature metadata, such as labels, as well as the geometries. Figure 9 shows an instance of the Globe listing test polygons for the Australian state of Queensland as well as three features it contains.
With the Globe's triplestore also containing Simple Feature relations, it is also now possible to show feature-to-feature links within the globe instance, as shown in Figure 9. These links are actionable, and the globe can refocus on features navigated to.

OGC API Features Backend
Traditional spatial data infrastructures are transitioning from being providers of spatial data via specified web services only to becoming spatial knowledge infrastructures [41,42]. These spatial knowledge infrastructures will provide spatial data in two ways, as illustrated in Figure 10. The first way is the provision of spatial data using geospatial web services. The second way is the provision of spatial data as Linked Data, the latter being enabled by ontologies such as GeoSPARQL. However, spatial web services are currently being reworked in the OGC API Features specification, which, as elaborated previously in Section 2.2.4, allows for Linked Data backends.
A live example of data delivered according to Linked Data principles, the OGC API Features specification, and also a SPARQL Protocol (https://www.w3.org/TR/sparql1 1-protocol/, accessed on 30 October 2021) service is Geoscience Australia's Floods API (http://floods.surroundaustralia.com/, accessed on 30 October 2021), a screenshot of which is shown in Figure 11. Through an application of the CQL to SPARQL mappings that the SWG is creating (see Section 2.7), the Floods API will also be able to respond to CQL queries.   This API supplies information according to the required OGC API Features URL structures with very simple queries to a GeoSPARQL 1.1. backend. The simplicity is possible due to GeoSPARQL 1.1's modelling which allows for geo:FeatureCollection, geo:Feature and geo:Geometry instances, the first of which as introduced in GeoSPARQL 1.1 to specifically cater for APIs like the OGC API Features.
APIs such as this Floods API act similarly to previous generation spatial data APIs, such as the well-known Web Feature Service (WFS) (https://www.ogc.org/standards/wfs, accessed on 30 October 2021) from which OGC API Features derives but are also able to present much simpler human User Interfaces (web page), SPARQL endpoints and more data formats.

DGGS Application Example
DGGSes represent both vector and raster spatial data as collections of cell IDs. Since GeoSPARQL 1.1, the storage system for DGGS data may be a triplestore.
Data for the API in Figure 11 are initially recorded as rasters, and data for the Australian Statistical Geographies Standard (ASGS) (https://www.abs.gov.au/websitedbs/D3310114 .nsf/home/Australian+Statistical+Geography+Standard+(ASGS), accessed on 30 October 2021) dataset is recorded in vector form. Both datasets are able to be stored using the Apache Jena TDB triplestore (https://jena.apache.org/documentation/tdb/index.html, accessed on 30 October 2021) as GeosPARQL 1.1 data with geometries in the AusPIX DGGS format.
The Floods & ASGS datasets are actually stored in the Loc-I for Disaster Recovery project's (https://ldr.surroundaustralia.com/, accessed on 30 October 2021) Data Platform with several other rasters and vector datasets, all of which can be cross-queried and presented as either features with geometries in vector form, features with geometries in raster form or as cells within regular grids with cell values of data or the IDs of their corresponding features.
The Loc-I platform does require up-front geometry data conversion to DGGS and feature information to GeoSPARQL RDF but then use of the spatial and non-spatial data is extremely simple-SPARQL queries-and all elements of the data can be used in one system. Given the simple nature of most of version 1.1's additions and the fact that SWG members have been able to create at least one implementation of almost all new ontology elements and functions, it is expected that the implementors' wider review will not result in major changes.

Work beyond GeoSPARQL 1.1
The original intention of the GeoSPARQL SWG, when formed in 2019, was to publish a 1.1 version of GeoSPARQL, and then possibly a 1.2 and a 2.0, as described in Section 1. While the scope of GeoSPARQL 1.1 has been in keeping with the original estimates for that version and there are still known un-tackled change requests that the SWG has tagged for a possible 1.2 version (see https://github.com/opengeospatial/ogc-geosparql/milestone/2, accessed on 30 October 2021), the SWG has entertained many thoughts about a more comprehensive tackling of spatial Semantic Web concerns that might require a different direction altogether, for example, non-earth geometries, comprehensive handling of rasters (see Issue 18) or a whole new ontological handling of Coordinate Reference Systems.
If there is a desire for much non-geo work, and if it extends beyond the SPARQL query language, it could be that neither the 'Geo-' or the '-SPARQL' parts of GeoSPARQL will sensibly apply to it, thus something other than a GeoSPARQL 1.2 or even a 2.0 may be required. The SWG will consult on this matter after GeoSPARQL 1.1's release.
The following subsections provide some more detail on specific GeoSPARQL 1.1+ potential directions.

Inclusion of Further Spatial Data Types
For now, GeoSPARQL 1.1 is a standard to describe 2D and 3D vector data and a single grid reference system. However, members of the SWG have already hinted at the need to represent mobile (e.g., 3D Meshes) and further immobile spatial objects and the inclusion of raster data query capabilities.

Geometry Roles
As noted in Section 2.2.1, new ontology elements were proposed for GeoSPARQL 1.1 to represent the roles of geometries with respect to features. SWG members saw new properties specialising geo:hasGeometry, such as geo:hasCentroid and geo:hasBoundingBox, as indicating geometries with particular roles and that GeoSPARQL could perhaps allow for an extensible way to indicate role by creating a vocabulary of them, which could be added to, rather than describing them in a number of properties that must remain fixed after a GeoSPARQL version's publication.
Timing and SWG participant effort did not allow for roles to be added in GeoSPARQL 1.1, and their addition may be sensible for a GeoSPARQL 1.2.

Interoperability with Buildings Data
There is a growing appetite for Semantic Web data within the building information modelling (BIM) communities, evidenced by the existence of working groups like the W3C Linked Building Data Community Group (https://www.w3.org/community/lbd/, accessed on 30 October 2021), and the existence of projects such as BRICK [43], IFC/Ontology mappings [44] and the "Building Topology Ontology" (https://w3id.org/bot, accessed on 30 October 2021). These all naturally have spatial components and some already use GeoSPARQL 1.0 (BRICK). It is also clear, evidenced by the fact that members of the Linked Building Data Community Group worked with members of the SWG to outline buildingrelated use cases and some shortcomings of GeoSPARQL 1.0 for their purposes in a 'White Paper' in preparation for the formation of the SWG [17], that GeoSPARQL has long been considered important to that community. Unfortunately, not all of this community's needs were met in GeoSPARQL 1.1, so more could be done to support it, for example, the inclusion of other, specialised, topological relations for voids and non-void features; geometry roles (as per the section above); non-coordinate geometry characterisations, for example, cylinders; and sub-surface geometry handling.

Formalisation of Spatial Reference Systems
While it is currently possible to use spatial reference system definitions in literal descriptions, spatial reference system definitions have not been completely formalised using an ontology model as of today. This can be a problem in many ways. For example, a triplestore might store a geometry encoded in a coordinate reference system not registered in a well-known repository such as the EPSG Geodetic Parameter Dataset. In these cases, the hosting triplestore might provide custom support for this coordinate reference system, but this support ends once the geospatial data is queried in a federated query scenario. A future version of GeoSPARQL, or a successor to the standard, should be able to describe the contents of spatial reference systems so that the user can make informed decisions about the appropriateness of the spatial reference system assigned to a given geometry that federated queries may resolve even previously not known coordinate reference system definitions.

Linked Data Fragments Support
GeoSPARQL data collections can be very large, either regarding the number of features or geometries stored, the size of their geometry literals, or both. APIs wishing to deliver large numbers of GeoSPARQL Feature or geometry instances would benefit from the ability to deliver them in a streaming manner, and for this, the so-called "Linked Data Fragments" (LDF) [45] approach has been considered. It appears that the LDF approach if implemented to stream data from an API, would allow for client-side GeoSPARQL topological querying. An example scenario could be that an API user wishes to know if an API contains a feature that overlaps a locally held feature. If the API were to stream features from a geo:FeatureCollection or as a result of a filtering query, the user could incrementally test for an overlap and cease the streaming session when a match is found.

Conclusions
A staged schedule of updates to this essential Semantic Web spatial standard has been initiated with simple and strictly backward-compatible changes now in GeoSPARQL 1.1. Reference implementations for all of GeoSPARQL 1.1's new features have been made. Examples of all elements used can be indicated online. Features discussed for GeoSPARQL 1.2 include the formalisation of coordinate reference systems in RDF, the depiction of accuracies and level of detail, and the addition of further-possibly also binary-literal types. Work on GeoSPARQL 1.2 will start at the earliest in mid-2022. GeoSPARQL 2.0, as yet unspecified, is likely to introduce more substantial changes to the standard. Changes proposed for GeoSPARQL 2.0 include broadening the scope of GeoSPARQL to include 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 information [46] and coverage data [39]. More requirements might also be introduced once feedback has been received from the GeoSPARQL 1.