Collection name aliases / deprecation

[soxofaan]

Feature request: let the /collections and /collections/{collection_id} optionally specify a list of collection_id aliases for each collection.

A backend might want to change the name/id of a collection (e.g. to simplify usage, have more uniform naming, bump version numbers, ...) without breaking existing code that uses old names.

[soxofaan]

somewhat related to #52

[soxofaan]

(and maybe uou could even take it a step further by adding deprecation flags and letting clients (or backends) raise warnings on usage of deprecated collection ids.)

[m-mohr]

• A flag deprecated as we have for processes seems like a reasonable addition.
• I'm not so sure about the collection aliases. It could either help or make things even worse. For aliases to help with Collection name differences  #52 it would still need a "common" list of collections and their properties. Otherwise it would make things worse in that sense that there are even more names will be floating around. Also, I feel that your examples are bad for reproducibility. So I'm not really convinced by this addition yet.

Both features are not foreseen yet in STAC (that's the basis for our collection discovery) and I'd need to check how to best integrate this.

[m-mohr]

I added that collections (and processes) can be marked as deprecated, see 4918bd8. Links with relation type successor-version can point to a newer version.

I'm still not convinced regarding the collection aliases, therefore I'm closing for now. Feel free to comment with more arguments and/or use cases and I may reconsider it for the next version.

[soxofaan]

The deprecation flag can indeed be helpful

About the aliases: no biggie, we can still duplicate collections under a new collection_id key (aliases would just make that a bit cleaner and more explicit)

One additional use case where it may come in handy: say the VITO backend provides Sentinel 2 data under "CGS_SENTINEL2_RADIOMETRY_V102_001" and an another backend provides it under "FOO_SENTINEL2_BAR". To improve interoperability, both backends might want to alias these with for example "SENTINEL2_V2019", while still keeping the original names for backward compatibility.

[m-mohr]

I guess the easiest solution with the current model would be that you duplicate the metadata under a different name and just internally let them point to the same source data. You could point to the alternative collections with a link of relation type duplicate. It doesn't really solve the issue to communicate which is the preferred name to use, but the aliases don't solve this either. In the end we are basically going back to #52. When's data the same and which name to use.