@ref attribute for implementing organizations in Dutch ODA data

The IATI documentation for the @ref attribute says:

Machine-readable identification string for the organisation. Must be in the format {Registration Agency} - (Registration Number} where {Registration Agency} is a valid code in the Registration Agency code list and {Registration Number } is a valid identifier issued by the {Registration Agency}. If this is not present then the narrative MUST contain the name of the organisation.

The Dutch government supported activities in Zimbabwe:


Not only are those ref codes malformed, but some of them also appear multiple times, representing different implementing orgs. Is it the reporting organization that’s using this identifier in an odd/wrong way, or merely a result of bad model mapping?

There’s nothing returned by that query. Looks like NL-1 is now XM-DAC-7, so:

Looks to me like the @ref’s are an issue in the publisher’s data: http://iatiregistry.org/dataset/minbuza_nl-activities20102011 .

Link to the relevant docs: http://iatistandard.org/202/activity-standard/iati-activities/iati-activity/participating-org/

Thanks Ben. I thought those identifiers aren’t supposed to change, ever.

And, I guess you are right. It appears the problem does lie in the publisher’s data.

I thought I would just add here that it is okay for organisation identifiers to change as organisations do sometimes merge , change status etc over time However, what should never change are the activity identifiers. The guidelines for managing organisation identifier changes were established at V2.01 of the IATI Standard and can be found here - http://iatistandard.org/202/upgrades/integer-upgrade-to-2-01/migrating/#organisation-and-activity-identifiers

Thanks Wendy. Actually, I just noticed there is a reference to the old publisher identifier in the XML output:


I also see budgets in there, but not in the CSV. Should I open a separate thread for that, or is there a simple solution to it?

Hi Uros. Not all fields currently get included in the activity level CSV download but you can get the budget data by selecting the appropriate datastore option http://datastore.iatistandard.org/api/1/access/budgets.csv?reporting-org=XM-DAC-7

Also regarding to the reference to the old publisher identifier in the XML output were you referring to the references in the transactions?

Hi all,

Since we get funding from the Dutch government as well, we used to reference them as NL-1, but indeed their organisation identifier has changed. This makes old files link to an unknown identifier and I haven’t been able to figure out why the switch was made (but haven’t done any thorough research either, to be honest).

But in any case, it seems like they’re at least keeping the old activity identifiers the same (starting with NL-1). Newer activities, however, seem to be prepended with the new identifier. See the preview of their 2016-2017 file: http://preview.iatistandard.org/index.php?url=https%3A//static.rijksoverheid.nl/bz/IATIACTIVITIES20162017.xml.


Thank you both!

@Wendy There is also the <other-identifier> tag in activity descriptions.

Thank you Uros and just to add that the use of the ‘old’ identifier in the element is correct as per the guidelines for handling changes to organisation identifiers (see earlier post for link).

Also @Kasper per the reason for the change of identifier is because the old identifier of ‘NL-1’ is not in the required format for an organisation identifier that became mandatory at v2.01 of the Standard

Ah, yes, of course… That makes sense, thx @Wendy

Thanks Wendy for your explanation.

We deliberately left the already published IATI identifiers of already published activities unchanged (NL-1-PPR-, because these identifiers might already be used in many systems. An IATI identifier should be unique throughout the life of an activity.

Since the 2.01 release, our organization identifier has been changed. Therefore we publish new activities as XM-DAC-7-PPR-.

See: http://iatistandard.org/201/codelists/OrganisationRegistrationAgency/ for more information on changes in 2.0.1

Shouldn’t the malformed/duplicate ref codes for the implementing organizations (e.g. 23000) be removed, though? Isn’t it a data quality issue?

Yes you are completely right. That will be our next release in the summer in which we will gradually add fully IATI compliant identifiers to implementing organizations.

Thinking about the organisation IDs more generally, I’ve seen a lot of donors using CRS channel codes in their data. Some of these are actually quite useful, especially in cases where more precise organisation IDs may be unavailable (due to systems limitations) or not exist (e.g. for public sector organisations). The channel code can also be quite useful as a way of understanding the type of organisation (it is more detailed and sometimes clearer than organisation type).

Given this, I wonder whether it would be useful to allow the CRS channel code and the ref to both be reporting on the same <participating-org> element (for implementing organisations)? Otherwise, it is hard to reconcile the two when an organisation is using multiple <participating-org> and multiple channel codes.

I did a comparison of DFID implementing organisations and transaction/receiver-orgs here which illustrates this issue reasonably well, I think (code half way down this page)

Thanks for your comments @markbrough and it is an interesting idea regarding the use of the CRS channel codes and I can see how that might be useful at the present time. However, I’m not sure from a Standard’s Management perspective that we would want to allow multiple organisation references to be used but would prefer that all parties just used a single common organisation reference? It would though of course always be interesting to hear from other data users (& publishers) to get alternative views on this?

Thanks @Wendy – perhaps a sensible way forward would be to align the OrganisationType codelist more closely to the DAC channel codes where the latter refer to types of organisations rather than specific ones?

The comment by @theo.sande half way down this page is probably what I’m suggesting… would an option be to merge the two lists?

Incidentally, the crs-add/channel-code element doesn’t really help, because it isn’t placed within participating-org elements. So you can’t relate a specific channel code to a specific implementing organisation if there’s more than one implementing organisation.

1 Like

Thanks for @markbrough and I am just going to move this to the Standard Management -> Modification Additions & Improvements category for further consideration