Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Defining an XML / RDF datatype for GeoJSON #4

Closed
andrea-perego opened this issue May 3, 2018 · 16 comments · Fixed by #58 or #59
Closed

Defining an XML / RDF datatype for GeoJSON #4

andrea-perego opened this issue May 3, 2018 · 16 comments · Fixed by #58 or #59

Comments

@andrea-perego
Copy link
Collaborator

Although RDF datatypes exist for WKT and GML (they are defined in GeoSPARQL), an XML / RDF datatype for GeoJSON is missing.

To address this issue, GeoDCAT-AP v1.0 uses the URL of the corresponding IANA media type (namely http://www.iana.org/assignments/media-types/application/geo+json), but this solution is not optimal, and the definition of a specific datatype might be considered. In such a case, the question is whether this should be done in the framework of GeoDCAT-AP or of the Core Location Vocabulary.

About this issue, see also SEMICeu/Core-Location-Vocabulary#2

@akuckartz
Copy link

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
Copy link
Contributor

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

@dr-shorthair
Copy link

@andrea-perego
Copy link
Collaborator Author

@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
Copy link
Collaborator Author

@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
Copy link
Collaborator Author

@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
Copy link
Collaborator Author

andrea-perego commented Nov 29, 2020

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

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
Copy link
Collaborator Author

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

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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

@akuckartz
Copy link

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
Copy link

AntoRot commented Dec 19, 2020

@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
Copy link
Collaborator Author

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 andrea-perego linked a pull request Dec 19, 2020 that will close this issue
@andrea-perego
Copy link
Collaborator Author

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?

@andrea-perego
Copy link
Collaborator Author

Thanks, @AntoRot .

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

@AntoRot
Copy link

AntoRot commented Dec 21, 2020

No objections from my side. Thanks.

geodcat-ap release 2.0.0 automation moved this from To do to Done Dec 21, 2020
andrea-perego added a commit that referenced this issue Dec 21, 2020
* Update §B.6.10

* Add bib entry for draft of GeoSPARQL and set max toc level to 3

* Revise changelog

* Remove outdated comments and add link to issue #57

* Update document version number

* Update README files

* Add README files

* Editorial revisions
@andrea-perego andrea-perego linked a pull request Dec 23, 2020 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

5 participants