Using related-activity to link data between different publishers

Thanks @andylolz! And yes, combo of user + user interface there :slight_smile:

OK - so there’s three organisations that currently use the Third Party related activity type. These are all, it seems, Dutch NGO publishers. It would be helpful if @pelleaardema , @rolfkleef & @Herman can share any ideas around whether this is expected

Here’s an example activity from one publisher:

http://d-portal.org/q.html?aid=NL-KVK-34106722-BEN

This declares this activity (from a different publisher) as a Third Party relation:

http://d-portal.org/q.html?aid=NL-KVK-27189542-BEN16

(which in turns links back)

(I added a GitHub issue for d-portal to display the Third Party label when it’s used)

Yes you are right Steven. We do NOT use the related activity to show the links between publishers. As @YohannaLoucheur 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.

Thanks @Herman

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

@amys @IATI-techteam is the advice you give on using the codelist similar?

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

My understanding of the other two types is:

Co-funded - where two donors fund the same project
Third party - is for instances where two organisations may be engaged in the same or similar activity but there is no funding connection

My other thoughts on co-funded are:
You can tell if there are multiple donors by looking at the recipient’s transaction data. However, this is not the case when looking at the donor’s data.

Hi All,
IN my opinion there is a usecase logic within networked organisations like the Oxfam Confederations to use the related activity element to refer upwards to ‘programmes’ that are owned by the network rather than owned by the network members. this the case I refered to at the BOND workshop with @stevieflow and @amys
In the Oxfam confederations all country and regional strategies, are ‘owned’ by the confederation. These strategies contain the programmes, while they are operationalised through IATI activities published by the network members (the Oxfams).
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.
For our networked situation this would help to visualise programme coherence in Oxfam activites…

does this make sense?

Hi @amys @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. @JohnAdams @Herman @rory_scott @rolfkleef does this fit into the ideas around “Link validation” – where we look to validate data, but use the wider IATI corpus to do this?

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

Would use code 1 parent when mentioning upwards to the programme…

Thanks @stolk

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

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

@stevieflow @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.

@pelleaardema: do you have any additional thoughts on this?

Programme activities @Oxfam confederation level would not have financial transactions…

@stevieflow @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 @stolk’s example, as I understand, this is not the case.

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?