fititnt
commented
2 years ago @TODO edit one by one and add missing UN m49 directly on Wikidata
Wikipedia do have most of the ISO 3166-1 numeric (which, by definition, would be equivalent to UN m49 codes). However, the UN m49 codes themselves have only 16 over 177 ISO 3166-1 numeric items.
Not as sure if automate this or do one by one, but even if take some time, makes sense to add the missing numeric codes, so we can simplify the queries.
Trivia
From the list of existing codes, seems previous people started from letter A to add the codes then stopped. I'm not evey surprised with this, since lexicography, is quite common the first letters be doing with far more attention/time and then the rest be rushed.
Current SPARQL query
This query is somewhat manual, but the idea would be generate it based on what Wikidata P's would be related to adm0.
In any case, this more manual query at least allow know which properties have more data. Some like the KML (https://www.wikidata.org/wiki/Property:P3096) have very few points, while the geoshape (https://www.wikidata.org/wiki/Property:P3896) seems to have for every adm0 we're getting (returns a link to geojson, based on data published by datahub; not as perfect as the COD-ABs and I'm very sure not as updated, but at least allow quick use of some geometries for other checks).
SELECT
(xsd:integer(?ix_iso3166p1n) AS ?item__conceptum__codicem)
(STRAFTER(STR(?item), "entity/") AS ?item__rem__i_qcc__is_zxxx__ix_wikiq)
#?item__rem__i_qcc__is_zxxx__ix_iso3166p1n
(GROUP_CONCAT(DISTINCT ?ix_iso3166p1n; separator = "|") AS ?item__rem__i_qcc__is_zxxx__ix_iso3166p1n)
(GROUP_CONCAT(DISTINCT ?ix_unm49; separator = "|") AS ?item__rem__i_qcc__is_zxxx__ix_unm49)
(GROUP_CONCAT(DISTINCT ?ix_iso3166p1a2; separator = "|") AS ?item__rem__i_qcc__is_zxxx__ix_iso3166p1a2)
(GROUP_CONCAT(DISTINCT ?ix_iso3166p1a3; separator = "|") AS ?item__rem__i_qcc__is_zxxx__ix_iso3166p1a3)
(GROUP_CONCAT(DISTINCT ?ix_unescothes; separator = "|") AS ?item__rem__i_qcc__is_zxxx__ix_unescothes)
(GROUP_CONCAT(DISTINCT ?ix_unagrovoc; separator = "|") AS ?item__rem__i_qcc__is_zxxx__ix_unagrovoc)
(GROUP_CONCAT(DISTINCT ?ix_xzosmrel; separator = "|") AS ?item__rem__i_qcc__is_zxxx__ix_xzosmrel)
(GROUP_CONCAT(DISTINCT ?ix_xzgeonames; separator = "|") AS ?item__rem__i_qcc__is_zxxx__ix_xzgeonames)
(GROUP_CONCAT(DISTINCT ?ix_jpgeolod; separator = "|") AS ?item__rem__i_qcc__is_zxxx__ix_jpgeolod)
(GROUP_CONCAT(DISTINCT ?ix_usworldnet; separator = "|") AS ?item__rem__i_qcc__is_zxxx__ix_usworldnet)
(GROUP_CONCAT(DISTINCT ?ix_usfactbook; separator = "|") AS ?item__rem__i_qcc__is_zxxx__ix_usfactbook)
(GROUP_CONCAT(DISTINCT ?ix_xzgithubt; separator = "|") AS ?item__rem__i_qcc__is_zxxx__ix_xzgithubt)
(GROUP_CONCAT(DISTINCT ?ix_zzwgs84point; separator = "|") AS ?item__rem__i_qcc__is_zxxx__ix_zzwgs84point)
(GROUP_CONCAT(DISTINCT ?ix_zzgeojson; separator = "|") AS ?item__rem__i_qcc__is_zxxx__ix_zzgeojson)
WHERE
{
?item wdt:P31 wd:Q6256 ;
OPTIONAL { ?item wdt:P2082 ?ix_unm49. }
?item wdt:P299 ?ix_iso3166p1n.
OPTIONAL { ?item wdt:P297 ?ix_iso3166p1a2. }
OPTIONAL { ?item wdt:P298 ?ix_iso3166p1a3. }
OPTIONAL { ?item wdt:P3916 ?ix_unescothes. }
OPTIONAL { ?item wdt:P8061 ?ix_unagrovoc. }
OPTIONAL { ?item wdt:P402 ?ix_xzosmrel. }
OPTIONAL { ?item wdt:P1566 ?ix_xzgeonames. }
OPTIONAL { ?item wdt:P5400 ?ix_jpgeolod. }
OPTIONAL { ?item wdt:P8814 ?ix_usworldnet. }
OPTIONAL { ?item wdt:P9948 ?ix_usfactbook. }
OPTIONAL { ?item wdt:P9100 ?ix_xzgithubt. }
OPTIONAL { ?item wdt:P625 ?ix_zzwgs84point. }
OPTIONAL { ?item wdt:P3896 ?ix_zzgeojson. }
}
GROUP BY ?item ?ix_iso3166p1n
ORDER BY ASC(?item__rem__i_qcc__is_zxxx__ix_iso3166p1n)
While the mappings at least at admin0 ("country level") is straightforward (since we can map ISO 3166-1 used on P-Codes prefix and UN m49), things get tricky already at admin boundary level 1. We know some UN PCode patterns of at least some regions (such as the case of P-Codes from Brazil) which we're even lucky have a mapping ready to use like https://www.wikidata.org/wiki/Property:P1585. But not sure about the rest.
Why such mappings becomes relevant
Even if we only manage to somewhat make mappings at best case of admin 1 and only specific administrative regions got very detailed, this alone already allow get more data from Wikidata, which is by far the best place different persons and organizations use it. I personally think (at least as soon as it get decent) worth allow publish such mappings as dedicated public domain dataset, so ITOS or OCHA can at least use it even if for internal comparisons. However, this "soon" can take time and is more likely that for population statistics such as #43, the data from such mappings would be less accurate than what OCHA have, in special for countries with active crisis.
However, in any case, the mappings start allow we know much more mappings (including OpenStreetMap and UN/LOCODE). But by no means I think this will be something ready anytime soon (assuming is something that could be ready at all, since regions can change over time).
Potential approaches
Tooling specialized to integrate intermediate controlled vocabularies
This topic alone will require create several scripts and strategies (even if the early ones would become not as necessary in the medium term) to start know how to make the other relations. The ones we should do more attention are what is relevant to run from time to time to discover new changes.
1. (Not sure, needs testing) maybe compare by matching geometries
At the moment we did not attempted to run tools which could make any type of matching by geometries, but while this definitely would need human intervention, maybe it could work.
To reach this point, not only we would need to create the scripts, but likely allow it run (maybe weekly or monthly) to check the official COD-ABs with what whatever is on Wikidata uses.
2. Trying reverse engineering numeric part of P-Codes (and hope already exist Wikidata P with them)
Since the documentation on how to design P-Codes for more than one decade already recommended to try reuse existing country codes, is likely that more regions would have equivalences such as IBGE Code P1585. The only thing we're sure is that all P-Codes without admi0 prefix are fully numeric (with few exceptions), so this already exclude a lot of potential existing codes
However, the new problem would become if other countries do have mappings on Wikidata P property (and such mappings be as updated as P1585 by others). Otherwise, even if we could know country by country how the P-Codes where designed without try and error (and they be be an 1:1 matching P-Code, which, again, we can't take for granted without human intervention) we cannot use it.
In any case, whatever would be the strategy to map P-Codes to Wikidata Q, we would need to document very well to allow revision.
3. Other inferences
There's several other codes on Wikidata, from OpenStreet Map (https://www.wikidata.org/wiki/Property:P402), UN/LOCODE (https://www.wikidata.org/wiki/Property:P1937), HASC (https://www.wikidata.org/wiki/Property:P8119) to a popular one, the GeoNames (https://www.wikidata.org/wiki/Property:P1566, this one not sure why somethines have more than one code for same place). They might somewhat allow some way to triangulate with P-Codes, but not sure at the moment.