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?

Comments (38)

Bill Anderson
Bill Anderson
Image removed. stevieflow:

But - It seems if we sharpen the description:

Image removed. YohannaLoucheur:

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.

… then that might help…

I agree (and it should remain a Boolean)

Steven Flower
Steven Flower

Hi matmaxgeds

Understood. I think this was part of my earlier confusion:

Image removed. stevieflow:

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 !

But - It seems if we sharpen the description:

Image removed. YohannaLoucheur:

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.

… then that might help…

Steven Flower
Steven Flower
Image removed. markbrough:

I think your intention is to remove the “or partially”

Thanks. No - the intention is along the lines of

Image removed. YohannaLoucheur:

In short: someone would not declare “partially”. This sentence rather means “if an activity relates to humanitarian aid, even partially”.

Have I made it even more unclear? Oh no!

Steven Flower
Steven Flower

Thanks Yohanna Loucheur Andy Lulham

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
Andy Lulham
Image removed. stevieflow:

doesn’t fully support this

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 Steven Flower . That doesn’t sound consistent to me.

Bill Anderson
Bill Anderson
Image removed. YohannaLoucheur:

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

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

Yohanna  Loucheur
Yohanna Loucheur

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

Image removed. stevieflow:

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

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
Bill Anderson

I agree this is inconsistent. Does this work?

  1. At activity level

A process flag to indicate that this activity relates to humanitarian aid, even partially.

  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
Steven Flower
Image removed. bill_anderson:

flag indicating “0” for development and “1” for humanitarian.

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 !

Steven Flower
Steven Flower

Hi matmaxgeds

Understood. I think this was part of my earlier confusion:

Image removed. stevieflow:

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 !

But - It seems if we sharpen the description:

Image removed. YohannaLoucheur:

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.

… then that might help…

Yohanna  Loucheur
Yohanna Loucheur

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
Mark Brough

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
Yohanna Loucheur
Image removed. markbrough:

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.

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

Steven Flower
Steven Flower
Image removed. YohannaLoucheur:

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

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

Yohanna  Loucheur
Yohanna Loucheur
Image removed. stevieflow:

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

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

Wendy Rogers
Wendy Rogers

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?

Steven Flower
Steven Flower
Image removed. Wendy:

Its been a while but work has now restarted on updating the IATI humanitarian guidelines.

Thanks Wendy Rogers . 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

Mark Brough
Mark Brough

Steven Flower I am a little unsure what the goal is here - I think your intention is to remove the “or partially” from the description “indicate that this activity relates entirely or partially to humanitarian aid”?

I am not sure that is a good idea. It seems as though it would rule out Wendy Rogers ’s point 3 (quoted below). I have argued above that this is important because:

a) a single project shouldn’t be split into artificial components, because it makes reconciliation of project units more difficult and

b) you may know that an activity is partially related to humanitarian aid, but not the precise amount, and your accounting system may not (I guess, often will not) be able to tell you precise amounts at the transaction level. I think the use of humanitarian DAC codes would be a better way of roughly stating the amount of aid that is humanitarian in nature.

Image removed. Wendy:

  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
David Megginson
David Megginson

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
Steven Flower

Hi all

In response to this, I’ve formatted this table to illustrate the permutations one could see with the humanitarian flag at activity and/or transaction level:

Image removed.

I also subscribe to the proposal from David Megginson , but also want to flag (!) how we can see a wide range of uses - all of which are valid (in terms of schema validation, at least).

With the FTS IATI pilot we will discuss this - so just raising a humanitarian-flag for Nick Imboden Wendy Rogers leo stolk Pelle Aardema Herman van Loon Daniel Mackenzie Roderick Besseling r_clements

David Megginson
David Megginson

Thanks, Steven – that’s a great table for organisations consuming IATI data. For organisations producing IATI data (as we discussed after you posted this), we would want to discourage some of these combinations, especially given the standard’s guidance that “1” should be set at the activity level if one or more transactions are humanitarian.

Steven Flower
Steven Flower

Thanks David Megginson

OK - if we agree that there are many combinations that anyone trying to process IATI data might have to consider, we can now look at (and you’ve said this already!) what we would consider as best practice amongst publishers:

(NB: I’ve a google doc with this, if anyone finds it easier to comment there)

If we consider these two publishing conditions to be acceptable:

Image removed.

We then have a reduced number of best practice combinations of the humanitarian flag:

Image removed.

Is this what we want ?

Moving on, it seems there’s two main actions:

  1. Revise the description of the humanitarian flag (as originally discussed) - consider this as bug fix of the standard
  2. Publish this Best Practice guidance for the community, and link to it from the documentation

I hope this gets us to a satisfactory place! It seems a real lesson in terms of introducing a relatively simple attribute to the standard, but then learning from the reality of implementation.

Mark Brough
Mark Brough

Steven Flower I am a little unsure what the goal is here - I think your intention is to remove the “or partially” from the description “indicate that this activity relates entirely or partially to humanitarian aid”?

I am not sure that is a good idea. It seems as though it would rule out Wendy Rogers ’s point 3 (quoted below). I have argued above that this is important because:

a) a single project shouldn’t be split into artificial components, because it makes reconciliation of project units more difficult and

b) you may know that an activity is partially related to humanitarian aid, but not the precise amount, and your accounting system may not (I guess, often will not) be able to tell you precise amounts at the transaction level. I think the use of humanitarian DAC codes would be a better way of roughly stating the amount of aid that is humanitarian in nature.

Image removed. Wendy:

  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
Steven Flower
Steven Flower
Image removed. markbrough:

I think your intention is to remove the “or partially”

Thanks. No - the intention is along the lines of

Image removed. YohannaLoucheur:

In short: someone would not declare “partially”. This sentence rather means “if an activity relates to humanitarian aid, even partially”.

Have I made it even more unclear? Oh no!

Mark Brough
Mark Brough

Sorry for slow reply Steven Flower - yes, looks good! I think I was just confused by the language in the table in your comment but I get what you’re trying to do now.

And matmaxgeds , I think if you want to (and are able to) state a specific percentage that is humanitarian then you can use the DAC humanitarian sector codes and percentages.

matmaxgeds
matmaxgeds
Image removed. markbrough:

then you can use the DAC humanitarian sector codes and percentages.

What if you are not using the DAC sector vocab, perhaps using the humanitarian clusters as the sector vocab?

matmaxgeds
matmaxgeds

I don’t follow why it should remain a boolean - did I miss the reasoning somewhere, or is it just a reluctance to change the standard?

Unless we change it, it seems to me that we cannot calculate a figure for the share of an activity that is purely humanitarian support without relying on the sector codes being the DAC sectors, therefore making them mandatory for reporting humanitarian support (or inferring it from the organisations involved), neither of which seem like the right/IATI way of doing things.

Bill Anderson
Bill Anderson
Image removed. matmaxgeds:

we cannot calculate a figure for the share of an activity that is purely humanitarian support

Correct, 'cos in the real world an exact calculation is often not possible. This is corroborated by Mark, Wendy and Yohanna above.

matmaxgeds
matmaxgeds
Image removed. bill_anderson:

Correct, 'cos in the real world an exact calculation is often not possible. This is corroborated by Mark, Wendy and Yohanna above.

That is what a separate ‘partial’ flag is for, leaving the ‘humanitarian = 1’, and ‘humanitarian = 0’ for when you can tell, and is why moving away from a boolean would help the accuracy.

Yohanna  Loucheur
Yohanna Loucheur

Matt, I don’t believe (based on feedback from humanitarian folks) that we can get to the accuracy you aspire to.

I do think we should correct the guidance, as we’ve been discussing for a long time now.

matmaxgeds
matmaxgeds

Thanks Yohanna, if it is a bridge, or PFM, then it is clearly not humanitarian, if it is emergency food aid, then it clearly is - for everything else, use the ‘partial’ marker. I agree it is sometimes not clear (I am in Somalia right now and discussed coding with UNOCHA and others on Tuesday) but this doesn’t mean that it often isn’t clear. I will give it up now, but this seems like the same situation as the DAC markers i.e. there are clearly yes bits, clearly not bits, and partial bits - hence the need for 0, 1 and 2, not a boolean, because if the DAC markers had one called ‘principally or maybe significant but not principal’ it would be silly and far less use. This idea about if it is a hard call to make then we should bundle two categories together seems a completely false line of reasoning, that is exactly why we need a category to reflect those hard calls so that the other categories mean more.

Yohanna  Loucheur
Yohanna Loucheur

I am reviving this thread to ask where we’re at regarding the correction to the guidance on humanitarian data, as discussed at length above (and in other threads related to humanitarian data)?

The reason I ask is because the 2016 document that presented guidance that pretty much everyone agrees is wrong is still online and misleading people (point in case: a colleague just sent it to me).

It would be great if the IATI Technical Team could update the guidance in light of the feedback that has been provided since its publication; if this is not feasible, it would be better to remove it for the time being.


Please log in or sign up to comment.