Proposing another formal method of classifying COVID-19 activities

Many thanks to everyone for the rapid thinking COVID-19.

I have two issues which have led me to consider three further options for classification.


Classifying Using Text

I don’t think this should be a formal method of classifying relevant activities - at least not on its own.

Although I absolutely encourage all publishers to be descriptive with project titles, there are legitimate reasons not to include “COVID-19”. There could be an existing convention of naming activities based on the country office they’re based in; it could be that the project has been named based on contractual or partnership details; it could be that the work is looking at the virus, not the disease.

To be clear, I think that using this approach will absolutely be helpful, but that it is not sufficient on its own.

Lack of Non-Humanitarian Classifications

In the linked guidance, it’s acknowledged that not all COVID-19 related projects will be humanitarian. Indeed, DFID is likely to have a mixture of hum / non-hum responses, as the pandemic touches all aspects of our work.

However, I presume it’s not best practice to use <humanitarian-scope> in a non-humanitarian activity. Although I can’t find any formal rule saying as much, intuitively I would only look for this element in activities where @humanitarian is true.

To allow for robust (non-statistical - see below) classification, I think one of the following three options needs to be endorsed by us as a community, and by the secretariat as a steward. I’ve very possibly missed something here, so shout if so.


Personally I recommend either Option 1 or Option 2, given my reluctance to use a <humanitarian-scope> element in non-humanitarian activities.

Option 1

Include GLIDE Codes as entries on the TagVocabulary codelist and recognise the following use of the <tag> element using it

This would allow for any activity that is relevant to be tagged in the following way:

<tag  vocabulary="1-2" code="EP-2020-000012-001" vocabulary-uri=""> 

This assumes that the entry would have the same vocabulary @code as it does on the HumanitarianScopeVocabulary codelist)

:+1: Unambiguous
:+1: Official
:-1: Requires (small) edit to the standard, which might take a bit of time
:-1: Not strictly necessary, given Option 2

Option 2

Recognise the following use of the <tag> element, declaring GLIDE as a custom vocabulary using code 99, 98, 97, etc.

<tag  vocabulary="99" code="EP-2020-000012-001" vocabulary-uri=""> 

:+1: Unambiguous
:+1: Require no change to the standard
:+1: Extensible approach - this can be done with any codelist with a unique URI
:-1: Depends on the vocabulary URI not changing, or being redirected if it does
:-1: More susceptible to typos!

Option 3

Endorse the use of <humanitarian-scope> elements in activities which do not have @humanitian='1'

:+1: Require no change to the standard
:-1: Ambiguous
:-1: Possibly confusing
:-1: More susceptible to typos!
:-1: I’d argue that the humanitarian scope, tag, and sector should have been <classification> elements all along :wink:

What about quantification?

In theory, it could be that people know exactly how much of a given activity is being budgeted, committed and spent on COVID 19. If so, we could use the approach of Option 2 above to refer to it in the element, as long as we could agree a ‘null’ value to pad the sector and ensure that it sums to 100 for that vocabulary. I’m planning to trial a similar approach with cross-government spending through International Climate Finance, and I’m interested to hear people’s thoughts.

1 Like

Seems option 1 has the fewest downsides if this change could be expedited. Just needs to be consulted on Discuss right? Option 2 feels hacky for some reason. Option 3 feels like overfitting a solution, and potentially introducing ambiguity?

Sometimes a simple imperfect solution is what is needed to make things work fast. Is this not a time to be pragmatic for all rather than perfect for a few?

I think this is a good discussion to have. I can understand the discomfort with using the humanitarian-scope element for non-humanitarian activities, and can see that tag might be more extensible. However, I think the overriding concern should be finding an approach to identifying projects related to the COVID-19 response that is most likely to be quickly implementable by a large range of organisations.

(I think quantification would require a bigger change to the standard that we probably shouldn’t focus on immediately.)

In other words: how quickly would publishing organisations be able to publish data in the humanitarian-scope element vs the tag element? Is there any difference between the two?

The IATI Dashboard shows there are currently 30 organisations publishing data in the humanitarian-scope element (8 are publishing data in the tag element). For these 30 organisations, presumably it would be easier to add a new code into their existing systems / publishing processes rather than to adjust the output to publish this particular crisis/response plan in a different element? That suggests to me that option 3 - using the humanitarian-scope element - might be the best approach for now.

(I think we should tidy things up here in future - e.g. standardising different vocabulary lists and improving the way we refer to different vocabularies.)


@bill_anderson: If people want to put ‘COVID-19’ in their project titles they can and should, and we can all agree to do a text search for relevant projects - none of the options contradict that or would make anyone act slower.

@markbrough: thanks for that analysis, point taken. Though for organisations not using the humanitarian attribute (and hence not using the humanitarian-scope element, the inverse is true, and again, my suggestion wouldn’t stop humanitarian organisations following the existing guidance.


The guidance is perfectly fine, especially to get data published on the first wave of funding published fast. But unless epidemiologists are wrong, Covid-19 is going to be with us for a long time, and having an affect on related and unrelated programming for — hope I’m not being alarmist here — years to come. I don’t think pragmatic and perfect/preferred are mutually exclusive.

The guidance itself starts out, “Version 1…”

I would say out of 1100+ publishers (caveats abound, I know), 30 and 8 are roughly equivalent.

I genuinely think <tag> could be useful here and elsewhere, and while it was initially lacking in codelists and recommended usage (hence 8), it’s been validated by the SDG guidance as of late September.

I wouldn’t be strongly opposed to Option 3, but I think @rory_scott’s analysis of “ambiguous, possibly confusing” reflects my personal hesitancy.

1 Like

This is a good point! Actually it made me think: I wonder if we should supplement here advice for users trying to access the data: if there are a few different options for publishing the data, maybe that is OK, as long as it’s clear how users would access the data (check the title, description, humanitarian-scope/@code and tag/@code).

I think the following will get the data from the v2 Datastore, according to any of the above options:

Both of these formats are not super accessible for the everyday user (and constructing the query was not super straightforward) - but given that we would expect to access this query through some nice front end - perhaps that is OK to have a couple of different ways of publishing this data; and we should spend our time focusing on how to improve various front-ends so that they can handle this complexity behind the scenes?

@rory_scott I don’t think it’s a matter of “if people want”. We’re still talking about a standard in which ALL publishers SHOULD use the title. If some can provide a more refined approach it should remain consistent with the simple universal case that allows all users to perform simple queries.

Over the years we have had many unresolved conversations about the need to simplify the standard. Is this another opportunity?

If this is to be the approach (not that I agree) I would suggest that both the Datastore and d-Portal add buttons to run this pre-built query. If we want to encourage more people to use IATI data we need to make access easier. A four-part filter doesn’t pass a user friendliness test …


I like @rory_scott’s option 2 - what would it take for IATI to adopt the GLIDE codelist necessary to make this really simple for everyone?

1 Like

@matmaxgeds IATI does recognise the GLIDE codelist, but only as an humanitarian scope vocabulary.

Bigger problem from a standards point of view is that GLIDE numbers are country specific and “EP-2020-000012-001” isn’t a valid code (it has been tweaked from “EP-2020-000012-CHN”).

This is a good point! GLIDE appears to use --- to denote codes that aren’t tied to a specific country:

  1. Go to the GLIDE search form
  2. Select country: (Non-Localized)
  3. See e.g. code TC-2008-000105----

So perhaps the code should be EP-2020-000012----

is quite different from adopting it i.e. replicating it. Currently, users have to search for “EP-2020-000012-001” which they have to look up themselves from a link to a website that you can find deep in the IATI website. If IATI made it replicated, users would be shown “COVID” when searching for or receiving data which would be much more helpful. It would also mean that D-portal and the Datastore could offer “COVID-19” on a dropdown, which neither can currently do because it is only “recognised”.

Yes, but it does still need to be added to the GLIDE database. (cf. your example

1 Like

Flagging for @IATI-techteam!

We recommend a simpler version of Option 2 where vocab="99" is treated as freetext and where no uri is needed, so

<tag  vocabulary="99" code="COVID-19"> 

We suggest this so that people can use the tag element in the way they would expect to use the tag element; ie. as organic tags.

Because the standard has recommended publishers include COVID-19 in the title, d-Portal is already equipped to find all these activities.

However, we have also be trialing more filters for search so it is possible to limit it by humanitarian-scope and/or tag.

And in this case, if tag were freetext, COVID-19 would be a dropdown.


Are there any lessons learned pieces from the Ebola crisis i.e. what worked with IATI and what didn’t? Were any studies done, anything internal? Presumably similar discussions on publishing were had?

If we assume that the same approach was used (putting Ebola in the activity title/description) then a d-portal text search - e.g. for the USA: gives something around 110 million.

This compares with a figures of 600 million from the US State Department:

I couldn’t get all the US Agencies to come up e.g. DCD, DOD etc, and I guess the figure in the press release is generous, but even then, this suggests that something would have to be very much improved (enforcement of the guidance?) if IATI is to be a useful data source for COVID in terms of capturing a reasonable estimate of the flows, as this is approximately 20% coverage.

Maybe examples from other publishers are better?

Edit: This study found something similar: which makes me conclude that before we all argue over how to do COVID reporting in IATI, it would probably help if we all discussed ‘what’ we are trying to do, i.e. what purposes we anticipate IATI data actually being used for in COVID.

Thanks to @IATI-techteam for the webinar yesterday, and @petyakangalova for facilitating in particular. I thought it was really positive, and great to hear a variety of perspective emerging. I have a few thoughts to underline coming out of it.

Regarding @bill_anderson’s thoughts on the title. I want to reiterate that I’m not against using “COVID-19” in the title, and I’m absolutely happy for us to say that this is sufficient for a given publisher: for a publisher like @Michelle_IOM, putting it in the title is fine. My contention is that there should be another formal and recognised way for development organisations to classify, inline with any of my options, or @shi’s suggestion above.

We wouldn’t ask UNHCR to rename every activity to “…including work on COVID-19” - they will of course use @humanitarian-scope with the corresponding code.

There are absolutely situations where I can imagine DFID adding ‘COVID-19’ to a title, and I will advocate for that, but there will be some projects and components for which that’s not appropriate, and I will also want to have a non-text field which reflects this classification formally.

Per @markbrough’s queries above, we can encode a relevant query in an URL very easily, and regardless of how we answer the questions above, we could make this query very inclusive. We could include “SARS-CoV-19”, “COVID-19”, “Orthocoronavirinae” - it’s just a query. In my view the real friction comes from formatting the data and presenting the relevant details.

I’m really not too opinionated on we answer the questions above. Currently I’m leaning mildly towards Option 2 or @shi’s proposal.

Do we have any further thoughts on quantifying through the use of <sector @vocabulary="not_OECD_DAC>? I don’t see any other way of putting numbers on COVID-19 spend, given the need to impute spend over transactions as we do with purpose codes.

1 Like

Hi @rory_scott and others, I would like to express my satisfaction with what the tech team produced in terms of guidance. For me it strikes the right balance, in speed and by the recommendations within the current elements and guidance. So chapeau!

In these times it is not easy for publishers to change and adjust program management system capability to capture new data points to an activity. Hence I understand @Michelle_IOM point s made in the webinar: adding COVID-19 to titles and descriptions is the fastest and easiest way to flag and filter out COVID-19 related activities.

I also support the recommendations for humanitarian projects to use of existing element practice and guidance. Also aware that many publishers have not yet incorporated the ability to use glide code and response code into their systems (as IOM) , so they can’t at his moment follow the recommendation.

I suggested to evaluate this in 2 month time. Than we can reflect on data use cases, and the possible need to recommend use of tag, or sector elements with new vocabularies.

As a publisher we just spend (significant) time and resources to properly introduce SDG tag, glide codes and humanitarian cluster codes in our project management system, as per 2.03.
At this stage, amids COVID-19 impact, we would not really welcome strong new recommendations for new vocabularies for TAG or SECTOR element use. This is not the time for system changes.

So I prefer the extension of available vocabularies for each element, rather than introducing new vocabularies for an element (even if reused from another element).

My plee would be to keep this simple and advice publishers to split off COVID-19 specific activities whenever possible, even when adjusting/altering ongoing activities, both Hum and Dev.

hope this makes sense

@shi @markbrough @matmaxgeds @bill_anderson


I would like to express my satisfaction with what the tech team produced in terms of guidance.

I don’t think anyone would contest that the @IATI-techteam responded remarkably quickly to a rapidly evolving situation and put out clear, concise, immensely actionable guidance. Chapeau indeed!

I think the concern here is that — as I already discussed earlier in the thread — this does not seem to be the kind of crisis that will neatly contain itself in time and space. Eventually, we may find that the indisputably right response in March is the wrong long-term response come 2021+, and overfitted to a particular “use case” (covid-19), especially if/when other across-the-board, all-hands-on-deck, beyond-humanitarian-response crises emerge in future.

I suggested to evaluate this in 2 month time.

I think that’s a perfectly reasonable timeline (or even longer), and agree that it would be disruptive to change course any earlier after the guidance just went out.

1 Like