La autoridad no es una propiedad de las filas

Existe en Uganda un consejo municipal llamado MASAKA TOWN COUNCIL. Tiene 5.731 habitantes y se encuentra en el Manafwa District, en el extremo oriental del país, pegado a la frontera keniana.

Existe también un lugar llamado Masaka. Es una ciudad de 294.166 habitantes situada en el suroeste, a unos 400 km de distancia. Los dos no tienen nada que ver el uno con el otro más allá de un nombre compartido.

Ambas filas proceden del mismo fichero: el censo del Uganda Bureau of Statistics. Ambas son correctas. Un pipeline que una datos geográficos por la cadena MASAKA las fusionará de todos modos, y nada en ninguna de las dos fuentes protestará.

Este artículo trata de defectos con esa forma — allí donde cada número publicado por un organismo con autoridad es correcto uno a uno, y el conjunto de datos construido a partir de ellos sigue siendo erróneo. Hemos escrito por separado sobre las filas abiertamente corruptas de las estadísticas oficiales, incluido un defecto de sustitución de caracteres en el censo de Estados Unidos que inventó cuatro apellidos. Este caso es el más difícil, porque no hay nada que corregir. La fuente está bien. Lo que está mal es el supuesto.

El supuesto: un nombre identifica un lugar

No lo hace. En el censo ugandés analizado — 2.669 filas administrativas, de las cuales 577 son consejos municipales — cinco nombres de consejo municipal los llevan dos consejos distintos cada uno:

El par MAYUGE es el instructivo, porque uno de los dos consejos está en el Mayuge District y el otro no. Un paso de deduplicación que conservara «la fila cuyo distrito coincide con su propio nombre» acertaría con este par por casualidad y se equivocaría en silencio con KINONI, donde ninguno de los dos consejos está en un distrito de ese nombre.

Y MASAKA es peor que un duplicado, porque las dos filas ni siquiera son el mismo tipo de cosa: un consejo municipal de 5.731 personas dentro de un distrito y una ciudad de 294.166 personas que constituye su propio distrito. Haga la unión por el nombre y o bien pierde el 98 % de Masaka, o bien gana 5.731 personas en la provincia equivocada, según cuál de las dos filas conserve por azar su GROUP BY.

La comprobación que detecta esto no es en absoluto una comprobación sobre los valores. Es esta: ¿el campo por el que está uniendo es realmente único en la fuente? Un solo COUNT() ... GROUP BY name HAVING COUNT() > 1 sobre las 577 filas devuelve cinco, y cinco no es cero.

El mismo fallo con otra autoridad: Wikidata

Nos topamos con el problema idéntico desde el otro extremo mientras montábamos los pesos de población de las ciudades. El método consistía en resolver cada nombre de ciudad en una entidad de Wikidata y leer en ella la declaración de población. Wikidata es una base de conocimiento curada, estructurada y legible por máquina — más autoridad que esa no puede esperar una unión automatizada.

Los nombres que lo rompieron eran palabras corrientes:

Ninguno de estos casos es un error de Wikidata. Cada entidad de destino está descrita correctamente. El error es enteramente nuestro: creer que un nombre más un país bastaban para identificar una localidad.

El residuo es un fichero de más de 60 correcciones manuales que abarca 17 locales — búlgaro, checo, alemán de Austria, griego, español, finés, francés de Bélgica y de Canadá, francés, croata, húngaro, italiano, noruego, polaco, rumano, rumano de Moldavia, ruso, eslovaco. Ese fichero no se puede derivar de ninguna fuente. Es la relación acumulada de cada lugar donde el método automático se equivocó, y si se borrara, la única manera de reconstruirlo sería cometer de nuevo los 60 errores.

El único resguardo automático que sí funciona es barato y merece copiarse: cuando la propiedad «país» de la entidad resuelta no coincide con el país del locale, emita un aviso. Los aciertos en el país equivocado son el subconjunto más ruidoso de los errores de homonimia y encontrarlos cuesta una sola comparación.

Un número que aparece dos veces es una transcripción

La versión estrecha de la comprobación de unicidad se aplica a los valores, no solo a las claves. Wikipedia viene dando una población de 195.531 para la ciudad ugandesa de Mbarara. En el fichero del censo de la UBOS, 195.531 es la población de Kyengera Town Council, un suburbio de Kampala situado a unos 260 km de allí. El total del propio Mbarara District es de 472.629.

Alguien que leía un largo PDF de tablas tomó el valor de la línea equivocada. Es el error más ordinario que quepa imaginar y probablemente el más ampliamente propagado de todo este artículo, porque una cifra de población de Wikipedia se copia mucho más a menudo de lo que se abre un PDF de censo. La regla es: una cifra debería aparecer en un solo sitio. Si el número de la ciudad A es idéntico byte a byte al número de la ciudad B en el documento fuente, uno de los dos es una transcripción, no una coincidencia.

Cuando la fuente no quiere decirle nada

Otro modo de fallo es el de una fuente con aires de autoridad que sencillamente no se puede comprobar.

forebears.io es el ejemplo canónico. Es un agregador propietario: no publica ninguna metodología por país, ningún registro de fuentes ni ninguna fecha de recogida. ridni.org y stats.ridni.org son el mismo tipo de fuente: aparece un número y detrás de él no aparece nada.

Queremos ser precisos sobre lo que podemos y lo que no podemos afirmar aquí. Podemos decir que los datos son inverificables: no hay metodología que leer ni forma de volver a derivar una cifra. No podemos sostener, ni hemos visto prueba alguna de ello, la afirmación más fuerte de que el sitio sirva deliberadamente cifras distorsionadas a los clientes automatizados; eso se aseveró en unas notas de trabajo que heredamos y no lo respalda nada que podamos reproducir. Un método no publicado no es prueba de un método deshonesto.

La posición defendible es más estrecha y sigue bastando: una cifra que no se puede rastrear hasta un registro ni volver a derivar es, como mucho, una pista sobre el orden, nunca un peso, y toda fila que se apoye en una de ellas debería quedar etiquetada en el conjunto de datos, para que un lector futuro sepa cuáles son.

La parte en la que se trata de nosotros

Sería cómodo terminar aquí, con una lista de errores ajenos. El defecto más caro de este tipo en el proyecto fue el nuestro, y sobrevivió precisamente porque parecía una confirmación.

Los pesos de los apellidos ucranianos (uk_UA) llegaron a producir una proporción del top 10 del 5,45 % dentro del corpus. Teníamos anotada una cifra del 5,45 % como proporción real del top 10 en el conjunto de la población ucraniana. Las dos coincidían exactamente, y la coincidencia se leyó como una validación.

Era justo lo contrario. La relación

top-10 share in corpus  ×  coverage  =  top-10 share in population

es una identidad, no una hipótesis. Si las dos proporciones son iguales, la identidad dice que la cobertura es del 100 % — que el corpus contiene todos los apellidos del país. El corpus tenía 2.207 apellidos. Ucrania tiene aproximadamente 707.685. Una cobertura del 100 % era imposible, así que uno de los dos números tenía que estar mal.

Lo estaban los dos. La cifra del corpus estaba inflada por una cola plana: 1.900 de las 2.207 entradas (86 %) se situaban en el peso mínimo de 2 y en conjunto llevaban el 71 % de la masa total. Y el 5,45 % «real» estaba a su vez equivocado — recalculados a partir de los recuentos de Yu. Pradid, los diez apellidos más frecuentes de Ucrania cubren 821.657 portadores de unos 45 millones, es decir, un 1,83 %; Мельник es un 0,24 %, no el ~1 % que veníamos arrastrando.

«Después» es el estado a 18 de julio de 2026, inmediatamente después de la corrección. El corpus se ha vuelto a reconstruir desde entonces: a 22 de julio de 2026 contiene 2.376 apellidos basados en los recuentos de cabeza del registro, una proporción del top 10 del 9,4 % y, frente a la cifra de población del 1,83 %, una cobertura implícita de en torno al 19 % — que es la forma que debería tener un corpus delgado de un repertorio muy plano.

Una concordancia perfecta entre dos números obtenidos de forma independiente es un hecho que pide explicación, no un resultado que pida celebración. Este era un doble fallo disfrazado de confirmación.

La trampa emparentada es la verificación circular. Si sus pesos se calibraron a partir del registro X, comprobarlos contra el registro X — o contra un artículo publicado que tomó sus cifras del registro X — mide su aritmética, no el mundo. Lo pillamos dos veces en un mismo día: una estimación húngara sobre un apellido etnónimo que parecía confirmar nuestro 8,20 % pero bebía del mismo registro, y una comprobación española en la que la proporción del top 10 multiplicada por la cobertura reproducía la proporción de población de forma casi tautológica. Nuestra autocomprobación taiwanesa concuerda hasta 0,03 puntos porcentuales y en el texto la etiquetamos como comprobación de coherencia interna y no como verificación, porque es exactamente eso lo que es. El antídoto consiste en teclear a mano la lista de comparación desde una fuente sin relación con la nuestra, y nuestros comprobadores de listas de cabeza hacen justamente eso.

Qué hacer en la práctica

1. Pruebe la unicidad de la clave de unión antes de unir. No los valores: la clave. Cinco nombres duplicados entre 577 consejos municipales ugandeses están a un GROUP BY de distancia.
2. Pruebe si dos filas que comparten nombre son el mismo tipo de objeto. MASAKA TOWN COUNCIL y MASAKA CITY se diferencian en un factor de 51 porque uno es un consejo municipal y la otra una ciudad de nivel distrital.
3. Pruebe que un valor aparece una sola vez. Cifras idénticas en dos entidades significan transcripción.
4. Avise cuando una entidad resuelta se salga del país esperado. Es el resguardo más barato posible contra los homónimos, y sirvió para pillar Nokia y León.
5. Mantenga el registro de correcciones manuales bajo control de versiones y trátelo como dato primario. Sesenta correcciones que ninguna fuente puede regenerar valen más por byte que cualquier otra cosa del pipeline.
6. Desconfíe de la concordancia. Cuando dos números coinciden exactamente, averigüe si son independientes. Cuando no lo son, la coincidencia no significa nada.
7. Etiquete las filas que se apoyan en fuentes inverificables, para que un mantenedor futuro pueda encontrarlas sin volver a derivar la procedencia.

La autoridad es una propiedad de las instituciones. La corrección es una propiedad de las filas. El Uganda Bureau of Statistics tiene autoridad y su fichero contiene dos lugares distintos llamados Masaka, porque Uganda contiene dos lugares distintos llamados Masaka. El defecto nunca estuvo en el censo. Estaba en la unión.

Datos actualizados a 2026-07-18

Todas las cifras se recalcularon el 18 de julio de 2026 a partir de los ficheros primarios e intermedios que se enumeran más abajo. Allí donde nuestras notas de trabajo anteriores discrepaban de los ficheros, mandan los ficheros, y la discrepancia se hace constar en el texto.

Fuentes:

• Uganda — UBOS, National Population and Housing Census 2014, perfiles regionales por área analizados hasta formar una jerarquía administrativa (2.669 filas a nivel de district / county / sub-county; 577 consejos municipales). MASAKA TOWN COUNCIL 5.731 en el Manafwa District, Bubulo West County; MASAKA CITY 294.166; las dos filas MAYUGE TOWN COUNCIL con 12.481 (Bugiri) y 20.197 (Mayuge). <ubos.org/&gt;
• Wikipedia, artículo sobre Mbarara, población 195.531 — coincidente con Kyengera Town Council en el mismo fichero de la UBOS. Total del Mbarara District 472.629.
• Wikidata — utilizada para resolver nombres de ciudad en declaraciones de población; fallos de homonimia corregidos en un registro manual de parches de más de 60 entradas repartidas en 17 locales.
• Ucrania — corpus de 2.207 apellidos (tal como estaba entonces) frente a aproximadamente 707.685 apellidos en el país; proporción del top 10 en la población recalculada a partir de los recuentos de Yu. Pradid en 821.657 portadores, es decir, un 1,83 %.
• forebears.io — agregador propietario, sin metodología publicada por país, sin registro de fuentes y sin fecha de recogida; las cifras no pueden rastrearse hasta un registro ni volver a derivarse.

Sobre la afirmación relativa a forebears.io. Unas notas de trabajo que heredamos aseveraban que el sitio devuelve datos deliberadamente distorsionados a los clientes automatizados. No pudimos reproducirlo ni respaldarlo de ningún otro modo, así que no se afirma en este artículo; lo que sí se afirma es que los datos no son rastreables, lo cual es verificable y suficiente.

Sobre la identidad de cobertura. top-10 share in corpus × coverage = top-10 share in population es una identidad algebraica siempre que las definiciones sean coherentes. Es útil porque castiga la coincidencia y peligrosa porque se satisface trivialmente cuando ambos miembros proceden del mismo registro. Véase Cómo auditar un conjunto de datos de frecuencia de nombres y Lo que hicimos mal con los datos de nombres.