-
Notifications
You must be signed in to change notification settings - Fork 6
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
Comments
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. |
Also note there are now 2 versions of geoJSON. Can these serializations be distinguished? |
@akuckartz said:
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. |
@bertvannuffelen said:
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. |
@dr-shorthair said:
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 |
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). |
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? |
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. |
@akuckartz , do you have any concern on the proposal? |
No, I only marked the comment to signal that I "should" perhaps look at this closer ;-) I do not know if I like GeoJSON. |
@andrea-perego 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. |
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? |
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:
The following text has been added at the end of §B.6.10.1, right before Example 35:
Would this work? |
No objections from my side. Thanks. |
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
The text was updated successfully, but these errors were encountered: