F03 section V mapping for awards involving the establishment of a framework agreement

[duncandewhurst]

The instruction given in the EU profile is to add both an award and a contract object.

This conflicts with the revised guidance on framework agreements in 1.1.5, which recommends that only the awards section is populated for the first stage of a framework agreement procedure.

Edit: If a contract object isn't used for framework agreements, then we'll need to decide how to map /AWARD_CONTRACT/AWARDED_CONTRACT/DATE_CONCLUSION_CONTRACT, /AWARD_CONTRACT/AWARDED_CONTRACT/VALUES and what to put in .tag

[jpmckinney]

Is there a conflict?

In the revised guidance, we haven't concerned ourselves with the lifecycle of the framework agreement as its own contract. We haven't done this, because most jurisdictions have little to no information about the FA as a contract. (That said, the EU has very little, too.)

If we were to change the profile's guidance, we could:

• Put only 'award' in the tag
• Map the date to the award's date – though this isn't quite correct, since eForms clarifies that this field means "The date when the last contractual party signed the contract."
• Map the value to the award's value – though this isn't any more or less correct than mapping to the contract's value. In both cases, in the case of an FA, it means the maximum value which can be spent on specific contracts, not the value obligated to be spent on specific contracts. (eForms separates the semantics into two fields: https://github.com/eForms/eForms/issues/32)

I don't think there's an inconsistency with the revised guidance. And, per above, only populating the award object might be less correct.

That said, I think the revised guidance should continue to limit its discussion to the awards section, as it's a simpler approach.

[ColinMaudry]

I agree with James.

I think having slightly diverging guidance for data publishing and data conversion from other established standards (TED, GPA, eForms) isn't being inconsistent.

These others standards may have made different design and regulatory choices, and we need to support the OCDS adopters who adhere to these standards in the translation of their data to OCDS. In the context of this translation, these design choices are ported to OCDS, as the continuity of the data semantics weighs more than the compliance to OCP guidance.

OCDS is one ("the best!" @LindseyAM) of these standards, and as such we make our own design choices based on the feedback we get from the field, hence the choices made for the first stage of a FA. Whether an OCDS adopter follows OCP guidance or another depends on the history of their data and their vision for the future.

[duncandewhurst]

Thanks both, that makes sense. @ColinMaudry I look forward to reusing your explanation!

In the EU example used in the revised frameworks guidance we'll focus on conforming to the frameworks guidance even if that diverges slightly from the guidance in the EU profile:

• populate awards but not contracts
• map the value to awards.value since the description in the schema states that:

In the case of a framework contract this may be the total estimated lifetime value, or maximum value, of the agreement

• don't map the date, since it is the date the contract was concluded rather than the award date

[jpmckinney]

Sounds good to me. Can you give Colin access to the Google document?