Transactions for versioned Features with OGC API part 4 (or..)

[lennartvanbergen]

Use case

This item wishes to adress the use case where Features are created and modified via an API.

Background

Part 4, Simple Transactions, will add the capability to create/modify/delete features to the API.
There is also the use case for an API for creating, modifying and ‘ending’ features, in a registration that also preserves a full history of the data, for each feature, throughout the years. In the sense that the data describes the same object/feature, but that the data about the object/feature changes over the years (same object/feature/resource, new data for it). This is a frequent use case in the context of managing a feature collection in a registration. This is called versioned objects/features.

In the underlying implementation a temporal datamodel is used. For instance the bi-temporal model with valid-time and transaction-time as mentioned on https://en.wikipedia.org/wiki/Temporal_database

Intention

To use REST, and HTTP operations, to manage objects/features. A user can then query the feature collection and select the data that is valid, a version, without having to know about the versions itself, nor having to know much about the temporal aspects of the data. The latter is an in the black box concern, not an API concern.

The main intention is to clarify if support for simple transactions on versioned features is in scope of Part 4 - or alternatively of another future extension.

Part 4: http://docs.opengeospatial.org/DRAFTS/20-002.html

Feel free to participate in this open discussion.

[cportele]

Meeting 2020-08-31: This will be a good topic to discuss with the Sprint participants in late September. The general feeling is that this should be part of another extension related to versioning, not just limited to transactions, but also to filtering. So, another part that adds requirements for versioned datasets an extends part 1, 3, and 4.

[lennartvanbergen]

OGC API illustration.pdf

Illustration of modifying a Feature/object as a version, in the internal implementation of the registration. This illustration is not meant as a specification, but is merely an illustration of the use case. Both implementation variants should be possible, without any impact on the API specification itself.

[cportele]

Meeting 2021-01-18: Versioned feature support is out-of-scope for part 4. In this context, in the last discussion about new tasks for the SWG, there was interest in support for versions and the SWG is looking for spec proposals from interested parties.