Lots: List fields with different semantics between tender and tender.lots

[duncandewhurst]

From open-contracting-extensions/ocds_lots_extension#40 (comment):

The cases where information could potentially go in one or the other is when the information is the same for all lots. For example, it's possible all bids for all lots are always opened at the same time in some jurisdiction. However, globally, we know that the bid opening information can differ per lot (hence the addition of that field). In that scenario, the guidance is to put it on the lot to have a single standardized location for that information, at the expense of duplication across lots. (The field on tender is thus essentially deprecated).

Other than value, there might be others where the semantics are different. If we want, we can perhaps list these and explain that their semantics are different and that the usage guidance therefore doesn't apply to them.

[odscjen]

field	Lot extension	Core 1.2 (in tender)	semantic diff?
status	The current status of the process related to this lot.	The current status of the tender, from the closed tenderStatus codelist.	yes? process is the contracting process, tender is a stage in the process. If the tender description is updated to refer to the "opportunity" think this will still be semantically different.
finalStatus	The final status of the lot, using the closed tenderFinalStatus codelist.	The final status of the tender, using the closed tenderFinalStatus codelist.	no
finalStatusDetails	Additional details on the final status of the lot. This field  can be used to provide the local name of the final status.	Additional details on the final status of the tender. This field  can be used to provide the local name of the final status.	no
finalStatusDate	missing	The date on which the tender reached its final status.	NA
value	The maximum estimated value of this lot.	The estimated value of the procurement, as estimated when publishing the tender information. A negative value indicates that the future contract(s) may involve payments from the supplier to the buyer (commonly used in concession contracts).	yes, lot states maximum, tender doesn’t
minValue	The estimated minimum value of the lot. A negative value indicates that the contracting process may involve payments from the supplier to the buyer (commonly used in concession contracts).	The estimated minimum value of the procurement. A negative value indicates that the contracting process may involve payments from the supplier to the buyer (commonly used in concession contracts).	no
tenderPeriod	The period when this lot is open for submissions. The end date is the closing date for bid submissions	The submission period for bids. Depending on the procedure, a bid can be an estimate, offer, proposal, quote or quotation, but not an expression of interest or request to participate.	no?
contractPeriod	The period over which the contract is estimated or specified to be active. If the lot does not specify explicit dates, the duration field can be used.	The period over which the contract is estimated or specified to be active. If the tender does not specify explicit dates, the duration field can be used.	no
buyer	The organization aiming to conclude a contract with a supplier or to use the goods, works or services in this lot. This may be different from the procuring entity who may be specified in the tender data.	(not in tender, at release level.) The organization aiming to conclude a contract with a supplier or to use the goods, services or works resulting from the contract.	no, although does have some additional specificity
additionalClassifications	Additional classification for this lot	doesn’t exist in tender, only in tender.item“Additional classifications for this item”	NA
mainProcurementCategory	The primary category describing the main object of this lot, using the closed procurementCategory codelist	The primary category describing the main object of this contracting (or planning) process, from the closed procurementCategory codelist.	no? the lot is not the process BUT in terms of the guidance and how this would be used there's no difference, having a single virtual lot with lots.mainProcurementCategory = "goods" would be interpreted as the same as tender.mainProcurementCategory = "goods"
additionalProcurementCategories	Any additional categories describing the objects of this lot, using the open extendedProcurementCategory codelist.	Any additional categories describing the objects of this contracting (or planning) process, using the open extendedProcurementCategory codelist.	yes? tender refers to the whole process
enquiryPeriod	The period during which potential bidders may submit questions and requests for clarification about this lot to the buyer or the procuring entity.	The period during which potential bidders may submit questions and requests for clarification to the buyer or the procuring entity.	no
milestones	Milestones associated with this lot	Milestones associated with the tender: for example, the date on which responses to enquiries are published.	no
submissionMethodDetails	Information about the methods by which bids are submitted for this lot. This can include the address, e-mail address or online service to which bids are submitted, and any special requirements to be followed for submissions. More structured information can be provided using the submission terms extension.	Information about how to submit bids. This can include the address, e-mail address or online service to which bids are submitted, and any special requirements to be followed for submissions.	no
submissionTerms	Information about how, when and where tenderers need to submit their bids.	Information about how, when and where tenderers need to submit their bids.	no
maximumValue	lotGroups - The maximum estimated value of the lots in this group. This can be lower than the sum total of the lot values.	The estimated maximum value of the framework agreement, as estimated when publishing the tender information.	yes

So Lot.value, Lot.status and LotGroup.maximumValue are all semantically different in such a way that the guidance to use a virtual lot in place of tender doesn't apply.

[jpmckinney]

Hmm, the comments about semantic difference in #40 were concerning this new paragraph in the guidance (note: "Usage guidance" in that issue refers to the "Guidance" section of the readme):

If a contracting process is not divided into lots, then you should nonetheless add a single, virtual lot. If a data element can be mapped to either a tender field or a tender.lots field, you should map it to the tender.lots field. In this way, information is accessible at the same location for all contracting processes, regardless of whether the process is actually divided into lots.

When I wrote:

Other than value, there might be others where the semantics are different. If we want, we can perhaps list these and explain that their semantics are different and that the usage guidance therefore doesn't apply to them.

I meant to say "tender.value is the estimated value of the procurement (i.e. greater than any individual lot). Lot.value is the estimated value of the lot. These mean different things, because one refers to the procurement and the other refers to the lot. Therefore, the relevant data element from the data source cannot possibly be mapped to either one or the other. It can only be mapped to one." It is not just the fact that lot mentions "maximum".

So, for example, the status fields are semantically different. The readme even has a section to explain the difference.

Here's the issue: In OCDS, there are no lots. If we had added lots to OCDS from the beginning, some fields on tender might not exist today. Some might only be there today, because they had to go somewhere.

The guidance "you should nonetheless add a single, virtual lot" is about encouraging publishers to implement OCDS as if we had added lots to OCDS from the beginning. To do that, we either need:

• A list of fields that don't belong on tender
• A list of fields that do belong on tender (because they mean something different)

The second option is what I was discussing in my quoted comment. But, it might be the case that the first option is simpler or clearer. From a very quick assessment:

Lists left in tender, and used via relatedLot(s):

• items
• documents
• milestones
• amendments

Fields that do belong on tender:

• id
• identifiers
  • source systems refer to the contracting process separately from the lot
• title
• description
  • source systems typically summarize the contracting process as a whole, separately from lots
• status
• finalStatus
• finalStatusDetails
• finalstatusDate
  • per the guidance, the status here summarizes the status of the lots
• procuringEntity
  • it's expected for this to always be the same for all lots (not sure if/when it differs – that's usually about buyers instead)
• value
• minValue
• maximumValue
  • the value of the contracting process is greater than or equal to the value of the lots
• procurementMethod
• procurementMethodDetails
• procurementMethodRationale
  • it's expected for this to always be the same for all lots, unless I'm forgetting something
• mainProcurementCategory
• additionalProcurementCategories
  • source systems typically categorize the contracting process as a whole, separately from lots
• datePublished
  • the notice is for the contracting process, not the lots

And that don't belong on tender:

• eligibilityCriteria (deprecated)
• selectionCriteria
• awardCriteria
• awardCriteriaDetails
  • Qualification and evaluation is done per lot, not for the contracting process as a whole
• submissionMethod (deprecated)
• submissionMethodDetails
• submissionTerms
• numberOfTenderers
• tenderers
  • Bidders submit per lot, not for the contracting process as a whole
• expressionOfInterestDeadline
• tenderPeriod
• enquiryPeriod
• awardPeriod
• standstillPeriod
• contractPeriod
  • Lots can have different timelines
• many extensions (bid opening was mentioned in the issue, for example)

Unclear or unknown, but probably don't belong on tender:

• exclusionGrounds
  • Exclusion grounds tend to be fairly universal, but maybe they can differ per lot.
• hasEnquiries
  • I don't know, but I assume this can differ per lot.

For all this, it'd be very useful to compare to eForms, to see where fields are allowed on both the procedure and lot, or only on one or the other (i.e. the -Procedure and -Lot suffixes to field names).

---

Something that can lead to confusion is that, in some jurisdictions, some fields might never differ across lots in any contracting process (e.g. maybe a jurisdiction never has a contracting process for multiple framework agreements, and so Lot.techniques is useless repetition). I don't know if we want to special-case that. Maybe it's a point for consultation.

---

The current status of the process related to this lot.

I think this is badly worded (from the very first version of the extension). In any case, it will be deprecated in favor of finalStatus, etc. open-contracting-extensions/ocds_lots_extension#51