Linking to IATI data

[stevieflow]

In discussion with Indigo, it is apparent that data is published in both 360 and also IATI

The internal ID is always used in these cases - eg: IND227

In the 360 publication, this project is then identified as:

360G-indigotrust:IND227

In IATI, this is

GB-CHC-1075920-IND227

How best to link the two? There is obviously a pattern, in terms of the org identifier replacing 360G-indigotrust - is 360 wedded to all identifiers have the 360G-orgnamestring prefix?

[practicalparticipation]

Good question. The desiderata for 360 Giving is (a) globally unique, and (b) stable IDs.

From a guid perspective if publishers already have a guid for their grants (or something that can be reasonably be expected to be globally unique) then the prefix is redundant in some senses.

From the stability point of view I do think IATI ids are not ideal though I think this has been dealt with to an extent in recent guidance.

So - we could relax 360 spec to allow reuse of iati ID where one exists perhaps. Or just use related project to link them...

[stevieflow]

It's an interesting one.

I dont consider the IATI ids to be particularly bespoke - in terms of [Org ID]-[project ID] format. What could trip up is that the 360 documentation currently suggests that Organisation are identified following "the Organisation ID standard." (which I assume is IATI convention GB-COH-123456, etc) and should added to the dataset. Actual grants do should follow "the 360Giving identifier format", which in turn does not involve the Org ID... there seems to be room for connecting together more explicitly?

[stevieflow]

I know this ticket is old, but I've been looking recently at the reverse of this

The question being:

Is it possible to use the IATI activity ID on 360G for grants that are published on both? This would save the step of having to convert the activity identifier from one format to the other.

[timgdavies]

For the time being, suffixing the full IATI identifier onto a 360G prefix would be possible, but does involve that light conversion step.

For allowing IATI identifiers as part of a 360 giving 'Identifier' column I believe would require a change to:

• The spec
• The validator - which I believe checks prefixes
• Guidance

but it would be a reasonable change to explore.

The key functional requirement we place on a 'record identifier' across IATI, OCDS, 360 etc. is that it is unique within the domain of all possible records published in that standard.

It would be possible for 360Giving to have a set of 'recognised identifier schemes' where we can be sure identifiers will never clash.

Essentially, that comes down to two schemes never allowing use of the same starting characters. For example, as IATI activity identifiers use http://org-id.guide codes as their first component, as long as '360G' could not be registered as an http://org-id.guide code, there is no risk of a clash.

We do need to be aware that asides from this functional requirement some users of the data may over-interpret identifiers, to assume that they can be split up into component parts, and interpreted based on the prefix etc. We would need in guidance to emphasise that identifiers should be treated as entire strings.

The one other role that the prefixes play in OCDS and 360 Giving is in terms of 'branding'. For example, if you see an identifier '360G-xyztrust-1234567' it communicates to someone aware of 360 giving that there is likely to be 360 Giving data available about this activity. If someone encounters 'GB-COH-00847472-1234567' they don't get the same message communicated to them.

[stevieflow]

This seems to be an implementation discussion. Im investigating this with a couple of publishers.

Action: keep this issue open for now. Use during investigation