 |
 |
Thanks to @YohannaLoucheur @markbrough and all those who responded to our call to help develop IATI’s new humanitarian reporting guidance.
We will be updating our draft guidance to reflect the views received so far and will publish a new version for further consultation soon.
In the meantime, you are welcome to continue providing your views on how we best support humanitarian actors by posting here or email to support@iatistandard.org.
@Wendy these are all very interesting discussions.
I’m allowing myself to step in the discussion to introduce the GeOnG conference we organize in Chambéry (France, 1h from Geneva) on October 17-19 : http://cartong.org/geong/2016
GeOnG is one of the biggest conferences in the world on humanitarian information management, with many experts from the IM, GIS and Monitoring & Evaluation from many major agencies present.
We’re having several discussions this year on the topics of data standards and operability (with a focus on the constraints of field operations, as always), with interventions from the Humanitarian Data Exchange platform among others, so we’ve thought the event could be of interest to IATI’s members and community.
Feel free to ping me if you have any question regarding the conference & potential interventions (please get back to me fast then since we’re finalizing the agenda): geong[at]cartong.org
Best regards.
Martin Noblecourt for the CartONG team
Many thanks @CartONG for bringing this to the attention of the IATI community and I’m sure that those interested will contact you directly
I realize I am chiming in late, but I’d like to express support for a couple of the comments that have already been made.
On the humanitarian flag, I agree with @YohannaLoucheur and @markbrough that it would be best for publishers to use this if any aspect of an activity is related to humanitarian response. The suggestion to split projects into two seems impractical, and I’d foresee many challenges for our members at least if this were the recommended guidance. I believe it would also be difficult for organizations to mark individual transactions as humanitarian if an activity has both humanitarian and development components.
On sectors, we have faced the same issue @markbrough raises with the DAC sector codes: the humanitarian codes alone are not sufficient for understanding the nature of the humanitarian activities taking place. It seems like it would be ideal not to have to use two separate vocabularies to get at this (DAC and clusters), but I admit I’m not sure what the solution here is.
Finally - one general comment: it would be really useful to understand why it is important to provide all of the requested pieces of information. If you could provide publishers with some indication of how each element might be used by FTS or others, or what the rationale was for including those elements in this “humanitarian standard,” that could help organizations justify the investments they might have to make in adapting their systems to publish this data.
Correct me if I am wrong, but according to this dashboard page (http://dashboard.iatistandard.org/element/iati-activity_@humanitarian.html), there are almost no donors using the 2.02 humanitarian flag introduced over a year ago, even those signed up to the “Grand Bargain”.
I see ECHO but apart from them, which other donor has adopted this marker?
Thanks
Ben
Grand Bargain signatories:
Australia
Belgium
Bulgaria
Canada
Czech Rep
Denmark
ECHO
Germany
Italy
Japan
Luxembourg
Netherlands
Norway
Poland
Sweden
Switzerland
UK
US
As an update to this post (and related to another to another Discuss post please find the latest update guidelines for humanitarian reporting here
Wendy, thank you for posting the revised draft guidelines for humanitarian data.
I went over the revised version and would suggest the following minor changes to increase their clarity and usefulness:
Step 1 ends by saying that activities should be encoded as per steps 2 to 7. Strictly speaking, step 7 is not about encoding and should be treated separately.
Step 2, under Exceptions, minor changes were made to soften slightly the notion that humanitarian and development activities should be split. Yet, you had received unanimous feedback that this would be impossible if not unadvisable. I would recommend to drop this part entirely. At the very least, the last sentence should be revised: saying that the flag should be added to the transaction rather than the activity contradicts all the feedback received above.
Increase clarity by adding a new step 3: Determine whether the activity responds to an emergency and/or an appeal. This will signal to readers that not all activities relate to an emergency or an appeal. Otherwise the current step 3 looks like a mandatory step (“Define which emergency the activity is responding to” does not leave room for the possibility that it may not relate to one).
In the current step 5 (which would now be 6), make readers’ life easier by providing the link to the UN cluster codelist.
Current step 7 is not about the elements or coding, so would suggest to create a new section (maybe called Publishing?)
We look forward to revised guidance on humanitarian data, and the results of the upcoming pilot.
Thank you @YohannaLoucheur and rather than create another version of the existing guidance here I shall flag these comments to our colleagues at FTS to integrate into the revised guidelines currently being worked on. @ximboden
Thank you Wendy.
I’m a bit concerned about waiting for UNOCHA-FTS to correct the existing guidance.
You said in post 1132: “However, as part of the work for the Grand Bargain Transparency Workstream (and also for the IASC HFTT) FTS are going to be running a pilot during the first half of 2018 to start processing published IATI data and they are planning to further develop the existing guidelines as a result of that process.”
This means it would take several months to get new guidance. In the meantime, people looking for guidance may arrive here and use the note provided in Joni’s initial message.
I think it really would be better to correct the note before the pilot starts, especially with regard to the second bullet in my previous message.
Thanks @YohannaLoucheur and just to confirm that under current plans FTS are planning to revise the existing guidelines by the end of Dec 2017 (and so can pick up the amendments here) and then further revise them in light of any finding from the pilot (currently due to run to Jun 2018). Hope that helps
I agree 
with you:+1:, I’m new in this community and trying to survive by Learnings from you all. Thank you so much
Does anyone know where these guidelines are at? The version that Wendy shared last November (above) appears unchanged, but perhaps there’s an updated version available somewhere else? @ximboden, would you know?
I’m also keen to know the status of this. There’s a new news item about the pilot on the Aid Transparency site this week. Would be good to get specifics in terms of the direction and version of the guidance (last updated Nov 2017)…
Dear all,
Reviving an old discussion!
In the meantime, based on @Wendy’s initial draft, in collaboration with a.o. @David_Megginson @stevieflow @rbesseling @Herman, the Netherlands ministry has developed DRAFT Humanitarian guidelines. Through this process we aim to achieve a common understanding and use of these data elements, serving multiple use cases - e.g. informing UN OCHA’s Financial Tracking Service (FTS).
We consider these guidelines as an addendum to the general NL IATI publication guidelines - in order to maintain the benefits of having linked and traceable IATI data.
Through these group discussions we’ve hopefully tackled most the points of discussion around the use of the humanitarian elements.
Looking forward to your thoughts and input! Either in the Google Doc, or in this thread.
We’re also planning a round of consultations with (a number of) our direct partners in humanitarian aid, to further inform the discussion.
Pelle
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!
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?
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.
@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)
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.
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:
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…