-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
partyRole: Change definition of 'funder' and/or 'buyer' #825
Comments
The 'funder' code was added in this commit 6989523 following from the discussion in #368 as part of the development of OCDS 1.1. However, a 'funder' role wasn't discussed in that issue, and has no precedent in OCDS – whereas the other roles at the time had a related field pointing to an organization in that role (and those field descriptions were re-used in the code descriptions). I can actually find no discussion whatsoever about the 'funder' role, so it seems to have slipped in unnoticed without review. While I have used it in the draft OCDS for EU work, it is not used in any other extensions, so one option is to deprecate it – and I can pursue an alternate modelling in OCDS for EU for EU-funded processes. The other option is to improve the descriptions in order to disambiguate the two roles. It's not clear to me that the definition of a buyer depends much on budgeting concerns; changing that will require changing the field description as well. |
Ok, thanks. For reference, I got into this subject when working on eForms/eForms#85 (comment) (and eForms/eForms#285 (comment)). (In eForms, we define "buyer" by referring to the legal terms such as "contracting authority". It is unavoidable, because notices have legal value and need to be 100% precise on this point, but doesn't really help with re-usability, because the definitions are very complex. Depending on the needs of other OCDS users, perhaps it might be useful to add something like "Party which is obliged to run public procurement procedures according to the local legislation." in one of the PartyRole descriptions.) |
Hi there, 'funder' may be relevant in cases where eg the World Bank is providing the funding for the contract (rather than government budget). |
We have other means of modelling various funding/financing relationships, none of which use this party role (the Financing extension has a Anyhow, we can keep the 'funder' role, but it requires changes to the 'buyer' role (and field). |
That would be the buyer since it is a central role in OCDS, with its own field at the top of release and usually the only buying party. |
We have used the 'funder' role in the EU guidance in a single case: to support the following form field (it's common across the forms):
Its implementation requires no extension |
This is the current (OCDS 1.1) description of buyer:
If we remove the budgeting part, there isn't much remaining. My feeling is that a buyer in OCDS is, by default, a combination of several roles, since it's the default role:
Proposalsa) For maximum accuracy, we remove the empty (semantically) "buyer" role and force publishers to use specific roles ("procuring entity", "funder", "payer", "legally bound entity", etc.). b) Alternatively, if we want to keep a default "buyer" role, it could be a compound role and its description should reflect its versatility:
This option gives room to ambiguity (what if party A is buyer and party B is procuring entity?), but it clarifies the situation and is in line with current usage. |
@ColinMaudry See also #903 (comment). Can you also have a look at the glossaries, etc. mentioned in #827? Since we will be doing a lot of lookups into these other glossaries, we might want to put together a comparison table. |
Regarding your proposals: a) The concept of a 'buyer' is a commonly needed concept, even if the entity it references might have different other roles in different contexts. So, we shouldn't do this option. While working on this issue, we should also update the description of the |
From the @eprocurementontology mailing list:
|
Hello, we at PODER are mapping from a government source, so for buyer we are using the procuring entity (unidad compradora), with a memberOf field that expresses the bigger institution to which it belongs (such as a ministry). And while the money for all contracts in our dataset is from the federal government and some times the institutions are from state and city level governments, we don't fill funder for those cases. Funder is a field that is only filled if there's an international bank such as IDB involved in the contract. An issue that has arisen from this structure is that it's sometimes hard to filter for parties. In the case of funders, the only place in which they appear is in the parties array, and the only way they can be filtered is from the roles array, this is not ideal because it forces the parser to grab the whole parties array and then filter it, instead of just grabbing one field, as one can do with the This is just an example of a bigger problem with storing JSON in databases, as we are doing, that is why we now have an alternate representation of OCDS in our database, that is still very close to the standard, but has a few advantages, such as that it's easier to find things while using Kibana and it's more easily flattened. Here's an example document for a release: https://gist.github.com/martinszy/36f501806547e7bf14550f4fe3910568 As you can see, there's no object arrays, only string arrays, and there's a named field for funders. This is particular to our case, in which we don't have multiple awards or multiple contracts in a single document, but I still share it here because I think it may be useful to show the adaptations that we needed to do. |
GeneralWe can group the "needs" / "use cases" into three levels:
The first two are based primarily on "who they are" (often based on legal definitions), the third is rather "what they do" (often based on real world actions). Judging from the EU, I think most systems work on the first two levels, because that's the way the legislation is written, people are used to it, and requirements it puts on manual data input. However, I think systems sometimes "dip" into the third level, but less for "analytical" purposes and more for "practical" purposes such as "who do I actually send my tender to", "who do I actually send my questions to", etc. In eForms, we try to cover the first two levels by organisation role, while giving the possibility to go into the third level with organisation subrole. ProposalTo solve the main issue in this ticket, I think we should:
RelatedThere are several issues related to these definitions (possibly worth moving into new issues):
|
0.2% of parties have the "funder" role when we last checked, so OK to deprecate.
I've opened open-contracting/ocds-extensions#157 and open-contracting/ocds-extensions#158
This seems fine to me. I'll open new issues for some of the related concerns. |
I created #1156 for
I didn't create issues for this, but issues can be opened if there is demand. For mediator, the OCDS for EU profile adds 'mediationBody', which can be promoted to the standard: https://github.com/open-contracting-extensions/ocds_eu_extension/blob/master/codelists/%2BpartyRole.csv |
Definitions used by Peppol:
Definitions used by UBL:
Ours:
I prefer that ours refers to a contract, rather than the verbs "buys or purchases". Also the above make it seem like the buyer and customer/originator are necessarily different, whereas we know they can be the same. |
Considering the following Party Role's definitions,
I'm struggling a bit to understand the difference. Isn't funder just a sub-category of buyer? Or is the important difference that the buyer pays for the "goods, works or services" while the funder pays for the "contracting process"? There may be some scope for clarification/alignment of terminology.
The text was updated successfully, but these errors were encountered: