Quién, qué, dónde, cuándo

El vendedor entregó la camiseta sobre el mostrador a las cuatro y media de la tarde. La frase tiene once palabras y la entiendes sin pensar: alguien hizo algo, con una cosa, en un sitio, en un instante. No hubo esfuerzo consciente, pero tu mente acaba de ejecutar una hazaña silenciosa. En menos de lo que dura un parpadeo separó la escena en cuatro piezas de naturaleza completamente distinta y le asignó a cada una su casillero exacto: una persona que actúa (el vendedor), una cosa que cambia de manos (la camiseta), un lugar físico (el mostrador) y un momento del reloj (las 16:32).

Y no solo las separó: las encajó sin equivocarse. A nadie le pasaría por la cabeza que «el mostrador» sea la persona, ni que «las cuatro y media» sea el objeto que cambió de manos. Esa operación de descomponer un hecho y colocar cada fragmento en su lugar correcto es, literalmente, la materia prima de todo este libro. Las cuatro preguntas que tu cerebro acaba de responder a ciegas (quién, qué, dónde, cuándo) son los cuatro pilares: las dimensiones que comparecen en cualquier descripción de algo que sucede, sin importar el idioma ni el grado de tecnicismo. Si falta uno, la historia se siente incompleta. Si están los cuatro, tienes al menos el armazón de un hecho.

En este capítulo recorreremos los cuatro pilares uno a uno. Todavía no como ejes matemáticos formales (eso vendrá cuando construyamos la arquitectura en la Parte III), sino como preguntas con personalidad propia. Cada una esconde rarezas, decisiones de diseño y convenciones que solemos pasar por alto. Comprenderlas a fondo ahora nos ahorrará incontables dolores de cabeza cuando empecemos a modelar bases de datos de verdad.

Para que el recorrido sea concreto, cruzaremos cada pilar con cuatro escenas que nos acompañarán toda la sección: la venta de una camiseta en una tienda, un gol de fútbol, una película y una ordenanza municipal. Cuatro mundos sin relación aparente; verás que responden a las mismas cuatro preguntas con la misma facilidad.

Q — Quién: la pregunta por el agente

A primera vista, quién parece el más inofensivo de los cuatro. Quieres saber quién hizo algo, quién recibió la acción o sobre quién recae la responsabilidad. La respuesta canónica que esperas es un agente capaz de ejecutar una acción: una persona, un grupo o una organización formal.

Cruzado con nuestras cuatro escenas, el panorama es plácido:

• Q 👕 Venta: ¿Quién despachó la camiseta? El vendedor, vendedor_17.
• Q ⚽ Fútbol: ¿Quién marcó el gol? El delantero, messi (y, con más detalle, quién dio la asistencia: di_maria).
• Q 🎬 Cine: ¿Quién dirigió la película? La directora, serra.
• Q 🏛️ Ordenanza: ¿Quién la promulgó? La municipalidad_centro, por mano del alcalde_reyes.

Hasta aquí, ninguna fricción. Pero la pregunta se vuelve fascinante apenas la sacamos de su zona de confort y la confrontamos con la realidad de los datos.

Un agente, varios agentes, agentes en disputa

Piensa en aquel gol. Lo hemos atribuido a messi, que remató, y a di_maria, que asistió. Pero «¿quién hizo la jugada?» admite respuestas en capas: quien remató, quien dio el pase, quien arrastró a los defensas para abrir el hueco. Y se complica más cuando el balón rebota en un defensor rival y entra al arco: las estadísticas oficiales hablan de «gol en contra» y, para la tabla de goleadores, le acreditan el tanto al delantero que pateó, no al defensor que lo desvió. El reglamento zanja la disputa; pero traducir esa decisión a una estructura de datos («este evento tiene un agente principal y varios agentes secundarios con roles distintos») está lejos de ser trivial.

El cine lo lleva al extremo. ¿Quién «hizo» pelicula_marea? La directora serra y la guionista haddad responden ambas a «¿quién?», pero con roles legalmente distintos: dirección y guion no son lo mismo, ni siquiera ocurren en el mismo momento. El problema empieza cuando un sistema mete a todos en un único campo genérico llamado autor. Cuando esa base de datos intenta compartir la información con otra, si nadie sabe qué convención interna usó cada una, los datos chocan: exactamente el conflicto de la torre de Babel.

Y aún hay una distinción más fina, de naturaleza temporal. ¿Quién «hace» la venta que tienes delante? vendedor_17 la cerró esta tarde, pero las condiciones exactas (precio de 49,90 dólares, 18 % de impuesto) las fijó alguien más, tiempo atrás. Hay una diferencia de fondo entre el autor (quien diseñó la regla) y el ejecutor (quien la materializa hoy). Las dos personas son respuestas legítimas a «¿quién?», pero pertenecen a momentos y a naturalezas de acción distintas.

El caso límite: cuando una cosa actúa

Y aquí aparece un caso que merece tratarse con cuidado. ¿Qué ocurre con el quién cuando el que ejecuta la acción no es una persona ni una empresa, sino un objeto inanimado? La terminal de cobro que aplica sola el descuento al pasar la camiseta; el sistema VAR que interrumpe el partido para anular un gol; el motor de recomendación que decide sugerirte cierta película. Al hablar, les concedemos agencia sin titubear: la terminal cobró el impuesto, el VAR anuló la jugada, el algoritmo eligió.

Sin embargo, a nivel de arquitectura de la información, estos objetos no pertenecen por naturaleza al eje quién; su domicilio de origen es el eje qué, porque son cosas o sistemas. Lo que sucede en estos casos es que, en situaciones muy específicas, un objeto asume temporalmente la capacidad de agencia.

Esta observación, en apariencia menor, tiene un peso enorme en el diseño de software. Decide si tu modelo puede registrar honestamente frases tan cotidianas como «el sistema rechazó el pago» sin mentir sobre la naturaleza del sistema. Mira la misma terminal de cobro bajo sus dos lecturas: en reposo es un objeto del eje O; pero en el instante en que aplica el impuesto sola, ese mismo objeto ocupa, transitoriamente, el eje Q:

El identificador no cambió (sigue siendo la misma terminal); lo que cambió fue el eje que ocupa, y solo mientras dura la acción. Volveremos sobre ello; por ahora, sigamos hacia la pregunta más resbaladiza de todas.

O — Qué: la pregunta por la cosa

El qué es profundamente engañoso porque la gramática parece exigirle una sola respuesta concreta, pero en la práctica abre la puerta a entidades de tipos irreconciliables. Si preguntas «¿Qué pasó?», esperas un evento. Si preguntas «¿Qué vendió el vendedor?», buscas un objeto material. Si preguntas «¿Qué situación atraviesa el equipo?», pides un contexto complejo. Las tres son gramaticalmente correctas, las tres aterrizan en el eje qué, y las tres apuntan a estructuras de datos que no se parecen en nada.

Para no perder la cordura adoptaremos un criterio funcional y deliberadamente amplio: el eje qué aloja absolutamente todo lo que no sea un agente, un lugar o un momento. Y, al hacerlo, hay que reconocer que dentro de ese gran contenedor conviven al menos tres familias muy distintas.

Aquí asoma una intuición de diseño sutil pero crítica: estas tres familias no están separadas por muros impenetrables. Un evento se transforma en objeto cuando otro dato lo menciona («ese gol fue revisado por el VAR»); ahí, la jugada deja de ocurrir y pasa a ser una cosa a la que apuntamos. Y, en sentido inverso, una situación gigantesca puede verse como un evento simple desde un nivel aún mayor («el partido se suspendió por un corte de luz»). El eje qué tiene una flexibilidad inherente respecto de la escala: lo que en un nivel del modelo es un evento activo, en un nivel superior es un objeto pasivo al que se hace referencia.

Esa flexibilidad es una ventaja arquitectónica enorme. Permite tratar de forma uniforme cosas que la programación tradicional se ve obligada a separar en tablas distintas y difíciles de cruzar. Pero —cuidado— también es una trampa mortal.

Asimilemos la intuición con nuestras cuatro escenas. Verás que el eje qué aparece tres veces en cada una, operando en registros distintos sin romperse:

En cada fila usamos el mismo eje qué tres veces, en tres niveles. El modelo no se confunde ni se quiebra: simplemente aloja cada cosa en el registro que le corresponde.

L — Dónde: la pregunta por el lugar

El dónde suele ser el más físico y concreto de los cuatro, y precisamente por esa aparente simpleza es el que más a menudo los programadores dan por sentado. Pero detrás de él se esconde una decisión semántica que, si no se toma de forma explícita, arruina cualquier cruce de información.

En el habla cotidiana manejamos dos «dónde» radicalmente distintos. El primero es el lugar físico estricto: una coordenada, una dirección, una ciudad, un recinto. El mostrador de la tienda, el césped del estadio, el plató donde se rodó escena_42, el despacho del alcalde. El segundo es el lugar organizacional o administrativo: un departamento, un ministerio, una franquicia, un club. La gerencia_transito, la municipalidad_centro, la selección a la que pertenece messi.

Ambos responden con total naturalidad a «¿dónde?», pero técnicamente apuntan a realidades de estructura incompatible. Una ciudad es un polígono geográfico; una gerencia es un organigrama de personas e intenciones. Si los mezclamos en el diseño (si guardamos plaza_central y gerencia_transito en una misma columna genérica llamada ubicacion) perdemos para siempre la capacidad de separar dónde ocurre algo físicamente de a qué estructura administrativa pertenece.

Veamos cómo conviven los lugares en nuestras escenas —y nota que, dentro de un mismo hecho, varios «dónde» de escalas distintas coexisten sin estorbarse:

• L 👕 Venta: ¿Dónde se cobró? En el mostrador. ¿Dónde está la tienda? En la tienda_centro. ¿En qué ciudad? En el casco urbano entero. Tres escalas físicas conviviendo.
• L ⚽ Fútbol: ¿Dónde se remató el gol? Desde el área chica. ¿Dónde se jugó el partido? En un estadio, dentro de una ciudad. Escalas anidadas.
• L 🎬 Cine: ¿Dónde se rodó la escena? En un plató de la ciudad. ¿Dónde transcurre dentro de la ficción? En un puerto imaginario. El lugar real y el lugar narrado no coinciden.
• L 🏛️ Ordenanza: ¿Dónde se firmó? En el despacho municipal (lugar físico). ¿Dónde tiene jurisdicción? En todo el distrito (lugar político).

Conviene dejar asentada una observación de fondo: el pilar dónde está diseñado por naturaleza para soportar jerarquías y anidamientos. El mostrador está dentro de la tienda, la tienda pertenece a un barrio, el barrio se inscribe en la ciudad y la ciudad en el país. A nivel lógico, las cuatro respuestas son correctas para «¿dónde ocurrió?» aplicada al mismo hecho; todo depende del nivel de zoom que pida la consulta. El modelo que construimos tendrá que navegar esas escalas hacia arriba y hacia abajo sin generar ambigüedad.

T — Cuándo: la pregunta por el tiempo

Llegamos al último de los cuatro pilares base, y al que solemos tratar con más ligereza, dando por hecho que se resuelve con un formato de fecha (AAAA-MM-DD). La realidad es que el cuándo es el eje más rico y lleno de sutilezas lógicas de todo el modelo. El lenguaje natural tiene muchísimas maneras de expresar el tiempo, y las fechas de calendario son apenas una de ellas.

Volvamos a la tarde de la venta. Si alguien la cuenta diciendo «la camiseta la vendió hace un rato», ¿cómo lo guardamos? Si el sistema almacena solo el dato frío 2026-05-14T16:32, destruye información: se pierde que la acción se vivió como reciente respecto del momento en que se habló. Pero si guarda literalmente la cadena «hace un rato», el motor se vuelve inútil, porque no puede calcular antigüedades ni ordenar eventos. La salida razonable es guardar la marca absoluta para el cómputo y, en una capa complementaria, conservar la expresión relativa como contexto asociado.

El problema se ahonda apenas salimos del calendario. En la música, una entrada no se sitúa «a las 20:03», sino «en el compás 17»: el tiempo no lo dicta un reloj de cuarzo, sino un compás interno. En el análisis de una película, una revelación ocurre «al final del segundo acto»: tiempo narrativo, medido por la posición dentro del relato. En una historia clínica, una crisis aparece «tres horas después de la última dosis»: tiempo relativo, anclado a un evento previo. Y en lo jurídico, la ordenanza_142 entra en vigor «a los treinta días de su publicación»: tiempo derivado por una regla.

Si atendemos al uso real de la información, descubrimos que cuándo debe soportar, como mínimo, cinco tipos de tiempo:

Un eje cuándo robusto tiene que aceptar los cinco formatos y, más importante aún, reconocer cuál se está usando en cada transacción. La estrategia que adoptaremos formalmente más adelante es la pluralidad de tiempos: no forzaremos toda la información a pasar por un único reloj universal, sino que el eje funcionará como un espacio donde conviven múltiples escalas temporales, todas válidas, cada una bajo su propio sistema de coordenadas.

Cómo ordenar sin aplastar: reificar el instante

Esa pluralidad plantea de inmediato una pregunta operativa: si conviven varios relojes, ¿cómo ordena el sistema los eventos sin reducirlos a uno solo? La regla de normalización es deliberadamente humilde: no traducir. El compás 17 no se convierte a un horario de cuarzo (eso destruiría su naturaleza); en su lugar, cada instante no-reloj se reifica con tres datos estándar.

# un instante musical, reificado en tres datos (no se "traduce" a reloj)
(entrada_coro, escala, "musical")        ∈ M(O, K)   # a qué sistema temporal pertenece
(entrada_coro, posicion, 17)             ∈ M(O, N)   # ordinal: ordenable DENTRO de su escala
(entrada_coro, valor_nativo, "compás 17") ∈ M(O, O)   # la expresión original, intacta

# y cuando el mundo provee un puente real, se declara como hecho explícito:
(entrada_coro, sonó_en, 2026-05-14T20:03:14) ∈ M(O, T)  # no una conversión inventada

• escala: a qué sistema temporal pertenece (musical, narrativo, paginado, reloj_absoluto). Impide comparar peras con manzanas: el motor nunca ordenará un compás contra una fecha por accidente.
• posicion: un ordinal numérico que lo vuelve ordenable dentro de su propia escala (compás 17 → 17; página 240 → 240; «final del segundo acto» → acto 2, 1.0). Es la clave de orden.
• valor_nativo: la expresión original, preservada tal cual («compás 17», «p. 240», «final del segundo acto»), para no perder fidelidad.

Con esto, ordenar es trivial dentro de una escala (se ordena por posicion filtrando por escala) y honesto entre escalas: no se mezclan, salvo que exista un puente real. Y los puentes existen cuando el mundo los provee: la grabación de un concierto ata el compás 17 de la escala musical a las 20:03:14 de la escala absoluta mediante un hecho explícito, no una conversión inventada. El modelo conserva la naturaleza del dato y, a la vez, gana la capacidad de secuenciar que el negocio necesita.

El tiempo no es un único río que todo lo arrastra, sino un delta de cauces que rara vez se tocan; el modelo no los funde, los deja correr en paralelo.La pluralidad de tiempos

Lo que era cierto y dejó de serlo

A todo lo anterior se suma una complicación fascinante que solo dejaremos planteada. Un dato puede ser plenamente válido durante un período y dejar de serlo en el siguiente. La tienda abrió en la plaza_central entre 2019 y 2025; si preguntas hoy dónde está, la respuesta es otra dirección. «¿Dónde queda la tienda?» no es un bloque de piedra: es un flujo de valores, cada uno con su propia fecha de caducidad. Ese fenómeno (un dato verdadero solo dentro de una ventana temporal) será un componente explícito de nuestro diseño final.

Cerremos el pilar aplicándolo a las cuatro escenas:

• T 👕 Venta: Tiempo absoluto (se cobró a las 16:32), cíclico (la tienda abre cada día) y relativo interno («aplicar el impuesto una vez confirmado el pago»).
• T ⚽ Fútbol: El gol cae en el minuto 87: tiempo de reloj corto, que solo cobra sentido respecto del inicio del partido.
• T 🎬 Cine: La revelación ocurre «al final del segundo acto» (tiempo narrativo); el rodaje de esa escena tiene una fecha de calendario (tiempo absoluto). Dos líneas conviviendo en paralelo.
• T 🏛️ Ordenanza: Se firmó ayer (tiempo absoluto); entra en vigor a los treinta días (tiempo derivado por regla). Dos relojes operando sobre el mismo objeto.

Cada uno de estos cuatro pilares es, además, un eje por el que cortar el conjunto. Fijar el «cuándo» en las 16:32 y dejar libre el «quién» ya es pedir todos los que vendieron a esa hora; fijar el «dónde» en la tienda_centro y soltar el «qué» es pedir todo lo que se despachó allí. Las cuatro preguntas no describen solo una venta: rebanan miles a la vez.

Cuando un pilar se confunde: una IA en libertad

Antes de cerrar el capítulo conceptual, vale la pena diseccionar un caso real. Es la clase de anécdota que circula por los foros de tecnología y que, por lo común del fallo, se ha vuelto casi un ejemplo de manual sobre los límites de la inteligencia artificial sin estructura.

Imagina a alguien que sale del trabajo con la bicicleta pinchada. Saca el teléfono y le dicta a su asistente:

Tengo la bici con una rueda reventada y la quiero llevar al taller de reparación, que me queda a tres cuadras de aquí. ¿Me conviene ir caminando o en bici?

La respuesta del modelo fue desconcertante:

Si te queda tan cerca, ve caminando sin problema. Son apenas tres cuadras, es más saludable y de paso no gastas energía pedaleando.

El consejo es un disparate físico: no se lleva una bicicleta al taller yendo a pie (la bicicleta es lo que hay que transportar). Pero el error no nace de una «estupidez» del algoritmo, sino de un problema muy concreto: una mala asignación de roles a los cuatro pilares. La estadística llenó las cajas, pero las llenó mal.

Una lectura humana y estructuralmente correcta de la escena reparte así las variables:

Q (quién)                  : la persona            (agente)
O (qué, lo que se mueve)    : la bicicleta          (paciente)   ← el centro de la escena
L (dónde, destino)          : el taller, a 3 cuadras
T (cuándo)                  : ahora
M (con_finalidad)           : reparar la bicicleta              ← le da sentido a todo

El verbo núcleo de la situación es llevar. La persona es, sin duda, el agente; pero el paciente (la cosa física que sufre el transporte) es la bicicleta. Y la finalidad ineludible de la maniobra es someter esa bicicleta a una reparación. Si quitas la finalidad de la ecuación, la pregunta «¿caminando o en bici?» pierde todo su sentido.

¿Qué entendió, en cambio, el modelo basado en pura correlación estadística? Su reparto de roles fue, con toda probabilidad, este:

Q (quién)                  : la persona            (agente)
O (qué, lo que se mueve)    : la persona            (¡la misma!) ← la bicicleta desapareció
L (dónde, destino)          : el taller, a 3 cuadras
T (cuándo)                  : ahora
M (con_finalidad)           : trasladarse al taller             ← finalidad real, perdida

Bajo esa lectura, la bicicleta se cae de su rol legítimo de paciente y queda empujada a un rol de instrumento opcional («puedes ir en bici o no»). La finalidad real (repararla) se diluye y la sustituye el mero acto de llegar a unas coordenadas. Como el modelo evalúa que la distancia es mínima, sus pesos probabilísticos concluyen que caminar es lo más eficiente y saludable. Impecable… salvo que el objeto central de la frase se evaporó.

Es aquí donde la promesa central de este libro cobra fuerza industrial. Si pudiéramos entregarles los hechos del mundo a los asistentes de IA con una estructura donde los cuatro pilares fueran explícitos (el agente siempre en Q, el paciente en O, el lugar en L y el momento en T), esta clase de absurdos desaparecería. Y no porque hubiéramos fabricado un algoritmo más listo, sino porque la propia arquitectura impediría la asignación incorrecta.

Los cuatro pilares y lo que falta

Si repasamos las cuatro preguntas (quién, qué, dónde, cuándo) y volvemos a la tarde de la venta, las cuatro piezas están ahí, haciendo un trabajo de ordenamiento preciso. El vendedor (quién) entregó la camiseta (qué) sobre el mostrador (dónde) a las 16:32 (cuándo). La escena queda sólidamente descrita.

¿Bastan para modelar la realidad entera? Para una frase así, sí. Pero no transcurrirá mucho tiempo en un entorno de producción antes de toparnos con registros donde estas cuatro cajas se quedan cortas. Hagamos crecer un poco la escena:

El vendedor despachó, en plena liquidación de temporada, una camiseta deportiva que costó cuarenta y nueve dólares con noventa.

El hecho base es el mismo, pero el caudal de información acaba de escalar. De pronto hay que procesar un precio (49,90). Entró en juego un motivo claro de la acción (la liquidación de temporada). Aparece una clasificación más fina del objeto: no es una prenda cualquiera, es una camiseta deportiva. Y, de paso, la frase deja entrever que la camiseta pertenece a la categoría prenda de vestir: un detalle que nuestros cuatro pilares todavía no permiten declarar, porque el eje Q guarda individuos concretos, no define categorías abstractas.

Conceptos como «prenda de vestir», «camiseta deportiva» o «dólar» no son cosas palpables. Son clases, arquetipos. Y, por definición, no encajan limpiamente en ninguno de los cuatro pilares que acabamos de estudiar.

De ahí emerge el resto del modelo. Necesitamos, como mínimo, una quinta pregunta (cuál, es decir, qué tipo de cosa es esto) con eje propio: el zócalo categórico donde habitarán los tipos, las familias y los conceptos abstractos. A ella hay que sumarle una sexta (cuánto) para las métricas, con sus propias trampas de conversión de unidades; y una séptima (cómo) encargada de articular las conexiones y atributos que amarran todo el modelo.

De esas tres, la primera y más delicada de todo el sistema es el eje categórico. Es, paradójicamente, el que soporta la mayor carga de trabajo en los sistemas del mundo real, y es allí donde la arquitectura de WQuestions se integra pacíficamente con los gigantes de la industria (Schema.org(30), QUDT(18), SNOMED, CIDOC CRM(4)), usándolos como aliados en lugar de competir con ellos: el vocabulario común que nos asegura no volver a levantar, nunca más, la torre de Babel de los datos. A ese zócalo (el eje K, cuál) dedicamos el capítulo siguiente.