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

Confirm GeoJSON-LD is out of scope in 'core' SELFIE #52

Closed
abhritchie opened this issue Oct 7, 2019 · 6 comments
Closed

Confirm GeoJSON-LD is out of scope in 'core' SELFIE #52

abhritchie opened this issue Oct 7, 2019 · 6 comments
Assignees
Labels
Engineering Report help wanted Extra attention is needed question Further information is requested

Comments

@abhritchie
Copy link
Contributor

abhritchie commented Oct 7, 2019

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.

@abhritchie
Copy link
Contributor Author

If y'all agree I'll move the .geojson examples to docs/examples/annex.

@abhritchie
Copy link
Contributor Author

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 databaseId example in the draft spec).

@abhritchie
Copy link
Contributor Author

abhritchie commented Oct 7, 2019

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.

@abhritchie abhritchie self-assigned this Oct 8, 2019
@abhritchie abhritchie added Engineering Report help wanted Extra attention is needed question Further information is requested labels Oct 8, 2019
@pbirkel
Copy link

pbirkel commented Oct 8, 2019

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.

@afeliachi
Copy link
Contributor

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.
@sgrellet & I provided an example (with some comments that will be deleted after discussion) of a GeoJSON-LD description.
An equivalent "pure" JSON-LD could be easily provided as in the second example file
I agree also with @pbirkel that we should keep it in mind the possibility to move it from annex to the body as a core alternative representation.

@abhritchie
Copy link
Contributor Author

Decision

  1. GeoJSON-LD is out of scope in SELFIE and our results and examples will be included as an annex in the engineering report.
  2. GeoJSON-LD example documents will be moved to a folder named 'deprecated' in the SELFIE repository.
  3. GeoJSON-LD documents are no longer to be used as examples in discussions or the main body of the engineering report.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Engineering Report help wanted Extra attention is needed question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants