WQuestions

Parte I · El problema

01

La torre de Babel de los datos

La información que salva una vida puede existir, estar guardada y no estar oculta para nadie, y aun así ser imposible de consultar. No es un fallo del azar: es un fallo de diseño que hemos repetido durante décadas.

Son las dos de la madrugada y entra en urgencias una mujer de cuarenta y dos años. La llamaremos María Gonzales.

Está consciente, pero suda frío y le falta el aire. Dice que tiene un dolor en el pecho que no cede.

El médico de guardia tiene minutos, no horas. Y para decidir bien necesita tres respuestas: qué medicación toma a diario, si tiene alergias documentadas y si ya vivió antes un episodio parecido.

Teclea su nombre en el sistema del hospital. La pantalla devuelve tres líneas: una bronquitis tratada hace cuatro años. Nada más.

Lo desesperante es que la información existe.

Gonzales tiene una endocrinóloga que lleva su historia desde hace siete años. Hace unos meses la evaluó un cardiólogo en otra ciudad. Y ya pasó por una urgencia muy parecida en un tercer centro, donde le hicieron un electrocardiograma completo.

Cada dato está escrito y guardado en algún disco. Ninguno de esos profesionales tiene el menor interés en ocultarlo.

El obstáculo no es el secreto ni la pérdida. Es que sus datos están repartidos en esquemas que no se hablan entre sí.

La endocrinóloga usa un software que guarda el diagnóstico en un campo llamado diagnostico_principal. El sistema del cardiólogo, hecho por otra empresa, lo registra como dx_p.

Con la medicación pasa lo mismo. La primera clínica la anota plana: nombre, dosis y frecuencia. La segunda montó una tabla de prescripciones que pide un número de fármaco, los miligramos por toma y las tomas al día.

Dos formas legítimas y razonables de anotar exactamente lo mismo. E incompatibles.

Si trabajas en software, ya sabes que conectar esas dos bases se puede. No es ciencia ficción.

Pero es un trabajo artesanal, caro y frágil: programar un puente de código, emparejar a mano qué columna equivale a qué columna, escribir una excepción por cada formato de fecha.

Y ese puente caduca. El día en que una de las clínicas actualice su sistema y renombre un solo campo, el puente se rompe en silencio.

Multiplica ese esfuerzo por miles de hospitales, decenas de proveedores y décadas de historias clínicas. Deja de ser un reto de ingeniería y se revela como un problema de diseño del tamaño del planeta.

La información existe. Lo que falta es poder razonar con ella.

La información de Gonzales no está perdida ni oculta. Está atrapada en idiomas que nunca acordaron hablar entre sí.El problema de Babel

El mismo hecho, cuatro idiomas distintos

El drama de urgencias es la versión extrema. Pero el mecanismo que lo causa late en el sistema más banal.

Para verlo en cámara lenta, bajemos a un escenario sin víctimas: una tienda de ropa.

A las 16:32, en la tienda del centro, el vendedor 17 le vende una camiseta a un cliente. La llamaremos venta_001.

Es un hecho del mundo, uno solo. Y si te asomas a los servidores del negocio, descubrirás que sus sistemas lo anotan en cuatro lenguajes que no se parecen en nada.

Para el punto de venta, la caja, lo que importa es la transacción y quiénes la protagonizan. El hecho se guarda como una fila:

SQL · punto de venta
INSERT INTO ventas
  (id, cliente_id, producto_id, monto, fecha, vendedor_id)
VALUES (1, 1042, 88, 49.90, '2026-05-14', 17);

Para contabilidad, en cambio, la identidad del vendedor o del cliente es irrelevante. Su única obsesión es que las cuentas cuadren por partida doble. El mismo evento se descompone en un asiento:

asiento · contabilidad
asiento: 2026-05-14
  debe:  cuentas_por_cobrar        49.90
  haber: ventas_brutas            42.29
  haber: impuesto_al_consumo       7.61

El equipo de analítica de producto ve otra cosa todavía. Le importa el comportamiento y el canal, para medir campañas. Estructura el hecho como un evento de telemetría:

JSON · telemetría
{
  "evento": "compra_completada",
  "id_usuario": "u_1042",
  "sku": "sku-88",
  "ingreso": 49.90,
  "canal": "tienda_fisica",
  "id_sesion": "s_abcdef"
}

Y para inventario, por fin, solo ocurrió una cosa: una camiseta salió del almacén. El evento se reduce a un movimiento de existencias:

JSON · inventario
{
  "movimiento": "salida",
  "producto": 88,
  "cantidad": 1,
  "almacen": "tienda_central",
  "ref": "vta-1"
}

Mira la desconexión. Cuatro equipos, cuatro estructuras. Cada esquema es perfecto y coherente para quien lo diseñó.

La fractura aparece cuando la dirección pide una visión global.

Si le entregas estas cuatro piezas a una computadora, no tiene forma obvia de saber que las cuatro hablan del mismo suceso. Contabilidad no sabe quién vendió la camiseta. Analítica no sabe de qué almacén salió. La caja no sabe separar el impuesto.

Cada programa capturó la sombra del evento que le interesaba y la archivó en su dialecto privado.

venta _001 UN hecho del mundo PUNTO DE VENTA vendedor_id 17 cliente_id 1042 monto 49.90 ¿quién? ¿cuánto? CONTABILIDAD cobrar 49.90 ventas 42.29 iva 7.61 ¿cuánto? ¿cuándo? ANALÍTICA evento compra canal tienda u_1042 ¿qué? ¿dónde? INVENTARIO salida producto 88 tienda_central ¿qué? ¿dónde?
Figura 1.1. Un único hecho (la camiseta que el vendedor 17 vendió a las 16:32) proyecta cuatro sombras parciales. Cada sistema captura la cara que le importa (vendedor_id, cobrar, evento, movimiento) y la escribe en su dialecto. Ninguna sombra sabe de las otras, aunque debajo todas respondan a las mismas preguntas.

A esta fragmentación la llamaremos, a lo largo del libro, la torre de Babel de las ontologías.

Y conviene desactivar una alarma: en datos, la palabra ontología no es un concepto filosófico inalcanzable.

Ontología (en ingeniería de datos)

El catálogo de conceptos que un sistema reconoce («cliente», «factura», «producto», «prescripción») y las reglas que dicen cómo se relacionan entre sí. Un diccionario con gramática, nada más esotérico.

El problema no es que existan ontologías. Es que cada departamento, empresa y disciplina construye la suya cerrada, de espaldas al resto.

El elefante en la habitación oscura

Hay una vieja parábola que describe esta torre de Babel mejor que cualquier diagrama.

En una habitación a oscuras encierran a un elefante. Entran a tientas varios hombres que jamás han tocado uno.

El primero palpa una pata y anuncia, convencido: «esto es una columna». El segundo abraza la trompa y lo corrige: «no, es una manguera gruesa». Un tercero acaricia la oreja y jura que es un abanico. Otro topa con el colmillo y asegura que es una lanza. El último se aferra a la cola y sentencia que es una cuerda.

Ninguno miente. Cada uno cuenta con honestidad lo que sus manos encontraron.

Y todos se equivocan, porque confunden la parte que tocaron con el animal entero.

Esa es la situación de nuestros sistemas.

El punto de venta toca la pata y la nombra vendedor_id. Contabilidad abraza la trompa y la llama cuentas_por_cobrar. Analítica acaricia la oreja y la registra como evento. Inventario topa con el colmillo y anota movimiento.

Cada ontología de dominio es uno de esos ciegos: palpa una región de la misma realidad, la describe con rigor impecable dentro de su alcance y la bautiza con un nombre que no se parece a ningún otro.

La torre de Babel no nace de la mentira ni de la incompetencia. Nace de que cada quien toma su vista parcial por la totalidad.

Pero el elefante existe.

Hay un animal completo debajo de las cinco descripciones incompatibles, y la pregunta decisiva es qué lo reconstruye.

La respuesta es el corazón de este libro. Lo que devuelve el animal entero no es una sexta ontología más fina, sino un repertorio de preguntas anterior a todas ellas.

«¿Quién?», «¿qué?», «¿dónde?», «¿cuándo?», «¿cuánto?» y «¿cuál?» no tocan una parte del elefante. Son las coordenadas que sitúan cualquier parte dentro del mismo cuerpo.

La pata y la trompa dejan de ser objetos rivales y pasan a ser dos respuestas, al «qué» y al «dónde», de un único hecho.

UNA realidad · cuatro nombres incompatibles PUNTO DE VENTA «es una columna» ANALÍTICA «es un abanico» CONTABILIDAD «es una manguera» INVENTARIO «es una lanza» La capa de preguntas reconstruye el animal completo Q quién O qué L dónde T cuándo N cuánto K cuál
Figura 1.2. El elefante en la habitación oscura. Cada sistema toca una parte del mismo animal y la nombra distinto («columna», «abanico», «manguera», «lanza»): así nace la torre de Babel. Las ontologías de dominio capturan vistas parciales; las preguntas son el animal completo. La capa de coordenadas (quién, qué, dónde, cuándo, cuánto, cuál) no añade otra parte: reconstruye el todo situando cada parte dentro del mismo cuerpo.

La causa de todo el problema

La raíz de esta torre de Babel, y el punto de partida de este libro, cabe en una frase: hemos dejado que cada sector invente desde cero su propia forma de entender la realidad.

La ingeniería médica no hereda nada de la contabilidad. El comercio no comparte cimientos con el derecho. La educación diseña bases que jamás hablarán con las del urbanismo.

Cada industria levanta su pirámide con planos distintos. Y luego nos sorprende lo carísimo que resulta contratar gente para tender puentes colgantes entre las cimas.

Llevemos esa frase a un caso donde el aislamiento no cuesta dinero, sino una nave espacial.

El precio de no acordar las unidades

En 1999, la Mars Climate Orbiter de la NASA se desintegró al entrar en la atmósfera de Marte.

La causa no fue un error de cálculo, sino de vocabulario. Un equipo entregaba el empuje en libra-fuerza por segundo y el otro lo leía como si fueran newtons por segundo. Cada número, por separado, era correcto.

La nave navegó hacia una órbita equivocada y se perdió.

Doscientos millones de dólares y años de trabajo evaporados porque dos sistemas no dijeron en voz alta qué pregunta respondía cada número. La distancia entre dx_p y diagnostico_principal es la misma, solo que sin el cráter.

El patrón es siempre el mismo. Donde cada parte cultiva su jardín amurallado, el coste de conectar no crece poco a poco. Se dispara.

Si tienes n sistemas y los quieres comunicar de a pares, los puentes que hay que construir y mantener son n(n−1)/2.

Diez sistemas no piden diez traductores. Piden cuarenta y cinco. Y cada uno es un punto que puede romperse.

Figura 1.3. El coste de la fragmentación es combinatorio: conectar diez sistemas de a pares exige n(n−1)/2 = 45 puentes (rojo). Un vocabulario común al centro reduce el problema a un solo punto de conexión por sistema (verde). Pasa el cursor sobre las barras para ver las cifras.

Por eso existe el integrador de datos, ese rol que casi ninguna escuela enseña y que casi toda empresa necesita.

Su oficio es escribir y vigilar esos n(n−1)/2 puentes: los procesos que vacían una base en otra, los emparejamientos columna a columna, las excepciones por cada formato de fecha.

Es trabajo valioso, y a la vez trabajo que no debería existir. Es el impuesto que paga la industria por un pecado original de diseño.

Lo que ya se intentó (y por qué no bastó)

Sería injusto sugerir que nadie vio el problema. Llevamos décadas intentando derribar la torre.

Los intentos se agrupan en dos familias, opuestas y simétricas en su fracaso. Vale la pena entenderlas, porque marcan el hueco exacto que este libro quiere ocupar.

Vía 1 · Las grandes ontologías

Construir esquemas formales, ricos y minuciosos para cada dominio. Funcionan con una precisión admirable… dentro de su parcela. Pero son profundas y estrechas: modelar un campo nuevo cuesta años de comité, y dos ontologías profundas vuelven a necesitar un puente entre ellas. Resuelven Babel dentro de cada torre, no entre torres.

Vía 2 · La extracción abierta

Renunciar al esquema y dejar que una máquina extraiga relaciones del texto libre (la llamada OpenIE(23)). Es ancha pero informe: cubre cualquier tema, sí, pero produce tripletas sin tipos estables, sin unidades, sin distinguir un agente de un lugar. Mucha cobertura y poca estructura: imposible de consultar con rigor.

El callejón de las dos vías(4)

Las ontologías clásicas, de las que CIDOC CRM o las redes de frames son ejemplos refinados, ganan en estructura lo que pierden en alcance. La extracción abierta gana en alcance lo que pierde en estructura.

La industria osciló entre los dos extremos sin encontrar el punto medio: un esquema ancho y estructurado a la vez. Ese punto medio es lo que perseguimos, y la pista de dónde buscarlo no está en la informática, sino en algo mucho más antiguo.

Y aquí cabe una pregunta incómoda, la que abre la puerta a todo lo demás.

¿Y si la solución a este caos fuera anterior, y mucho más simple, que cualquier diseño de base de datos?

¿Y si mucho antes de que existieran los hospitales, los bancos o el comercio internacional, la humanidad ya hubiera fijado un armazón mental que nadie, en ningún idioma, puede evitar usar?

La apuesta de este libro

Volvamos a la venta una última vez.

Si paras a cualquier persona en la calle, sin nociones de bases de datos ni de código, y le pides que describa lo que pasó en esa tienda, dirá algo muy parecido a esto:

«El vendedor (quién) vendió (qué) una camiseta (qué) en la tienda del centro (dónde) esta tarde (cuándo) por casi cincuenta dólares (cuánto).»

Sin el menor esfuerzo, cualquier persona produce una descripción estructurada, completa y combinable.

La mente no percibe el mundo como un bloque de texto ni como una hoja de cálculo. Descompone cualquier evento con un repertorio brevísimo de preguntas.

Y aquí está el giro: esas preguntas son exactamente las coordenadas que las cuatro sombras de la venta estaban capturando por separado, sin saberlo.

Punto de venta Contabilidad Analítica Inventario LAS PREGUNTAS Q quién el vendedor 17 O qué la camiseta vendida L dónde la tienda del centro T cuándo a las 16:32 N cuánto 49,90 USD K cuál clase: camiseta cuatro dialectos un solo armazón
Figura 1.4. Los cuatro dialectos de la venta no son cuatro realidades: son cuatro recortes de la misma. Debajo de todos late un único armazón de preguntas. Si los sistemas declararan qué pregunta responde cada campo, convergerían sin necesidad de conocerse entre sí.

Esa es, enunciada con todas sus letras, la apuesta del libro:

La apuesta

Hay un puñado corto y estable de preguntas (siete) que basta para describir cualquier hecho, en cualquier industria y en cualquier idioma: quién, qué, dónde, cuándo, cuánto, cuál y cómo.

Si diseñas las bases de datos alrededor de esas coordenadas, y no del vocabulario de turno de cada sector, la fragmentación se corta de raíz. La torre de Babel se desmorona desde los cimientos.

Y viene un beneficio que en 1999, o en 2010, habría sonado a ciencia ficción.

Cualquier inteligencia artificial entrenada con lenguaje humano entiende esta estructura de fábrica, porque es la misma con la que aprendió a leer.

A un modelo de lenguaje no hay que explicarle qué es un «quién» o un «cuándo». Esas categorías ya viven en él.

Si los datos del mundo se expusieran sobre los ejes de las preguntas, un agente tendría que aprender a hablar una sola vez, en lugar de un dialecto nuevo por cada servicio que toca.

Conviene separar las siete coordenadas en dos grupos, porque así las recorreremos.

Seis fijan la posición de un hecho. La séptima, cómo, pone los enlaces que amarran las otras seis entre sí:

Q quién, O qué, L dónde y T cuándo son las cuatro más concretas: el agente, el objeto o evento, el lugar y el tiempo.

Son las que un niño domina primero, y las que ningún sistema deja de registrar por raro que sea su dialecto.

N cuánto y K cuál son las dos que el genérico «qué» suele esconder: la magnitud con sus unidades (las que la Mars Climate Orbiter aprendió a la mala) y la clase a la que algo pertenece.

Y M cómo es la séptima: los enlaces que conectan todo lo demás.

Adelantando un poco la maquinaria, así se ve el hecho venta_001 ya en el formato del modelo. Cada línea conecta el hecho con uno de sus valores, y la marca final dice a qué par de ejes pertenece:

tripletas · WQuestions
(venta_001, agente,   vendedor_17)   ∈ M(O, Q)
(venta_001, lugar,    tienda_centro) ∈ M(O, L)
(venta_001, instante, 16:32)         ∈ M(O, T)
(venta_001, monto,    49.90)         ∈ M(O, N)
(venta_001, clase,    camiseta)      ∈ M(O, K)

No te detengas todavía en la notación. El capítulo 7 la desarma pieza por pieza.

Lo único que importa ver aquí es que las cuatro sombras de la Figura 1.1 acaban de fundirse en un solo registro. Y que ese registro se lee de izquierda a derecha, como una frase, tanto para cualquiera de los cuatro sistemas como para una máquina.

Una promesa que se puede comprobar

No te pido que tomes esto como un acto de fe.

La fuerza de la apuesta no está en que suene elegante. Está en que estas siete preguntas no son un invento moderno.

Filósofos griegos, juristas romanos, escuelas de periodismo de 1900 y los propios niños que aprenden a hablar llegan a la misma lista, sin coordinarse y separados por siglos.

Cuando tantas tradiciones independientes coinciden, esa coincidencia deja de ser una hipótesis y empieza a parecer un descubrimiento.

A esa coincidencia, la prueba de por qué estas preguntas y no otras, le dedicamos un capítulo entero.

Pero no hace falta esperar a la demostración para empezar a construir. Conviene construir primero: ver la maquinaria funcionando convence más que cualquier argumento.

Cómo nació este modelo

Esta arquitectura no se diseñó en abstracto para luego forzar a los datos a encajar. Salió al revés: dominio tras dominio, chocando con las fricciones que cada negocio exigía resolver.

El día decisivo fue aquel en que vimos que ocho industrias sin relación entre sí, de un spa a un banco y de una clínica a una mina, pedían la misma solución disfrazada con vocabularios distintos. Cuando ocho problemas independientes convergen en la misma respuesta, esa respuesta deja de ser una opinión.

Lo que sigue es la ingeniería.

Vamos a desarmar las siete coordenadas una por una: qué significan, dónde están sus trampas, en qué casos límite parecen romperse.

Empezaremos por las cuatro más concretas (quién, qué, dónde y cuándo), porque son el suelo firme sobre el que se levanta todo lo demás.

La paciente Gonzales nos espera al final del camino. Cuando volvamos a su sala de urgencias, la consulta imposible de esta noche será una sola línea.