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.
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?
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-activityshould 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 anotherreporting-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.