Adding "Created" and "Updated" to all resources #206

Hello Connected Systems People,

I believe there is a valid use case for adding two fields to every resource

• created: the date the resource was created
• updated: the date the resource's own representation was updated (aka adding a new observation does not update a datastream, or adding a new subsystem does not change the parent system)

This would follow existing OGC terminology with records

  created:
    type: string
    description: |-
      The date this record was created in the server.
    format: date-time
  updated:
    type: string
    description: |-
      The most recent date on which the record was changed.
    format: date-time

Use Cases

Better UI/UX Experience: This would greatly help the user experience whenever Sorting/Order is added, as currently there is no direct way to get most recent created or updated resources. The closet would be observation thru resultTime but for part 1 resources validTime is the best option and that does not always refer to "created" and certainty not updated

Federation and cache invalidation: A client aggregating several CS API servers into one view needs a cheap way to know which cached resources are stale.

Consistency with Part 3: Part 3 deals with created updated and deleted lifecycle events. These fields would just bake it in the resource in case a client was offline and missed those events, currently there really is no "catch up mechanism"

System History: There is also some precedent in Connected Systems itself with system history. Where it tracks the changes of just the system resource over valid time. This would bring some of that tracking to all resources in more unified consistence way

Protentional Arguments

HTTP already has Last-Modified and ETag.: This would hint towards the in-progress Features Part 4 Create, Replace, Update and Delete method of dealing with updated. This still does not invalidate the need for the new fields. Those headers only apply to single-resource response, which make sense for single features but not when you want a list of systems, observations ...etc. In addition, detailed querying could never work, as you cannot filter or sort on Etags or Headers

This is record metadata, not domain data. It doesn't belong in the resource model: There is a clear argument that these fields should be just stay part of the record API and if you want this information use Records API.

• This was my first approach. The problem shows up on the harvester side. If the Records API is separate and you're trying to keep it in sync with a Connected Systems server or in my case many CS servers, you have no way to find what changed since the last sync. The only option is to re-crawl everything and compare each record against what you already have.
• Assuming you just bake in records API to avoid the sync problem, this approach would make a Records API an unofficial requirement for answering basic questions about a CS API server's own resources, such as when a system was added or last changed. A server that doesn't run a catalog alongside it couldn't provide this information at all, and a client that wants it would have to query two separate APIs and match resources between them by ID.