The IATI Platform
Consultation Note on Technical Architecture and Data Formats
see also consulation paper unlocking the potential of aid information
1.0 Introduction
IATI aims to improve the availability and accessibility of aid information by committing donors to agree common standards for publication of information about aid. It is anticipated that this standard will also be used by other providers of aid and resources for poverty reduction: NGOs; foundations; private sector organization etc.
IATI is not about creating another database on aid activities. It aims to establish common ways of recording and publishing aid information to create a platform that will enable existing databases – and potential new services – to access this information and provide more detailed, timely, and accessible information about aid.
The idea of openness is crucial to creating this platform and achieving transparency. Information must be openly available with as few restrictions how the information is accessed and used as possible. To this end, we need to design a technical architecture that enables information to be published and accessed in an open way. The attached consultation paper ‘unlocking the potential of aid information’ covers three aspects of this:
Making aid information legally open
Making aid information technologically open
Making aid information easy to find
This consultation note outlines the high level objectives of the technical workstream of IATI, the type of information the standard will cover and identifies the main requirements the providers and users of aid information have from IATI.
This note, and the attached ‘unlocking the potential of aid information’ paper, has been written for open consultation purposes and is intended to stimulate debate around:
The objectives of the technical component of IATI
The target users and their requirements
What is required to meet the needs of publishing info
The technicalities of making aid information available, open and easy to find
Invite advice, comments and feedback on other aspects we should consider
Advice on where existing standards could be used and exemplars of similar initiatives
2.0 Potential IATI Information
|
Information |
Type |
Notes, & Possible Standards |
|
Donor information |
||
|
Policies, strategies, procedural docs etc. |
Documents (+metadata) |
Dublin Core? |
|
Forward planning budgets by country, by sector |
Data |
XBRL? |
|
Country strategies |
Documents (+metadata) |
Dublin Core? ISO countries |
|
Future procurement opportunities & tenders |
Documents (+metadata) |
|
|
Project / Unit of Aid information |
||
|
Project Documents |
Documents (+metadata) |
Dublin Core? |
|
Project identification information (ID, title, descriptions, dates, status) |
Data |
|
|
Country & detail geo info |
Data |
ISO country Geo code (longitude/latitude) Administrative region/district (?) |
|
Sector (Global & local) |
Data |
DAC sector codes / local country budget classifications |
|
Type of Aid |
Data |
DAC standards |
|
Project Contacts |
Data |
|
|
Funding organization |
Data |
Standards for organization details? |
|
Financial information (project budgets, commitments, individual disbursement data, value & recipient) |
Data |
XBRL? |
|
Result/output indicators |
Data |
SDMX? |
|
Implementing agency /channel of delivery |
Data |
Standards for organization details? |
|
Details of contract issued |
Data / Docs |
Procurement standards? OECD good practice |
|
Paris Indicators |
Data |
SDMX? |
|
Conditions |
Data / Docs |
|
3.0. Information Providers Requirements
3.1. Information providers
Donor HQ
Donor country offices
NGOs
Foundations
Private organisations
Infomediaries
3.2. Provider Requirements for an IATI platform
|
Requirements |
Implication for design |
Priority |
|
The platform must meet the needs of most donor reporting requirements |
There needs to be a way of handling DAC & FTS reporting as well as IATI requirements |
|
|
It should support automated publication of information |
|
|
|
Enable providers to add information in a decentralized way (e.g. HQ might publish info on past spend, but country offices could publish info on forward planning info) |
How will we avoid or highlight duplication of data? We will need to highlight the source of information |
|
|
Allow providers to mark data as validated or non-validated |
Metadata |
|
|
Allow providers to add additional non-IATI information (e.g. where data has been crowdsourced or improved) |
|
|
|
Providers should have a degree of choice in formats and licensing options |
There should be an approved IATI list of acceptable options |
|
4.0. Information User Requirements
4.1. 1st Level Users
The focus of the architecture should be for information to be primarily accessible by experienced users of data who can repackage and repurpose it into more accessible formats. These include:
Infomediaries – Complete aggregators of all aid information (e.g. DAC, AIDA, PLAID)
Infomediaries – Sector/country/donor specific aggregators (e.g. Health portals, Uganda portal)
Partner Government aid management systems administrators (e.g. DAD, AMP)
Individual data specialist for one-off analysis (e.g. researchers, journalists)
4.2. User Requirements
|
Requirements |
Implication for design |
Priority |
|
IATI data must be comparable regardless of the source |
Schema is required |
|
|
There must be manual access to raw data in human-readable & machine readable formats (i.e. to meet need of researcher who wants raw data) |
A simple format may be necessary (e.g. .xls)
A mechanism to check for broken links |
|
|
There must be an automated way of accessing the information (i.e. for aggregators) |
At least through direct access to data files
Possibly by recommending API access |
|
|
Users should be able to be informed when information is updated |
Rss feeds? Dashboard monitoring updates? |
|
|
The user must be able to distinguish between official and non-official sources as well as validated and non-validated |
Metadata for data sets
Should documents be in read-only format? |
|
|
The user must have the ability to use the information without constraints |
Open licensing |
|
|
It should be easy to find data sets -by country -by donor - sector |
How granular should datasets be?
Finding data by sector is likely to be more challenging |
|
|
There should be an audit trail for changes and updates to data sets |
How long should data be available for (retention schedule)? How important is having a timeseries? |
|
|
It should be easy to monitor the level of donor compliance to IATI standard
|
|
|