 |
 |
As you may be aware, the DAC Chair (Charlotte Petri Gornitzka) gave a talk at the IATI Members’ Assembly last week, and spoke very positively about co-operation between DAC and IATI. In addition, the miniTAG at FAO last Friday looked at technical interoperability around codelists.
So, how could we achieve this greater interoperability between IATI and the DAC? I’d be grateful for thoughts around the following dimensions:
Is being able to use IATI as a format to report to the DAC a solvable issue? @OJ_ said here that while DAC > IATI was possible, currently IATI > CRS++ is not.
I think this is important as it would really focus publisher’s attention on improving IATI data quality. The DAC needn’t accept IATI XML (although that would be cool) but if there was an official converter that all publishers could use (the new pyiait tools?) to convert from IATI xml to the CRS++ input format that would do.
My mission is to render the third-party codelist management work @andylolz did unnecessary, and the horse I would bet on there is the proposal that @dubeys’ team is putting together, which the miniTAG participants and Mr. Lolz gave a tremendous amount of input on. (And yes I know that’s not his real name!
)
Interoperability aside, I just saw a really cool data visualization tool built on CRS data that FAO has been working on for a while. It’s called AIDmonitor, launching in November. No public link yet, but if you’d like to get a preview (and are willing to serve as a peer reviewer) reach out to me privately and I’ll put you in touch with the team. #coworking
Although there are some edge cases - how, for example, do you export an IATI activity that contains percentage splits on sectors and countries - I do believe this is possible. I would initially see the output not as an automatic submission to CRS but a file for DAC reporters to work with.
This is not currently a priority for the Tech Team (we’ve got websites and datastores and validation tools to build) but we and others (@Herman?) would, I’m sure, be happy to advise an intrepid developer supported by a visionary DAC donor.
Here’s a related discuss post from @stevieflow: Planning for machine readable, version controlled OECD-DAC codelists
Echoing @reidmporter’s point, I’d also ideally like my third party codelist work to be rendered unnecessary! Long-term via co-operation between IATI and the DAC. E.g. not so long ago we heard about the DAC’s plans for an automated system to do this.
In the short-term, I’d love it if one or more organisations that internally rely on machine readable DAC codelists could either fund or take on the ongoing maintenance of the work, so that it can continue to be provided as a public service to publishers and data use tools.
As mentioned in my (impromptu) miniTAG presentation, it’s worth flagging again this pull request, that should make it much much easier for IATI to keep third party non-embedded codelists in sync. (This builds on some excellent work by @bjwebb.) If there’s any feedback from the @IATI-techteam on whether that looks okay or if anything else needs to be done before it can be merged in, that would be much appreciated.
I’ve been using the code on that pull request to generate amendments to keep IATI third party codelists up-to-date. Here’s a bunch of them:
…And once the IATI codelists were up-to-date, I was able to use those to update AidStream:
…and d-portal:
…and the query builder:
…and the datastore:
So this is demonstrably useful for both publishing and data use tools. Apologies for writing an entire essay!
Yes, very interesting, is there anyone familiar with the CRS++ submission process who could share how this is currently dealt with as it is not an IATI specific issue, the same problem must come also when preparing the current non-IATI based CRS++ submissions. I have found a copy of the guidance here which suggests that this issue is similar to the issue of a donor funding a multilateral i.e. the solution is to also take the measurement from the recipient perspective i.e. what outflow from project X which covers multiple countries, was received by country Y. In reality, I presume that percentage splits are taken based on the percentages for each country receiving benefits from an activity/project.
Perhaps someone (@OJ_?) could also share the format for submitting data to the DAC?, I can only find mention of what sounds like a spreadsheet reporting format e.g. see mention of columns here.
Perhaps someone (@OJ_?) could also share the format for submitting data to the DAC?
@matmaxgeds I got temporarily excited when I stumbled into a CRS XML Schema (!) the other day. Alas, as @Herman pointed out: same organisation, same acronym, but different standard. My head doesn’t really compute this.
@reidmporter fully agree - making @andylolz obsolete should be a priority! But seriously, if we value and rely on this work, then IATI core needs to maintain it?
@JohnAdams in terms of IATI <> DAC collaboration, then I know @dalepotter was pushing (despite my unhelpful grumbling!):
Given this, we encouraged the DAC to consider setting-up a (perhaps quarterly) user group meeting/consultation call to speak directly with codelist users and other interested parties in the open and development data communities. However, given resourcing constraints, there is no capacity to do this and it is felt that an informal relationship is most sustainable, given they see their primary remit being to service DAC members. They have said that interested parties and data users are however welcome to get in touch using the contact information on their website.
Do we think this has now changed?
(wrt Discuss, I do wish it/someone can start to link threads automagically. Like on GitHub :))
The format is being changed these years; we are moving from a format where only the primary purposecode could be reported and multible countries shall be aggregated to the relevant regional code, to a format that allows multible purposecodes (totaling 100%) and multible countrycodes. The first is decided, the second is expected to be approved next year. Personally, I am pushing for a data-governance rule that only allows the reporter to apply one multible element for any activity; it is hardly useful or transparent to have multible on multibles - how should a fifty-fifty coding of two purposecodes for two countries be interpreted by the relevant consituency in any of the countries? I also claim that one of the multibles will be more important than the other in any specific activity.
The complete CRS++ format is available on OECD’s website, along with the Directive that provides instructions and guidelines on the completion of the format.
I will revisit this post Friday and include links - it’s too much of a challenge on the phone in the airport …
Agree. I also think it is in principle possible to produce CRS++ from IATI. A few years ago we did a pilot to do exactly this. There were a few challenges, but they can be overcome. Since we are already producing CRS++ and IATI from the same reporting database, the added value of this format conversion is not very significant, and therefore we haven’t pursued this.
What would be interesting though is if the DAC would be willing to accept IATI XML as a data interchange format to do DAC reporting. IATI XML for instance supports multiple CRS purpose codes and multiple countries for one activity. The DAC is, if I am not mistaken, also considering multiple CSR pupose codes for one activity. I.m.o. the CRS++ flat file format will be too inflexible to accomodate these kind of changes. But in the end it is up to the DAC of course what formats will be accepted.