Vocab codelists - make "non-embedded"?

Standard Management 2.03 Decimal Upgrade Discussions
#1

There are two different versions of SectorVocabulary codelist for

This is because this list (and other vocab lists) are “embedded” - meaning they can only be changed through version updates: http://iatistandard.org/202/codelists/codelist-management/

It might be a more useful approach for these vocab lists to be “non-embedded”, meaning that a new code can be added independently. Currently the standard seems to suggest that additional/new vocab codes published in 2.02 cannot be used in previous versions of the standard (as they are not on the list). I’m not sure this is the intention - if I publish 2.01 (or a relevant 1.0x version) and want to utilise a new vocab, it’s probably practical (and useful) to refer to a single/definitive list…

(more widely, this might point at how versions of different codelists are managed and published - but the vocab use-case may provide a good focal point)

Clarification: multiple RO Sector Vocabularies
Tech Paper: Codelist Management
#2

Thanks for raising @stevieflow and I agree that we should perhaps consider making most/all of the vocabulary codelists non-embedded so that they could be updated outside of a formal Standard upgrade and the entries available to earlier versions of the Standard. In fact we did actually make the Humanitarian Scope Vocabulary that was introduced at V2.02 non emebdded for that reason. We are also seeing an increasing requirement for the IATI Standard to enable linking to other sets of information/ topics of interest etc so such a change could certainly increase the ability of the IATI Standard to be more flexible and react more quickly to these.

However, I should also mention that one thing we would need to be mindful of is that the non-embedded codelist update process has enough oversight to ensure that only valid entries for formal vocabularies (that are themselves well managed and likely to endure) are added. To that end I would certainly encourage members of the community to ‘subscribe’ to the non-embedded codelist amendment forum so that they can be aware of any proposed/accepted changes and provide input/comment on any changes as well . In addition, it may still be necessary to only allow deletions of any entries as part of an integer Standard upgrade due to not being backwardly compatible.

However, we would certainly welcome other views on this issue?

Criteria for assessing external codelists / vocabularies / registries
#3

Hi Wendy and Steven. I definitely think making the OECD/DAC sector codelists non-embedded is a good idea. The contents of this codelist is maintained by the OECD/DAC and should i.m.o. immediately follow the changes made by the OECD/DAC.

The IATI validation software should also check whether or not the proper code list values are used. Shouldn’t the OECD/DAC codelist also have an ‘valid from’ and ‘valid until’ date for each value, since the OECD/DAC sometimes does depreciate sector codes?

#4

Herman all third-party lists are already non-embedded. The issue is how we handle lists created by ourselves.

So, for instance, Transaction Type is, in my view, correctly an embedded list which means it can only be changed through formal upgrade procedures. Others that we have created do not necessarily have to be embedded.

What I think we need to set in place at the next TAG are clear rules and guidelines for the embedding and versioning of code lists.

#5

Thanks @Herman and @bill_anderson for your comments

I just wanted to step back to the original focus - that of codelists relating to vocabularies. To help, I’ve made a list, which echoes @Wendy’s point about the mix between embedded and non-embedded lists

embedded:

non-embedded:

My suggestion is that it may be useful to maintain vocab related lists as non-embedded - so that new vocabs can easily be added. As @Wendy also suggests, there might be a need for a criteria to add new vocabs - whilst my observation about the limited practicality of different versions (related to the version of IATI) of these lists still remains

#6

@stevieflow I agree with your suggestion

#7

Moving this to the Standard Management -> Modification Additions & Improvements category for further consideration

#8

This topic will be covered by the TAG Codelist Management paper