Humanitarian flag - " entirely or partially"


(Steven Flower) #1

The definition of the humanitarian flag attribute, at activity level declares:

A process flag to indicate that this activity relates entirely or partially to humanitarian aid.

It’s a boolean - so my understanding is that 1 = Yes, 0 = No

Therefore, how would someone declare “partially”, at the activity level?


(Siem Vaessen) #2

@stevieflow ask @TDahlfors, she became rather proficient in setting this attribute.


(Yohanna Loucheur) #3

This was discussed in another post, in relation to the guidance the Secretariat was drafting. Changes to the Standard to fit Grand Bargain priorities

In short: someone would not declare “partially”. This sentence rather means “if an activity relates to humanitarian aid, even partially”. So if there’s a humanitarian component/aspect to the activity, you would code 1=Yes.


(Andy Lulham) #4

^^ This wording is muuuch clearer, in my opinion.


(Steven Flower) #5

Thanks @YohannaLoucheur @andylolz

Agree - that wording is clearer.

However, there’s some guidance in the IATI Humanitarian Best Practice that doesn’t fully support this, imho:

If an activity has both a humanitarian and development component then the publisher should consider splitting the activity into two; one activity to describe the humanitarian component and the other to describe the development activity.


(Andy Lulham) #6

It seems consistent to me.

  • Best practice: consider splitting it; use humanitarian="1" for one, and humanitarian="0" for the other
  • If you decide not to split (for whatever reason): use humanitarian="1"

Does that seem like the correct interpretation?


EDIT: Oh – I see what you mean:

If splitting the activity is not possible then the activity should still be encoded with all related humanitarian elements. In this case, the flag should be added to the transaction rather than the activity and only the transactions that relate to the humanitarian activity should be encoded

Mm… Good point @stevieflow. That doesn’t sound consistent to me.


(Bill Anderson) #7

I agree this is inconsistent. Does this work?

  1. At activity level
  1. At transaction level

If an activity has both a humanitarian and development component then the publisher should consider splitting the activity into two; one activity to describe the humanitarian component and the other to describe the development activity.

If splitting the activity is not possible then it is recommended that where possible all transactions contain the flag indicating “0” for development and “1” for humanitarian.


(Steven Flower) #8

Sorry @bill_anderson - I get confused by this (it could well be me) – as I understand a boolean / flag to be Yes/No or True/False or 1/0 in terms of humanitarian. Bringing in “0 = development” seems like a … codelist !


(Bill Anderson) #9

“0” = not humanitarian


(Yohanna Loucheur) #10

No, splitting things up at the transaction level doesn’t work.

If you go back to the main thread on this topic Help develop IATI’s humanitarian reporting guidance (sorry, I posted the wrong one above), you will see that we flagged this problem waaaaayyyyy back when.

I asked repeatedly for this DRAFT guidance to be corrected, precisely to avoid leading people down the wrong path, but nothing happened. It’s a bit frustrating, honestly.


(Bill Anderson) #11

Why doesn’t this work? No one objected to a flag at transaction level when it was introduced into the standard.


(Yohanna Loucheur) #12

For the reasons explained in the other thread.

It’s fine to have the possibility to do it, but it should not be presented as the preferred way to do it.


(Mark Brough) #13

I think it is a really bad idea to split a single project into artificial components and a bad precedent to set. Project IDs will no longer be consistent between published data and source systems, making reconciliation between different systems (e.g. IATI and local AIMS) more difficult. Activity-based reporting is an advantage of IATI over the CRS’s transaction-based reporting.

We have seen this a lot with donors breaking projects into multiple activities for each sector and country, where it significantly increases the amount of noise in the data. See for example Swedish projects here (Sweden is in the process of correcting this). The project beginning SE-0-SE-6-5204006501- is broken into three activities (one for each sector code 72010, 72040, 72050) and many more activities when you consider the other countries this project is active in.

USAID recently corrected the same issue in their data and it made their data far more useful and usable.


(Yohanna Loucheur) #14

Thanks for this Mark. Will be useful in an (unrelated) discussion regarding the “right” amount of project disaggregation by country and sector.


(Steven Flower) #15

Yes, I agree. Should we start a new thread?


(Yohanna Loucheur) #16

Sure. This way we can keep this one focused on correcting the humanitarian guidance as soon as possible.


(Wendy Rogers) #17

Its been a while but work has now restarted on updating the IATI humanitarian guidelines. As a result of the above and other consultations the following scenarios for use (or not) of the iati-activity/@humanitarian and iati-activity/transaction/@humanitarian attributes have been identified:

  1. An activity has no humanitarian component (eg development only)
  • Neither the iati-activity/@humanitarian attribute or iati-activity/transaction/@humanitarian are required and should NOT be included

  • NB there have been some discussions that in this case the iati-activity/@humanitarian attribute should be present but set to ‘0’. Eg iati-activity humanitarian=“0”

  • However, general publishing best practice recommends that unnecessary elements and/or attributes should not be included in an IATI XML file in order to reduce file ‘bloat’ and subsequent file processing overhead & times etc.

  1. All aspects of an activity are humanitarian related
  • The iati-activity/@humanitarian attribute is required
    iati-activity humanitarian=“1”

  • The iati-activity/transaction/@humanitarian attribute is NOT required

  1. Some aspects of an activity are humanitarian related but the activity cannot be split at the transaction level to specifically indicate its humanitarian and other components
  • The iati-activity/@humanitarian attribute is required:
    iati-activity humanitarian=“1”

  • NB Humanitarian and other related DAC sector codes with a percentage split should also be present in this situation

  • The iati-activity/transaction/@humanitarian attribute is NOT required

  1. Some aspects of an activity are humanitarian related and the activity can be split at the transaction level to specifically indicate its humanitarian and other components
  • The iati-activity/@humanitarian attribute is NOT required

  • The iati-activity/transaction/@humanitarian attribute is required and should be used on ALL transactions. Eg

  • If a transaction is humanitarian related
    transaction ref=“1234” humanitarian=“1”

  • If a transaction is NOT humanitarian related
    transaction ref=“1234” humanitarian=“0”

NB One issue that has been raised in relation to this option is that it does mean that from a data processing perspective there is a big overhead of having to check both the activity and at least one transaction of every published activity to identify if an activity is ‘humanitarian’ or ‘not’.It would therefore be interesting to get the view of other developers on this?


(David Megginson) #18

Thanks for sharing that, Wendy. My proposal is slightly simpler:

  1. iati-activity/@humanitarian sets the default for child transactions: if iati-activity/@humanitarian is “1,” then every child transaction/@humanitarian defaults to “1” unless overridden; if it is “0” or omitted, then every child transaction/@humanitarian defaults to “0” unless overridden.

  2. recommended best practice is to set iati-activity/@humanitarian to “1” if any child transaction is humanitarian: while not strictly required for data processing, this practice makes it easier to scan quickly for activities that have some humanitarian component (however small).

This proposal follows the rule of least surprise by conforming closely to the existing model of attributes and elements at the iati_activity level including @xml:lang, @default-currency, default-flow-type, default-finance-type, default-aid-type, and default-tied status, all of which set default values that individual child elements (mostly, transaction) can override on a case-by-case basis.


(Steven Flower) #19

Thanks @Wendy. Please can you indicate when these guidelines would be updated, and which document we should be following. There’s a document online, but that doesn’t provide any indication of how current it is, nor include some of the information above