Using related-activity to link data between different publishers

Community Zone IATI Standard
#1

Hi everyone

I’ve been taking another look at “traceability” - especially following the excellent presentation of @Herman at the TAG (https://www.dropbox.com/s/rlb4hdoicvdwztb/linking%20iati%20data%20v7.pptx?dl=0 ) -

I have put some slides together: http://slides.com/opendataservices/traceability - which centre on org references, activity identifiers and transaction encoding to link data between different publishers.

In discussion with others - a point was raised about the use of the related-activity element to express links between activity data published by different organisations - especially the use of code 5 (“Third Party”: http://iatistandard.org/201/codelists/RelatedActivityType/).

Im not sure. Checking the dashboard, nobody is using this code atm:

http://dashboard.iatistandard.org/codelist/1/related-activity_@type.html
http://dashboard.iatistandard.org/codelist/2/related-activity_@type.html

Regardless - would others in the community utilise related-activity to do this? One of the drivers to this would be that the only other method to express direct links between activities is within transactions. At the participating-org level this is not possible (I’ve raised this here: http://support.iatistandard.org/entries/82377659-Add-activity-id-attribute-to-participating-org-element)

How to link donor activities to implementing partner activities
How to link donor activities to implementing partner activities
Co-funded and thirdparty for related-activities
#2

I find this set of slides and @Herman’s very helpful. What I get from them is

  1. using the transactions element is the best way
  2. the transactions element is pretty much sufficient, as set up in 2.01. (I note that it includes a receiver-activity-id attribute which the slides do not seem to mention. @Herman’s request for an incoming-commitment transaction type could also be useful)
  3. the main problem is getting reporting agencies to use what’s there effectively. Designating a few more elements/attributes as mandatory or highly recommended might help. So might @Herman’s suggestion of another guideline (whether as document or other training medium).
#3

We’ve been using the related-activity element quite differently than is suggested here - we use it to identify related activities within our own programs (e.g. phase 2 of a project, or elements of a bigger projects). We always assumed the other-identifier element would be where we’d be recording the activity number assigned by our implementing organization, thus enabling traceability. We hope to start testing this approach with UNICEF soon.

In our case there wouldn’t be a need to identify related activities at the transaction level, as transactions will be almost exclusively with our implementing partner. This could well be different for another donor whose definition of “activity” may be quite different from our - clealy a donor’s business model will affect how they need to structure their related-activity data. Which in turn will present interesting challenges when trying to use data from several donors.

#4

Coming back to this —> 18 months later!!

In December 2017, @SJohns, @TimDavies & @tanaka 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 @amys then saying that the @IATI-techteam 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 ( @pelleaardema @Herman ?)? 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 @stolk was interested in this too!

#5

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?

#6

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

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

#7

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.]

1 Like
#8

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)

#9

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.

#10

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!

#11

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

#12

Thanks @Herman

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

#13

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.

Co-funded and thirdparty for related-activities
#14

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?

#15

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?

Enabling Two-Way Traceability
#16

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

#17

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!)

#18

@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?

#19

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

#20

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