This item has been moved to the '2.02 Decimal Upgrade Proposals' forum for inclusion the upcoming decimal upgrade.

In I agree with the need to be able to model this kind of relations. Should not there be an IATI guideline though how to use the standard to model these relations between activities? When to use the 'related activity', the 'participating organisation' and the tranaction providers and recipients? How to use the different kind of relations in which use cases? How to avoid double counting?  In the current standard there are many possibilities how to model these relations. Without guidelines everybody will invent the wheel for themselves: every publisher speaks its own IATI dialect. Adding more possibilities to link up activities without clear guidelines, mightbe detrimental to the usability of the data.

Hi Herman

I'd agree 100% that there would need to be clearer guidelines around implementation.  We've discussed how the related-activity element does / doesnt help too: http://discuss.iatistandard.org/t/using-related-activity-to-link-data-between-different-publishers/288

I do think this proposal should be considered too - the participating-org element is well-used across the standard - and so the addition of the option to indicate the relevant IATI activity identifier alongside organisation @ref and @type could gain traction

I think this is an excellent idea SO LONG AS it is not seen as an alternative for basic traceability rules.

This will add richness to related data on participating organisations. The key to traceability however must, wherever possible, be built around transactions reporting incoming funds and provider-activity-id.

I agree.  As Herman states, this would also need to have some guidance alongside it

This proposal has been discussed amongst the IATI Technical Team following the end of the initial suggestion phase of the v2.02 upgrade.

The IATI Technical Team supports the principal of this proposal although we invite further discussion before a final decision on inclusion within v2.02 is made.

Yes, I like this one. As Bill says, needs to be part of an overall traceability ruleset, but would enable relationships to be established before expenditure.

Please see below for the technical implementation that is suggested in the Version 2.02 - Formal Proposal:

New attribute: participating-org/@activity-id [MODIFIED 27-Nov-2015, with improved definition]

• Add new attribute: activity-id

• Example

• Current usage

    <participating-org ref="BB-BBB-123456789" role="2" type="40">
          <narrative xml:lang="en">Name of Agency B</narrative>
    </participating-org>

• Proposed usage

<participating-org ref="BB-BBB-123456789" role="2" type="40" activity-id="BB-BBB-123456789-1234">
          <narrative xml:lang="en">Name of Agency B</narrative>
    </participating-org>

• Add definition:
  A valid activity identifier published by the participating organisation which points to the activity that it has published to IATI that describes its role in this activity.

Thanks

regarding naming this attribute <activity-id> it might be worth checking for consistency where similar data is shared in the standard. So, elsewhere, we have:

<activity-identifier>: http://iatistandard.org/201/activity-standard/iati-activities/iati-activity/iati-identifier/

transaction/provider-org/@provider-activity-id: http://iatistandard.org/201/activity-standard/iati-activities/iati-activity/transaction/provider-org/ (and same for receiver-org)

Therefore, it could be OK to name this new attribute <activity-id> rather than <activity-identifier>. but just wanted to raise the issue , just in case!

Hello Steven, thank you for raising this. As it stands, we are planning to keep the ‘activity-id’ name, as this will be consistent with the <provider-activity-id>, and they both have very similar functions (i.e. referring to an activity’s id, rather than declaring it).

You’re right, however, that this inconsistency shouldn’t be there in the first place. Given that it is, and that non-backwards-compatible changes require more consultation (plus and must take place within as part of an integer upgrade), we think it’s best to just make to two referential instances compatible for now.

This proposal has been added as a GitHub issue, for inclusion in the version 2.02 development branch of the IATI-Schemas: https://github.com/IATI/IATI-Schemas/issues/278

This proposal has now been incorporated into a version 2.02 code repositories (see the above GitHub issue link for technical details). The relevant page on a development version of the 2.02 reference and documentation site is available to view here.

We welcome scrutiny on the implementation of this proposal and encourage the community to feedback and suggest solutions for any errors, omissions and problems. This should be done before Monday 7 December, when the process will commence to release version 2.02 as a live version of the IATI Standard. More information on the inspection phase is available here.