Bids: Make awards.relatedBid an array

[yolile]

In some cases the tenderers can make multiples bids, one for each lot or item that are being tender. And then, the procuring entity can make an award that includes differents items/lots that were bidded in differents bids.

For example, the EU has "The contracting authority reserves the right to award contracts combining the following lots or groups of lots".

Due that, OCDS should have a way to combine multiple bids on different lots into one award.

To make that possible the suggestion is that the Award.relatedBid field change to Award.relatedBids and become an array instead of a string.

cc @jpmckinney

[duncandewhurst]

@jpmckinney this seems like a straightforward change, i.e. deprecating Award.relatedBid and adding Award.relatedBids. Do we need to do any more research or consultation?

[jpmckinney]

Can you get a quick statistic from OCDS Downloads on how frequently relatedBid is used?

[duncandewhurst]

It's used in all the digiwhist publications, plus:

• honduras_iaip: awards_relatedBid (25699 occurences)
• kyrgyzstan: awards_relatedBid (2017832 occurences)
• moldova: awards_relatedBid (342974 occurrences)

Noting that there's no data available in OCDS Downloads for:

• afghanistan_record_packages
• afghanistan_records
• afghanistan_release_packages
• afghanistan_releases
• europe_ted_tender_base
• moldova_positive_initiative
• openopps
• paraguay_dncp_records
• paraguay_dncp_releases
• paraguay_hacienda

[jpmckinney]

We don't expect Afghanistan or TenderBase to come back, and I think Positive Initiative and OpenOpps don't track bid information. @yolile Do you know about Paraguay?

[yolile]

In Paraguay, we use the bids extension and therefore the Award.relatedBid field for auctions.

[duncandewhurst]

@jpmckinney based on the above, what do you think we should do?

[jpmckinney]

I think we can go ahead with the proposed change to relatedBids.

The contract related to the combined award will be singular, and we want the number of contracts in OCDS to match reality.

On the other hand, awards are somewhat artificial constructs, so their number is less important. An option I considered is whether to represent the "combined" award as individual Award objects. However, this is not an option, since the Contract object has a singular awardID – and so far the evidence seems weak for a need for an array of awardIDs.

[jpmckinney]

Hmm, just remembered this discussion with @JachymHercher open-contracting/standard#790

However, the last comment provides alternatives, and it seems like a more narrow problem.

At any rate, even if we make awardIDs plural, we probably still want relatedBids, since it's a nice feature to be able to represent a combined award as a single award, to match the real-world notices.

[duncandewhurst]

Sounds good! I'll prepare a PR.

[JachymHercher]

Hello, two clarifying questions here:

1. Is the EU use case the only concrete use case we have or are there others?

   "The contracting authority reserves the right to award contracts combining the following lots or groups of lots".

   From the EU perspective, I can't think of others. (For example, you might have a single tenderer submitting multiple bids for the same lot, but still only one of the bids would be chosen, so you would need to refer to just one of them in the award, so you don't need anything special to model that.)

2. If it is just the case above, the eForms approach is not to model it by repeatedly explicitly declaring all the lots that form the group. Instead, in Group Lot Award (BG-330) they allow you to define a group, which consists of Group Identifier (BT-330) and a set of lots with Group Lot Identifier (BT-1375). From there onwards, you can plug a group ID in many places that you would plug a lot ID (e.g. award criteria, procedure results, bid statistics, in theory even other places).

   The main reason for this approach is grouping lots is very much a corner case and used extremely rarely in practice, so we didn't want to complicate/confuse things by replacing all "non-repeatable lot id" fields with "non-repeatable lot id... but actually if it was a group then you could squeeze multiple lot ids in here" fields.

   For the EU use case, I would suggest doing it similarly? (The fields could probably be added as part of the work on eForms - OCDS mapping. Since this field will rarely be used, I wouldn't bother changing relatedLot etc. to "relatedLotOrGroup`, but rather explaining this in the extension's description and iterating further only if someone uses the option.)

---

(This point is an alternative to the above, you can probably ignore it.)

3. If we wanted to model the "grouped lots" scenario differently than the EU, then my reflex still wouldn't be to model it as Award.relatedBids but rather as bid.relatedLots, because already the bid gets submitted for a pre-defined group.

   (This tries to essentially be a practical instruction on how to execute the options somewhat ambiguously described in Art 46(3) and esp. Rec. 79 of the classical directive).

Also, on the basis of this issue, I've created #182 (comment).

[jpmckinney]

The concrete implementation of eForms does indeed use identifiers prefixed with GLO- (Group of LOts), LOT- and PAR- (Part). https://docs.ted.europa.eu/eforms/0.6.0/schema/procedure-lot-part-information.html. All of these are represented by a ProcurementProjectLot object. Which fields are populated on that object depends on the type.

Regarding eForms, there is no need or desire to match the modeling. There is only a desire to match the coverage of concepts.

That said, how do the two options compare, for a data user? In eForms:

1. The LotResult contains one or more LotTender, which are parts of a bid ("tender" means "bid", not "call for tender"). Both of them refer to a TenderLot, which is part of an opportunity (contract notice). (I actually can't tell how TenderLot then relates to ProcurementProjectLot. I'll assume that TenderLot only contains an ID field.) (Presumably, the TenderLot of the LotResult and LotTender are consistent.) (Also, the names LotTender and TenderLot are confusing.)
2. The user looks up the ProcurementProjectLot using the TenderLot ID.
3. The user checks the schemeName attribute to know whether ProcurementProjectLot is a group of lots or a lot. If it's a lot, they are done.
4. If not, they need to find the LotsGroup object (within the LotDistribution object) whose LotsGroupID matches the ID.
5. The user looks up the ProcurementProjectLot(s) that match the IDs in the ProcurementProjectLotReference elements.

In OCDS:

1. The Award contains one or more relatedLots.
2. The user looks up the tender/lots that match the strings in relateLots.

Honestly, at some points, I wanted to give up figuring out how to do this in eForms.

For (3), if a bidder submits multiple bids for the same lot, how would you know which was the winning bid if there is no Award.relatedBid(s)?

[JachymHercher]

Honestly, at some points, I wanted to give up figuring out how to do this in eForms.

I've never looked into the concrete implementation of eForms (regrettably or luckily - not sure) - it was done after I more or less left the field. Consequently, I won't argue with you on which modelling is better :).

---

For (3), if a bidder submits multiple bids for the same lot, how would you know which was the winning bid if there is no Award.relatedBid(s)?

In eForms:

1. Mainly through Contract Tender Identifier (BT-3202) which is part of Contract (BG-310) - it links to a bid, not a tenderer.
2. Secondarily through Tender Rank (BT-171), even though the current wording doesn't really "allow" for using it for that purpose (hopefully someone will fix that in the next version)

The position of the tender (i.e. whether the tender ended up first, second, third, etc.) in a design contest, some framework agreements with multiple winners (e.g. cascades) or an innovation partnership.

In OCDS:

An equivalent of 1) wouldn't work, because OCDS has Contracts linking to Awards and Awards relying on Suppliers, right?

Then I guess we would need an equivalent to 2), which I guess currently doesn't exist, but would/should be part of Bid.details, perhaps to be introduced as part of the eForms mapping? :)

---

I noticed only now that OCDS already has LotGroup implemented in https://extensions.open-contracting.org/en/extensions/lots/master/schema/#lotgroup.

If https://extensions.open-contracting.org/en/extensions/awardCriteria/master/ accepted lotGroup.id in the lots.id field, then I guess that would be equivalent to the eForms approach.

---

(I'll just drop here a random potential complication to watch out for, coming from eForms. Consider two scenarios (which can happen at the same time):
A) Lots 1, 3, and 5 have an award criterion "just lowest price".
B) Lots 1, 3 and 5 from a group (the buyer says) and he wants the group to have an award criterion "just lowest price".

We need to be able to distinguish these situations, so, for example, we can't just link award criteria to lots 1, 3 and 5 and assume it's enough - it might be ambiguous. However, I think (I'm not 100% well oriented in the award criteria extension, or rather its interaction with the lot extension) that currently in the extension we just give award criteria per one lot, not multiple lots, so this shouldn't be a problem.)

[jpmckinney]

I've never looked into the concrete implementaion of eForms (regrettably or luckily - not sure) - it was done after I more or less left the field. Consequently, I won't argue with you on which modelling is better :).

FWIW, the annex to the regulation is straight-forward. The concrete implementation – not so much. The EU basically has 3 models now: ePO, annex, and eForms XML. The models correspond, but they are not identical. eForms XML simplifies some things (e.g. it removes some indicator fields, relying instead on the presence of scalar fields), and complicates others.

---

I'm confused. You had said:

If we wanted to model the "grouped lots" scenario differently than the EU, then my reflex still wouldn't be to model it as Award.relatedBids but rather as bid.relatedLots, because already the bid gets submitted for a pre-defined group.

And now you clarified:

Mainly through Contract Tender Identifier (BT-3202) which is part of Contract (BG-310) - it links to a bid, not a tenderer.

But BT-3202 is essentially the same as Award.relatedBids (well, it's more like Contract.relatedBids – but anyway, it's definitely not like bid.relatedLots).

I don't see an issue between putting relatedBids on Award vs. Contract, but at any rate, that's a different issue than your first quote above.

---

I've opened #183 about referencing tender/lotGroups.

---

Yes, https://extensions.open-contracting.org/en/extensions/awardCriteria/master/schema/ creates tender/lots/awardCriteria, such that awardCriteria need to be repeated per lot.

We could have instead had free-floating criteria, which then reference (or are referenced by) lots. However, our experience has been that implementers and users have a lot of trouble with highly referential data. In OCDS, only top-level concepts get referenced (parties, lots, bids, awards); unlike criteria, these can't be construed as being nested under another array.

[JachymHercher]

I'm confused. You had said:

If we wanted to model the "grouped lots" scenario differently than the EU, then my reflex still wouldn't be to model it as Award.relatedBids but rather as bid.relatedLots, because already the bid gets submitted for a pre-defined group.

And now you clarified:

Mainly through Contract Tender Identifier (BT-3202) which is part of Contract (BG-310) - it links to a bid, not a tenderer.

But BT-3202 is essentially the same as Award.relatedBids (well, it's more like Contract.relatedBids – but anyway, it's definitely not like bid.relatedLots).

I don't see an issue between putting relatedBids on Award vs. Contract, but at any rate, that's a different issue than your first quote above.

bid.relatedLots would correspond to eForms' Tender Lot Identifier (BT-13714) which allows identifying a single lot or a single (predefined) group of lots for which a bid is submitted.

Contract Tender Identifier (BT-3202) is a repeatable field, but it is unrelated to groups of lots (for which a contract would link to a single tender which links to a single group which links to several lots). Instead, it is repeatable because eForms allow for several awards (for different lots) to result in a single contract.

Was this the source of confusion?

[jpmckinney]

I am no closer to clarity :) This issue is closed. Could you please restate, as simply as possible, what your question or concern is?

[JachymHercher]

Restating (still along the lines of #125 (comment)):

1. Are EU's "lot groups" the only use case for Replace Award.relatedBid with Award.relatedBids open-contracting-extensions/ocds_bid_extension#46 ? I don't think I got an answer.
2. Thinking about the EU's "groups lots" use case, I asked whether you wouldn't rather have IDs for groups of lots. I got the answer (in Bids: Make awards.relatedBid an array #125 (comment)) that "no, becase it's complicated", but https://extensions.open-contracting.org/en/extensions/lots/master/schema/#lotgroup creates lotGroup and Lots and related extensions: Allow referencing to lotGroups #183 suggests to build on that (by allowing to refer to them). How does that fit together? Shouldn't we drop lotGroup? Or, going in the other direction, if we do use lotGroup, then what is the purpose of having award.relatedBids if instead we could keep award.relatedBid and just refer to a group of lots?

[jpmckinney]

1. The EU is the only confirmed use case.

An award needs to refer to the winning bid(s), whether in OCDS or otherwise. There's a question as to whether these references need to be repeatable.

In the EU, the groups of lots must be stated beforehand, according to Art 36(3) of 2014/24/EU. In eForms, this is BG-330 ( Group Lot Award).

In terms of the result, in eForms, BG-7 (Notice Result) contains BG-310 (Contract), which contains BT-3202 (Contract Tender Identifier). BT-3202 is repeatable. This is also true in eForms' concrete implementation, as described in #125 (comment), where LotTender (a part of a bid) is repeatable within LotResult. BT-3202 refers to BG-320 (Tender) via BT-3201 (Tender Identifier). BG-320 contains BT-13714 (Tender Lot Identifier), which is not repeatable, i.e. a bid can be for a single lot or a single group of lots.

Note that, in TED XML, the description of the groups of lots is free text (/OBJECT_CONTRACT/LOT_DIVISION/LOT_COMBINING_CONTRACT_RIGHT), and the contract refers to the lot (/AWARD_CONTRACT/LOT_NO), with no support for groups of lots and no reference to bids at all.

Are you saying that BT-3202 should not have been repeatable?

2. We need to keep tender/lotGroups, as that is for describing the groups in advance (along with their maximum value, etc.). Whether awards and/or bids refer to groups of lots or lots is a separate question, which is the discussion above.

[JachymHercher]

1. Are you saying that BT-3202 should not have been repeatable?

No. In the eForms regulation, it is correctly repeatable for the reason stated at the end of #125 (comment). I've very slightly updated it, but I'm not sure I know how to explain it better in writing.

2. Ah, ok. I assumed it would be better to do it the same way in both cases, but it's true that might not necessarily be the case.

[jpmckinney]

Aha, so in eForms, there would be a 1:1 relationship between award and bid ("tender") and lot/group, but this relationship is not explicit, because the notice result instead focuses on the contract (which can itself combine awards and lots/groups).

This issue is becoming a bit of a all-consuming topic, so I'll continue after a line break.

---

In eForms, a bid can only be for a single lot or a single (pre-defined) group of lots. However, the concrete implementation decomposes a bid into parts, each corresponding to a lot of group of lots: https://docs.ted.europa.eu/eforms/0.6.0/schema/competition-results.html#lotTenderSection

At present, in OCDS, the bids extension has no such discussion. That said, its use of Bid.relatedLots suggests that a Bid
describes an entire submission, not each part corresponding to a lot/group. OCDS also has Award.relatedLots and (per this issue) Award.relatedBids.

If we were to simplify OCDS' bids and lots model, we could remove Award.relatedLots, and require the creation of a Bid object, even if it just contains an id and relatedLots. In that way, there would always be only one way to answer which lots an award relates to, rather than two (currently Award.relatedLots, and Award.relatedBids -> Bid.relatedLots).

If folks agree with that suggestion, please create a new issue, as it seems the least controversial change.

We could similarly require that bids always be decomposed per lot. Whether we do that at top-level (e.g. hundreds of Bid objects for one offer of medicine products) or at a second-level (e.g. hundreds of BidPart objects within a Bid object) will depend on what questions we want to be easiest to answer. (I suspect users want to be able to count the number of submissions, not the number of bid parts, for example.) As before, if all we know is that a bid is for 3 lots, but no more lot-specific details, then each BidPart object would just contain an id and relatedLot.

At this point, we'd have BidPart.relatedLot and no more Award.relatedLots. The remaining plural would be Award.relatedBids. However, this (if following eForms) refers to a BidPart, not a Bid. If we took the approach of nesting BidParts within Bids, then looping through each Bid and its BidParts to find a match would be annoying – plus BidParts would need to be identified uniquely across all Bids.

If we impose all these above constraints, we're left with many questions:

1. Are governments able to decompose bids into parts?
2. Do governments always award a single (part of a) bid at a time? Right now, the "Award" definition is loose enough to not require a 1:1 relationship here.
3. Do governments always define the groups of lots in advance? Do they never combine lots into groups after the submission deadline? (i.e. no pre-defined group)
4. Do bids always indicate the group, or do they sometimes only indicate individual lots (all of which may or may not relate to a group)?
5. If the previous scenario, if the bid would win the group of lots, but did not explicitly refer to the group (only the individual lots), is it then the eGP system's responsibility to reframe the bid as if it were explicitly for a group?
6. Does any of this contradict how the Bids extension is currently being used?

Right now, arrays make it so that we don't need to answer these questions, because all scenarios are supported. In order to limit the cardinality to 1, then we need to answer these questions.

[duncandewhurst]

@jpmckinney shall I create the issue proposed in your previous comment (it sounds good to me) or do you want to wait for more input?

[jpmckinney]

If we were to simplify OCDS' bids and lots model, we could remove Award.relatedLots, and require the creation of a Bid object, even if it just contains an id and relatedLots. In that way, there would always be only one way to answer which lots an award relates to, rather than two (currently Award.relatedLots, and Award.relatedBids -> Bid.relatedLots).

If folks agree with that suggestion, please create a new issue, as it seems the least controversial change.

@yolile @ColinMaudry What do you think? Do you have a sense of how many implementers it affects?

[ColinMaudry]

I have never worked on an implementation that included bids, so my experience is close to Jachym's: the French/EU/eForm way of doing things.

I think @jpmckinney implies in his last big comment (#125 (comment)) that we need

• unique IDs for BidParts
• these BidPart IDs to be used in Award.relatedBids

because otherwise, there is no way to know which part (lots or groups of lots) of the bid are successful. A tenderer bids on lot 1 and 3 (one bid, two parts), but they may only be awarded a contract for the part of their bid related to lot 1. But if a BidPart is evaluated as a whole, is a Bid with .relatedLots evaluated as a whole too, and thus rejected/awarded as a whole (not lot per lot)?

The way I see it, we have three main options, with their pros/cons:

1. only creating Award.relatedBids and deprecating Award.relatedBid: flexible model but difficult data analysis because hars to connect bids and lots (the initial issue reported by @yolile)
2. the above, plus:

• deprecating Award.relatedLots
• adding Bid.relatedLots
  Having a single place to connect bids and lots is a big pro, but doesn't it cause confusion in the case described above: the award says the bid is successful, but only one of the related lots actually is? (my understanding may be wrong, and a Bid with .relatedLots is rejected/awarded as a whole, not lot per lot)

3. we use an eForms-like model, where have two modelling approaches:
   1. each bid-lot relation is a Bid, which simplifies the award-bid relation, but may end up with many bids (the medicine scenario James mentions, I don't know how frequent/problematic it is)
   2. each bid has several BirdParts that are uniquely identified, but it will be annoying to parse each Bid.parts to match the values of Award.relatedBidParts)

[yolile]

Do you have a sense of how many implementers it affects?

Hmm I see that at least united_kingdom_wales, united_kingdom_fts, Netherlands, *_digiwhist, united_kingdom_scotland, moldova, italy_anac and Germany use Award.relatedLots

What do you think?

I think your proposal makes conceptual sense, as an award is made against a bid, not against a tender (and even in direct tenders I guess we could say the single tenderer made a bid)
Of course, having to create an additional object would create more complexity for publishers who don't have bids at all (and also, from the data user perspective, if you only check their data quickly you might believe they publish bids data, but in really they don't)

even if it just contains an id and relatedLots

And tenderers?