Using related-activity to link data between different publishers

Coming back to this —> 18 months later!!

In December 2017, SJohns , Tim Davies & Tanaka Nyamadzawo and I held a workshop with several Bond members to start discussion around “IATI & Federated Organisations” (I’ll format the materials and such and post them online).

Anyway, we discussed the use of related-activity, in terms of making connections between activities. I recall Amy Silcock then saying that the IATI Technical Team were specifically advising publishers to NOT use related-activity to link between activities from other publishers. Can we confirm if this is the case?

I think this is in line with MFA guidance ( Pelle Aardema Herman van Loon ?)? If so, can anyone explain the purpose of code 5 (Third Party) on the RelatedActivityType codelist:

A report by another organisation on the same activity you are reporting (excluding activities reported as part of a financial transaction - e.g. provider-activity-id or a co-funded activity, using code 4)

I think leo stolk was interested in this too!

If so, can anyone explain the purpose of code 5 (Third Party) on the RelatedActivityType codelist:

A report by another organisation on the same activity you are reporting (excluding activities reported as part of a financial transaction - e.g. provider-activity-id or a co-funded activity, using code 4)

Wouldn’t this be used by secondary publishers who assign their own Activity ID to a project that is already published by someone else? They should be reporting the Activity ID of the original publisher, would they not use this code? This is how we would avoid double-counting, isn’t it?

Wouldn’t this be used by secondary publishers who assign their own Activity ID to a project that is already published by someone else?

Could be. I’d expect the description to say that though, wouldn’t you?

Andy Lulham (magic man!) - any insight on who is using this code already? The dashboard only seems to report on 1.0x usage?

Andy Lulham (magic man!) - any insight on who is using this code already? The dashboard only seems to report on 1.0x usage?

Yep – 2.0x codelist usage is also on the dashboard.

[If you scroll way down the codelists dashboard page, you get to codelists for 2.0x. I agree this could be clearer! Either via a table of contents at the top of the page, or (at least) by reordering to show 2.0x (i.e. current integer) first, and 1.0x (i.e. legacy integer) second. I’ve just sent a pull request.]

Yes you are right Steven. We do NOT use the related activity to show the links between publishers. As Yohanna Loucheur mentioned above, the relation with implementing partners is always through transactions.

The use of the related activity is in our case limited to making the link between the activity level and the programme level within an organization. The reason for this is that a lot of organisations, do not model their internal financial flows as transactions in their financial administration.

The use of the related activity is in our case limited to making the link between the activity level and the programme level within an organization.

Thanks Herman van Loon

In the case of those three examples we found, who look to be under MFA requirements, would they fail your validation for (mis)using the related activity in their data? Interested to know!

Yes it will fail validation, but will not stop processing of the data. We have not implemented an automatic validation on this yet.

Thanks Herman van Loon

Amy Silcock IATI Technical Team is the advice you give on using the codelist similar?

Hi, Steven Flower Herman van Loon Pelle Aardema , 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 leo 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 van Loon & Pelle Aardema

Thanks leo stolk

Herman van Loon Amy Silcock what do we think about use of related-activity codes within a federated situation, such as described by leo stolk ? Is this still “internal”?

(and obvious disclaimer, we are just discussing this openly and transparently – we’re not validating anybody!)

Steven Flower leo stolk I would not use the related-activity elements to model flows between organisations. Since within a federation of organisations, you have actual fiancial transactions between the organisation members and these members are separate legal entities with their own IATI identifier. I.m.o. you should use transactions to model these actual money transfers and limit the use of the related activity (types parent-childs) within an organisation.

The programme structure of activities within a federation or alliance, can be modeled with transactions. An example is the Both Ends alliance, where the programme level activity is maintained by Both Ends, and the project type interventions are being maintained by the partners funded by Both Ends.

Pelle Aardema : do you have any additional thoughts on this?

My advice was (and still is) that Parent/Child/Sibling relationships should only be used internally, and not refer to activities from external organisations.

Herman van Loon leo stolk Pelle Aardema - 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:

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!

Hi Amy Silcock leo stolk - many thanks

We seem to be getting into quite nuanced and contextual “rules” around usage of these codes, particularly the co-funded and third party ones. Additionally, it seems that if we wanted to try and validate usage of these codes, we would be unable to do this on the activity alone - we’d need access to many other activities, published by other organisations. John Adams Herman van Loon Rory Scott Rolf Kleef does this fit into the ideas around “Link validation” – where we look to validate data, but use the wider IATI corpus to do this?

I hoped to be allowed to publish the country strategy programmes by Oxfam Confederation secretariate as hierachy one activities, and convince all Oxfams to link their project to secretariate programmes, using the related activity element.

Thanks. Which related-activity code were you thinking of using?

Amy Silcock and Steven Flower 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?

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.

Steven Flower leo stolk I wouldn’t use related-activity parent/child/sibling relationships between members of a federated organisation. The related-activities, help mark internal transfers of money within a single organisation/(primary) publisher. For leo stolk ’s example, as I understand, this is not the case.

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

– similarly, when a donor is publishing alongside another donor, and needs to signal that their funding is connected

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?

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.

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.

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.

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

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

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.

There were four codes in version 1.01: http://reference.iatistandard.org/archived/101/codelists/related_activity_type/index.html

The text which includes “sub-component” has always been there. It looks like “reported to IATI” was added along the line, but I can’t see whan (Andy Lulham : would you know?)

If there is any assumption about who publishes, then this isn’t / wasn’t stated.

A fifth code, “Third Party” was added in version 2.01 update: http://reference.iatistandard.org/203/codelists/RelatedActivityType/

The text which includes “sub-component” has always been there. It looks like “reported to IATI” was added along the line, but I can’t see whan (Andy Lulham : would you know?)

It was added in v2.01 in this commit, as part of this issue. It’s mentioned at the bottom of the related proposal:

• A clearer definition has been found for the proposed Related Activity Type

I’ve mentioned it before, but this sort of historical paper trail is really useful for maintaining organisational knowledge. It’s pretty good in this instance, but could be better.

We shouldn’t be in a situation where the only explanation for a change resides in the memory of the previous tech lead!

We shouldn’t be in a situation where the only explanation for a change resides in the memory of the previous tech lead!

Hence the importance of removing all ambiguities by standardising the standard.

For what it’s worth this, I believe, was the initial set of codelists, dated 3 December 2010 - https://drive.google.com/file/d/1n8Gjm6Tpn5LJeZEFsB5PI7gESzDuJEHS/view

This folder contains the documents that were (I believe) present on the first iatistandard website, end of 2010.

bit.ly/iatistandard_2010_sitedocs

NB IATI XML Schema Tutorial

Yikes! Some of those look eerily familiar.