Planning processes and parts eForms/OCDS

[adamssonj]

I have some questions regarding how eForm planning notices are to be modeled in OCDS, and how it fits in to the road map going forward.

• The recommended way of handling "Parts" is to create a separate release per part and have them in separate records (ref). Is this simply because the semantics of the OCDS lot aren't fit to represent an eForm Part? How does this relate to the proposal of deprecating fields on the tender level in favor of their lot equivalent (Merge Lots extension open-contracting/standard#891). E.g. will the meaning of a lot change in OCDS, such that a planning process may have "lots" and store fields such as enquiryPeriod.endDate? Would be interesting if there's more to read on the topic, and if there are any plans going forward.

• Let's say there's two parts of an eForm notice. Is the idea to model that as only two releases? If so, wouldn't there be an information loss of the data stored on the procedure level ('ProcurementProject'), that could be valuable? At least for those fields that are overwritten by Parts. I suppose e.g. tender.communication.futureNoticeDate is replicated across releases. And changes/amendments (e.g. enquiries) relevant for all parts would (in the naive approach) be replicated for each record as well?

• The suggested mapping of BT-1251-Lot seems wrong, or perhaps I have misunderstood. Shouldn't the ReferencedDocumentInternalAddress refer to a part (e.g. PAR-0001) on the notice referenced by the identifier, and the relatedLots be populated with the identifier of the ProcurementProjectLot (e.g. LOT-0001) under which we are mapping.

[jpmckinney]

Good questions.

Parts of planning notices

First: A lot is not a part. In fact, a part can contain many lots.

It's important to remember than eForms continues in the tradition of paper notices, that are ultimately published in the EU's official journal, which also has heavy influences from paper-based processes. In this tradition, it makes sense to limit the number of notices where possible. As such, the prior information notice (PIN) is a very flexible planning notice, that can be used, for example, to describe an entire government unit's annual procurement plan (at maximum). Each part of the PIN can be made up of one or more lots. In general, a single PIN is followed by one or more contract notices (CNs), often one for each part. The CNs can be published at different times, each following up on different parts of the PIN.

In a digital system, there is no advantage to combining different "parts" into one notice. And in the real world, there is hardly much advantage to combining the parts, either. Instead of having two possible hierarchies like in eForms:

• Planning notice → one or more parts → one or more lots
• Non-planning notice → one or more lots

OCDS instead has only:

• Contracting or planning process → one or more lots

Lots

We can continue the discussion in the linked issue. In brief: The meaning of "lot" will not be changing, and the proposal is in alignment with eForms (eForms always has at least one "virtual" lot in every notice).

Procedure-level information

The information would be repeated across releases. As such, there would be no information loss. If you notice any information loss in the mapping, please let us know specific examples.

BT-1251-Lot

Indeed, this seems incorrect. cc @duncandewhurst

[duncandewhurst]

I agree that BT-1521-Lot is a reference from a lot to a part. I'll prepare a PR to update the mapping.

I think we'll also need to update the mapping for BT-125(i)-Lot to add the identifier of the lot from which the reference is made to relatedProcesses.relatedLots.

[adamssonj]

Very interesting, thank you for the background.

Regarding the procedure-level information, and information loss. I believe for example the below business terms cannot coexist on the same release.

• tender.title: BT-21-Procedure & BT-21-Part
• tender.description: BT-24-Procedure & BT-24-Part
• tender.value: BT-27-Procedure & BT-27-Part
• tender.items.classification: BT-262-Procedure & BT-262-Part

E.g. if we have this shortened eForm:

<PriorInformationNotice>
<cac:ProcurementProject>
  <cbc:Name languageID="ENG">Some title of the procedure</cbc:Name>
</cac:ProcurementProject>

<cac:ProcurementProjectLot>
  <cbc:ID schemeName="Part">PAR-0001</cbc:ID>
  <cac:ProcurementProject>
    <cbc:Name languageID="ENG">Part title 1</cbc:Name>
  </cac:ProcurementProject>
</cac:ProcurementProjectLot>

<cac:ProcurementProjectLot>
  <cbc:ID schemeName="Part">PAR-0002</cbc:ID>
  <cac:ProcurementProject>
    <cbc:Name languageID="ENG">Part title 2</cbc:Name>
  </cac:ProcurementProject>
</cac:ProcurementProjectLot>
</PriorInformationNotice>

I understand it as it would result in these two releases

{"tender": {"title": "Part title 1"}} and {"tender": {"title": "Part title 2"}}

So the title of the procedure is lost

[jpmckinney]

True – perhaps we can concatenate the titles and descriptions. @duncandewhurst

I'm not sure in what scenario the procedure's value and main category are relevant (when using a multi-part PIN). To preserve these, we would need to add a new object to describe the procedure (this would be an EU-specific object).

[duncandewhurst]

True – perhaps we can concatenate the titles and descriptions. @duncandewhurst

Concatenation sounds good, but for the procedure title, we could use the process-level title field from the process-level title and description extension (BT-300-Part and BT-300-Procedure already map to the process-level description).

[jpmckinney]

Ah, great!

[duncandewhurst]

PR to concatenate descriptions and map titles to separate fields: open-contracting/european-union-support#248

[jpmckinney]

I've noted our changes at https://standard.open-contracting.org/profiles/eforms/latest/en/changelog/

I think we've now addressed all except:

tender.value: BT-27-Procedure & BT-27-Part
tender.items.classification: BT-262-Procedure & BT-262-Part