-
Notifications
You must be signed in to change notification settings - Fork 8
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
Confirm GeoJSON-LD is out of scope in 'core' SELFIE #52
Comments
If y'all agree I'll move the .geojson examples to docs/examples/annex. |
Regardless of the outcome I'll patch up the examples to put the contexts in a more sensible place and to mark API specific properties, like fid, as 'not JSON-LD' (see the |
Note I think we should recommend the following in the main text: GeoJSON is a valid media-type to request during content negotiation against a non-information resources IRI. Just as HTML, GML and others are. For semantic consistency across responses, the resulting document should use the same key names, key values should use full rather than compact URIs. |
Good morning. I'm merely an observer here, but have had reason in other OGC-related work to have explored this topic. I agree with the proposal (Informative Annex) and the rationale. The current expectation is that JSON-LD 1.1 might be approved next summer and thus by this time next year we could reasonably expect better support by parsers. Based on finalization and support the content of the Informative Annex could then be updated and be integrated into body text as normative. |
I do agree with your proposal @abhritchie. As long as jsonld 1.1 is still a working draft GeoJSON-LD should not be considered as a core encoding. That been said, the current JSON examples (as in aquifersystem-richelieu) should be a bit shaken to be a valid usable GeoJSON-LD file. |
Decision
|
This issue is to determine whether we document the use of GeoJSON-LD as a core SELFIE encoding (i.e. good to go as is is we were to move from an IE to a SWG) or as an annex (i.e. promising but not ready).
If you disagree with the proposal below below say so, and why, in the comments. We'll review and close this issue with a decision at the SELFIE call on October 9/10). Silence will be considered as 'no objection to unanimous consent'.
Proposal
The use of GeoJSON-LD should be presented as an Annex in the SELFIE Engineering Report. SELFIE development should focus on 'pure' JSON-LD.
Reason
GeoJSON-LD is not mature enough for formal use in a standards-based system. The use of GeoJSON-LD is dependent on a JSON-LD to RDF processing model not supported by the current W3C recommendation (JSON-LD 1.0). It is addressed by JSON-LD 1.1 but this is currently a W3C working draft. Furthermore, support for version 1.1 by JSON-LD parsers is sporadic. For example, it is only recently that the JSON-LD Playground could process a GeoJSON-LD document describing anything other than a point.
Background
ELFIE tested and rejected the use of GeoJSON-LD as 'GeoJSON coordinate arrays were incompatible with the processing model of of JSON-LD 1.1' (see 'Outstanding issues' here). We revisited this in SELFIE as JSON-LD 1.1 has introduced support for containers that are lists of lists (Section 4.3.1). The original GeoJSON-LD 1.0 context document is compatible with how to define nested lists in GeoJSON-LD so our existing examples should be readily processed.
Initial testing of example GeoJSON-LD documents encoding polygons (e.g. meta-resource-1.geojson) and using the JSON-LD Playground in July 2019 failed. This is likely due to JSON-LD 1.1 processing only being partially supported by the Playground. Recently (2019-10-08) this partial support seems to have been improved and the Playground processes our examples without incident.
GeoJSON-LD is therefore promising, worthy of mention in SELFIE, and of future work, but it not yet ready to be a core component of our current work.
The text was updated successfully, but these errors were encountered: