Add vocabularies to aid-type (included 2.03)

This proposal is part of the 2.03 upgrade process, please comment by replying below.

Standard
Activity

Schema Object
iati-activity/default-aid-type/@vocabulary
iati-activity/default-aid-type/@vocabulary-uri
iati-activity/transaction/aid-type/@vocabulary
iati-activity/transaction/aid-type/@vocabulary-uri

Type of Change
Schema addition
Codelist addition

Issue
Defining types of aid (project-type interventions, budget support, debt relief, technical cooperation, etc) is a critical piece of data for users to understand and analyse IATI data. The global standard for this classification is the OECD DAC CRS Type of Aid codelist. This is currently the only list available in the IATI standard. There are, however, use cases in which additional information may be required to define the aid modality. The standard can accommodate this by allowing additional vocabularies from recognised sources to be used in addition to the DAC list.

Proposal

  • Allow for multiple occurrences of iati-activity/default-aid-type and iati-activity/transaction/aid-type elements
    • Occurs 1..*
  • Add attributes iati-activity/default-aid-type/@vocabulary and iati-activity/transaction/aid-type/@vocabulary
    • Definition An code for the vocabulary aid-type classifications. If omitted the AidType codelist is assumed. The code must be a valid value in the AidTypeVocabulary codelist.
    • Occurs 0..1
  • Add attributes iati-activity/default-aid-type/@vocabulary-uri and iati-activity/transaction/aid-type/@vocabulary-uri
    • Definition The URI where this vocabulary is defined
    • Occurs 0..1
  • Guidelines
    • Each selected vocabulary should only be used once for each activity (iati-activity/default-aid-type) or transaction (iati-activity/transaction/aid-type)
    • All activities and/or transactions should contain a code from the DAC Type of Aid Vocabulary
    • The above guidelines should be converted to rules at the next integer upgrade.
  • Add AidTypeVocabulary codelist
    • A non-embedded codelist should be created

Standards Day
It was recommended that the IATI Technical Team and IATI WP-STAT members engage with the OECD DAC with regard to future modifications to the DAC Type of Aid codelist. There was also consensus that the vocabulary approach could provide more flexibility/granularity.

Links

This topic has been included for consideration in the formal 2.03 proposal

Have the IATI Tech Team and the IATI WP-STAT members engaged? If so, what was the outcome?

Main question: is there a use case that makes this an important issue to address now?

1 Like

These are very relevant questions. Are there answers?

Wouldn’t the Purpose Code be the thing that needs attention? Or a marker?

If DFID gives UNHCR money to do multipurpose unconditional cash grants, then the Type of Aid (which seems to describe the nature of the understanding between DFID and UNHCR in this context) does not appear much different from UNHCR doing a range of in-kind services.

Couldn’t you argue that the type of aid is the same, but the manner of delivery is different, which could be captured in CRS Purpose Codes or a new Marker?

I fail to see why has this been included in 2.03? I see no valid use case and there seems to be no consensus on this topic.

Agree with Herman.

In addition, I am surprised that the suggestion (made in another post, not sure which one though) of using the Expenditures element to address the use case isn’t reflected above.

For my response on the issue of classifying cash transfers please see this post.

The first use case for adding a vocabulary here relates to the Grand Bargain commitment to reduce the earmarking of donor contributions, for which a classification system of earmarking modalities has been developed (see Annex 1 to the Grand Bargain).

I think it is correct for the standard to include this classification. It could be introduced as a new element, but it seemed logical to add it as an aid type vocabulary.

@bill_Anderson: thank, this sheds some light on this topic.

Concerning the classification of cash transfers apparently some work needs to be done.

Concerning the earmarking discussion: this reminds me of the DAC classification for core (=non-earmarked) and non-core (=earmarked) contributions. This is a part of the DAC aid-type classification. The classification above looks like a more fine-grained classification solely for the purpose of distinguishing between all shades of earmarking.

So the question seems to be: do you just want to indicate the level of earmarking (the first colored column) or do you want to represent all aid types (the 2nd and 3th column) in IATI. If you only want to do the former, I would say a 4 valued code list and one additional element would be enough. If you intend the latter, I would be very reluctant since we are than introducing a fully fledged new Aid typology where we already have one in the form of the international DAC standard aid typology.

I agree with @YohannaLoucheur that we should be careful with introducing new aid typologies.

You ask what I want to do? As Technical Lead I want to reflect IATI’s commitment to the Grand Bargain (a commitment shared by many of its members including the Netherlands and Canada).

Signatories of the Grand Bargain have committed to the use of a system for classifying earmarking modalities which contains 12 values grouped into 4 categories.

If you disagree with this, is this not a matter for your humanitarian colleagues to take up in Grand Bargain channels?

I believe we have a misunderstanding here. The discussion is not if we should add the possibility to add earmark modalities to IATI or not. The discussion is about how we should do that.

The Grand Bargain requirement is that donors and aid organizations are transparent about their level of earmarking, so that the goal to reduce earmarking of contributions can be monitored.

To meet this requirement it could be sufficient to just add an earmarking element to the activity standard, with 4 possible values defined in a codelist(‘Unearmarked’, ‘Softly earmarked’, ‘Earmarked’, ‘Tightly earmarked’).

I would be very reluctant to add the whole aid typology from annex 1 to the standard for the following reasons:

  • it will increase the chance of inconsistencies when you have two aid typologies. So it will be decrease data quality and it will make aid-typology data harder to use;
  • it would mean moving away from the common standard we have right now;
  • it will mean adding a new, detailed aid-typology to donor’s and aid organizations project management systems. This will take time, if it will happen at all. So it will increase the effort and therefore the barrier to adopt the Grand Bargain requirements.

Can anybody who has been involved in the discussion about the content of Annex 1, shed some light on this (@OJ_?). The text on page 12:

Progressively reduce the earmarking of their humanitarian contributions. The aim is to aspire to achieve a global target of 30 per cent of humanitarian contributions that is non-earmarked or softly earmarked by 2020

suggests that what is enough to make the distinction between earmarked and non-earmarked or softly earmarked.

@bill_anderson @Ben_Parker A possible solution might be to use the same approach for earmarking as is chosen for the CRS purpose code, where a distinction is made between the 3 digits CRS code (high level sector classification) and the 5 digit CRS code (detailed level classification).

An earmarking codelist is, from the IATI angle, a third-party, non-embedded codelist. As is the case with DAC codelists, the content is not under our control. All we need to do is reference the codelist as a valid vocabulary.

@bill_anderson Doesn’t exactly the same argument apply to the CRS purpose 5digit and 3digit codelists? Here we do support both the course and fine level grain for IATI publication.

Apologies, @Herman, I missed this post

which I take to mean that you are happy with both parts of the earmarking list being optionally available.

Do you therefore agree to:

  • Adding a vocabulary attribute to the default-aid-type and aid-type elements. (If no vocabulary is specified the DAC vocabulary is assumed)
  • Adding a non-embedded codelist AidTypeVocabulary

Yes, that would be fine: it would allow IATI publishers to publish on
1 - the high level earmarking (Unearmarked, Softly earmarked, Earmarked, Tigthly earmarked)

OR

2 - on the detailed level (A - L). The high level earmarking can be derived from the detail codes.

I am still a bit doubtful about to call this an aid typology since the whole purpose of Annex 1 is to determine the level of earmarking. Wouldn’t it be an idea to keep this distinction clear by adding this vocabulary a new element ‘Earmarking’?

While there is nothing intrinsically wrong in adding another element, I am personally in favour of adding vocabularies as a more flexible approach to developing the standard.

I also observe from a multi-stakeholder perspective that the DAC doesn’t hold a monopoly in defining aid typologies beyond its membership.

What, for example, will we do if we don’t get a DAC code for cash transfer programming and the Grand Bargain team come up with another taxonomy?

I would prefer that we have one main aid typology since that will keep the IATI standard as close as possible to a common international standard as possible.

Therefore I see the Grand Bargain typology as additional typology for humanitarian aid activities, not as a replacement for the OECD/DAC typology.

That being said, the question remains how to model this in IATI. For me it would not be a showstopper to add the grand bargain classification as an aid typology, if there is an IATI guideline stating that:
1 - the OECD/DAC aid typology is the preferred common aid typology for all constituents
2 - that in addition to the OECD DAC Aid typology, for humanitarian aid activities an additional aid typology can be published for Grand Bargain signatories.

As an afterthought: when looking at the 4 level Grand Bargain earmarking, I suspect it might even be possible to derive the level of earmarking directly from the OECD/DAC typology.

1 Like

Yes, I completely agree with this. This was taken for granted in the original OCHA proposal so apologies for not having made that clear.

1 Like

@bill_anderson @Herman I agree - I had read the orginal proposal as adding an additional optional external codelist to sit alongside the existing OECD/DAC codelist and to provide additional information in specific contexts. That seems a sensible use for a vocabulary.