Comments (16)
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.
from geodcat-ap.
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?
from geodcat-ap.
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?
from geodcat-ap.
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.
from geodcat-ap.
Also note there are now 2 versions of geoJSON. Can these serializations be distinguished?
from geodcat-ap.
Also see https://w3c.github.io/json-ld-syntax/#the-rdf-json-datatype
from geodcat-ap.
@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.
from geodcat-ap.
@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.
from geodcat-ap.
@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).
from geodcat-ap.
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).
from geodcat-ap.
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?
from geodcat-ap.
@akuckartz , do you have any concern on the proposal?
from geodcat-ap.
No, I only marked the comment to signal that I "should" perhaps look at this closer ;-) I do not know if I like GeoJSON.
from geodcat-ap.
@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.
from geodcat-ap.
Thanks, @AntoRot .
Unless there are any objections, I will merge PR #58 and close this issue.
from geodcat-ap.
No objections from my side. Thanks.
from geodcat-ap.
Related Issues (20)
- Remove example for Media Type as it is confusing
- Improve notes on using embedded objects vs. references HOT 2
- Relation of various Agent classes used throughout the specification
- Revise usage of Licenses and Rights HOT 2
- DataService protocol mapped to `dct:conformsTo`
- Dataservice protocol list HOT 3
- Info: licenses in Flanders
- Access rights codelist issue
- Shared codelist for spatial concepts
- Format Publications Office HOT 1
- Info: on distribution / dataservice mapping rules HOT 1
- Info: entity conformity
- Info: mapping lineage statements
- pitfalls for metadata providers regarding expected mapping of distributions , digitaltransfers from ISO19115/19139 metadata to GeoDCAT-AP HOT 1
- Mapping of ISO metadata datestamp to DCAT HOT 4
- Mapping ISO dates to GeoDCAT-AP HOT 1
- The representation of the spatialResolution should be clearer specified and explained HOT 5
- The new GeoDCAT-AP should be defined as profile of the upcoming OGC GeoDCAT Specification HOT 2
- Mapping of metadataStandardName HOT 1
- applicableLegislationrequired for geospatial HVD´s HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from geodcat-ap.