 |
 |
The spreadsheet of changes includes an entry for iati-activities/iati-activity/tag/narrative/text().
This is not an element or attribute. The definition should be under iati-activities/iati-activity/tag/narrative. This is an element, so does not have a type.
EDIT: This appears to be something magic about <narrative> elements being unlike anything else in the Standard, and so this can be passed over with no action.
There are inconsistent references to the Aid Type Codelist with respect to the new vocabulary.
The definition for iati-activities/iati-activity/default-aid-type/@code refers to it as:
the OECD DAC vocabulary
The definition for iati-activities/iati-activity/default-aid-type/@vocabulary refers to it as:
the AidType codelist
These should be made consistent so that it is clear that they are referring to the same thing.
Definition’s changed to:
Code: A code from the specified vocabulary.
Vocabulary: A code for the vocabulary aid-type classifications. If omitted the AidType (OECD DAC) codelist is assumed. The code must be a valid value in the AidTypeVocabulary codelist.
See Github: https://github.com/IATI/IATI-Schemas/issues/346 and https://github.com/IATI/IATI-Schemas/issues/345
The definition of iati-activities/iati-activity/transaction/receiver-org/@ref currently states that:
if omitted on incoming funds then the receiver organisation is assumed to be the reporting organisation
The proposed definition removes this information.
Additionally, the Previous Definition in the spreadsheet is incorrect for this attribute.
EDIT: It has been noted that this issue impacts a range of receiver-org/@ref and provider-org/@ref attributes, not just the one specified here.
Comment added to relevant Github issue.
The @value attribute for various things within results is proposed to become optional so that it is clearer how to report qualitative data.
iati-activities/iati-activity/result/indicator/baseline/@valueiati-activities/iati-activity/result/indicator/period/target/@valueiati-activities/iati-activity/result/indicator/period/actual/@valueIt is proposed that 3 Rules are added:
With these Rules…
A note that: Numbers 1) and 2) are Non-Machine Readable, and so will not displayed on the relevant attribute pages (at least with the current architecture).
Additionally, because the attributes are currently so lax in what is allowed (permitting both quantitative and qualitative values, numeric and non-numeric), implementing these as Rules (must) is not backwards-compatible.
#2) can be a Rule at 2.03 because it maintains the status quo. 1) and 3), however, cannot because they would add additional restrictions. They must instead be Guidelines (should).
EDIT: It has been explained how my interpretation of the IndicatorMeasure Codelist is incorrect. I would therefore suggest it may be worth adding something along the lines of This can be used to detail [qualitative|quantitative] indicators. to the Description of Codes in this Codelist.
This corrected understanding changes the above points to:
2.02) to quantitative indicator valuesChanged rule 3 from a must to a should: “the @value should be a valid number for all non-qualitative measures”. See Github issue: https://github.com/IATI/IATI-Schemas/issues/353
A couple of things with {x}Vocabulary Codelists…
ResultVocabulary
It is currently detailed that this Codelist will have 99 and 98 values in a similar way to SectorVocabulary.
The addition of a 98 value seems problematic since it allows partial use of multiple vocabularies, but only to a limited extent. A more versatile option would be to either:
@vocabulary-uri attribute to deem uniqueness (this was introduced as a concept at 2.02, after 98 became a thing with SectorVocabulary).<narrative> sub-element to provide information (partially implemented with sectors, though how to deem uniqueness is slightly unclear).Due to how other @[vocabulary|indicator]-uri attributes are implemented (ie. they lack child narrative elements), 1) appears the preferable option.
Whichever way, 98 codes should be on a path towards deprecation in favour of a more robust solution - more 98 codes shouldn’t be added.
TagVocabulary
This is to be used by an element (iati-activities/iati-activity/tag) with a @vocabulary-uri attribute. It is not proposed that a 99 code is added.
TagVocabulary Codelist should include a 99 code.With regards to the proposal to introduce iati-activities/iati-activity/result/baseline/@iso-date with occurrence rule 1..1.
Is it not the case that decimal upgrades can only add optional fields, so perhaps the occurrence rule should be 0..1?
Occurrence rule changed to 0…1. See Github: https://github.com/IATI/IATI-Schemas/issues/364
It is proposed to change a number of Codelists from Embedded to Non-Embedded.
The following Codelists had their format changed from 1.05 to 2.01. As such, they cannot become Non-Embedded since there is no categorisation to allow particular Codes to exist at only particular integer versions of the Standard:
@petyakangalova (with assistance from others) has been working on a full solution to allow this change to occur, through the introduction of a new category of Codelist.
It is proposed that 4 new Codelists are added:
These have names, though do not appear to have been provided additional details, in particular:
(other details may also be relevant, though the above are essential (some like the prose name and language are obvious, so don’t really require stating, though others may))
I’m wondering what happened to: Adding links to related OCDS contracts (excluded 2.03). The title of that post suggests it was excluded (which I believe just means the proposal as it was originally stated was rejected), but the thread suggests it was included. However, I can’t see any mention of it in the final proposal.
I wonder if budget-omitted might be a pithier name than budget-not-provided (and avoids the negation.)
Like the OCDS contracts, the Results – recognising partner contributions (excluded 2.03) proposal was also included until the 25th October when the title changed to “(excluded 2.03)”, and the post was immediate closed to further discussion meaning no response could be made. Please could someone clarify why it was excluded and why there has not been opportunity for discussion after it was dropped from the upgrade process on the 25th October? The IATI @IATI-techteam also emailed me to check the results proposals on the 25th October and respond but because the posts are closed I cannot do so. Should I include my response here?
OCDS link was omitted because @TimDavies, on second thoughts, felt some more work was required to get this right.
Thinking things through, I think that result/indicator/@aggregation-status can only be 1 if result/indicator/@measure is 1 (Unit)
Percentages, scales and qualitative results can’t be aggregated.
@mikesmith: the “Results – recognising partner contributions (excluded 2.03)” proposal was probably omitted because I expressed my doubts.
(this post is in reference to Results – recognising partner contributions (excluded 2.03) )
Hi @pelleaardema thanks for the response, please could you provide some reasoning behind your doubts - for example many of the 2.03 proposals “add complexity” why in particular should this one not be accepted? Also e.g. @Herman queried in your referenced post Our shared understanding of what IATI is, and is not, if the "propose to defer the adoption of the IATI 2.03 upgrade” - but the community has collectively decided that there will be a 2.03 upgrade. It would be good to understand what your reasoning is.
To help provide the UK NGO and Nethope consultation perspective, this proposal is about improving the consistency of the IATI standard and simplifying IATI reporting. For the former, it’s remiss that transactions are for specific organisations but results cannot be. For the latter, I think we can agree that IATI should not cause a fundamental redesign of our work, just for IATI reporting ( see Results – represent more than quantitative data (included 2.03) and other comments). For example one currently has to artificially split an activity because you cannot assign different parts of the results framework to different organisations. This requires duplicating data (eg, title, description) and designing projects to a level of detail beyond that is required for internal management and donor reporting (eg you have to split budgets, organisation spending etc. by individual results, partners etc.). Some overarching results (ag indirect advocacy ) can’t be split so must also be treated separately. This all adds up to very complicated reporting which is even highlighted in the document that is referenced (https://www.drostan.org/wp-content/uploads/2017/05/Partos-IATI-Results-2017-report-of-meetings.pdf ) in the post that @pelleaardema you refer to (Our shared understanding of what IATI is, and is not, ) "there are no ways to indicate the boundary of a partnership, or to better mark activities as joint activities. This can lead to overlaps and duplications.”. They also talk about this problem of having to change the fundamental way projects are managed under the section "How do you coordinate working with the same indicators in a partnership?” which I know has caused a number of organisations a headache. The additional coordination effort to produce reports (with various additional discussions, sign-offs between organisations etc.) just to report in this way is substantial. A simplified example (in practice there are often many more indicators) , 5 partners, 5 indicators (2 of which overarching):
requires artificially splitting 1 activity into 5 (red ellipses marking the activity boundary) just so that they can be reported in IATI. As well as causing duplication and confusion, there is substantial effort involved in splitting finances per each activity (doesn’t sound like much but this is in effect adding an additional dimension to all financial reporting in an organisation) which is beyond what most NGO systems can do at the moment, and adds a huge overhead to our programmes staff, just for IATI. This proposal alleviates these problems by not forcing artificial splits.
Hi @mikesmith,
I understand what you’re trying to do, but I’m in doubt about the proposed solution.
In general adding elements to reduce complexity would not be my preferred solution. IATI is already perceived as a complex standard, and from my experiences with many different publishers I am doubtful if this specific proposal makes their lives easier - let alone for users of the data, for whom it will introduce yet another dimension to take into account when dealing with results.
In line with our joint statement I’m in favour of making changes to the standard supported by very clear ‘use cases’ and inline with a common understanding of what IATI is and is not. I feel we are not there yet, so let’s please take some more time to share and learn from each other’s experiences.
Now preparing Requests for Change proposals for 2.03 changes.
Can you please confirm that codelist change, the new organisation “type 24” is meant for ‘partner countries based NGOs’.
Oxfam Novib so far used type 22 (National NGO) for NGOs based in partner countries, operating at national level, and sub national level.
The description in the upgrade list suggests that type 22 refers to NGOs based in donor countries. Understood from Charter4Change perspective, that the distinction between a (partner country based) national NGO and (partner country based) Internationally affiliated NGO or INGOs, is important.
Noticed in discuss that others also expected type 24 to identify a Partner country based INGO.
just seek confirmation that 24 = partner country based NGO. and that 22 is donor country based NGO. l
@stolk Apologies for the significant delay in getting back to you.
Can you please confirm that codelist change, the new organisation “type 24” is meant for ‘partner countries based NGOs’.
Yes, this is correct.
The mapping spreadsheet that was shared by @Wendy during the upgrade discussion for this proposal also has descriptions that probably make the distinction between 22- National NGO
24- Partner country-based NGO clearer. Also direct link in here.
For clarity, I will add the descriptions from the spreadsheet to the new organisation types to the relevant Github issue so that they can be incorporated as part of the 2.03 upgrade process.
Dear @IATI-techteam, as I review 2.03 schema and changelog carefully I’m noticing a few mistakes, typos etc. What would be the best way to report these?
Hi @YohannaLoucheur where you’ve spotted mistakes could you please send us the details to support@iatistandard.org? We’ll take a look first off at what kind of errors there are and how best to fix them.
Thank you.