Open stevieflow opened 2 years ago
stevieflow
commented
1 year ago @markbrough I think this is largely implemented, but we might now want to tie up some loose ends : eg get this listed in https://codelists.codeforiati.org/Sector/ , for example?
markbrough
commented
1 year ago Hmm yeah this is a good question... do we want to list all these codes on codelists.codeforiati.org @andylolz ?
markbrough
commented
1 year ago (It would be nice more generally to have a nice big list of organisation identifiers and organisation names that we could reconcile data against...)
stevieflow
commented
1 year ago do we want to list all these codes on codelists.codeforiati.org
I'd recommend so - which would be a case of setting up a new updated on https://github.com/codeforIATI/codelist-updater to pull the csv/json ?
I think this would tie up things nicely
to have a nice big list of organisation identifiers and organisation names that we could reconcile data against
also agree - but one step at a time !
Rationale
There is no common or standard format to identify recipient governments, and their subsequent agencies, ministries and/or sub-divisions. The OECD-DAC CRS codelists only provide provider government codes (Agency). For recipients, this is just high-level country codes (Recipient).
It is therefore not feasible or practical for a publisher to reference a recipient government in their IATI data, with a code that others might commonly use. There is a great demand for this, particularly for publishers that have several connections to such entities.
A potential source does exist, however, in The World Bank Boost Portal: https://www.worldbank.org/en/programs/boost-portal/country-data. This provides structured and licenced data to be used.
In this, line item fiscal data for countries is provided, via the Chart of Accounts (COA). It is therefore possible to extract from this a list of relevant recipient government identifiers, and mint identifiers for them.
Proposal
This project would use data published on the Boost platform to generate a set of references for recipient country government entities.
Volunteers would need to work on countries, and then submit their data to a shared drive/pool for inclusion. Here is an example for Kenya: https://docs.google.com/spreadsheets/d/1LXrBOZKYWmr1wDZtBL30eEe-k4jI69WkH1FdbYuXBhc/edit?usp=sharing
From this, a shared list could be formed, and published via https://codelists.codeforiati.org/. This can be searchable to users.
In terms of a "namespace" for the references that this project could create - it seems that a "global" namespace would be more practical - eg: "XM-COA-[ISO2code]-". Doing this would mean just one entry on https://org-id.guide/ - rather than one-per-country
Metadata will also be important in processing Boost data, in terms of establishing and recording when the data was retrieved. This will be especially useful when / if Boost codes change periodically.
Notes on prior work
This project would mint a set of references for practical use. However, there is context to this whole topic that is both useful, and should not be ignored. The proposal here is not to have a definitive solution, but scaffold something together for quick use by willing partners.
The upcoming Aid Transparency Index run by @publishwhatyoufund includes a Network Data Test: https://github.com/pwyf/2022-Index-indicator-definitions/issues/25 - but faces difficulties in this specific issue. The test would not use anything from this project, but publishers who are adjusting their systems and processes may have incentive to incorporate it, as they prepare for the ATI.
There's a discussion in the IATI community on this in https://iaticonnect.org/group/standard-management-consultations-0/discussion/discussion-post-identifying-government. @timgdavies worked on this issue in, and submitted a paper to Development Initiatives (via the Joined Up Data initiative, not the IATI secretariat) in 2017. The outcome is not clear. It should also be recorded that Tim outlines alternative methods to address this: this proposal does not attempt to dismiss them.
To reiterate, I appreciate this proposal is not definitive and addresses all the issues, but it's a practical step forward , given the current window of opportunity to improve IATI data