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)