Support for Complex Relational Data Models in JSON schemas

[maxcollombin]

Could you consider adding the possibility to return data model informations (constraints, relationships, p- and fkeys)
in the JSON schemas like the INTERLIS data models in Switzerland?

The idea behind this would be to allow the creation of any dataset (.geojson, .gpkg, .shp,...) from the model.

[jerstlouis]

I believe this is related to Part X - Schemas and Part X - Search/Queries, and to some extent to OGC API - Joins, as well as to the relationship with SensorThings API and Connected Systems.

Having the ability to express the relational model, and possibly leverage it in queries as well.

[jerstlouis]

Also related to #801

[cportele]

This issue is related to the scope of the planned part Schemas, so I have added it to that project board.

A few comments:

We can distinguish at least the following variations of a feature schema that are relevant:

• A schema that describes the type independent of the feature encoding.
• A schema that is specific to an encoding and can be used for validation (e.g., for GeoJSON, JSON-FG or GML). In some encodings, this information is part of the encoded data (e.g., for GeoPackage or FlatGeobuf).
• The schema may also vary depending on the operation (create, replace, update, fetch, etc.).

There are use cases for all these variations, but we need to decide, what needs to be standardized.

Consistent with the approach for the Queryables, Sortables or Tile Set Metadata resources, the idea for the feature schema that is independent of an encoding would be to use JSON Schema as a general schema to specify an object schema.

This covers constraints, but there is no convention for expressing relationships in such a schema (*). There would likely be a need to distinguish multiple approaches, depending on the source data. Relationships may be between features in the same dataset, between features in different datasets, loosely coupled links to any resource using a URI, etc.

(*) This is separate from the considerations how to express relationships in the encoded data, where in a Web API a typical approach will be to represent them as a URI or web link consistent with RFC 8288.

[cportele]

This is a part of the discussion in #740. Once #740 can be closed, this issue can likely be closed, too.