Using related-activity to link data between different publishers

Just wanted to flag what the standard says on related-activity:

Another separately reported IATI activity that is related to this one.

I think that supports both use-cases. Are we now in the realm of a difference between reference documentation (what is written down for all) and implementation guidance (what is done in context)?

@amys and @stevieflow If referring to a single set of level one activities across our our confederation is not an option, all affiliates will have to include repetitions of the hierachy one activities in their individual data sets. Such repetion is undesirable isn’t it?

Ok, so programmes @Oxfam are used to group related activities, but not for financial planning?

indeed, at this stage, that’s where we are. …

Regions or country level strategic intentions (5 yr) are expressed in sets of three - five programmes (focus choices) each. with tiles, descriptions, etc.
Financial and result intentions are set per country/region per ‘programme’ in annual operating plan,

However actual transactions, income and expenditures are recorded at project level across affiliates that contribute to these programmes.

So programmes ‘belong’ to the collective aka the confederation, the projects belong to and are administrated in, the various confederations affiliates.

HI everyone

I do like that this thread over three years old, 24 posts long, and still not at consensus!

I think we can learn lessons from this around the potential complexity of rulesets and validation of - and this might be a simple case!

The reason for my posting here, is that @Herman @stolk @David_Megginson @Wendy @ximboden @pelleaardema and I discussed related-activity during a focus on FTS & IATI last week.

We got to this very same question: should related-activity be used to point / link between activities published by different reporting-orgs?

Having reread this thread, I think our position is:

  • most cases suggest that related-activity should be reserved for pointing within a publisher dataset
  • however, there’s a case to suggest otherwise:
    – when a publisher is a part of a federation / network of organisations, and needs to relate to an activity (published by another reporting-org) that provides more context
    – similarly, when a donor is publishing alongside another donor, and needs to signal that their funding is connected

And that, brings the codes for “co-funded” and “third-party” into question.

However, as @herman confirmed, use of related-activity outside of the scope would mean a fail of Netherlands MFA validation rules, although not render the data useless

So… I’m still not sure we have a Best Practice on use of this element. As more publishers create and connect data, it strikes me we need something…

3 Likes

Isn’t this (best) expressed in the data as funding going to the same activity? In other words, by the recipient indicating both donors’ incoming funds to this activity and/or both donors indicating which recipient’s activity their funding goes to?

1 Like

I had always interpreted related activity as being for situations where activities were related e.g. in terms of objectives, joint planning etc, but where there were no financial flows that would already have allowed that link to be made, whether it was between different donors, within a donors portfolio etc.

Perhaps more importantly, do we know many publishers who have a publishing process where they lookup the activity codes of either related activities or activities/org codes from other publishers that they are funding? If not, all this is a bit optimistic no?

IOM had a few conversations with a few of our donors while at TAG and off-line. Knowing the donor reference is often known at the time the donor agreements are signed. We don’t currently have a place to store that info such that it can easily be pulled into our IATI data set but we are working on it.

Expecting us to look it up after the fact is ambitious. Particularly when some of our donors don’t publish their donations to us until after we’ve published the projects they have funded. We be playing catch up most of the time.

The challenge we face (may not be an issue for others) is that we don’t know what our project ID will be at the time of signing the agreements. That would require a follow up to communicate that information back to the donor if they want to reference our IDs. That too is ambitious I believe but would be a possible solution for linking two donors to the same project.

It is imperfect but our plan was to use the participating-org/@activity-id or provider-org/@provider-activity-id elements/attributes/?? when we do. Our (perhaps incorrect) understanding of related-activity wasn’t for this purpose. If you “experts” tell me otherwise, we still have time to course correct as we don’t yet publish this info.

That’s a challenge we identified as well when trying to figure out how to get activity IDs. My very simple suggestion: put your activity ID (and org ID for that matter) on all your communications to the donor, especially reports. Very little cost, no risk, and tremendously useful if the donor ever wants the info.

We do and always have but that doesn’t mean the donor does anything with it that makes its way into IATI.

Maybe I am missing something in the workflow here, but isn’t it always the case that at the moment of signing the contract/agreement, the donor knows their own funding activity-id? In that case the recipient can always point back to the donor’s activity-id (which is mentioned in the contract). So the key point here is to point upward in the funding chain and not downward, since that would require the donor to refer to not (yet) existing activities.

Herman - you aren’t missing anything. What you suggest is completely possible assuming the recipient system has a place to store that data. My point was only that it would only work in one direction and thus might not help all users depending upon what direction they are coming from along the chain. I would have thought that ideally both donor and recipient would cross-reference one another so the traceability could work in either direction.

As you point out @Michelle_IOM it is already possible for donor and recipients to cross reference each other and the IATI Standard does already make provision for that to happen. However, as @Herman has mentioned (and it was also my understanding) I think that the original intention for traceability within IATI was just to trace upwards within the funding chain? As @Herman and @YohannaLoucheur have pointed out a donor or funder can generally provide their own originating IATI activity identifier to the recipient via contract documentation and/ or as part of the contract management business process etc .

Interestingly, some of our most recent work within the Grand Bargain (particularly around issues relating to Localisation) is highlighting that there would indeed be value in being to be able to trace both ‘up’ and ‘down’ the funding chain. Presumably for this it happen, Donors and other funders would need to regularly ‘harvest’ the recipient activity identifiers and add them into their own systems. I think this process could certainly be automated and it would also provide donors with an automatic confirmation or validation that recipients have also now published the receipt of that funding to IATI? As a result I would be very interested to hear any views from donors or others on the practicalities and appetite (or lack of?) for making this happen?

NB as this question is moving away from the original post topic I am happy to move this post to a new topic if required

4 Likes

@Wendy +1 for starting a new thread. The reciprocal links question is v interesting, but it’s sufficiently different to this related-activity discussion.

Thanks @andylolz and new post created

1 Like

@Herman @stolk @pelleaardema - I was looking at a full set of “linked activities” via the Yes I Do programme just recently.

Whilst the use of linkages via transactions is clear, there is also use of related-activity (parent) between different organisations in this chain.

Hence, Rutgers declare their activity has a parent of the Plan Nederland activity:

d-portal%20org%20q%20html%20aid%20NL-KVK-41193594-YID7300

Given we have a set of 29 activities from nine publishers, we could just consider this as a slight blip - esp as other publishers in this “family” do not act this way. However, I’d be interested to hear thoughts about this - especially if it starts to break stuff!

1 Like

Hi, @stevieflow @Herman @pelleaardema , within the DRA alliance, the lead organization in a ‘joint response’ is actually the holder of the parent activity, whilst participating organizations in that ‘joint response’ publish the child projects. As far as I know DRA members do not use the related activity across to point up to an alliance member in the ‘joint response’ lead role (rotating function in the alliance). But I find the use of related activity parent, better than provider org activity ID, as DRA acts as an alliance. That is also often the case within the Oxfam Confederation, where participating affiliate contribute from their parent to executing affiliates implementing.

Thanks @stolk

Whilst I’m not aware of a specific “rule” that governs usage of related-activity , perhaps we have to be pragmatic in terms of what means “external” It seems quite legitimate to use this within the context of a delivery chain / consortium, as evidenced.

I do think this isn’t in the Netherlands MFA guidance - would be interested to hear from @Herman & @pelleaardema

@stevieflow and @stolk: in the Dutch MFA guidelines we have added the related activity with the purpose of enabling publishers to model the logical activity structure of an alliance, even if there are no transactions (yet).

Another example that makes the case for ‘standardising the standard’.

If my memory serves me correctly the original Version 1 codelist contained 3 values - parent, child, sibling. A child was defined as a ‘sub-component’ of a parent: the assumption being that they both belonged to the same organisation.

This is not, however, clear in the wording of the standard (in both schema definition and code list).