Lots and related extensions: Allow referencing to lotGroups

[jpmckinney]

Based on discussion in #125.

The Lots extension allows for the creation of tender/lotGroups, but there are never referenced from any other field (like relatedLots), as far as I'm aware.

We have two options:

1. Change all relatedLot and relatedLots fields (I think those are the only names we use) to allow referencing an object in the tender/lotGroups array
2. Create a separate field, in the case where a group is referenced.

I think (1) is preferred, as the use of lotGroups is rare. This will require some additional rules around how lotGroup IDs are generated, e.g. with a group- prefix, so that users know where to perform the lookup.

[jpmckinney]

Some context about lot groups from eForms https://op.europa.eu/en/web/ted-eforms/minutes-4th-eforms:

Q: What is the business meaning of the group of lots? Documentation specifies constraints on what it contains but it does not give a clear sense of what a group means for the end user.
Answer: A group of lots allows to have the same values for more than one lot – but unless this is used or needed in your country, we suggest you hide this from the end user.

Q: Group of lots - the question is what do they represent for the business? I cannot make a conscious choice on if I want to hide it unless I know what it means, and this is not clear at all.
Answer: Groups of lots represent business opportunities where tenderers can provide their services with common criteria. For example, a group of lots to produce office furniture could contain several lots for several specific objects (chairs, desks, etc.). There are common constraints in the group, such as common award criteria, and a common value which could be less than the value of the individual lots contained within.
Even if a group of lots can simplify some of the constraints related to the individual lots, and tenders can be submitted for it, it cannot be awarded as an entity. Contracts must be signed for all the lots separately even if the buyer takes advantage of the conditions presented in the group.

[odscjen]

Agree that option (1) is preferable.

Re the extra rules, in eForms lotGroup id's need to follow the pattern GLO-XXXX (see https://docs.ted.europa.eu/eforms/latest/schema/identifiers.html#identifiersSection). The current OCDS mapping guidance for BT-137-LotsGroup (the lot group ID term) says to just map this ID directly to tender.lotsGroup.id. So any lookup rules would also need to account for this pattern. For ease maybe the guidance on generating a lotGroup id could be just to follow that pattern and that way OCDS would only need one pattern look up? But I could also understand if using the EU's pattern exclusively may be politically sensitive, so offering another pattern might be preferable even if it makes the look up code more complicated. If so having a group- prefix seems simple and clear. I suppose this also depends on whether anyone other than the EU are using lotGroups?

[jpmckinney]

For ease maybe the guidance on generating a lotGroup id could be just to follow that pattern and that way OCDS would only need one pattern look up?
I suppose this also depends on whether anyone other than the EU are using lotGroups?

That's my thinking as well. I've only heard of lot groups in the EU, so let's use GLO- as there seems to be no advantage to breaking that consistency.