Add additionalTags to the release schema

[ColinMaudry]

As discussed in #792, we need to add a new field additionalTags to support additional tags to track more specific events that motivate the publication of a release.

This field will be bound to an open codelist additionalTags that is empty in core, but expanded in extensions (bids, enquiries, etc.).

[ColinMaudry]

I suggest the following description, inspired by the description of tag:

One or more values from the open additionalTags codelist. These tags can be used to track events that cannot be tracked with the tag field.

[jpmckinney]

We might want to describe the use case more clearly, maybe:

A tag is a label for the release: for example, to indicate the event that caused the release to be created.

And to clarify the rules around tag vs additionalTags:

This field must not contain tags from the closed releaseTag codelist, for which the tag field must be used.

Update: Hmm, if we ever promote codes from the additionalTags codelist to the releaseTag codelist, then that change would be backwards-incompatible if we have the above rule. Do we need a sentence about the tag field?

In the schema, the field will need to be "omitWhenMerged": true, since it only makes sense in the context of an individual release (not a compiled release).

[ColinMaudry]

if we ever promote codes from the additionalTags codelist to the releaseTag codelist, then that change would be backwards-incompatible if we have the above rule. Do we need a sentence about the tag field?

I have thought of several scenarios:

1. promoting codes and forbidding the presence of releaseTags codes in additionalTags
2. promoting codes and allowing the presence of releaseTags codes in additionalTags
3. no promotion of codes from additionalTags to releaseTags

The first question is: why would we promote tags to the releaseTag codelist?

We could expect additionalTags codes from the bids or other near-core extensions to become structuring and popular, to a point it may make sense to add them to the releaseTags codelist. @jpmckinney is that what you had in mind?

However, I don't think the benefits (structure, normative power) of promoting codes outweigh the drawbacks (managing the duplication codes across lists). I prefer 3.

PS: moreover, the popularity of the extensions that implement the codes of the open codelist seems sufficient to structure the practices and prevent the use of too many different codes.

[jpmckinney]

In that case, could we instead just change tag to an open codelist (the other option from #792)? If we have additionalTags that repeats and adds to tag, there is really not that much utility to tag. Publishers would still need to use existing codes where appropriate; they'll just now have the option to use other codes. Extensions can then add new codes, and if we decide to promote a code to core (whether from an extension or from publishers), then there is no issue.

[ColinMaudry]

To be sure, my proposal in #1184 (comment) is not to promote codes from additionalTags to tag. additionalTags would be used to narrow down the purpose of the release in a more flexible way than tag.

I'm also OK with turning releaseTag into an open codelist, but I find it more risky than my proposal above, as the existing codes in releaseTag offer little semantics. If the new codes we add from bid, etc. don't match the use case of the implementers, a significant number of them may mint more fitting codes. As usual, good documentation and support would be key to prevent the multiplication of release tags.

[jpmckinney]

My concern is having two fields that are arrays of codes that are semantically identical, but where the only difference is that one uses a closed codelist and the other uses an open codelist. It would make more sense to just have a single field.

[ColinMaudry]

We have procurementCategory and additionalProcurementCategory, isn't it the same pattern?

[jpmckinney]

Notes from call:

additionalProcurementCategories was first discussed in #376 as part of the 1.1 upgrade. The three main procurement categories (goods, services and works) are well established. A contracting process has a single main procurement category. Different jurisdictions have additional categories, like "services related to goods", "services related to works", etc. These other categories are less standardized and overlap semantically with the three main categories. There are clear use cases for distinguishing contracting processes according to the three main categories.

In this context, it makes sense to use a static closed codelist for the mainProcurementCategory as field, and to have a separate field for additional codes.

tag, to my knowledge, was introduced very early, prior to any issues in this repository. Its codes are not well established. They can be used to match notices published in paper-based processes, or events in electronic records-based processes. This mapping is not robust; it's largely up to each publisher, and different publishers might make different mappings for similar situations. The mapping can be difficult to reconcile with reality: whereas an observer can easily reconcile a "goods" contract with the reality of a crate of bananas. The use cases are less clear. Some BI tools use tags to distinguish between events (#791). Some users might use tags to reconcile OCDS' record-based approach with notice-based systems (e.g. this 'tenderAmendment' release is an F14 TED form). The tag field is an array.

In this context, it makes sense to encourage the use of common codes, but to allow the use of additional codes within the same field.

As such, we will close this issue and re-open #792.