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.
Issues
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.
Options
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="https://glidenumber.net/glide/public/search/search.jsp">
This assumes that the entry would have the same vocabulary @code
as it does on the HumanitarianScopeVocabulary codelist)
Unambiguous
Official
Requires (small) edit to the standard, which might take a bit of time
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="https://glidenumber.net/glide/public/search/search.jsp">
Unambiguous
Require no change to the standard
Extensible approach - this can be done with any codelist with a unique URI
Depends on the vocabulary URI not changing, or being redirected if it does
More susceptible to typos!
Option 3
Endorse the use of <humanitarian-scope>
elements in activities which do not have @humanitian='1'
Require no change to the standard
Ambiguous
Possibly confusing
More susceptible to typos!
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.
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…”
markbrough: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.