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

Round 1

Reviewer 1 Report

This paper presents GeoSPARQL 1.1, an extension of GeoSPARQL 1.0, that includes new geometry representations and serialisations, alignments to other ontologies, handling of new spatial referencing systems, and new artefact presentation.

The paper is an extended version of the paper published in GeoLD Workshop at ESWC 2021.

GeoSPARQL is largely used in the community and this paper contributes for understanding its improvements. Overall, the paper is well written and structured, with several examples motivating the changes in SPARQL 1.1. The paper also discusses potential future improvements.

Minor comments:

• The introduction could be improved in order to make explicit what changes with respect to [11].
• Make explicit what are them classes and properties in Figure 1 (version of SPARQL 1.0 and SPARQL 1.1).
• It could be interesting to describe how the user feedbacks have been gathered and how the decisions to include the new features have been taken.
• The alignments to other ontologies have not been discussed (but they were mentionned in the introduction)
• Please, correct the many typos:

- for [spatial] information => for geospatial information
- a SPARQL[6,7] => a SPARQL [6,7] check all references
- "including classes new properties" 
- The Figures Figure 4 and its associated Listing, Listing 3,
- ed.[13]
- GeoSPARQL 1.1’s nrew

Author Response

We appreciate your review comments and have addressed all the 4 minor points you raised in the following manner:

> The introduction could be improved in order to make explicit what changes with respect to [11]

We have improved the introduction accordingly and noted, for instance, the remove of the geo:SpatialMeasure class.

> Make explicit what are them classes and properties in Figure 1 (version of SPARQL 1.0 and SPARQL 1.1).

We improved the graphic to show the distinctions very clearly.

> It could be interesting to describe how the user feedbacks have been gathered and how the decisions to include the new features have been taken.

User feedback has been gathered on conference talks (e.g. GeoLD), in the GitHub repository of the standard, in OGC Technical Committee meetings, especially in the GeoSemantics Special Interest Group and similar groups such as the W3C Spatial Data On The Web Working Group and the ISO's Technical Committee 211.

> The alignments to other ontologies have not been discussed (but they were mentionned in the introduction)

Thank you for this comment, we have added a section on alignments. Since first drafting this paper, a lot of alignments have been completed for GeoSPARQL 11 (see https://opengeospatial.github.io/ogc-geosparql/geosparql11/spec.html#_annex_e_alignments_informative)

Reviewer 2 Report

This paper presents the new GeoSPARQL 1.1 standard. The paper is very interesting and worth to be published in the present status.

Author Response

We thank the reviewer for this short but very positive review. There are no points to address.

Reviewer 3 Report

This is an interesting non-research paper that describes the main characteristics of the new upcoming version of GeoSPARQL (1.1), which is the result of the work performed during several years by a working group at OGC. As discussed in the comments for editors (not visible to authors but replicated here), I am not sure if this type of paper is allowed for this journal. I leave that decision to the editors.

Before moving further into specific characteristics that would need some improvement, in my opinion, I would like the authors to confirm that they are the ones entitled to submit this paper as representatives of the working group. There should be a statement or discussion with the editors to confirm that there are no other relevant authors of this new version of the standard. Similarly, it would be relevant to check whether OGC allows for the publication of this paper as well, according to their policies. This is something to be stated by the authors and checked by the editors before moving forward.

Another point before moving further is that I have a very clear feeling that given the fact that GeoSPARQL 1.1 is not yet recommended as a standard and there may be minor changes, it may be an error to publish a paper on its current ongoing version without waiting for the final one to be accepted. Any minor change would partially invalidate this paper. For instance, there are comments in the paper as the one in page 14, which says "is likely to be included". Same happens with part of the discussion in section 6 on future work.

Now the more detailed comments, which I hope that can help in improving the paper. 

• The introduction and motivation sections may be clearly merged, since they form part of the same storyline.
• In Listing 1 there is an error in the RDF inside the hasArea part (a property qudt: that is missing the qName).
• In section 3.2.2, single property should read single subproperty. I also wonder why the authors mention "other similar properties" but do not say which ones they are.
• In section 3.2.3 I would expect a complete enumeration and description of the whole set of topological relations that are identified in GeoSPARQL 1.1.
• In section 3.2.4, it is not clear to me what the authors mean with the discussion on virtual collections generated from SPARQL queries. I have not found myself doing this when using GeoSPARQL queries. 
• I do not think that it is right to use JSON-LD in listing 3, when all the other examples are available in Turtle. I would understand it much later, as an example of the JSON-LD serialisation. Besides this, the context is published in raw.githubusercontent, which does not seem right as this is not a permanent URI. I think that this vocabulary should be published properly following good practices in vocabulary publishing, with appropriate content negotiation, in the corresponding URI for the vocabulary, which should correspond to its namespace.
• In section 3.2.4, it is not clear how all the new functions are going to be implemented in different types of systems. Indeed, this was a problem with the previous version of GeoSPARQL (1.0), where all the identified functions were not fully supported in all triple stores. I have "suffered" from it in the past with several triple stores. 
• In section 3.3.1, it would be nice to have an example of KML as well, even if this is not new in this version of GeoSPARQL.
• In listing 7 it is not properly explained why the datatype is auspixLiteral instead of dggsLiteral. Most probably is my lack of knowledge of this format, which is the first time that I have seen. Similarly, all the discussion on DGGS is too much detailed, IMO, compared to other elements in the paper, and probably such discussion should be much more reduced, especially when it comes to justifying why it can be used, or moved to an annex. Particularly, the last paragraph of section 3.3.3 is very unclear to me.
• In section 3.4 you comment that it is expected that triple stores will implement geometry conversions. Again, my experience in the past (e.g., with Virtuoso) is that using different CRSs was a nightmare, since some versions provided support to them and some others did not. 
• In section 3.6 I would have expected this topic to be dealt in more detail in a research-oriented paper, with more clear correspondances among query languages, a deeper discussion on query expressivity, etc. 
• Section 3.9.2 comments on the usage of RDF reasoners. What for? Why?
• I think that in general that section would benefit from clear examples of how SHACL expressions would be extended by domain-specific communities. 
• The reference to W3C SSN may probably be changed to the JWS paper on SSN ontology.
• In general, the descriptions on tools and use cases are very narrow, and very focused on the cases of Australia. This is not wrong at all, but there are many other cases of geospatial linked data having been published in GeoSPARQL 1.0 which may have been discussed, with their pros and cons.

 

Other comments that are also relevant are the following:

• Figures in general are very difficult to see. They are too small to be read properly when printing in A4.
• Some code snippets are also very difficult to read when printed in black and white. I would recommend checking that as well.
• Typo in Table 1, in the third column.
• Error in Listing 10, in the last sentence, inside the print() function?
• Figure 8 is too large, especially in comparison with other figures taht are too small.
• "where met" --> "were met"

Author Response

We thank this reviewer for his/her most detail review.

We have made changes to the paper to accommodate essentially all of the reviewer's points, other than adding in other examples not from Australia. As we explain in the final rebuttal below: the since set of examples was chosen to highlight how GeoSPARQL can be used to describe the same real-world feature and so we've re-used the same feature over and over again. It just happens to be in Australia.

 

> I would like the authors to confirm that they are the ones entitled to submit this paper as representatives of the working group. There should be a statement or discussion with the editors to confirm that there are no other relevant authors of this new version of the standard. Similarly, it would be relevant to check whether OGC allows for the publication of this paper as well, according to their policies. This is something to be stated by the authors and checked by the editors before moving forward.

We gained approval from all working group members to publish the paper in this form during Working Group meetings and had approval for the first version published at the GeoLD workshop as well.
Internally, everyone in the working group was invited to contribute to this work. In the end, the paper was written just by two authors and reviewed by the working group members before submission. 

We have made the approval to publish demonstrable by polling WG members in a publicly visible GitHub issue, please see https://github.com/opengeospatial/ogc-geosparql/issues/248 and note the unanimous approval to publish.

We have checked with OGC leadership (Scott Simmons, standards lead) regarding publications like this and he has confirmed that Working Group approval is the only approval necessary.

> Another point before moving further is that I have a very clear feeling that given the fact that GeoSPARQL 1.1 is not yet recommended as a standard and there may be minor changes, it may be an error to publish a paper on its current ongoing version without waiting for the final one to be accepted

In the specification group we have a very clear scope of changes which will be published in GeoSPARQL 1.1. This scope will not change anymore before going into public review.
Yes, it might be true, that some minor details of the standard might be changed until the official release, however, we do not believe that essential facts will be removed from the publication as it is presented now.

This paper is also part of the standard's review and it is sensible to publish it now while there is still a possibility for readers of this paper to contribute to GeoSPARQL 1.1's development via the public review process.

> The introduction and motivation sections may be clearly merged, since they form part of the same storyline.

Thank you for your comment. We have merged the two sections.

> In Listing 1 there is an error in the RDF inside the hasArea part (a property qudt: that is missing the qName).

Thank you for spotting this mistake. It is now corrected.

> In section 3.2.2, single property should read single subproperty. I also wonder why the authors mention "other similar properties" but do not say which ones they are.

Thank you for spotting this oversight on our part. We have added references to the properties, e.g. geo:hasBoundingBox.

> In section 3.2.3 I would expect a complete enumeration and description of the whole set of topological relations that are identified in GeoSPARQL 1.1.

Since no new topological relations have been defined in GeoSPARQL 1.1, we thought not to include the table of already existing relations. However, we added the table into the annex of this paper now for better comprehension.

> In section 3.2.4, it is not clear to me what the authors mean with the discussion on virtual collections generated from SPARQL queries. I have not found myself doing this when using GeoSPARQL queries. 

Before GeoSPARQL 1.1, if users did not group features in Linked Data by means of a declared object instance, e.g. skos:Collection, an intermediate web service wanting to expose feature collections from a SPARQL endpoint would need to define this collection by means of a customized SPARQL query in which one query variable would represent a feature id and one or more query variables would represent the geometry representations.
Now features can be grouped in the RDF graph using the SpatialObjectCollection classes, which allows one to express groups of features as intended by data providers, instead of only exposing typed features. 

> I do not think that it is right to use JSON-LD in listing 3, when all the other examples are available in Turtle. I would understand it much later, as an example of the JSON-LD serialisation. 

Listing 3 was created for the purpose to show the usage of a JSON-LD context, so it would not make sense in our view to use a different serialization. You are correct that the URL of the JSON-LD context might change after releasing the GeoSPARQL 1.1 standard and that it will then be published by the OGC Naming Authority, but the Github URI used in this example will also remain valid, as it points to the official GeoSPARQL repository maintained by members of the OGC.

> In section 3.2.4, it is not clear how all the new functions are going to be implemented in different types of systems. Indeed, this was a problem with the previous version of GeoSPARQL (1.0)

You are correct, GeoSPARQL support suffered from a lack of implementers as is evident in a variety of GeoSPARQL benchmarks, some of which we even referenced in the paper.

As for the specific things mentioned in 3.2.4:

* the collection classes are just new OWL classes. They are already supported by any SPARQL engine today.
* the functions geometryN and numGeometries are not defined in GeoSPARQL 1.0, however, even in GeoSPARQL 1.0 it was already possible to work with define WKT Literals with GeometryCollections, so the functions proposed in GeoSPARQL 1.1 are mitigating an already existing accessibility problem to these literal contents, if implemented correctly. If they are not implemented on a larger scale, the situation does not change compared to GeoSPARQL 1.0, but as authors of the standard, we have limited influence on implementers and can only inform them and include them in the standardization process - which we do. We have also provided many more notes and guidance for function implementers to attain consistent implementation results, for example, the whole of Annex D in the Specification (https://opengeospatial.github.io/ogc-geosparql/geosparql11/spec.html#_annex_b_functions_summary_normative) that normatively lists functions, their inputs and outputs, and far more detail than in GoeSPARQL 1.0

> In section 3.3.1, it would be nice to have an example of KML as well, even if this is not new in this version of GeoSPARQL.

We have added a KML example to the paper (Code Listing 6). KML is indeed new in GeoSPARQL 1.1.

> In listing 7 it is not properly explained why the datatype is auspixLiteral instead of dggsLiteral. Most probably is my lack of knowledge of this format, which is the first time that I have seen. 

An additional clarification sentence has now been added to the Listing's description: "A DGGS geometry serialization example in RDF (Turtle) of the area of the feature in \Cref{fig:geom-01}. The generic predicate for indicating a DGGS serialization - \texttt{geo:asDGGS} - is used and the specific DGGS - \textit{AusPIX} - is indicated via use of a custom datatype \texttt{ex:auspixLiteral}"

> Similarly, all the discussion on DGGS is too much detailed, IMO, compared to other elements in the paper, and probably such discussion should be much more reduced, especially when it comes to justifying why it can be used, or moved to an annex. Particularly, the last paragraph of section 3.3.3 is very unclear to me.

Indeed the DGGS discussion is detailed: as the paper makes clear: adding KML & GeoJSON geometry literal formats is uncontroversial but DGGS literal addition was controversial. This paper communicates that controversy and indicates how resolution was reached (a test for a literal to perform as a geomtery through DGGS functions). It is critical to relate, in the paragraph identified, that software has been demonstrated that can perform SF topology calculations using DGGS literals. 

We have re-worded the particular paragraph though to remove the levels DGGS jargon from the paper.

> In section 3.4 you comment that it is expected that triple stores will implement geometry conversions. Again, my experience in the past (e.g., with Virtuoso) is that using different CRSs was a nightmare, since some versions provided support to them and some others did not. 

Well, we expect triple store implementers to follow the standard and we are in contact with triple store implementers. Whether these implementers will implement the whole specification is depending on many factors, not the least of which being money. What we can only provide is as much documentation and examples (such as this paper) why it makes sense to implement the new standard. Nobody writing a standard can guarantee that it will be well adapted. However, there will be a variety of reference implementations, some of which we discuss in the paper.

Another experience is that implementers also lacked a standardized test for GeoSPARQL compliance and that because of this, implementation of the standard was not as easy as it could be. A candidate for this test has been available for a year and it is now being be updated for GeoSPARQL 1.1. With such a test, we expect implementers to be more willing to approach an implementation.

> In section 3.6 I would have expected this topic to be dealt in more detail in a research-oriented paper, with more clear correspondances among query languages, a deeper discussion on query expressivity, etc. 

We will extend this section to discuss missing query capabilities with respect to relational GIS databases, however geometry format conversion functions themselves are not new in GeoSPARQL - only those for the particular new serializations. We can't back-justify the existence of conversion functions in the original GeoSPARQL!

> Section 3.9.2 comments on the usage of RDF reasoners. What for? Why?

GeoSPARQL provides function definitions and also an OWL ontology. Such ontologies must be valid according to reasoners and indeed GeoSPARQL is. Data created according to GeoSPARQL can be tested for validity using reasoners, for example someone may create an object that is both an instance of Feature and an instance of a subclass of Geometry. Basic RDFS reasoning will indicate this is invalid: a Feature cannot also be a Geometry. Without reasoning, this may be missed. This was true in GeoSPARQL 1.0

Additionally, in 1.1, we have provided lots of SHACL shapes for graph validation that do not require reasoning. Having reasoning and SHACL validators avalable is powerful.

> In general, the descriptions on tools and use cases are very narrow, and very focused on the cases of Australia. This is not wrong at all, but there are many other cases of geospatial linked data having been published in GeoSPARQL 1.0 which may have been discussed, with their pros and cons.

We are not able to describe all the tools and examples that use GeoSPARQL 1.1 or that are known to the standards' editors. OGC community groups will have the task of providing lists of tools and fulsome examples after standar publication.

The focus on Australia results simple from the choice to carry through one example to multiple other figures and code listings. The longer examples section in the Standard itself contains examples from elsewhere, for example:

ex:Seleucia_Artemita
    a geo:Feature ;
    skos:prefLabel "The route from Seleucia to Artemita"@en ;
    geo:hasLength [
      qudt:unit ex:Schoenus ;
      qudt:value "15"^^xsd:integer ;
    ]
.

We chose to use a single set of repeated examples here to show multiple representations of the same real-world objects highlighting different GeoSPARQL data forms, rather than introducing new real-world features that might get in the way of a reader comparing data forms.

Round 2

Reviewer 3 Report

I have read the comments provided by the authors. Thanks for providing support to some of my previous comments and questions, and especially on the issue related to whether the group gave you permission for publishing this paper (having worked on the W3C SSN ontology, for instance, and having published the original paper on it I know that it is important and that is why I was insisting).

I think that the paper is now mostly ready for publishing, except for some minor aspects:

• I insist in changing listing 3 to Turtle format and then replicating if you wish the same example, or any other, in the section where you talk about the JSON-LD serialisation (section 2.9). It does not make sense to have it in page 9, IMO.
• I cannot understand why you present in section 3.2 GeoSPARQL-Jena, when I understand that it does not provide support to GeoSPARQL1.1 yet. Is my understanding correct? I have checked several times and I cannot see why you include it with the others. 

 

Typos:

• Line 24. Format --> Framework
• Lines 204 and 205 should be joined in one single line, as with the previous ones. 
• Wrong reference in line 236
• Line 239: Figures Figure --> Figure
• Page 11. mapping mapping --> mapping.
• In the end of section 2.8, you comment on representing two serialisations connected to a geometry, but in the esample in code listing 11 I see three instead of two, if I am not wrong. 
• Listing 12 caption. "An custom" --> "A custom"
• I would suggest reducing the size of figure 8