design and implement tag backend

We are leaning towards a solution where the literal string value is kept on the record. As such, there are two elements to the proposed solution:

1. a new JSON schema for tags (similar to the metadata schema, but not readonly), implementation of the handling in RMB, filtering will be automatically possible through CQL by using the array fields workaround

2. central module (mod-tags) for keeping a list of values used for tagging across FOLIO, there is a list of questions here that will guide the implementation:

• deleting tags: should tags from the central list get removed when the last tags from tagged records is removed? (preferably not as it increases complexity) No, tags remain on the central list until removed via a central administrative action. That functionality comes in phase-2.
• deleting tags: if tags are centrally managed, should removal of the tag from the central storage be prevented if the tag is used in any of the modules/records (again, preferably not as it requires consistency checks between the tag module and the specific module) Tag cannot be removed from the central tag list unless it is not assigned to any record in any FOLIO app. The central tag list will also be a way to review records across all apps that have a specific tag, so it's going to need to be aware of how each tag is being used in each app anyway.
• allowing/disallowing tags: do we validate tag values at the point of assignment or only provide values as an auto-completion aid? (again preferably no validation happens) No validation, just auto-suggest, I think. However, we're going to have a permission that allows a user to only assign existing tags (tag must already be on the central tag list) versus a permission that allows the user to assign a completely new tag (which will then need to be automatically added to the central tag list). Not sure if that has an impact on the design you're considering or not.

As discussed on the call, to provide validation or prevent removal we need to create a dependency between a given storage module and the tag module (to perform lookup at the point of assignment/removal), or construct a business logic module to provide it.

Alternatively, we could look at some sort of push approach where the business logic modules would provide updates to the interested modules that keep a list of all tags. This is the most complex solution.

In case it's helpful, for phase 2 (working with a tags central admin area), we're also considering the idea of a "tag record" that would have the tag, plus also a description field, where someone could describe how the tag is to be used. Any tags created in phase 1 would not have descriptions, but the descriptions could be added later, once phase 2 allows access to the central tag list and individual tag records.