Open yolile opened 4 years ago
@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?
Can you get a quick statistic from OCDS Downloads on how frequently relatedBid is used?
It's used in all the digiwhist publications, plus:
Noting that there's no data available in OCDS Downloads for:
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?
In Paraguay, we use the bids extension and therefore the Award.relatedBid
field for auctions.
@jpmckinney based on the above, what do you think we should do?
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
.
Hmm, just remembered this discussion with @JachymHercher https://github.com/open-contracting/standard/issues/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.
Sounds good! I'll prepare a PR.
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.)
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 https://github.com/open-contracting/ocds-extensions/issues/182#issue-1232150827.
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:
schemeName
attribute to know whether ProcurementProjectLot is a group of lots or a lot. If it's a lot, they are done.In OCDS:
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)
?
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.)
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 https://github.com/open-contracting/ocds-extensions/issues/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.
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?
I am no closer to clarity :) This issue is closed. Could you please restate, as simply as possible, what your question or concern is?
Restating (still along the lines of https://github.com/open-contracting/ocds-extensions/issues/125#issuecomment-1123298116):
lotGroup
and https://github.com/open-contracting/ocds-extensions/issues/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? 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 https://github.com/open-contracting/ocds-extensions/issues/125#issuecomment-1129386289, 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?
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.
- 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 https://github.com/open-contracting/ocds-extensions/issues/125#issuecomment-1139444088. I've very slightly updated it, but I'm not sure I know how to explain it better in writing.
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:
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.
@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?
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?
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 (https://github.com/open-contracting/ocds-extensions/issues/125#issuecomment-1141526626) that we need
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:
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)Award.relatedLots
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)Bid.parts
to match the values of Award.relatedBidParts
)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?
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 toAward.relatedBids
and become an array instead of a string.cc @jpmckinney