Open hayttom opened 1 month ago
We use dates for versions as like many systems a branching phenomenon occurs, and versions are not tagged but are identified by dates
Note the dates in 4 versions of updated data for the following: https://[apps.itos.uga.edu/CODV2API/api/v1/themes/cod-ab/locations/UKR](https://apps.itos.uga.edu/CODV2API/api/v1/themes/cod-ab/locations/UKR)
HDX are unhappy. The crux is: For Administrative Boundaries, the truth has generally exists for finite determinable time periods. For instance the last change to the Canadian ADM0 and lower ADM levels in adjacent features was the establishment of our new land border with Greenland (Denmark) in 2022. The previous change was the ADM0_EN name "Newfoundland and Labrador" (previously "Newfoundland"). I feel the the start date should be 2022 and the end-date ongoing. HDX would feel (if there were a Canadian COD) that start date should be the date that the COD is updated.
For Population Statistics we all know that a child dies every minute in some of our countries. Population statistics are estimates assigned to a census date or to a projection date (which is normally only known as / referred to as a whole year). What to do there?
We have an unused versionlabel or version tag if you will that would provide for both if needed. In this way HDX or similar you can show all ADM0 datasets tagged "Newfoundland and Labrador " or "Greenland" or 2022 where Canada would show up. The tag can be updated with the dataset entry.
Javier at HDX raised concerns about the use and significance of validity dates in HDX datasets.
Tom to confer with UNFPA