transaction/provider-org/@ref | receiver-org/@ref

[stevieflow]

@xriss @notshi - this is more of an initial check / query atm, but thought it better to start here

We now have pages such as this, which are really useful:

https://d-portal.org/ctrack.html?/participating-org@ref=XM-DAC-47066#view=main

We also know that an organisation can be cited in the transaction element via

• transaction/provider-org/@ref
• transaction/receiver-org/@ref

I think that view is possible through:

• https://d-portal.org/ctrack.html?/transaction/provider-org@ref=XM-DAC-47066#view=main
• https://d-portal.org/ctrack.html?/transaction/receiver-org@ref=XM-DAC-47066#view=main

Just checking if that is so, first of all :)

cc/ @IsabelBirds @robredpath

[xriss]

That should work, although the problem might be considered bad data?

Any organisations referenced in transactions also belong in participating-org.

And we could possibly fix it by pulling any references in transactions up and into participating at import time, but again this is fixing published data.

[stevieflow]

Thanks @xriss

We would expect an organisation cited as a participating-org would then likely be in a transaction and vice versa.

I think there's an (unwritten) assumption in the standard that if there's only one implementing participating-org then there would be no need to include them in each and every transaction

Perhaps what we might be looking for here is:

• Instances where the @ref we are searching for are in the participating-org and/or transaction - and then include that in the breakdown of names / roles that are detailed on click thrus

That might catch instances where an org is only cited in transactions (and not in participating-org)

Appreciate that this might be a lot of extra effort for not much reward

[xriss]

Perhaps the question is are you interested specifically in participating-org as published data or are you interested in activities that are related to an organisation in some way?

If related then, for example, it might also make sense that any explicit activity references to other activities would also imply a direct relationship to the organisations participating in that related activity?

Also the question becomes, do we start looking all the way up and down relationship trees of organisations and activities to find all related data.

We could create a degree of separation graph ( eg if this activity was Kevin then what would be the Bacon Number of all other activities ) between activities / organisations.

This relationship data is something we can build/use, but we might want to stop thinking of it as using participating-org since that would only be one source of the data.

[stevieflow]

Thanks @xriss

That's really helpful, and a great way to explain it (the seven degrees of IATI data!). I'm going to use that ;)

I think we're two principles:

• Exploring all the ways that activities are linked to an organisation (whether they be a reporting-org or not) --> which we've started to explore and implement
• Not fixing the data, in terms of making assumptions or altering things, to show this

I don't know where that takes us on this specific issue - maybe we get the current participating-org developments up first of all, and then plan more deeply / widely thereafter

Thanks again