2 of 15

IATI STANDARD: A DETAILED OVERVIEW

[Date]

Behind the scenes: a technical guide through the IATI Standard.

IATI Speakers' Kit: 04 IATI STANDARD: A DETAILED OVERVIEW

International Aid Transparency Initiative

NOTE TO PRESENTER

This presentation provides a detailed overview of the IATI Standard in two main sections. Please provide the information that is most suitable to the audience(s) you are presenting to.

Slides 55–72 present what data is required by the IATI Standard. Here, you will find a detailed overview of the different types of data included in the Standard on development and humanitarian financing and projects. This section is useful to anyone who is interested in publishing or using a wide range of data set out in the IATI Standard.

Please note this presentation does not provide information on every single data field in IATI Standard. The full list can be found on the IATI website’s Standard Reference pages: https://iatistandard.org/en/iati-standard/203/reference/

Slides 73–84 present the technical format of the IATI Standard. This section explains the different components of the IATI Standard, providing useful background information to help publishers and users refer to the full Standard online https://iatistandard.org/en/iati-standard/203/reference/. This section is particularly useful for technical and data experts working to create bespoke solutions and products for publishing and using IATI data.

This section also provides brief information on the processes of updating the IATI Standard to meet changing data demands.

3 of 15

BEHIND �THE SCENES:

[Date]

Technical guide through the IATI Standard

IATI Speakers' Kit: 04 IATI STANDARD: A DETAILED OVERVIEW

International Aid Transparency Initiative

4 of 15

FORMAT: �IATI DATA IS PUBLISHED IN XML FILES

[Date]

IATI ORGANISATION SCHEMA

IATI ACTIVITY SCHEMA

IATI Speakers' Kit: 04 IATI STANDARD: A DETAILED OVERVIEW

International Aid Transparency Initiative

5 of 15

COMPONENTS TO CREATE �IATI XML FILES

[Date]

ELEMENTS

Represent every data field �in the IATI Standard

ATTRIBUTES

Are a set of values to provide information about an element. Attributes start with @

CODELISTS

Some attributes require publishers to add a code from a list of options. Codelists provide all options and their numerical code

IATI Speakers' Kit: 04 IATI STANDARD: A DETAILED OVERVIEW

< >

EXAMPLE

<participating-org>

10 government

11 local government

15 other public sector

21 international NGO

22 national NGO

23 regional NGO

@ref

@type

@role

@activity-id

@crs-channel-code

International Aid Transparency Initiative

To create IATI XML files, there are key components. We will look at three of these components: Elements, Attributes and Codelists.

Elements

Elements represent every data field in the IATI Standard. For example, participating-org is an element for providing data on which other organisations are involved in an activity.

Attributes

Attributes provide data about the elements. For example, for the element participating-org, there are 5 attributes. They include @type, which describes the type of organisation that is participating.

Codelists

Some attributes require publishers to choose data from a set list of categories. These lists of categories are called codelists. Codelists provide the name of the category, a description of the category and a code to represent it. For example, on the @type attribute for the element participating-org, a category must be chosen from the Organisation Type codelist (https://iatistandard.org/en/iati-standard/203/codelists/organisationtype/). There are 16 different types of organisations, including government, local government and international NGO.

We will now look into these components in more details.

6 of 15

ELEMENTS

[Date]

EXAMPLE ELEMENT

SUB ELEMENTS

IATI Speakers' Kit: 04 IATI STANDARD: A DETAILED OVERVIEW

<location-reach>

<location-id>

<Name>

<activity-description>

<point>

<location-class>

<feature-designation>

International Aid Transparency Initiative

Elements represent every data field in the IATI Standard. There are many elements in the IATI Standard, allowing publishers to provide very detailed and specific information about their work.

A list of elements can be found on IATI’s website and each element has its own page.

Some elements have sub-elements. These are additional fields of data that can be provided about the element. For example for the element ‘location’, it has 10 sub-elements to allow publishers to provide very specific information. For example the sub-element called ‘feature-designation’ (at the bottom of the list on the slide) allows publishers to provide a specific building or environmental feature that their activity relates to. For example, a school, farm, beach or hospital.

View all IATI elements on the IATI website’s Standard reference pages:

IATI Activity Standard elements https://iatistandard.org/en/iati-standard/203/activity-standard/summary-table/
IATI Organisation Standard elements https://iatistandard.org/en/iati-standard/203/organisation-standard/summary-table/

7 of 15

ATTRIBUTES

[Date]

Start with ‘@’

@ref

@type

@role

@activity-id

@crs-channel-code

Types (format):

xsd:string:

xsd:dateTime

xsd:anyURI

xsd:boolean

xsd:int

xsd:decimal

xsd:positiveInteger

xsd:nonNegativeInteger

IATI Speakers' Kit: 04 IATI STANDARD: A DETAILED OVERVIEW

EXAMPLE:

ELEMENT

<recipient-country>

ATTRIBUTES

@code �(code for named country)

@percentage �(% activity budget/commitments going to this country)

International Aid Transparency Initiative

8 of 15

CODELISTS

[Date]

IATI Speakers' Kit: 04 IATI STANDARD: A DETAILED OVERVIEW

EXTERNAL

CODELISTS are managed by:

Core, noncore or replicated codelists

e.g. Budget Type is a core codelist

External codelists

e.g. UNOCHA Humanitarian Response Indicators is a codelist managed by the United Nations Office for the Coordination of Humanitarian Affairs.

Example: CODELIST �for Budget Type

International Aid Transparency Initiative

Codelists

Codelists are key to making IATI data from different publishers comparable. Codelists provide a list of values to represent a set of categories. For example, on this slide you can see the codes to describe the budget type in an Activity File. ‘1’ represents if the budget is in its in its original form and ‘2’ represents if the budget has been revised.

Codes help reduce the amount of human error when entering data. Having set values also helps with data analysis. All codelists can be found on the IATI website Standard Reference page: https://iatistandard.org/en/iati-standard/203/codelists/

Codelist management

Codelists are either managed by IATI or produced by an external organisation. Codelists that are managed by IATI fall under three main types:

Core codelists: These are codelists that are core to a specific version of the IATI Standard (IATI Standard versions are explained on Slide 83). Changing core codelists has a significant impact on all those publishing and using IATI data.
Non-core codelists: Non-core codelist values are not version specific. These codelists usually provide lookup information, e.g. ‘description type’, ‘geographic location’, ‘indicator vocabularies’. An addition or modification has a minor impact on the sense and use of the data.
And replicated codelists: The content of replicated codelists is generally managed by a third-party organisation. In exceptional circumstances an additional code can be added. The IATI Technical Team maintains a corresponding copy in a document that conforms to the codelist schema.

External codelists are managed by an external organisation that has expertise around a particular element of data. For example UNOCHA’s Humanitarian Response Indicators is a codelist that managed by the United Nations Office for the Coordination of Humanitarian Affairs. With external codelists, the IATI Technical Team does not maintain a corresponding copy in a document that conforms to the Codelist Schema.

More details about IATI’s codelist management processes can be found on IATI’s codelist management page: https://iatistandard.org/en/iati-standard/upgrades/how-we-manage-the-standard/codelist-management/

9 of 15

VOCABULARIES

[Date]

Code	Name
1	WHO Registry
2	Sphere Handbook
3	US Foreign Assistance Framework
4	World Bank World Development Indicators
5	UN Millennium Development Goals Indicators
6	UNOCHA Humanitarian Response Indicators
7	HIV/AIDS Indicator Registry
8	Harmonized Indicators for Private Sector (HIPSO)
9	UN Sustainable Development Goals (SDG) Indicators
99	Reporting Organisation

IATI Speakers' Kit: 04 IATI STANDARD: A DETAILED OVERVIEW

Indicator Vocabulary�

Provides lists of CODELISTS

International Aid Transparency Initiative

When publishing data, organisations may need to understand and use vocabularies. A vocabulary provides a list of codelists.

For example, the element called ‘indicator’ has an attribute that requires a publisher to state which list an indicator has come from. They can choose a list from the Indicator Vocabulary. For example, an organisation working within the health sector may choose to use the World Health Organization Registry. This provides a list of hundreds of indicators such as ‘Number of deaths due to HIV/AIDS (HIV/AIDS)’ or ‘Nursing and midwifery personnel (per 10,000 population)’. There are 10 codelists provided in the Indicator Vocabulary. Once a list is chosen, a publisher will include the code representing the codelist.

All vocabularies are included on the IATI website’s Standard Reference page for codelists: https://iatistandard.org/en/iati-standard/203/codelists/

10 of 15

RULESETS

[Date]

These are an agreed way of checking that an IATI XML file complies with the IATI Standard.

IATI Speakers' Kit: 04 IATI STANDARD: A DETAILED OVERVIEW

IATI SCHEMA RULESETS

e.g. Checks that Reporting Organisation has been added (mandatory) and occurs only once.

e.g. Checks that�IATI schema version 2.01, 2.02 or 2.03 has been used.

ORDER OF IATI ELEMENTS

OCCURRENCES

VERIFY IATI SCHEMA VERSION

e.g. Checks that ‘Title’ is followed by ‘Description’ and by ‘Participating-org’.

International Aid Transparency Initiative

The IATI Standard has rulesets that provide additional instructions for IATI publishers. There are two main types of IATI rulesets. They are IATI schema rulesets, and IATI non-schema rulesets.

On this slide, we will look at IATI schema rulesets.

As mentioned earlier (on Slide 74), the IATI Organisation Schema and IATI Activity Schema provide the exact order and structure that organisations should provide in their IATI XML files. The IATI schema rulesets check:

That the order of elements is published correctly. For example, within an IATI activity, the element ‘title’, is followed by ‘description’, followed by ‘participating-org’.
Other rulesets set out and check the occurrences of elements. That is whether data on mandatory elements have been published and whether elements are published the correct number of times. For instance, the element called Reporting-org is a mandatory element and must only occur once.
There are also rules to verify that the all schema rules have been followed for each schema version, whether that is 2.01, 2.02 or 2.03 (IATI Standard versions are explained on Slide 83).

This is not an extensive list but gives you an idea of some of the IATI schema ruleset checks. More information about the IATI schema rulesets can be found on IATI’s website: https://iatistandard.org/en/iati-standard/203/schema/.

11 of 15

RULESETS

[Date]

IATI Speakers' Kit: 04 IATI STANDARD: A DETAILED OVERVIEW

IATI non-schema rulesets provide additional instructions for IATI publishers.

Contain ‘MUSTS’

IATI NON-SCHEMA RULESETS

Percentages for sectors, within a vocabulary (e.g. 1 – OECD DAC), must add up to 100%.

The target must have a value when indicator measure is unit (1), percentage (2), nominal (3) or ordinal (4).

Dates

Percentages

Results

The actual start date must be before the actual end date.

The transaction date must not be in the future.

International Aid Transparency Initiative

We will now look at IATI’s non-schema rulesets.

As you saw in the previous slide, IATI XML schemas set out the structure of an IATI XML file, and the schema rulesets checks against this. However, the XML schemas cannot enforce all the rules of the IATI Standard on their own. For example, the IATI Activity Schema, as it stands, cannot check to see if an activity has a start date that occurs before its end date.

This is where non-schema rulesets are needed. Non-schema rulesets enforce rules that contain ‘MUSTS’ in the IATI Standard. Machines are able to test for these rules, given the correct instructions. Non-schema rulesets provide what those instructions should be, and group rules into meaningful collections.

On the slide, there are a few examples of IATI rules that contain ‘musts’.

The middle example shows that if an activity falls within multiple sectors, the percentage of finance allocated for each sector must add up to 100%. If the percentage is less or more than 100%, the file will not pass the IATI rule and there will be an error.

All rulesets can be found in here: Data4Developement's IATI Ruleset repository: https://github.com/data4development/IATI-Rulesets

12 of 15

NAMESPACES AND EXTENSIONS

[Date]

They allow organisations to publish extra information not currently covered by the available IATI elements.

IATI Speakers' Kit: 04 IATI STANDARD: A DETAILED OVERVIEW

International Aid Transparency Initiative

‘Namespaces’ and ‘extensions’ allow organisations to publish extra information not currently covered by existing IATI elements. They also allow organisations to publish their internal data using the original formats or values to avoid information loss. Here is how namespaces and extensions can be used:

Use an XML namespace to extend the IATI schema. The first approach allows organisations to invent any required markup and add it to an IATI Activity File. For instance, an organisation could add a specific reference about its risk assessment for the activity. The extended markup does not harm the compatibility of the data with the IATI Standard. IATI users that do not recognise the extended markup are required to simply ignore it without reporting an error. Users that are familiar with the namespace, however, can take advantage of the additional information.

Extensions. An extension can be added when data cannot already be reported within the IATI Standard. For example, this could be the ability to report the name of the publishing tool that an organisation is using. Or when the rules in IATI mean that you cannot publish what you need using existing elements and attributes. Extensions are normally created by a group of publishers deciding on the use case and then adding the same extension into their data. Extensions are managed by the group of organisations that created it, and extensions are not formally part of the IATI Standard. Those groups that want to create extensions should note that publishing tools tend not to support the use of them.

Technical users who are interested in namespaces and extensions should refer to the IATI website: https://iatistandard.org/en/iati-standard/203/namespaces-extensions/

13 of 15

VERSIONS OF THE IATI STANDARD

[Date]

IATI Speakers' Kit: 04 IATI STANDARD: A DETAILED OVERVIEW

The IATI Standard has been upgraded to meet changing demands for data.

Use the most up-to-date version of the IATI Standard: v2.03.

STANDARD

v2.03

Version 1 deprecated in 2019

v2.02

v2.01

v1.01

v1.02

v1.03

v1.05

International Aid Transparency Initiative

The IATI Standard has been upgraded over time to meet changing demands for data. Since the launch of the first version of the IATI Standard, version 1.01, it has been upgraded 5 times. Versions include 1.02, 1.03, 1.05, 2.01, 2.02, and 2.03. These changes include one major upgrade from version 1 to version 2. Each upgrade process has involved consultation with the IATI community.

It is important to note that since 2019, version 1 of the IATI Standard has been deprecated, so IATI publishers should no longer use this (more information can be found here: iatistandard.org/en/news/notice-iati-standard-version-1-is-deprecated/).

IATI encourages all publishers to use the content of the most recent version of the IATI Standard, version 2.03.

Version 2.01 and 2.02 are also supported versions of the IATI Standard and can be used by publishers.

Detailed documentation about each version of the Standard can be found on the IATI website: https://iatistandard.org/en/iati-standard/upgrades/how-we-manage-the-standard/versions/

14 of 15

HOW TO CHANGE THE IATI STANDARD

[Date]

IATI Speakers' Kit: 04 IATI STANDARD: A DETAILED OVERVIEW

BUG �FIXES

CODELIST �CHANGES

MINOR �UPGRADE

MAJOR

UPGRADE

When: �Ongoing

Where:

IATI – GitHub

When: �Ongoing

Where:

IATI Discuss

Online community forum

When: �Periodically

Where:

IATI Discuss

IATI Governing Board initiates and approves the upgrade

When: �Periodically

Where:

IATI Discuss

Members’ Assembly initiates and approves the upgrade

International Aid Transparency Initiative

There are several ways in which changes to the IATI Standard can be made:

Bug fixes: At any point in time, if a user identifies a bug with the IATI Standard they can raise an issue on Github. These are backwardly compatible bug fixes. Changes are implemented by the IATI Technical Team under the approval of the Secretariat.

As explained in the slide on codelists (Slide 78), there are different types of IATI codelist. Changes to non-core codelists can happen at any time and changes are posted on IATI’s community forum, Discuss https://discuss.iatistandard.org/c/standard-management/35. Changes to IATI core codelists require an IATI Standard upgrade process. Full information about codelist management can be found at: https://iatistandard.org/en/iati-standard/upgrades/how-we-manage-the-standard/codelist-management/

IATI Standard Upgrades: Periodically IATI runs two types of IATI Standard upgrade processes: a minor and major upgrade. This is a chance for the IATI’s community of publishers and data users to suggest additions and changes. This process takes several months and involves IATI’s entire community.

Minor upgrades can cover changes that are optional and backwardly compatible. The Governing Board is responsible for initiating, overseeing and approving the upgrade. Minor upgrades include:

Bug fixes, including resolution of spelling and grammar errors (where edits have implications for usage and/or meaning)
Modifications to core codelists
Minor additions to the Standard that improve the functionality without introducing substantial new content.

Major upgrades can cover non-backwardly compatible changes. IATI’s members are responsible for initiating and approving the upgrade at Members’ Assembly meetings (see Presentation 05 Governance and IATI story so far). The IATI Governing Board is responsible for overseeing the process. Major upgrades can include:

Substantial additions to the Standard
New mandatory fields
Changes that are not backwardly compatible.

More information about IATI Standard Upgrade processes can be found on IATI’s website: https://iatistandard.org/en/iati-standard/upgrades/

1 of 15

2 of 15

3 of 15

4 of 15

5 of 15

6 of 15

7 of 15

8 of 15

9 of 15

10 of 15

11 of 15

12 of 15

13 of 15

14 of 15

15 of 15