Add budget-exempt attribute and codelist (included 2.03)

Standard Management 2.03 Decimal Upgrade Proposals
,
#1

This proposal is part of the 2.03 upgrade process, please comment by replying below.

Standard
Activity

Schema Object
iati-activity/@budget-exempt

Type of Change
Addition to Schema and Codelists

Issue
One of the key goals of IATI is to improve the predictability of resource flows for users through the provision of forward-looking budgets. Users should expect IATI data to provide them with annual budget estimates across the lifetime of all activities. There are, however, circumstance under which forward-looking data cannot be provided, be it for operational, legal or commercial reason. This modification allows users to know which activities are exempt from providing budget data.

Proposal

  • Add attribute iati-activity/@budget-exempt
    • Definition A code indicating the reason why this activity does not contain any iati-activity/budget elements. The value must exist in the BudgetExempt codelist.
    • Occurs 0..1
  • Add non-embedded BudgetExempt codelist
    • Initial Values 1 - Commercial restrictions 2 - Legal restrictions 3 - Rapid onset emergency

    Standards Day
    Further consultation was requested

    Links

#2

This topic has been included for consideration in the formal 2.03 proposal

#3

I would question the value of adding a specific attribute to state only that the budget field is deliberately not published. I can see the value of being able to state exemptions in a structured way but I don’t think it makes sense to cover only one particular field.

I thought the discussion at Standards Day more or less reached the consensus that adding particular fields into the Standard simply in order to facilitate the calculation of publisher statistics is not a very strong use case.

(As an aside, I would also suggest that the calculation of whether or not an activity should be exempted from requiring forward data is something that should be determined by other things in the data (e.g. activities marked as administrative, humanitarian, or whatever) rather than the publisher’s own choice to not have them assessed.)

1 Like
#4

I would not agree that there was consensus on this. The argument was also made that the primary use case for this is for data users to know whether data on an activity is accurate and complete.

Forward-looking data is one of the most important cornerstones of IATI’s raison d’etre and accurate benchmarking of this dimension is, I would argue, a legitimate exercise.

There is nothing in the data, for example, that defines which humanitarian activities should or shouldn’t contain forward-looking data. Nor is it always clear which activities are covered by legal or competitive restrictions. Self-reporting is not ideal but it is better than nothing and a publisher’s use of it can be spot-checked.

Which other fields require metadata on exemptions that would improve the ability of users to assess and process the data?

#5

There is nothing in the data, for example, that defines which humanitarian activities should or shouldn’t contain forward-looking data.

I think the argument here is that rapid onset emergencies would not necessarily expect to have forward looking data for those activities. Could we not exclude activities tagged as humanitarian (iati-activity/@humanitarian='1') which started less than 6 months ago, or something like that?

Nor is it always clear which activities are covered by legal or competitive restrictions.

Again I think this is something that should be externally defined. For example, if we think that all DFIs should be exempted from publishing this information (I am still not convinced of this, but it sounds like that’s the argument) then that is relatively easy to do. We could do something like exclude activities reported by private sector organisations, for example (e.g. reporting-org/@type='70').

If there are other types of activities that should not be expected to publish such information then we should be able to at least describe features of them (and we could then see the extent to which they could be covered by other fields in the Standard).

Which other fields require metadata on exemptions that would improve the ability of users to assess and process the data?

For issues around commercial confidentiality, I would guess a number of transactional fields (though various publishers will clearly have more ideas here). I also think making clear that data is not published because of systems limitations would be useful for certain fields, e.g. title, description, implementing organisation, some classifications.

Forward-looking data is one of the most important cornerstones of IATI’s raison d’etre and accurate benchmarking of this dimension is, I would argue, a legitimate exercise.

Agreed, but I don’t see how self-reporting will allow you to do this with any accuracy. You would have an uneven playing field between similar publishers depending on whether each of them decided to use this or not. It would be odd if at least some publishers didn’t tag all of their activities that didn’t have a budget element as budget-exempt. (And they wouldn’t necessarily be acting in bad faith by doing so.)

1 Like
#7

I can see why this information might be useful, but I think we should avoid giving the appearance of there being sub-standards for different types of publishers. IATI does not provide blanket exemptions for certain types of publisher or certain types of activity. Of course there are sometimes valid reasons for omitting data, but these need to be justified case by case. So we would propose some changes here:

  • A more granular codelist of reasons for not publishing information
  • Case by case justification as to how publishing the redacted information would cause material or direct harm

Forward looking budgets have been a consistent demand from partner country governments, and concerns have been raised that ‘commercial sensitivity’ might become the standard excuse for not providing information. IATI should be careful to avoid legitimising this.

Also, the word ‘exempt’ is perhaps best avoided here: publishers are explicitly declaring that they will not publish forward budgets for an activity, but IATI is not granting them exemption from doing so.

Andy Lulham
Aid Information Advisor, Publish What You Fund

#9

Notes from consultation calls w/c 3rd July

Outcome:
The proposal was reviewed by those on the call and there was no objection from the group about the inclusion of the attribute @budget-exempt
There were some specific proposals for modification:
Change the attribute name as the word ‘exempt’ was not deemed appropriate. Possible suggestion: @budget-not-provided
Including an additional code (4-Other)

Discussion:
There was discussion around the need to be able to add add more information, in addition to selecting a codelist, elaborating on the reasons for not being able to publish forward-looking budget. As currently an attribute is used the option for free-text is not possible.
The group expressed a need for more use cases on how the attribute will be used.

#10
  1. In my opinion the primary use case is for users accessing forward-looking data. This has always been one of the most important features of IATI data and users need to know whether the absence of budgets is a legitimate use case or a data quality issue. Placing the burden on users to run a number of checks (is this a fast-onset emergency, does the activity have commercial or legal restrictions, etc) is complicated.
  2. I do not support the inclusion of an ‘Other’ code. If a new use case emerges for which budgets are not applicable it should be properly defined and classified.
  3. I take the point that ‘exempt’ is inappropriate. Personally I’m happy with (the rather cumbersome) @budget-not-provided
#11

I am content with @budget-not-provided and the initial codelist would cover the reasons that we normally exempt forward-looking budgets at an activity level.

Where there are other exemptions (security & safety, international relations), these are normally applied to either a whole activity or other elements (participating-orgs for example).

The value in this is not so much the publisher statistics, but in informing “real” data users that the data is not available for a particular reason.

#12

This proposal has been been included in the 2.03 upgrade. It can be viewed in the following two Discuss posts:

#13