Add more synonyms to various field descriptions

[jpmckinney]

Background

In at least the EU, design contests use a different set of terms:

• contract -> prize
• bidder -> participant
• supplier -> winner
• tenders (bids) -> projects
• (award period) -> ’date of jury decision’

For other procedures:

• award -> result of procedure

Proposal

The alternative terms can be added in field descriptions to make it clear that the fields are appropriate for design contests as well as other procedures.

[jpmckinney]

Background

More broadly, OCDS uses buyer and suppliers, but these terms are inappropriate for many contracting processes, like design contests (above), public private partnerships, government asset sales, concessions, etc.

In the OCDS for PPPs profile, to address this, buyer and suppliers are deleted from the schema in favor of publicAuthority and preferredBidders (though 'privateParty' is also used).

In the EU, to address this, the more generic terms 'contracting authority' or 'contracting entity' (the distinction is irrelevant from OCDS' perspective) are used instead of 'buyer'. At the UI level, the EU changes its term on forms from 'contractor' to 'concessionaire' ('supplier' in OCDS), but the TED data uses CONTRACTOR for both.

Proposal

Rather than multiplying the fields used to identify the two parties, I think it's better to (1) accept we chose less-than-ideal terms and then (2) change the titles/definitions to broaden their scope though ideally in limited ways, e.g. "If this contracting process is to award a concession, then the buyer is X. If this contracting process it to sell government assets, then the buyer is Y, etc."

We can of course deprecate the old term and add a new term.

From a data use perspective, you would typically narrow the processes to those you care about first (concessions, asset sales, procurements, etc.), then look at the buyers and suppliers (whose semantics are then narrowly scoped). A broader analysis might still want to know e.g. "which government agencies are doing some sort of business with external parties" in which case it's much easier to look for the answer in a pair of fields instead of a growing number of fields, and in which case the broader semantics are acceptable (even desirable).

[ColinMaudry]

Looking at eForms annex spreadsheet, I'm not sure contract -> prize.

BG-44 mentions ranks, and BT-41 says the winners of a contest aren't necessarily awarded all contracts, implying prizes and contracts are not bound.

[jpmckinney]

In a design contest, my understanding was that participants were at most awarded a prize – but that, following the contest, they might be awarded a contract. Does it work differently?

[ColinMaudry]

(21) | ‘design contests’ means those procedures which enable the contracting authority to acquire, mainly in the fields of town and country planning, architecture and engineering or data processing, a plan or design selected by a jury after being put out to competition with or without the award of prizes;

I agree that some participants are awarded a prize. I don't think all participants to a contest are awarded a prize.

But what is a prize? I don't think it's a contract, in the directive it's always used alongside 'payment'. It may be a monetary or in-kind reward, but it does not seem to bind the winner to the provision of a service/goods. Which makes it quite different from a contract.

Is that your opinion too?

[jpmckinney]

Not all bidders are awarded a contract either :)

A prize is certainly different from a contract. The question here is whether contracts in OCDS should simply mean "Result of the procedure", in which case it applies to both prizes and contracts (related #896), or whether it should just mean a narrow definition of contract.

I prefer the former, because having lots of different fields/classes to represent the result of a procedure seems like it makes a lot of use cases harder, instead of finding another way to differentiate the different types of results.

[jpmckinney]

Taking a step back, do design contests even need to use the contracts section? It might be simplest to just not have any contracts for design contests.

[ColinMaudry]

because having lots of different fields/classes to represent the result of a procedure seems like it makes a lot of use cases harder

It's the Open Contracting Data Standard, design contest prizes are an edge case, but I believe we'll mostly deal with contracts. If not, we may be stretching the scope of OCDS a bit too far :) Narrow definition of contract is good.

Taking a step back, do design contests even need to use the contracts section?

(120) [...] The design contest used to acquire the plans for such financial engineering could also stipulate that the subsequent service contracts for the realisation of this financial engineering would be awarded to the winner or one of the winners of the design contest by a negotiated procedure without publication.

There is this case where the prize is automatically followed by a procedure. Do we represent this procedure as a distinct but related procedure (relatedProcess)? That would work, and it may be another occasion to use the prev code 😉

[jpmckinney]

I agree that it would be a case for relatedProcesses; however, we might want a more specific code (e.g. designContest).

[JachymHercher]

A prize is certainly different from a contract. The question here is whether contracts in OCDS should simply mean "Result of the procedure", in which case it applies to both prizes and contracts (related #896), or whether it should just mean a narrow definition of contract.

To add an extra twist: public administrations being public administrations, I have always assumed (never really verified) that awarding any prize money would require a signed contract between the buyer and the winner. In the EU, this contract would not be a "public contract" in the sense of public procurement law, but it would still be "contract" in the broad legal sense and being between a public body and a company, I'd think it should fall within the scope of OCDS. It would use Contract fields such as Title, Value and dateSigned.

[jpmckinney]

@JachymHercher Agree, that makes sense to me.

[JachymHercher]

Going back to #903 (comment), two comments:

• I fully agree it is better to have synonyms in descriptions rather than new fields. The changes you mention in OCDS for PPPs seem like to me like going in the wrong direction.
• I went through the terminology section of the eForms legal act and looked for more clarifications/synonyms which might be useful for the OCDS. It was significantly less useful than I expected - most of it is unnecessarily detailed. I would consider just the top two from the list below (I'm sharing the whole list in case you see things differently).

  • 'Party' / ‘Organisation’ -> can be a legal person, a natural person or a public entity (in some jurisdictions, public entities are distinct from legal persons).

  • ‘Supplier’ -> can be a contractor, "successful tenderer party to a framework agreement", or "winner of a design contest". As long as the definition of contract in Clarify Contract description #896 (comment) clearly covers design contests and framework agreements, I think this does not need to be covered in individual definitions.

    However, in the current definition of "An entity awarded or contracted to provide goods, works or services.", I'm wondering whether "awarded or contracted" isn't an unnecessary duplication.

    As long as the definition includes "awarded", if a buyer awards a contract to supplier A, then supplier B goes to court, then a new award goes to supplier B, you have two suppliers (as long as the original award isn't cancelled, but just doesn't lead to a contract). I'm not sure this is ideal.

    On the other hand, since OCDS only has 'suppliers' in Award, perhaps "awarded" needs to stay as the centrepiece. However, it might be clearer if "contracted" stems out of "awarded", something like "An entity to which the buyer or procuring entity has decided to award a contract".

  • (‘Buyer’ -> can be a contracting authority, a contracting entity, a defence contractor, an international organisation, or an organisation awarding a contract subsidized by a contracting authority. I think most of this is unnecessarily detailed and does not need to be reflected in partyRole: Change definition of 'funder' and/or 'buyer' #825, as long as we keep the definition general enough.)

  • (‘Contracting process' -> can be a design contest. (Already covered through the definition of contract, see above.))

  • ('Bid' -> EU law calls it a 'tender' and (in case of design contests) a 'project', but I would say 'bid' is clear enough and doesn't need to be reflected in a definition.)

  • (‘Request to participate’ -> EU law calls it (in case of concessions) an 'application', but my feeling would be that this distinction is not that crucial.)

[jpmckinney]

The changes you mention in OCDS for PPPs seem like to me like going in the wrong direction.

Yes, we are reversing those changes (originally made in 2017: open-contracting-extensions/public-private-partnerships@25c06b4), in this new issue: open-contracting-extensions/public-private-partnerships#236

I agree that the last four do not clarify much, so we don't need to add those synonyms to the schema. That said, we could use "project" and "application" if we add some design contest-specific or concession-specific guidance.

'Party' / ‘Organisation’ -> can be a legal person, a natural person or a public entity (in some jurisdictions, public entities are distinct from legal persons).

Hmm, could you have a look at #883, @JachymHercher? Right now, we only carve out a small exception for "natural person" in the case of a sole trader.

However, in the current definition of "An entity awarded or contracted to provide goods, works or services.", I'm wondering whether "awarded or contracted" isn't an unnecessary duplication.

As long as the definition includes "awarded", if a buyer awards a contract to supplier A, then supplier B goes to court, then a new award goes to supplier B, you have two suppliers (as long as the original award isn't cancelled, but just doesn't lead to a contract). I'm not sure this is ideal.

On the other hand, since OCDS only has 'suppliers' in Award, perhaps "awarded" needs to stay as the centrepiece. However, it might be clearer if "contracted" stems out of "awarded", something like "An entity to which the buyer or procuring entity has decided to award a contract".

Could you open a new issue about the description of supplier? I'm also not clear what you mean by "stems out" in your last sentence.

[JachymHercher]

Summary: I would suggest changing the last sentence of the Contract description to "Contracts are used in public procurement, concessions, public-private partnerships and sales of government assets, as well as governing the granting of prizes or other rewards (e.g. a follow-up contract) resulting from a design contest." and closing this issue.

---

Reviewing this ticket, I think it is best to go back to @jpmckinney's original proposal (first two comments), which was to add synonyms in the descriptions of certain terms to cover OCDS use-cases outside the most classical one - public procurement (e.g. by adding phrases such as "If this contracting process is to award a concession, then field X is Y.").

Here is a list of fields mentioned in this issue as candidates for changes and their descriptions.

• Contract - "Information regarding the contract, typically between the buyer and supplier. This includes contracts describing all the contractual conditions (e.g. item, quantity, price, payment terms, time and place of delivery), as well as contracts only describing the general contractual conditions (such as a framework agreement) and those only describing the specific contractual conditions (such as a contract within a framework agreement). Communication between contractual parties that consists of minor specifications of conditions agreed previously (e.g. specifying the time or place of delivery) is not considered a contract. Amendments are considered as part of the contract that is being amended. Contracts also govern the granting of prizes or other rewards (e.g. a follow-up contract) resulting from a design contest.", (source).
• "Contracting process" - "All the actions aimed at concluding one or more contracts. [...] (source)
• Award - "Decision by the buyer or procuring entity on the supplier with whom it intends to conclude a contract, including the items the supplier should supply and their price. Typically, this decision leads to a contract, but not always (e.g. the award is appealed at court or the supplier refuses to sign the contract). [...]" (source).
• 'buyer' - "The organization aiming to conclude a contract with a supplier or to use the goods, works or services resulting from the contract." (source).
• 'supplier' - "An organization with which a buyer or a procuring entity decided to conclude a contract." (source).
• 'tenderer' - "All entities who submit a tender."

The use cases considered in this issue (so far) beyond public procurement are design contests, concessions, PPPs and government sales assets. In my opinion:

1. We only need to consider changes to Contract, because all the other definitions refer to Contract sufficiently for changes in the meaning of contract to transfer to the other concepts.
2. In principle, the status quo would already be ok: Contract explicitly mentions that it also covers design contests, while concessions, PPPs and government asset sales are contracts "obviously". (E.g. because legally speaking contracts are any agreements, it's mentioned in the law, it's the way wikipedia talks about it.)
3. That being said, I think we should still make it more explicit. I would suggest changing the last sentence of the Contract description to "Contracts are used in public procurement, concessions, public-private partnerships and sales of government assets, as well as governing the granting of prizes or other rewards (e.g. a follow-up contract) resulting from a design contest."
4. Specifically, I don't think we need to mention that buyers can be public authorities; bidders can be participants; suppliers can be concessionaires and winners; tenders can be projects; award periods can be date of jury decisions; awards can be results of a procedure. The main arguments are that simple is better and adding these conditions would confuse people; that it would be hard to keep them consistent across all OCDS fields; that many of them might be English-specific; and that they are not being used as labels in IT systems anyway, so they need to be logically correct, but do not necessarily need to contain "the most frequently used" synonyms.

Besides the above, the rest of the discussion in this issue resulted in separate issues, so we don't need to cover it here:

• Legal persons are being discussed in Add a class for natural persons #883.
• The definition of supplier is being discussed in Supplier - definition ("awarded or contracted") #1149.
• Additionally, I've newly opened Replace "submit a tender" with "submit a bid" #1230.

[jpmckinney]

I'm happy to focus on that last change and then close the issue. Original proposal:

Contracts are used in public procurement, concessions, public-private partnerships and sales of government assets, as well as governing the granting of prizes or other rewards (e.g. a follow-up contract) resulting from a design contest.

"Granting" can be understood as a specific type of process/contract (e.g. grants to charities), so I'd prefer another word or phrasing. Could this work?

Contracts are used in public procurement, design contests, concessions, public-private partnerships, and government asset sales.

In other words, is it critical to specify follow-up contracts and prizes as specific rewards from design contests?

Update: I guess we might want to make clear that this is not an exhaustive list. We can add, "among other contexts" or similar at the end.

[JachymHercher]

I agree with your comments, but on second thought, I would modify my original proposal. I think the sentence is more about the use of OCDS rather than uses of contracts as such. Consequently, wouldn't it fit better as the first or last sentence of the schema description (latest version in 588097f#diff-8ede12936d49b6f0107d60beaef0abe845f548e91d78acc0c430cf6c1516d183)? For example like:

"Open Contracting Releases are used for contracts in public procurement (incl. design contests), concessions, public-private partnerships, government asset sales and other contexts."

If we went this way, I would leave the clarifying sentence on "prizes or other rewards (e.g. a follow-up contract)" in the definition of contract (just replace "granting"), as it clarifies the use of contracts.

[jpmckinney]

Yes, that sounds like a better proposal!

[JachymHercher]

I agree with your comments, but on second thought, I would modify my original proposal. I think the sentence is more about the use of OCDS rather than uses of contracts as such. Consequently, wouldn't it fit better as the first or last sentence of the schema description (latest version in 588097f#diff-8ede12936d49b6f0107d60beaef0abe845f548e91d78acc0c430cf6c1516d183)?

For example like:
"Open Contracting Releases are used for contracts in public procurement (incl. design contests), concessions, public-private partnerships, government asset sales and other contexts."

Done in 76413ea.

---

If we went this way, I would leave the clarifying sentence on "prizes or other rewards (e.g. a follow-up contract)" in the definition of contract (just replace "granting"), as it clarifies the use of contracts.

Done in e93fe10.

Consequently, once #1216 and #1208 are merged, this issue can also be closed.

[jpmckinney]

Agreed. Okay to close after #1216.