Help develop IATI’s humanitarian reporting guidance

Consultations
#22

Hi all,

One of the difficulties we are having using IATI humanitarian data in Somalia (great that we can even have this issue though!) is that because the GLIDE sector-vocab=10 is not embedded into IATI, it is much harder to show our users what something that appears in IATI as

<sector vocabulary="10" code="7" percentage="35.00"/>
<sector vocabulary="10" code="9" percentage="35.00"/>
<sector vocabulary="10" code="11" percentage="30.00"/>

Really refers to. In order to decode this, we have to seperately maintain mirrors of the non-included codelists and most of the fragile states I work in have difficulty with this.

My preferred option would be for the GLIDE codelist to be brought inside IATI (where it could be maintained once, and benefit all) - it also seems fair that it should be given equal standing to the DAC codelist if IATI is serious about the Grand Bargain.

However, that seems a medium term aim? In the short term, it would be incredibly useful if humanitarian publishers using a non-DAC5 vocab could be encouraged to use the sector @narrative element therefore also give the human readable text. This means that if a codelist changes, our system/users are not left in the dark until we have time to update our local copies.

PS - If the the @narrative element could be mandatory for all non-included IATI code-lists this would be incredibly useful!

Request use of @narrative when using 'non-embedded - external' codelists
#23

Sorry, but no. Making the @narrative attribute mandatory would defeat the purpose of having moved from words to codes in the codelist. If a publisher’s codelist narrative is in eg German, or Chinese, or French, having @narrative won’t help most users. The solution cannot be to provide @narrative in every possible language - we’re already getting into trouble because IATI files are too big.

Isn’t it the/one job of APIs to fetch the narrative that corresponds to a given code?

#24

Yes, except the humanitarian code-list is not included - hence why we are in this pickle - see http://reference.iatistandard.org/203/codelists-guides/codelist-management/ it is classified as ‘Non-Embedded Codelists - External’ and so not available through the code-list API.

I have requested that it would really help if it was included but no luck so far - hence my latest suggestion of using @narrative elements to help out.

I would definitely take a French, German, or Chinese narrative as it is much better than just a number! The @narrative element is already used in this way by publishers using e.g. 98/99 sector vocabs and it really helps us.

#25

@matmaxgeds I assume you mean IASC Cluster codes. Can you not use this? http://vocabulary.unocha.org/json/beta-v1/global_coordination_groups.json

And for GLIDE numbers there is this post - New GLIDE number source available

Personally, I think this is definitely worthy of consideration. @amys @petyakangalova what do you think? (Not for GLIDE numbers, however, as the list changes too often)

1 Like
#26

Hi @bill_anderson - good spot, thanks - I am mixing up the IASC codes with the GLIDE numbers. I mean the IASC Cluster codes.

I can definitely use the links you post, but writing a separate scraper/parser in country-systems for each of the non-core external codelists is prone to failure / not very sustainable (someone has to be constantly monitoring in case they break etc, and who fixes them when they do…) - hence we often don’t manage it and the users get stuck with codes not names.

It would be great if IASC could get included, and for the others, I am starting to think that as a group of users, we should think about maintaining a joint resource mirroring the IATI codelist repo that fills this gap - @andylolz pointed to something similar on a past post - at least then we would all be consistent between users, and benefit from each-others efforts rather than each re-inventing the wheel.

#28

This is well and good but I think this touches on the tensions that are again creeping into some of our discussions (and yes, as an ex-member of the Tech Team, I can get defensive at times).

The community can, and does, produce a range of great tools and services. Voluntary contributions, however, are, by definition, not necessarily sustainable: people move on and leave legacy tools behind. With the best intentions in the world the open data / open source community is not, at the end of the day, accountable to the kind of demands expected of a professional team employed to maintain a global standard.

What the @IATI-techteam is attempting to do is consolidate core products, tools and services that are both reliable and sustainable.
This involves two things:

  • For a number of historical reasons (discussed elsewhere) they have a mountain of technical debt to deal with as part of this consolidation.
  • Establishing a robust architecture that enables the entire IATI core digital estate to be sustainably interoperable, whether developed and maintained in-house or outsourced.

Some in the community may indeed from time to time be frustrated by their efforts. I think the team understands the impatience of the community. They can handle that. But they get frustrated when their integrity is questioned…

2 Likes
#29

hi @bill_anderson - will email to try and not derail the thread. Summary - agreed that discuss is far too combative these days - lets make plans to improve it in Copenhagen - understood that @IATI-techteam cannot take this on at the moment - so thought that suggesting the community stepped in was being supportive - keen to hear if there would be friendlier ways to do that.

3 Likes
#30

Thanks for sharing @pelleaardema - I’ve added the combined comments from UK partners of the MFA who are receiving humanitarian funding. Would you be able to confirm your expectations about when MFA would expect to see organisations start to use these guidelines?