IATI is quite clear in how and where either sector and country/region classifications can be mixed between the activity and transactions.
For sector codes
Sector can also be reported at the transaction level rather than the activity level. Sector must only be reported at EITHER transaction level OR activity level.
and country/region:
The country can also be specified at transaction rather than activity level. If recipient-country OR recipient-region are reported at the transaction level, ALL transactions MUST contain a recipient-country or recipient-region element and iati-activity/recipient-country and iati-activity/recipient-region MUST NOT be used.
With the Initiative for Open Ag Funding we think it might be useful to relax this rule, in terms of:
- any activity can have sector / country/region codes at BOTH activity and transaction level
- sector / country/region codes do NOT have to apply to all transactions
We can see use-cases such as:
- A publisher may want to describe their activity with a certain set of sector codes at a high level / early on, and then gradually build up a more detailed picture over time of the activity via transaction encoding.
- A publisher may be able to codify certain transactions (eg disbursements to partners) with a sector / country/region codes, but have no reason or use with other types.
Both of these may help end users understand the delivery and scope of the activity via access to greater detail. We understand that this may also place a high bar on publishers to do this effectively - this post is to illustrate that within the current guidance neither of these scenarios are permitted.
I’ve been working on some notes below - but the more I look at this, the more confused I’m finding I’m getting. So posting for now - in the hope this parses clearly enough. But planning to return to it more later too - perhaps with a few more worked examples.
(initial) Problem analysisIt would be interesting here to understand what business logic (if any) data users are currently employing to cope with the fact that, if working with data from different sources, a user has to look at both activity and transaction level to understand funding flows, and to find out what sectors an activity is in.
Whilst in theory the rules might aim to get at 100% of the financial flows, I’m not sure how far it works in practice.
With the current rules, I think the current business logic (for sector as an example) would go something like this:
For faceted browse tools which want to find all the activities in a given sector, they have to look at both iati-activity/sector and iati-activity/transaction/sector.
(Would be good to hear if anyone is using business logic like this…)
But, in cases where we might have two sector coding vocabularies, this creates problems. For example, an activity could be coded:
This breaks the rule that “Sector can also be reported at the transaction level rather than the activity level. Sector must only be reported at EITHER transaction level OR activity level.”
There is also a rule for iati-activity/transaction/sector which states that “This element can be used multiple times, but only one sector can be reported per vocabulary.”
(I think this last issue is something we’ve not picked up properly in our analysis to date…)
Possible responses (1) Require sectors/countries/regions at the activity level, but make them optional at the transaction levelA validation rule might be added along the lines of:
Whilst the logic to calculate this isn’t entirely trivial - it would just be a job for validation of data, not for individual users.
This change would make things easier for users: they can get high-level summaries at the activity level, and dig deeper at the transaction level.
From the publisher perspective, it introduces some redundancy, and the need for publishers who have transaction-level data to calculate the activity level information, but otherwise it introduces little extra burden.
This would impact publishers who are currently providing only transaction level sectors/locations etc, but it seems to me from the dashboard that might not be very many publishers right now.
(2) Adjust the restrictions to only apply to OECD DAC Codes, or just to be per-vocabularyFor example, updated rules could state something along the lines of:
This doesn’t really deal with the recipient country issue though.
(3) Propose an alternative <tag> element for the kinds of coding we are looking forThis would help with the sector issue, but not country.
Tag could be defined differently from sector as:
I’m generally cautious about adding new fields, but if the semantics of the tagging we are aiming for is different from the semantics of sector, then maybe we should have a different field.
Notes:
[1]: I realise here I’m not entirely clear on the business logic for aggregations from the transaction level and what it equates to. Clarifications welcome.