Since the TAG meeting in Tanzania, I have had several strands of thought floating around in my head and on scraps of paper.

These are concerned with the idea of how we in the tech community can help make IATI more usable.

I’m encouraged by the range of people wanting to use the data for a wide range of purposes, but I also hear from people that they are frustrated at not being able to get hold of the data in the way that suits them best.

You can read the latest iteration on this Google Doc. Thank you to those who have given constructive feedback so far.

In summary, I am proposing four actions

  1. Separate the definition of the standard from its technical implementation
  2. Build a Repository, not just a Registry
  3. Simplify the standard for different user needs through a modular approach.
  4. Encourage the development of interoperable tool components as global public goods

I’d love to hear what you think, either online here or if you are able to be with the MA in Rome next week. Please post your comments in this discussion thread and not in the document.

Comments (41)

Reid Porter
Reid Porter

Interesting proposal(s) John. I applaud the spirit, perhaps I am missing the context/user story, but I’m scratching my head a bit:

  1. Simplify the standard by moving from one format to many? This seems like Androiding the standard - there would be a multitude of formats to consider. You admitted this technical challenge, but aren’t we struggling to get validation and upgrade-adapted tools as is? Wouldn’t this user need be better met by better multi-format export and data manipulation tools? Funny, I know some guyzz

  2. At first I thought “so your solution to the creation of 3 separate databases is to build a 4th?” But I’m intrigued by the quality gatekeeping and enrichment capabilities you described. (Centralized repo, quality gatekeeping, post-publication data enrichment - I feel like I just wandered into a minefield. Should this post have a trigger warning? )

  3. I think I’m with you here. Open Ag has already anticipated the name-pending element with its own extension (credit to Open Data Services there - http://openagfunding.opendataservices.coop/en/latest/extensions/) There are also several rulesets out there already - Open Ag has one, PWYF has one, etc., some of which we’re integrating with ODS’ Cove/Validation tool as part of the “Open Aid Publishers Toolchain” (working title for now). This doesn’t seem as earth-shattering as your other proposals. So - sure, let’s do it!

  4. This one deserves special attention:

In order to build the integrated and interoperable infrastructure that IATI needs, it would be good to agree the areas where investment is needed, and seek a collaborative approach among tool developers to build those tools and components. That might require IATI to act as a broker, seeking broad consensus on tools and possibly pooling funding towards common goals.This approach is challenging where the community is made of independent organisations and businesses.

Amen! But similar to 3, isn’t this already a thing? The majority of tool developers have been in the same room not once, not twice, but three times in one calendar year so far, and all their work is open source (and I say that not to toot my own horn but to toot Z&Z, Young Innovations, Wet Genes, DI Tech Team, Dev Gateway, Foundation Center, Open Data Services, Neon Tribe -'s horns ) As Steven Flower says, “what’s to stop us from doing this again?” Funding and coordination, yep. I suspect most members feel like they already contribute their fair share to support the standard/initiative - so where would this come from? My suggestion: a consortium of donors that either care about data accessibility strongly or have requirements on their implementers to publish IATI data (therefore, the logic goes, that data is a public tax-payer funded good, therefore it shouldn’t be restricted to the technically literate population).

John Adams
John Adams

Hi Reid, many thanks for being the first to comment and react, your comments are very helpful. A few comments back (maybe each of the points need a separate thread!)

  1. The core user need I have in mind here is to help the standard work for people whose natural technology is Excel. Publishers should not need to know about the IATI relational model - tools (like CoVE) should obfuscate this for them. Similarly, end users should be able to download in different formats, and again should not need to know the full detail of the IATI data model. I think I’m asking here for tools to hide the relational model from end users, much like we already do with BI tools within organisations.

  2. I think there is a need for IATI itself to provide a curated data store so that end users can extract the data they need in the format that they need it. Otherwise, everyone who needs to use the data has to build one, or understand the differences between the different aggregators. But I’m not sure whether that is indeed a consensus among the TAG community, and I’d be interested to hear what others feel about it.

  3. Yes, although I think we need to revisit how extensions and rulesets would work better, and some practical examples would help.

  4. Yes, this is indeed already a thing, and the community is brilliant in building things in the open. But I wonder how we could be more strategic in co-ordinating this effort so that we can better meet the data use user needs. I like your thinking around a consortium of donors who would be willing to support strategic investment.

SJohns
SJohns

I think this is a really interesting proposal and look forward to discussing more next week. I wondered though if we can also take one step back. If the core issue for usability is data that makes sense, is it also a good idea to re-look at the XML file requirement for publishers?

Although I understand the merits of XML in relation to the nested structure of the data standard and the open nature of the data, it’s not a file type that’s easy to produce using the software most organisations have access to. And although the number of publishers are growing rapidly, we still only have one stable, tested, public access free tool that converts CSV data into XML - AidStream (I know CoVE and Aid Studio are being developed to do this conversion, but they are still not available and I’m not sure what the sustainability plan is for these tools). The market forces to encourage more conversion tools to be developed are not working and it’s really not a great state of affairs to have the majority of publishers dependent on just one tool. If we can’t get the tools, let’s cut out the conversion process entirely.

There is a proposal in your paper to effectively ‘normalise’ the data at the point of entry to the Repository. If this is the case, and given that you want to hide the workings from end users and the fact that JSON and CSV can be used as export options, isn’t it time to open up the import options too? Imagine how many more publishers you would get if they could publish in CSV. Maybe the point has passed that this is possible because the standard is so nested and complicated now, but we should still consider the idea of making it way more simple to publish and create usable data.

I’d be interested in what others think.

John Adams
John Adams

Sarah, I do think that would be a good goal, and I would like us to move towards that.

Tools that do the CSV-IATI translation are a good first step, which means that the IATI relational model is preserved.

matmaxgeds
matmaxgeds

Hi,

What would the advantages of a repository be over the datastore? Most users (currently) just want IATI data in an excel sheet - I am not sure they would notice the difference between a curated repo and a registry. On the other hand, if IATI has a repository, IATI is taking far more direct responsibility for the numbers/quality due to the curation…lots of issues there - e.g. the OECD curate CRS data and it takes them 12 months to do so.

I am not sure what making it more modular means e.g. in comparison to having everything included and just using the bits you want? On the other hand, I think that there are a lot of expansions to the standard that would help, and perhaps these could be called modules e.g. X is publishing IATI 2.03 with OpenAg extension module 1.04 - and this does suggest that the modules/extensions, need to be self contained to a degree i.e. in their own part of the tree.

I am not convinced that there is a need for more money for tools (and I may regret saying this a lot) but for example, how much money has the OECD CRS spent on making tools, websites, visualisations, integrations etc - comparatively nothing, and yet it is still far more used than IATI. This suggests that the problems really lie elsewhere. Either we are making the wrong tools, or the data is not what people are looking for. I suspect a bit of both.

As I read all the recent country profiles of IATI use that keep popping out, I think that your suggestions on ‘data quality is at a median score of 35%’ is much closer to the truth. Add that to ‘IATI data is not official data’ and ‘IATI data cannot solve double counting’ and I think that is as much of the problem as the format/complexity issues. There are a few situations where I prefer IATI data to OECD data, e.g. single donor queries for DfID data, the quality means that it is as good as the OECD data, it is official (as it is the same as used on their website), and with a tool like http://spreadsheets.aidonbudget.org, I can easily get it into an easy to use flat format. Perhaps this is a ‘ruleset’ like you suggest - a harder enforced quality standard, that means the data it covers meets a specific need.

Now if the OECD decided to only accept IATI data as an input for the CRS, then we would be talking…how about that OECD?

Matt

Bill Anderson
Bill Anderson
Image removed. matmaxgeds:

if IATI has a repository, IATI is taking far more direct responsibility for the numbers/quality due to the curation…lots of issues there - e.g. the OECD curate CRS data and it takes them 12 months to do so.

Agree 100%

Image removed. matmaxgeds:

I am not convinced that there is a need for more money for tools (and I may regret saying this a lot)

Disagree 100% (and I think you will regret this). FOSS means free to use, not free to develop. If we want to stimulate the community to develop tools and services that are of benefit to all publishers/developers/users then someone needs to pay for this. The marketplace isn’t that mature (yet?) to sustain this.

Image removed. matmaxgeds:

Now if the OECD decided to only accept IATI data as an input for the CRS, then we would be talking…how about that OECD?

Indeed. Ole Jacob (OJ) Hjøllund is WP-STAT ready for this???

Ole Jacob (OJ) Hjøllund
Ole Jacob (OJ) Hjøllund
Image removed. bill_anderson:

matmaxgeds:

Now if the OECD decided to only accept IATI data as an input for the CRS, then we would be talking…how about that OECD?

We can’t blame OECD for our own blunders - we have designed the IATI standard in a way that allows for a conversion of DAC-formatted CRS++ data into a (simple) IATI-file, but we have made it impossible to go the other way; IATI activity-files cannot be converted into CRS++ and are thus unable to fit into, or feed into the statistical databases of the DAC.

What we can do (and I make the statement at any chance) is to advice the DAC to use IATI as a secondary datasource whenever they draft statistical analyses that trancends CRS++ (e.g. assessing flows from private charity-funds or working on the TOSSD measure for the future).

matmaxgeds
matmaxgeds

Hi Ole Jacob (OJ) Hjøllund I would be really interested to know about why IATI > CRS++ is not possible - is there anywhere I can read about it?

Ole Jacob (OJ) Hjøllund
Ole Jacob (OJ) Hjøllund
Image removed. matmaxgeds:

why IATI > CRS++ is not possible

I made a paper for a session at one of the TAG’s in Canada - not at hand right now - but the obstacle identified at that time was the org_type etc. codes of IATI that can’t be translated into CRS channel-codes. Will need to update that paper in order to verify wether this problem is solved with version 2.03 of our standard.

Another issue should be noted as well: We must recognise that the DAC has a strong need for ‘single point of contact’ to governments of donor countries, for the dialogue and data-validation. Even though some of us are currently reporting on behalf of our Government, making sure that our IATI-reported ODA-volume reach 100% of our DAC-reported ODA, this is not the case for all donors, and might not continue to be the case for us; IATI is designed for reporting by individual organisations rather than Governments. There are advantages, certainly, but it will be an organisational challenge for IATI-formatted CRS-reporting.

Winnie Kamau
Winnie Kamau

I like the part of IATI data being repository which can be accessed in different formats and not confined in XML format only.

Going forward we need to adopt a collaborative method amongst developers to come up with tools that will simplify the data.

I say this so that we are able to communicate easily and that we may not rebuff the new publishers and users who will come on board who may site it being too technical.

John Adams
John Adams

Bill Anderson matmaxgeds

if IATI has a repository, IATI is taking far more direct responsibility for the numbers/quality due to the curation…lots of issues there - e.g. the OECD curate CRS data and it takes them 12 months to do so.

I don’t doubt the challenges in maintaining a repository. The IATI Tech Team are already maintaining the Datastore and are using it for IATI quality monitoring.

But how much more useful would a Datastore be if it was able to serve up different cuts of data (by provider, country, sector, and other dimensions), in different output formats (XML, JSON, Spreadsheet).

The alternative without a Repository is that every user has to download all the raw XML data from the Registry links and then process those files. There must be a better way.

The benefit of IATI is that it has everyone’s data, therefore the whole is definitely greater than the sum of the parts. The network tells the story much better than any individual provider’s dataset.

Bill Anderson
Bill Anderson
Image removed. JohnAdams:

But how much more useful would a Datastore be if it was able to serve up different cuts of data (by provider, country, sector, and other dimensions), in different output formats (XML, JSON, Spreadsheet).

The Datastore provides this already

CSV via a user interface

Or a more advanced search and xml and json outputs via API

The problems with the current datastore are:

  • It is not comprehensive (eg. Results and locations are not accessible)
  • Its update procedures are not sufficiently robust
  • Its user interface and API are incomplete

Work on fixing these problems will start before the end of the year. The Tech team is committed to providing a robust basic ‘vanilla’ service to all activities, all elements, all filters, etc.

John Adams
John Adams

And I am fully supportive of those upcoming changes, Bill. Particularly as those changes are based on the robust user research carried out earlier this year.

Herman van Loon
Herman van Loon
Image removed. JohnAdams:

Build a Repository, not just a Registry

In addition to the comments made by Reid Porter , matmaxgeds and Bill Anderson , I doubt that it is possible to define a repository which will serve all the different use cases. A lot of functional design decisions would have to be made which are use-case dependent. E.g.:

  • Do we split up transactions by their sector and country percentages in order to facilitate data use? If so, how? By sector, by region/country or both?
  • How would we implement traceability? Would we attribute outgoing flows to the relative contribution of incoming flows or not?
  • Etc.

Secondly, looking at the conclusions being drawn the last few years about the use of IATI data in country pilots, an very important problem is the completeness and accuracy of the published data. Wouldn’t we therefore better invest our very limited recourses in tooling, procedures, etc. enabling publishers to publish better quality data instead of trying to build another repository?

Herman van Loon
Herman van Loon
Image removed. JohnAdams:

In summary, I am proposing four actions

Separate the definition of the standard from its technical implementation

It would indeed be nice if the technical representation of IATI data would be separated from its semantic definition. A way to do this, would be to keep the current XML representation as the core representation and provide tooling to:
1 Convert non XML IATI data to IATI XML (e.g. convert CSV to IATI)
2 Retrieve non XML IATI data from IATI XML (e.g. convert IATI to CSV)

So I would keep the rich and proven XML format as the core technical representation for IATI data. The advantage is that we keep one canonical technical representation for all IATI data which has enough power to model all use-cases.

In such an approach it would i.m.o. be important to automatically check the consistency and conformance of the data being converted to the IATI. So the tooling should not only do the technical conversion, but should also do an automated quality check. Ideally there would be a centrally maintained data quality service, which could be used by all tool developers.

Herman van Loon
Herman van Loon
Image removed. JohnAdams:

In summary, I am proposing four actions

Separate the definition of the standard from its technical implementation

It would indeed be nice if the technical representation of IATI data would be separated from its semantic definition. A way to do this, would be to keep the current XML representation as the core representation and provide tooling to:
1 Convert non XML IATI data to IATI XML (e.g. convert CSV to IATI)
2 Retrieve non XML IATI data from IATI XML (e.g. convert IATI to CSV)

So I would keep the rich and proven XML format as the core technical representation for IATI data. The advantage is that we keep one canonical technical representation for all IATI data which has enough power to model all use-cases.

In such an approach it would i.m.o. be important to automatically check the consistency and conformance of the data being converted to the IATI. So the tooling should not only do the technical conversion, but should also do an automated quality check. Ideally there would be a centrally maintained data quality service, which could be used by all tool developers.

Ibrahim Aboalfadl Omar
Ibrahim Aboalfadl Omar

If you allow me,

Image removed. JohnAdams:

Simplify the standard for different user needs through a modular approach.

I do support this, most of the data users depend mainly on some of the attributes(fields), we could have something such as “Basic” data or “Core” data and “Extended” or “Complete” data, this will:

  • Simplify exporting the “Basic” data to Excel format for the user

  • Simplify the publishing of the “Basic” data which minimize the invalid data and increase the reliability and quality of data

matmaxgeds
matmaxgeds

Hi Ibrahim Aboalfadl Omar ,

I think this is a great idea. Does the recent work that was done on ‘IATI users’ help to define what data is needed by the different use cases? Or for the ‘basic’ needs, I can share the data that the various countries I work with would love to be able to easily access (in flat/excel) format, basically: a row per project: funder(s), implementer(s), total project value, local sector, start date, end date, grant/loan, disbursements to date, disbursement in last local FY, disbursements in next local FY, description (incl in local language), local contact name, local contact email. ADM1 geographic information, humanitarian/development.

If agreed, we could then work on making sure that that very restricted set of fields is comprehensive, not double-counted, uses local language.

Matt

Ibrahim Aboalfadl Omar
Ibrahim Aboalfadl Omar

Hi matmaxgeds ,
Thanks for your reply, to me these fields is fair enough, I only want to add a note for how to represent the multi-valued fields such as sectors or donors in a flat Excel file, I propose to separate them by either “,” or “/” or whatever else, this will help to import this in a database later, and keep that each row has one activity.

matmaxgeds
matmaxgeds

Hi,

Is there a list of the mandatory fields somewhere? I tried here in the guidance but couldn’t see it. There is mention in the upgrades for specific mandatory fields?

[quote=“bill_anderson, post:21, topic:1047”]
Is this really what in-country decision-makers need?
[/quote] from my experience, yes - it is not everything they need, but a list of all the active and pipeline projects solves 80% of the needs for 80% of the users. At worst, it is a good starting point for them to be able to follow up further - at which point the use cases become too individual/unique to be able to cater for as a consistent group.

[quote=“bill_anderson, post:21, topic:1047”]
is this really the IATI vision?
[/quote] - I am not sure what the IATI vision is, but it would seem to me that first catering to the dominant user need would be a good start - I could be wrong that this is the dominant user need - and I think that DI commissioned some research last year working out who the users of IATI data were, is that something that is public yet? If not, a public mapping of the different user groups and their data needs sounds sensible to help define what the IATI vision is - and to guide future iterations of the standard/effort.

RE the UNDP example - of course we want the 4bn (UNDP mainly as an implementer, not as a funder), but are you suggesting that in the quest for simple export of basic fields in a flat format, we will not get the $4bn, but instead the $400mn?

Bill Anderson
Bill Anderson
Image removed. matmaxgeds:

the quest for simple export of basic fields in a flat format

I am agreeing (110%) that your use case can be met by a standardised export - and we should do this.

I’m disagreeing that your use case can be used to define the standard itself

matmaxgeds
matmaxgeds

aha - thanks Bill Anderson - based on that, I think Ibrahim Aboalfadl Omar and I are suggesting a slight expansion of the core/manadatory fields?

Ibrahim Aboalfadl Omar
Ibrahim Aboalfadl Omar
Image removed. bill_anderson:

I’m disagreeing that your use case can be used to define the standard itself

Agreed(100%)

Image removed. matmaxgeds:

Hi - also agreed, IATI is much more than just this one use case

Agreed(100%)

Image removed. bill_anderson:

I am agreeing (110%) that your use case can be met by a standardised export - and we should do this.

what I am proposing is that the standard has two parts: “Basic” and “Extended”, The “Basic” is the mandatory and the “Extended” is all the others.

matmaxgeds
matmaxgeds

Hi Ibrahim Aboalfadl Omar

Yes, I think that ‘basic’ and ‘extended’ are a good idea - although there might be ‘extended - results’ and ‘extended - openAG’ etc, i.e. multiple different extensions for different more specific use cases. The reason I like this idea is that it should make it easier to focus on comprehensiveness and usability in the key fields first - and at the same time, perhaps answer some of the needs of those currently campaigning for simplification, and those wanting more extensions. What worries me is that IATI already has some structures e.g. the different parts of the XML tree, and this would add another structure that runs across that which would add complexity.

Matt

matmaxgeds
matmaxgeds

Hi Yohanna Loucheur exactly right, this would be aggregated disbursements. It is not like I can’t see the value of having the individual disbursements in the standard, just that none of the 5 recipient countries I have worked with recently actually uses them in that way e.g. for annual ODA reports, budget integration, sectoral planning, M&E etc, so for a flat reporting standard, it seems like it would hugely simplify the reports, without losing any/many use cases.

Yohanna  Loucheur
Yohanna Loucheur
Image removed. matmaxgeds:

so for a flat reporting standard, it seems like it would hugely simplify the reports, without losing any/many use cases

This is a very important point. Not only would it simplify the reports (ie the data), but in some cases it would remove an important barrier to getting buy-in from partners - for instance in cases where commercially-sensitive information may be revealed by publishing individual transactions.

This is a great example why we need feedback from actual users of aid data (not necessarily IATI data), to better understand how they use it, what they need so IATI tools can be responsive.

matmaxgeds
matmaxgeds

Hi Yohanna Loucheur - completely with you on IATI needing to be driven by user feedback both in terms of demand i.e. few country level processes need individual disbursements, and also supply, e.g. your information that aggregation

Image removed. YohannaLoucheur:

would remove an important barrier to getting buy-in from partners

This post mentions a set of user stories that the IATI secretariat use to guide future developments - perhaps a a community we need to go through these again and check how they might have changed since they were first developed?

Imogen Kutz are these something you can share - or am I getting the wrong end of the stick and they are user stories in terms of how users use e.g. d-portal etc, but not in terms of the supply and demand for IATI data? If so, are you aware of any user stories / IATI user profiles/analysis that has been done? I only know of the recent DI report here? I guess there must have been right at the beginning?

Bill Anderson
Bill Anderson
Image removed. matmaxgeds:

I can share the data that the various countries I work with would love to be able to easily access (in flat/excel) format

Image removed. matmaxgeds:

disbursements to date, disbursement in last local FY, disbursements in next local FY

This sounds like ODA macro-management. I accept that this may be the most prevalent use of AIMS at present, but is this really the IATI vision? Is this really what in-country decision-makers need? I would go so far as to argue that ODA macro-management (for which double counting is an issue) is an edge case. Is IATI a bean-counting balance sheet, or part of what the data revolution promotes as data-driven decision-making?

I agree that we can provide more focused (even standardised) outputs from IATI data, but for every person satisfied with this use case you will find many to the contrary. We already have a ‘basic’ standard, common to all: it is defined by mandatory fields.

To return to my much-used UNDP example. Would you like to see the arithmetically clean $400m number they report to the CRS, or the $4bn they account through IATI for their activities on the ground?

Yohanna  Loucheur
Yohanna Loucheur
Image removed. matmaxgeds:

Or for the ‘basic’ needs, I can share the data that the various countries I work with would love to be able to easily access (in flat/excel) format, basically: a row per project: funder(s), implementer(s), total project value, local sector, start date, end date, grant/loan, disbursements to date, disbursement in last local FY, disbursements in next local FY, description (incl in local language), local contact name, local contact email. ADM1 geographic information, humanitarian/development.

Mat, question of clarification on the disbursments info in the list above: if this is meant to be in a single line per project, I assume disbursments to date, in FY and new FY would be totals, not disaggregated by transactions (like we are asked to publish)? This actually jives with data requests we get from the field ie adding up disbursments by year (or sometimes quarters), not by specific transaction. Just checking that I’m not misunderstanding.

Ibrahim Aboalfadl Omar
Ibrahim Aboalfadl Omar
Image removed. bill_anderson:

I’m disagreeing that your use case can be used to define the standard itself

Agreed(100%)

Image removed. matmaxgeds:

Hi - also agreed, IATI is much more than just this one use case

Agreed(100%)

Image removed. bill_anderson:

I am agreeing (110%) that your use case can be met by a standardised export - and we should do this.

what I am proposing is that the standard has two parts: “Basic” and “Extended”, The “Basic” is the mandatory and the “Extended” is all the others.

matmaxgeds
matmaxgeds

Bill Anderson thanks - regarding recipient country data needs, it mainly references this 2014 USAID report - which has three case studies - and each give their data needs on 34, 80 and 129 .

I just put the three into a google doc, and it is already quite suggestive on how the mandatory/core fields need to change in the next major upgrade if IATI is to meet the data needs of aid recipient countries. In summary, those requested across all three case studies, but not currently mandatory include:

  • Reporting results
  • Basic financials
  • Sub-national locations

I guess the next step is consultation with the data providers to see which of these they are able to supply?

Edit: perhaps I am barking up the wrong tree here - a multiple year wait to change the mandatory fields is a very slow process, and I am not convinced that most of the countries I have tried to excite about IATI will have that much patience. Perhaps better is to gather together a definition of what data fields recipient countries need, and see if we can make a specific quality measurement with which to address donors for improvement. As well as a list of key fields, tt could also include things like requiring the activity description being provided in the national language of the recipient.

Murad Hirji
Murad Hirji

There is at least one organization I know of whose business model operates at a national or higher level. Why would you make sub-national locations mandatory when not everyone operates at that level.

Reporting Results is another area I have concerns with as results frameworks vary across the multitude of domain we operate in. In the case of health, we might be tracking, and have targets for, an indicator we would want to mention to help give context, but would not expect a result for another year or more.

I fully agree to re-looking at what is mandatory, but it should be from the perspective of what all organizations have in common so that at the end of the day, when analyzing data you are getting closer to comparing apples to apples, which is not always the case today, or at least that is my 2 cents.

Bill Anderson
Bill Anderson

Wearing my DI cap, we are preparing a flat file serialisation not a million miles from your needs. If we can agree on your required columns we can piggyback your job onto ours. Until we are in a position to provide this as a standard output from the data store …

matmaxgeds
matmaxgeds

Bill Anderson that sounds great (the datastore version too of course), is the first version a d-portal output?

What is going to be the most helpful way to engage on the columns? No problem to give my choice, but I am sure there will be plenty of other variations/tweaks?

How about a google doc where we could list the colums, and do the different use cases as rows, marking which fields they would need to see if that suggests a clear set?

I am also mindful of Yohanna Loucheur ’s previous posts requesting the ability to select/unselect/order which columns appeared in a ‘flat file serialisation’.

I am also aware that we are getting to the stage where different IATI tools (at least the ones that have to make decisions) might end up giving different results based on their different assumptions e.g. I think OPIA allocates a uniform distribution to sectors without percentages but this raises the possibility that the different tools will start producing different outputs e.g. if the flat file tool that you are working on takes a different approach and this might lead to confusion about which is the ‘real’ IATI.

Bill Anderson
Bill Anderson

First version is going back to the registry. We have this “unbundling aid” tool which presents 2006-2015 CRS data. We will be adding 2016-2020 data from IATI, which involves a partial IATI to CRS conversion.

Image removed. matmaxgeds:

ability to select/unselect/order

For this particular piece of work we could produce a superset of requirements which could be trimmed.

Image removed. matmaxgeds:

might end up giving different results based on their different assumptions

I think this is inevitable. We will share our methodology once finalised. There is, for example, the challenge of double nesting (multiple sectors and countries) which the standard doesn’t currently express an opinion on.


Please log in or sign up to comment.