Canonical JSON-Ld context and Feature Schemas for OGC API

[rob-metalinkage]

The work on a FG-JSON schema to extend the options for OGC API beyond GeoJSON (WGS84 and a narrow subset of simple features) means the potential for multiple competing JSON schemas to be defined for the basic matter of handling features and geometries.

See opengeospatial/ogc-feat-geo-json#26

The details are somewhat tricky, but it appears that various possible schema patterns in JSON are possible and the model for features from GeoSPARQL probably suggests some patterns would be more natural than others. Is it possible to derive a candidate for FG-JSON from GeoSPARQL and get JSON-LD implementation "for free" ?

[rob-metalinkage]

Please see example at https://github.com/ogcincubator/iliad-apis-features/blob/master/build/tests/hosted/iliad/api/features/iliad-jellyfish/example_1_1.ttl

e.g. at the moment we have to make use a geojson specific ontology - but we need the same level of granularity for JSON independent of GeoJSON itself.

    geojson:geometry [ a geojson:Point ;
            geojson:coordinates ( 3.180691e+01 3.463478e+01 ) ] .

[rob-metalinkage]

We should be able to provide a canonical JSON-LD for feat-geom-json using GeoSPARQL and register it here: https://opengeospatial.github.io/bblocks/generateddocs/slate-build/geo/json-fg/feature/#json-ld-context

[situx]

@nicholascar it sounds to me that we should define a JSON-FG-compatible literal for the next revision of GeoSPARQL since JSON-FG would be a superset of GeoJSON.
@rob-metalinkage is that correct?
In that case, every GeoJSON literal defined in GeoSPARQL 1.1 is still valid, the only question we would need to answer as a working group is whether to rename the literal type, maybe from geo:geoJSONLiteral to geo:jsonFGLiteral.... or to only extend the scope of the GeoJSON literal to also encompass JSON-FG

[rob-metalinkage]

This is actually about more granular literals for components matching the fg-json and GeoJSON schema models.
AFAIK it would require a change to the JSON-LD specification and tooling to directly embed JSON sub-schemas as encoded literals in the JSON-LD processing algorithm to generate RDF. GeoSPARQL has no support for coordinate lists - admittedly RDF lists are horrible and probably should never be stored, but GeoSPARQL support for these elements allows transfer of data using JSON .