Json-LD instances test : issue for polygons. lists of lists not allowed in JSON-LD 1.1

[afeliachi]

Polygons in GeoJSON are represented as lists of lists of lists of point coordinates. Lists of lists are actually not allowed in JSON-LD 1.1 (cf. https://json-ld.org/spec/latest/json-ld/#sets-and-lists), thus, GeoJSON should be used for representing polygons.

Example : https://opengeospatial.github.io/ELFIE/nrcan/aquifer/cr/Richelieu_contexte_3 JSON-LD processors consider it invalid (https://json-ld.org/playground/)

This should give a partial answer to the discussion about what to use for describing polygons #107.

The best solution is to use WKT (or EWKT) literals instead.

[denevers]

ok for geometry WKT, But how can we encode 1:* properties without lists ? (https://json-ld.org/ is down)

[afeliachi]

simple lists are allowed. I think 1:* properties are encoded as lists of objects

[ { }, { }, { }, ... ]

and not lists of lists

[ [ ], [ ], [ ], ...]

[denevers]

oh.. ok, I'm fine then

[afeliachi]

https://json-ld.org/playground/ is on now

[dblodgett-usgs]

Related to my comment over in #135

I think the solution here is going to be to link to standalone geojson (non-ld) documents for a preview geometry. We should note that JSON-LD is limited for our desire to mix ld content and conventional json content.

Opinions?

[dblodgett-usgs]

Circling back on this with info from #135 comments.

From me:
Doing some snooping at http://geojson.org/geojson-ld/ -- I see this:

Nested GeoJSON coordinate arrays are incompatible with the processing model of JSON-LD 1.0. There are no current best practices for addressing this issue. Applications that process GeoJSON as JSON-LD using the GeoJSON-LD 1.0 context must take extra steps not defined here to ensure that geometric coordinates are processed appropriately.

This leaves us with two options -- 1) break the rules and point out that this issue needs to be solved or 2) scale back our ambition to encode geojson geometries directly in our json-ld documents by linking to them directly instead.

I had already been considering doing #2. @abhritchie @jkreft-usgs -- you two have been the most active in this discussion, what say you?

---

And from @lieberjosh

The processing referred to is compatibility with RDF, which doesn’t have nested sorted lists. So any nested coordinate lists representing geometries have to be preserved as opaque literals wrt RDF and processed separately from any standard JSON-LD processing or they will be mangled. Geometric coordinate lists usually need special treatment anyway, which is why they are serialized in WKT for geosparql.

---

I continue to think we should use geosparql for the actual geometry of a feature and a geojson encoded geometry for a preview geometry. This will be a topic to bring up in the engineering report for sure. For our tests, I would lean toward linking to a geojson document as the @id of the geojson:geometry relation. But I'm basing that on a pretty limited set of priors -- very curious what others think.

[jkreft-usgs]

I think that the idea of linking to a geojson could totally work, especially if it facilitates using standard tools to parse the json-LD. Breaking the json-LD spec seems like a great way to make general-purpose indexing tools ignore all the data we are trying to show them.

[dblodgett-usgs]

It could also be a way to highlight the potential of WFS -- if only they'd do XYZ in WFS3 ?

[dblodgett-usgs]

Decided to link to geojson from the schema:geo element. No inline geojson but can link to it with a type from schema.org.