At that point this internal thing becomes a liability / external dependency for external services doing searches into it.
Therefore it would be better if we could shield this external dependency off from possible internal changes.
This could be done by allowing a manageable alias for this data-set (e.g. /dataset-alias/bodc-p06)
This should not replace the usage of the uuid for internal management and storage, it would just need to be translated at the entrypoint from alias to internal uuid
Use cases:
be able to replace the supporting backend-vocab with an updated and tested config (e.g. previous based on dump, now on ldes, or using new sources) behind the scenes without the need to update deployed widgets
survive an admin glitch that unintenionally (or intentionally for some cleanup reasons) removed a vocab that needs to be put back because many existing widget deployments rely on it
as discussed: mapping from alias to actual index could be done in the widget. This might be our preferred option, as this allows for better user feedback.
All vocabs get assigned an internal uuid.
However this internal id gets exposed at the time we configure an actual widget for search:
At that point this internal thing becomes a liability / external dependency for external services doing searches into it.
Therefore it would be better if we could shield this external dependency off from possible internal changes.
This could be done by allowing a manageable alias for this data-set (e.g. /dataset-alias/bodc-p06)
This should not replace the usage of the uuid for internal management and storage, it would just need to be translated at the entrypoint from alias to internal uuid
Use cases: