Why does 2.02 include a code list that was not supported since 1.04?

Thanks Bill Anderson - have put something into https://github.com/IATI/IATI-Codelists-NonEmbedded/issues/176 - it’s a Non Embedded Codelist, so should make this easier…

At present Non-Embedded Codelists refer to Codelists that are present at all versions of the Standard. There is no way for a Non-Embedded Codelist to exist at some versions (decimal or integer) but not others.

In terms of hiding it from display on iatistandard.org against versions of the Standard from 1.05+, we have deemed it to be a wontfix due to the way in which the site is generated, and upcoming work on the core website architecture.

In parallel to this, Petya Kangalova (with assistance from others) has been working on a full solution to rectify the oversight that leads to the situation that has been brought up here (plus a range of other issues, some impacting the proposal to re-categorise some Embedded Codelists as Non-Embedded). I cannot recall the exact status of this, though last I saw it was a reasonably comprehensive and sensible proposal.

If the proposal in this thread is to completely wipe this Codelist from the face of history, that can be done (from a technical perspective). If the proposal is to remove it from versions 1.05+ (or 2.01+) only, that is not possible with the current methods of Codelist categorisation.

All other IATI codelists define allowable values for an attribute or element. Not so for this list, which provides information about possible reference values.

Removing it from all versions does not break anything.

bill_anderson:

All other IATI codelists define allowable values for an attribute or element. Not so for this list, which provides information about possible reference values.

That’s the difference between a complete and incomplete codelist, isn’t it? If so, I’ve no idea why the Organisation Identifier codelist is complete. I suspect that’s probably an error (this is far from a complete list of all organisation identifiers!) My mistake! I muddled up two codelists.

But anyway – Great! It sounds like removing the codelist is both technically possible, and won’t break anything. This is brilliant – Let’s do it!

So - is the way forward to remove this list?

stevieflow:

So - is the way forward to remove this list?

I’ve sent a PR for that:

github.com/IATI/IATI-Codelists-NonEmbedded Remove the OrganisationIdentifier codelist IATI:master ← andylolz:176-remove-OrganisationIdentifier-codelist opened 11:57AM - 12 Feb 18 UTC andylolz +0 -2530

I can see your point Mark Brough

markbrough:

The currently published codelist is the only place that you can get lookup values for these organisation identifiers.

I slightly disagree - but only via the existence this thread, which has been implemented by Andy Lulham --> checking publishers organisation files (against the reporting-org ref) to give us some indication of what reference to use (GB-GOV-1 or GB-1 or XM-DAC-12-1?)

This doesn’t answer all your queries, but a danger to the idea of a definitive / clean list is a list that is a) quite out-of-date with the references actually used by publishers, and b) also with the original source - OECD DAC.

A number of us in the community are suggesting that this methodology, list and (possibly) lookup should become a core piece of infrastructure adopted by IATI. In turn, I think harks back to some of the original requests from members (ie: a master list of organisation references) via community members such as Otto Reichner Ole Jacob (OJ) Hjøllund Yohanna Loucheur & Herman van Loon , for example.

Thanks for your reply Steven Flower and apologies for my delayed response.

I agree that a nice lookup tool (I guess building on Andy Lulham ’ awesome work) would alleviate some of these concerns. But until then (or until at least major organisations are moved away from using these identifiers), I don’t like the idea of removing something that is at least somewhat useful. I guess generally I am also against removing data just because people might misinterpret it

Removing all of the codes from a codelist clearly has the same effect as removing the codelist itself. I don’t think it is an acceptable reading of the rules that govern the Standard.

amys:

Therefore, I propose that we remove all of the codes from the codelist and update the description to explain what has happened.
…
If there are no objections in the next 7 days we can start this process.

I object to this for the reasons I previously outlined above. In the absence of a well supported organisation identifier lookup tool, given that these codes are already being used by a number of organisations, and given that 2.x encourages providing codes without narrative text, this removes the only available source for dereferencing a large number of organisation identifiers.

amys:

However, as this is an incomplete codelist we can remove individual codes whilst maintaining backwards compatibility (Hayden Field ) .

Please can you point to this in the Standard upgrade procedures? I cannot see where a codelist being tagged as incomplete means that it is not subject to the normal rules around decimal and integer upgrades. I also do not accept that removing codes (unless it is actually a bugfix) is backward-compatible.

markbrough:

Removing all of the codes from a codelist clearly has the same effect as removing the codelist itself.

From a user’s point of view, that is correct, yep.

From a Standard Management point of view, however, they are slightly different - in the former, the statement that “there is a Codelist called ‘[thisThing]’ at version xyz of the Standard” remains true. In the latter, it becomes false (and so does not maintain backwards compatibility).

given that 2.x encourages providing codes without narrative text

v2.0x provides the means of including the names of reporting and participating orgs.

If there is any Guidance that discourages the use of these elements, could you point towards it?

this removes the only available source for dereferencing a large number of organisation identifiers

The historical source will remain, and updates to the documentation will signpost this for those who require it.

Please can you point to this in the Standard upgrade procedures?

Non-Embedded Codelist Management Process

I also do not accept that removing codes (unless it is actually a bugfix) is backward-compatible.

If a Codelist is complete, removing Codes is not backwards compatible (since it is not permitted to use a Code that is not on the Codelist - a Dataset that was previously valid would suddenly become invalid).

If a Codelist is incomplete, removing Codes maintains backwards-compatibility (it is permitted to use Codes that are not on the Codelist, so a Dataset that was valid before their removal remains valid after they are removed).