There are two different versions of SectorVocabulary codelist for
- 2.01 (8 codes): http://iatistandard.org/201/codelists/SectorVocabulary/
- 2.02 (12 codes): http://iatistandard.org/202/codelists/SectorVocabulary/
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)
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?
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.