[Added] Add SDG goals and targets to the TagVocabulary codelist

Vocabularies for the SDG goals and targets should be added to the TagVocabulary codelist to enable the publication of data in line with the DAC WP-STAT decision to create a new CRS field to report SDG targets (per this post)

These vocabularies are code 7 ‘SDG goal’ and code 8 ’ SDG Target’ in the Sector Vocabulary 5 codelist .

While not covered in CRS, I suggest we may want to also add the SDG indicators (code 9 in the SectorVocabulary codelist).


There has been no objection to the proposal for an addition of SDG goals and targets to the non-embedded codelist for Tag Vocabulary. As we understand the proposal is to also add SDG indicators. If no further concerns are raised the below tag vocabularies will be added added to the codelist within a week (by 4th of December).

2 SDG Goal A value from the top-level list of UN sustainable development goals (SDGs) (e.g. ‘1’) https://sustainabledevelopment.un.org/?menu=1300
3 SDG Target A value from the second-level list of UN sustainable development goals (SDGs) (e.g. ‘1.1’) http://unstats.un.org/sdgs/indicators/indicators-list/
4 SDG Indicator A value from the list of UN sustainable development (SDG) indicators (e.g. ‘1.1.1’) http://unstats.un.org/sdgs/indicators/indicators-list/

What are the plans for the SDGs as listed as Sector Vocabularies? It could be very confusing to have this information available in two places?

I agree with @Wendy, having SDGs in two places would be pretty unhelpful. Is there an idea/rule somewhere about the difference between sectors and tags?

I could imagine that the difference is something to do with sector vocabularies being comprehensive in coverage (i.e. one would/could apply to all activities), whereas tags do not need to be?

It would also be good to know why the DAC Policy Markers are also not included as a Tag vocabulary as they seem similar in use case/organisation to the SDGs.

DAC policy markers are not tags; they come with specific levels (the @significance attribute, which is mandatory when using the DAC policy markers vocabulary).

Sectors come with %, tags don’t. In other words, if an activity is coded with 3 sectors, the activity budget is split between them (evenly split if no % are specified). Tags are simply attached to an activity, without an implicit budget allocation.

Thanks @YohannaLoucheur that clarifies that the key question is whether users/publishers want/can supply percentages with the SDG information - once we know that, we can decide whether it should be a sector vocab or a tag vocab.

1 Like

Thanks for the follow-up @YohannaLoucheur and clarifying. Yes, it is correct that the difference between reporting SDGs using the sector vocabulary and including it in the tagvocabulary is that when reporting multiple SDG goals, targets, indicators at sector level a % is required.

@matmaxgeds , this proposal allows the flexibility to be able to report multiple SDGs using the tagvocabulary without having to assign a percentage.Feedback is indeed needed from users on which option is feasible and what the recommended guidance should be. At the TAG in Kathmandu earlier this month an initial discussion was started and suggestion made to set up a reference group to share, develop and review good practice.

No objection has been received since the proposal was posted 20 days ago so the tech team proceeded with including the codelist as per standard procedure for adding a non-embedded codelist. @matmaxgedsand and @Wendy are you content with inclusion?

Thanks all for comments and clarifications. Also while I don’t want to delay this update I am rather uncomfortable with this information being available within the Standard in two places. I also think that some publishers are already using the sector code vocabulary for SDGs so is there a recommendation for those publisher to update their published data to use the TagVocabulary codelist instead (although technically that could make the change not backward compatible and therefore should only happen as part of a major upgrade)? In addition, it would mean that data users would also have to check for SDG information in two places?

Three places actually:
As inputs (sectors), outputs (results) or non-specific (tags)

thanks for the summary @IATI-techteam - I am with @Wendy that having SDG data in two places would make using the data incredibly difficult - imagine if you wanted to compare the contribution to SDG1 of two donors, one of which used the sector vocabulary, and the other which used the tags - it doesn’t seem likely that there is any tool/website available to end users that could handle this situation.

I just did a check of the use of the SDG sector vocabs - I count 2 publishers using sector code=“7”, 1 using “8”, and 33 publishers using sector code=“9”

I’m confused by this. The DAC has already decided to report on SDG targets as tags, so clearly this option is feasible. Given the number of active IATI publishers who also report to the DAC, not having this option in the IATI standard would create important discrepancies in the data. Also, the fact that so few publishers currently report on SDG goals and targets as sectors (according to Matt below) shows that THIS option is clearly the least feasible.

We already have SDGs in more than one place in the standard (as Bill reminded us above). Nobody seemed to mind until now.

That being said, if we feel strongly about not having the same vocabulary in more than one place (which should have been flagged when they were duplicated), we could note for the next integer upgrade that:

  • SDG goals and targets should be removed from sectors (very few publishers use them at the moment) and reserved for the tag element
  • SDG should be removed from sectors and reserved for the Result element, since SDG indicators are about outcomes more than inputs.

Bottom line: now that the DAC has made a decision, donors and multilaterals reporting to the DAC will start coding their activities with SDG targets. This will be available in DAC statistics. It is up to the IATI community to decide whether they want them in IATI data as well - thus making IATI relevant to SDG monitoring - or not. I strongly recommend that we do.

It appears that they have already been added?! http://reference.iatistandard.org/203/codelists/TagVocabulary/

This therefore seems to me to be a case of principle vs practicality? I still do not feel that I could endorse this proposal on principle due to its impact on existing publishers and data users as mentioned previously by both myself and @matmaxgeds. Also, as I have not been involved in the most recent TAG or other discussions on SDG reporting etc.I would be really interested to learn in more detail what the other issues and limitations are (aside from publishers not having to assign a 100% or other value) as to the use of the existing implementations for SDGs (ie via sector or result indicators?) and how using the TagVocabulary is a better solution?

However, if it is subsequently decided to also add SDGs via the TagVocabulary then it would be good to know that it is being done so in a managed way with a clear recommendation of action(s) for existing publishers along with any appropriate communications around the deprecation(?) or other actions relating to the previous publishing options.

Bit off-topic here, so forgive me…

^^ I flagged this on github, but just to restate: I don’t think this is the process. The codelist management process is described on the codelist management page:

If a decision has been made to make a change to a non-embedded list the IATI Standard discussion thread *will be notified* (within 1 working day) about the change that is to be made and *the date that the change will take effect* (usually within 7 calendar days). The proposal will be *marked as ‘Planned’* on the support forum. At this point people have the right to disagree.

I’ve highlighted above all the bits that I don’t think happened here. In this sense, I don’t think the process has been adhered to.

I would be really interested to learn in more detail what the other issues and limitations are (aside from publishers not having to assign a 100% or other value) as to the use of the existing implementations for SDGs (ie via sector or result indicators?) and how using the TagVocabulary is a better solution?

@Wendy - to your point, @aparr or @petyakangalova facilitated the SDG session at TAG and might have more comprehensive notes.

1 Like

@andylolz I have responded to Github as well. It was indeed an error that the changes were picked up with the deployment of the website this week, as opposed to next week (giving the community until 4th of December). @matmaxgeds this refers to your comment that the changes are live on the website. We will wait to hear opinions until 4th of December (until either a consensus is reached or proposal rejected) and will then update the tagvocabulary codelist accordingly.

Following the 7 day period since the proposal was added for inclusion consensus has not been reached on adding SDG goals, targets and indicators under the tagvocabulary.

As Reid mentioned above at the TAG in Kathmandu some participants volunteered to form a working group on SDGs that can look at current challenges with how the standard currently incorporates SDGs and focus on recommendations for SDG reporting (addressing some of the questions raised in this thread). @aparr will be following up with participants who volunteered end of this week/early next week.

This proposal will be put ON-HOLD until there is clearer guidance and consensus on the inclusion of SDGs under TagVocabulary.

Another reason for the M&E expert community to get their act together and agree upon some standards. This isn’t an IATI problem.

Personally I think the issue is between inputs and outputs. Tags are just tags, not analytical classifications.

This is a very unfortunate turn of events. There is no downside to adding this codelist to the Tag element.

The result of putting this change on hold is that SDG tags reported to the DAC will not be available in IATI data. This will make IATI data less relevant for SDG-related discussions, a missed opportunity for data use efforts.