JSON Schema compatibility with data modelling - e.g. referencing GeoSPARQL using JSON-LD

[rob-metalinkage]

Whilst accepting that a normative dependency on JSON-LD is not desired, consideration should be given to not proliferating more JSON schema patterns than necessary. A natural JSON-LD context can be derived for features and geometries from GeoSPARQL identifiers. Several possible JSON schemas might be used with such a context to create isomorphic encodings, however a canonical encoding would be preferable. Thus if FG-JSON was able to build on GeoSPARQL 1.2 it could perform that function as a normative JSON encoding for GeoSPARQL.

Coordination between GeoSPARQL SWG and FG-JSON should identify the opportunities for, or conversely a well reasoned rationale for not, taking this path to produce compatible and complementary specfications.

[cportele]

Meeting 2022-01-22: We are open for discussing opportunities, but it is unclear what needs to or should be done in JSON-FG? @pvretano will raise it in a GeoSPARQL SWG meeting.

[cportele]

Meeting 2022-02-21: @pvretano joined a GeoSPARQL SWG meeting. The status is currently that GeoSPARQL cannot yet be used over JSON-FG, but there is nothing in JSON-FG that would block future use. Whatever needs to be done, it needs to be done in GeoSPARQL, but probably not in the next version.

It is unclear to us, what it means that JSON-FG would be "able to build on GeoSPARQL 1.2". It is also unclear why JSON-LD would matter in this context. @rob-metalinkage - can you clarify and if we can close the issue?

[rob-metalinkage]

JSON-LD is RDF - schema elements have URIs and these should resolve to a model of what they mean - RDF needs a canonical model - OWL but probably also SHACL to define the frame a JSON schema can be derived from. That model would be GeoSPARQL since yet another one would be just another source of confusion and interoperability failure. So nothing really needs to be done in GeoSPARQL - the requirement is that arbitrary JSON schema patterns are not introduced that cannot be directly derived from a semantic model. I.e. avoiding further proliferation of incompatible but similar-looking ad-hoc JSON schemas.

Possibly - and this may be more a lot work - you could develop a canonical mechanism for mapping arbitrary JSON schema elements to a data model described in OWL, SHACL - but this is out of OGC control and moves away from previous practicves with GML where schema patterns are defined and supported by data model translation. So why not start with a known mechanism for deriving JSON schemas for FG-JSON from formal models from start, and declare that as OGC best practice.

It may constrain JSON schema patterns - I expect exploiting existing JSON-LD schema patterns for significant data types such as langString would be the obvious starting point.

Possibly also specific data type patterns could be pushed back to JSON-LD if needed. Again I dont think this affects GeoSPARQL - its all about compatibility of FG-JSON with data modelling approaches. I have renamed the issue according..

[cportele]

JSON-FG is normatively specified by JSON Schema and builds on the GeoJSON schemas for features and geometry, the link schema from the OGC API standards for web linking, and the CQL2 schema for the temporal entities. Only very few data types are originally specified by JSON-FG (the feature type(s), the geometry dimension and coordinate reference system references, if I am not missing something) and those are simple and consistent with the new Simple Features, Topic 2 and ISO 19107.

We want to keep it simple for users of the specification and avoid a normative dependency to JSON-LD or GeoSPARQL. It must be possible to implement JSON-FG without a need to know, understand or care about JSON-LD, RDF or GeoSPARQL.

There could be a mapping for those who care, e.g., a JSON-LD context, if someone will make a proposal.

[rob-metalinkage]

That is understood - it may however mean that another family of JSON schemas may be required to support domains using their own data models with OGC APIs - or possibly not being able to use OGC APIs at all if normative schemas are not able to support JSON-LD patterns. Given the choice between losing necessary capability and inventing a better option standards that dont work well enough will be bypassed. I'm not sure what the gap here is likely to be - will aim to get some experimentation in.

[cportele]

Thanks @rob-metalinkage, it would be great to get a better understanding if there is a gap and what it is.

[KathiSchleidt]

@rob-metalinkage FYI - we've started first experiments with LD and STA, see opengeospatial/sensorthings#137

A few of the entries in the context I put up there are still improvised (anything concerned with "sta": "http://something.org/sta/" is full freestyle improv!), but managed to nail most of the STA concepts against existing resources.

Issues encountered:

• attributes/associations with the same name, but subtly different semantics. Was actually a non-issue, as STA bypassed the object-property model (so no association names, just the next class), while the attribute names are consistent in meaning across classes. In O&M we've also taken care to assure this, but pretty sure that this will cause issues in less semanticly crafted models
• OData 4.1 also has an @context element with a different meaning. Not relevant to OAPI, but worth being aware that other technologies are reusing the same attribute name. Within STA we've come to the conclusion that it's not that bad with the following approach
  • as long as you're using normal STA, it's the OData context (if we integrate that in STA 2.0)
  • if you request LD as a response format, the @context provided is the LD one

For what its worth!

[cportele]

Sorry, I pressed the "close" button by accident...

[rob-metalinkage]

After a good deal of experimentation the OGC BuildingBlocks validation tools can support semantic annotation of GeoJSON and FG-JSON structures.

Use the "JSON-FG" filter button at https://opengeospatial.github.io/bblocks/register.html

To see examples of these in use, check out https://ogcincubator.github.io/iliad-apis-features/

Note the way the example uses @context nested to define URI mappings for identifier tokens - i.e. it is not necessary to embed full URIs in JSON.

 "observedProperty": {
      "@id": "sosa:observedProperty",
      "@type": "@id",
      "@context": {
        "@base": "http://w3id.org/iliad/jellyfish/property/"
      }
    },

note also the relative simplicity of the source context fragment: https://github.com/ogcincubator/iliad-apis-features/blob/master/_sources/iliad-jellyfish/context.jsonld that is assembled into the correct structural model to override the inherited base model context documents.

[rob-metalinkage]

After further exploration the conclusion here is that this is an issue for GeoSPARQL more than FG-JSON - successful mapping of FG-JSON to an arbirtrary RDF form that can be entailed into GeoSPARQL or other models can be done in an addtional layer via alternative forms of "building block" re-using the FG-JSON schemas.

As the issue raiser, I consider this due for closing, as successful JSON-LD implementations of the proposed schemas can be evidenced.