Future use of Hierarchies

Consultations
#1

Following from the Discuss post of Agreeing best practice – using Hierarchies

The IATI tech team propose that hierarchies do not need to exist within the IATI standard. Their removal will not restrict the flexibility of organisations to show internal decisions about funds nor will it affect timeliness, structure or granularity of published data. This is based on the assumption that the changes outlined in the Agreeing best practice – using Hierarchies post are taken forward. Implementation of this would need to happen at the next integer upgrade as the changes are not backwards compatible.

Here is our reasoning:

  • Only the attribute @hierarchies will be removed. All other reporting best practices will remain.

  • Activities previously reported in a hierarchical model can still be reported in the same structure. The structure will be detailed through use of the <related-activity> element, which allows organisations to specify ‘Child’ and ‘Parent’ relations within their reported activities.

  • The hierarchies attribute does not add any additional information needed for data quality analysis or data use. This is true for the IATI Dashboard, d-Portal and likely all other data use platforms.

  • Therefore @hierarchies is a superfluous attribute which only adds complexity, and often confusion, to the IATI standard.

Current number of organisations using multiple hierarchies

When I was looking into this a few months ago there were 46 organisations using the @hierarchy attribute (this number will now have grown significantly). The majority of these organisations only use levels 1 and 2, with one organisation correctly using three levels of hierarchy. Removing the @hierarchy attribute will not remove the relationships between the published activities but will enable data users to better navigate the data as they will not be misled by incorrect @hierarchy labeling.

Level 2: 44

Level 3: 1 (4)

Level 4: (1)

Level 5: (1)

(Numbers in brackets show the number of organisations only publishing at that hierarchical level or not publishing sequentially to that level)

Please do let us know what you think by responding to this post.

TAG session on reviewing the need for a next minor or major IATI standard upgrade
#2

Thanks Amy

I’m not convinced that this is a good idea if we are trying to describe complex aid interventions, but will respond more fully next week.

Also if we don’t hold finances at a particular hierarchy level, would that be possible?

John

#3

Or is there something missing in your second bullet point - are you proposing replacing the @hierarchy attribute with the use of the related-activity element?

#4

Thanks @JohnAdams the <related-activity> now appears. Looking forward to your responses next week and starting a discussion on this.

#5

Unless I’m mistaken, you’re proposing the removal of the @hierarchy attribute here. You’re not talking about removing hierarchies in general. Is that correct?

If so, I’d suggest removing or rewording the first sentence:

…because it might cause confusion / derail the discussion.

#6

According to the dashboard, 79 publishers use multiple @hierarchy values. But as we know, the @hierarchy attribute is in many cases used incorrectly. If we instead look at related-activity, 199 publishers have at least one parent/child relation in their data.

Looking at how this is used in the wild, these parent/child relations very often span multiple publishers. Here are some random examples (these are some of the longest, each involving four activities):

You can also see in these examples that reciprocal parent/child relationships often aren’t declared. That is, while B might declare that A is its parent, that doesn’t necessarily mean A will declare that B is its child.

So it looks like in the absence of clear guidance, and without feedback loops to correct publishers’ data, publishers have been left to figure out their own rules.

The cool thing about the @hierarchy attribute is it provides a checksum, which can be used to spot errors. So IATI (or a third party) could use it to check related activity data and raise the issue with publishers.

This attribute is surely there to make life easier for data users. Of course if it’s wrong, that won’t help the data user. But I wonder if the correct solution should be to fix it, rather than to remove it.

#7

I added my comments on the other post – sorry, I’m a bit confused about the distinction between the two posts.

I think this post is just suggesting that the @hierarchy attribute should be removed. I would strongly disagree with this. I think it is very useful as it means you can easily select activities from a particular level (e.g. “select only DFID’s programs, and not their project sub-components”). I have used this many times to roll up data according to what is most appropriate to the context, it is super useful.

I am also still very unclear on the arguments in favour of removing it, it would be great if those could be explained in more detail.

#8

Hi amy

In my view the use of hierachies has added value. For instance it allows organisations of networked organisations to link/group/cluster activities under one upper level entity.
Within the Oxfam confederation we now almost agreed on one maintained repository of confederation wide oxfam (country strategy) programmes. This opens up the possibility to demonstrate strategic coherence within the activities of all members of the confederation. In my view programmes should not necessarily be part of the funding flow.
the relation between programme type of activity and project type of activity is one to many. Each project type of activity can have multiple internal and/or external sources of funding (provider activity ID). A hierachy one activity is therefor not necessarily the funding source of hierachy 2 activities,
Hence we need related activity/hierachies ánd specific reference to provider activity ID and receiver activity ID in transactions.
I see this as two separate useful dimensions, getting rid of one of them would be a loss

leo

#9

I noticed in d-portal FAQ the following:

There are currently plans under consideration to use the lowest hierarchy level data only, should data at multiple hierarchies exist, in order to avoid double counting.

I think this illustrates - and @markbrough provides further evidence - that those using IATI data are considering hierarchies.

I’ve always understood the hierarchy attribute as a mechanism to help distinguish and provide rationale for distributing various levels of data / IATI elements differently, within a set. As we know, DFID only publish budgets at H1, with transactions occurring at H2 etc. The same could apply to other data points (results, for example).

To completely remove hierarchies would need careful consideration of the impact on such flexibility provided to the growing community of publishers and users

2 Likes
#10

This sounds like an action, not a reason.

Yes, but this would imply migrations for many of the information products (UI’s) -> we do not see the benefit. This will also burden publishers with changes.

This is not true. We and many in the IATI space use this element. The IATI Dashboard, d-Portal are not any ‘IATI’ default as far as I am concerned.

I strongly disagree.

I therefore find removing @hierachies as an attribute a very bad idea and should be abandoned asap.

The thought of complete removal gave me an instant headache.

2 Likes
#11

Hi @amys,
Since i.m.o. all activity hierarchies can be modelled using the ‘related-activity’ element, and because the hierarchy level itself can be derived/calculated from the published activity data (as we do based on both the related activity as the providing activity transaction elements) , I think your proposal makes sense. It would reduce redundancy and therefore remove a possible source of inconsistencies in the IATI data.

That being said, the issue here seems to be:
1 - is it worth the effort? Removing hierarchies would but a burden on both publishers and data users.
2 - isn’t the redundancy worthwhile to have because it may help to detect data quality problems?

From the data modelling ‘purist’ point of view I tend to agree with this idea since registering derivable data always leads to consistency problems. But we also need to consider the migration effort this will mean for both publishers and data users.

2 Likes