Defining an XML / RDF datatype for GeoJSON about geodcat-ap

[andrea-perego]

Please give your feedback on the following proposal:

PROPOSED RESOLUTION: Adopt in GeoDCAT-AP 2 the GeoJSON datatype defined in the current draft of the new version of GeoSPARQL, and deprecate the use of the GeoJSON media type URI for GeoJSON literals supported so far in GeoDCAT-AP.

[andrea-perego]

Thanks for raising this issue, @AntoRot .

For the GeoJSON datatype we could follow the same approach used for deprecated classes and properties, i.e., although they are replaced by other ones, they will still be supported for backward compatibility. Such support could be phased out in future versions of GeoDCAT-AP, if this can be done safely.

Moreover, we can take an action, and report this revision to the CKAN community.

Would this be enough to address this issue?

[andrea-perego]

I have create a draft PR along these lines: #58

The main changes concern §B.6.10 and §B.6.10.1.

In particular:

The following text has been added to the NOTE at the beginning of §B.6.10:

• For GeoJSON [RFC7946] literals, the GeoJSON IANA media type URI used until [GeoDCAT-AP-20160802] is replaced by datatype gsp:geoJSONLiteral, defined in the current draft of the new version of GeoSPARQL [GeoSPARQL11].

The following text has been added at the end of §B.6.10.1, right before Example 35:

As geometries may be provided in multiple encodings, the corresponding datatype SHOULD be always specified to ensure that the geometry literal is correctly interpreted.

For GML and WKT, the [GeoSPARQL] datatypes gsp:gmlLiteral and gsp:wktLiteral, respectively, MUST be used.

For GeoJSON [RFC7946], datatype gsp:geoJSONLiteral, defined in the current draft of the new version of GeoSPARQL [GeoSPARQL11], SHOULD be used.

For the other geometry encodings, no datatype is currently available. Therefore, their interoperability is not ensured.

NOTE
Until [GeoDCAT-AP-20160802], the recommended solution to specify the datatype for GeoJSON literals was to use the following URI from the IANA Media Types registry [IANA-MEDIA-TYPES]:

https://www.iana.org/assignments/media-types/application/vnd.geo+json

This solution, intentionally meant to be provisional (see Issue #4), is deprecated starting from this version of GeoDCAT-AP in favour of gsp:geoJSONLiteral. It will still be supported for backward compatibility with legacy metadata and applications, but it may be phased out in future versions of GeoDCAT-AP.

Would this work?

[akuckartz]

I am not sure if that is relevant here, but there is some hope that JSON-LD 1.1 can be a basis for GeoJSON-LD.

[bertvannuffelen]

Also note there are now 2 versions of geoJSON. Can these serializations be distinguished?

[dr-shorthair]

Also see https://w3c.github.io/json-ld-syntax/#the-rdf-json-datatype

[andrea-perego]

@akuckartz said:

I am not sure if that is relevant here, but there is some hope that JSON-LD 1.1 can be a basis for GeoJSON-LD.

Thanks for the heads-up . This could be an additional geometry encoding to be supported.

However, I think it should be kept separate from a "plain" GeoJSON literal encoding, for which the GeoDCAT-AP WG had some use cases in mind.

[andrea-perego]

@bertvannuffelen said:

Also note there are now 2 versions of geoJSON. Can these serializations be distinguished?

This is just my personal view, but I think the reference one should be the latest - i.e., the one standardised in RFC 7946 (https://tools.ietf.org/html/rfc7946) - which supersedes the original one, and it is already being supported in widely used tools (as PostGIS).

Said that, there's a possible issue in the IETF version of GeoJSON, as pointed out in #6, but IMO it can be sorted out.

[andrea-perego]

@dr-shorthair said:

Also see https://w3c.github.io/json-ld-syntax/#the-rdf-json-datatype

Thanks for the pointer. This would indeed fit better than the GeoJSON media type URI. However, I wonder whether there may be some possible issues on using the rdf:JSON datatype for GeoJSON literals, since there exist other JSON-based geometry encodings - as the ones used in ArcGIS (https://developers.arcgis.com/documentation/common-data-types/geometry-objects.htm).

[andrea-perego]

Noting there's work under way in the new version of GeoSPARQL - see:

• opengeospatial/ogc-geosparql#1
• opengeospatial/ogc-geosparql#48

The current proposal defines the GeoJSON literal datatype as follows:

@prefix : <http://www.opengis.net/ont/geosparql#> .

:geoJSONLiteral a rdfs:Datatype ;
	dc:contributor "Timo Homburg" ;
	dc:creator "OGC GeoSPARQL 2.0 Standard Working Group" ;
	dc:date "2020-10-30"^^xsd:date ;
	dc:description """
      A GeoJSON serialization of a geometry object.
    """@en ;
	rdfs:comment """
      A GeoJSON serialization of a geometry object.
    """@en ;
	rdfs:seeAlso <https://tools.ietf.org/html/rfc7946> .
	rdfs:isDefinedBy <http://www.opengis.net/ont/geosparql> , <http://www.opengis.net/spec/geosparql/1.1> ;
	rdfs:label "GeoJSON Literal"@en ;
	skos:definition """
      A GeoJSON serialization of a geometry object.
    """@en ;
	skos:prefLabel "GeoJSON Literal"@en .

See also the relevant section in the GeoSPARQL 1.1 draft (pull request approved, but not yet merged).

[andrea-perego]

Noting there's work under way in the new version of GeoSPARQL - see:

• opengeospatial/ogc-geosparql#1
• opengeospatial/ogc-geosparql#48

PR opengeospatial/ogc-geosparql#48 has been eventually merged.

Should we already adopt this solution, or wait until the new version of GeoSPARQL is officially out?

[andrea-perego]

@akuckartz , do you have any concern on the proposal?

[akuckartz]

No, I only marked the comment to signal that I "should" perhaps look at this closer ;-) I do not know if I like GeoJSON.

[AntoRot]

@andrea-perego
I'd agree with your proposed resolution, but we should take into account that the IANA URI for GeoJSON literals is still used e.g. in CKAN for the dct:spatial property expressed as geometry.

Consequently, deprecating the use of the GeoJSON media type URI for GeoJSON literals will affect the compability with the CKAN model for all data providers who use that tool. Unless CKAN community will align the RDF DCAT to CKAN mapping by including the new GeoJSON datatype being adopted in GeoDCAT-AP 2.0.

[andrea-perego]

Thanks, @AntoRot .

Unless there are any objections, I will merge PR #58 and close this issue.

[AntoRot]

No objections from my side. Thanks.