Revise RDFS entailment extension clauses for WKT and GML

[FransKnibbe]

During the teleconference of 2020-12-02 I was tasked with adding an issue about the RDFS entailment extension clauses for WKT and GML. This was something that came up while discussing the Pull Request for GeoJSON literals. But I am afraid I can't recall exactly what to about those clauses.

Is it that the required RDFS class hierarchies are already made and published for WKT and GML? I did find http://schemas.opengis.net/sf/1.0/simple_features_geometries.rdf and http://schemas.opengis.net/gml/3.2.1/gml_32_geometries.rdf. And URIs using the patterns described in clauses 10.3 and 10.4 of the GeoSPARQL spec, like http://www.opengis.net/ont/gml#Arc or http://www.opengis.net/ont/sf#Polygon do resolve. So all there is to do is to replace the current requirements with the requirement to use the GML and simple features ontologies that are now available?

By the way, the SF and GML ontologies really could do with some extra metadata (like a title)!

[situx]

Hi Frans, it was my understanding that the RDFS entailment section should be removed from the standard, unless I misunderstood something. In case this information is wrong and we want to recommend class hierarchies for specific literal types in this section we should consider adding the GeoJSON class hierarchy for the GeoJSON literal. https://geojson.org/geojson-ld/

[FransKnibbe]

Thanks Timo. I guess I became confused because when reading the bits about RDFS entailment extension I thought there is something to be said for having RDFS entailment extension in general. Not for all the different geometry serialization literals, but for geometry subtypes within the GeoSPARQL ontology itself. Yes, I realize they don't exist yet, but I think it would be cool to have them. This probably warrants another change request.

But these two issues can be viewed separately. I can make a change request for adding a geometry class hierarchy to GeoSPARQL and another one for removing the RDFS entailment extension requirements. For the latter, it would be good to explain why they should be removed. Do you happen to recall what was said about that?

[FransKnibbe]

I have just mentioned the idea of having a geometry class hierarchy in the GeoSPARQL ontology in a comment on issue 42.

[situx]

Thanks Timo. I guess I became confused because when reading the bits about RDFS entailment extension I thought there is something to be said for having RDFS entailment extension in general. Not for all the different geometry serialization literals, but for geometry subtypes within the GeoSPARQL ontology itself. Yes, I realize they don't exist yet, but I think it would be cool to have them. This probably warrants another change request.

But these two issues can be viewed separately. I can make a change request for adding a geometry class hierarchy to GeoSPARQL and another one for removing the RDFS entailment extension requirements. For the latter, it would be good to explain why they should be removed. Do you happen to recall what was said about that?

As I recall there was no support of adding arbitrary geometry class hierarchies to the standard as that would be somewhat redundant and the Geometry type might be inferred from the Geometry literal. However, I think adding a single geometry class hierarchy would be a good idea.

[FransKnibbe]

An attempt to clarify which changes are requested, and why:

This concerns section 10 of the GeoSPARQL specification, which is about the optional RDFS Entailment Extension. This extension is considered a module of GeoSPARQL. Implementers can choose whether or not to support it. Essentially section 10 consists of three requirements. First there is a general requirement:

Req 25 Basic graph pattern matching shall use the semantics defined by the RDFS Entailment Regime

One could argue that this requirement is superfluous because SPARQL engines either support RDFS entailment or not, it does not have to be a concern of GeoSPARQL.

The other two requirements are for WKT and GML: Req 26 Implementations shall support graph patterns involving terms from an RDFS/OWL class hierarchy of geometry types consistent with the one in the specified version of Simple Features

Req 27 Implementations shall support graph patterns involving terms from an RDFS/OWL class hierarchy of geometry types consistent with the GML schema that implements GM_Object using the specified version of GML

The required class hierarchies are available on the web (see the first message in this thread). I wonder now how to support these requirements. What kind of graph pattern could make use of a class hierarchy? For example, what would a GeoSPARQL query look like that requests all surfaces from a graph and returns geometries that are designated as polygons?

When considering removal of a part of the specification, we must ask ourselves if such a step could break any existing implementations. I don't think it will: if implements do support the module they can continue to do so.

[mperry455]

Req 25 Basic graph pattern matching shall use the semantics defined by the RDFS Entailment Regime

One could argue that this requirement is superfluous because SPARQL engines either support RDFS entailment or not, it does not have to be a concern of GeoSPARQL.

The idea is that if your triplestore supports RDFS entailment then it supports the RDFS entailment extension of GeoSPARQL.

Req 26 Implementations shall support graph patterns involving terms from an RDFS/OWL class hierarchy of geometry types consistent with the one in the specified version of Simple Features

Req 27 Implementations shall support graph patterns involving terms from an RDFS/OWL class hierarchy of geometry types consistent with the GML schema that implements GM_Object using the specified version of GML

The required class hierarchies are available on the web (see the first message in this thread). I wonder now how to support these requirements.

The requirements really just say that you should be able to use URIs from this vocabulary in SPARQL queries.

As you mentioned, it is obvious that any triplestore that supports RDFS entailment satisfies Req. 25, and it is obvious that any triplestore will support the use of GeoSPARQL IRIs in triple patterns. This is just plain RDF, RDFS and SPARQL. However, OGC specifications must define a set of requirements that implementations must be compliant with. Requiring triplestores to support use of terms from our ontology, while trivial, is how we define the ontology as a set of requirements.

[FransKnibbe]

@mperry455, thank you for explaining! I guess the main question now is whether the historic reasons to include section 10 with requirements 25, 26 and 27 still exist today. If so, then it stands to reason to add an extra requirement for the GeoJSON literal. If not, then we have a good reason for removing section 10.

In general I am curious about the requirements OGC has for its specifications. I asked about that in issue 41. If there is a set of requirements for OGC specifications, it would be good for us all to be aware of that.