WQuestions

Parte III · Cómo funcionan juntas

07

El hecho atómico

Seis ejes sueltos no describen nada. Hace falta una pieza que los conecte (una sola, repetida millones de veces) para que el modelo deje de ser una lista de columnas y empiece a ser un mundo.

Son las 16:32 de la tarde y el vendedor Marco cierra la venta de una camiseta. Ese gesto, que dura tres segundos, esconde más datos de los que parece: hubo alguien que la vendió, un cliente que la pagó, un artículo entregado, un monto en dólares y una hora exacta. En los seis capítulos anteriores aprendimos a clasificar cada uno de esos fragmentos en su eje: Marco es un Q, la camiseta un O, los 49.90 dólares un N. Pero clasificar no es describir. Tenemos las piezas separadas sobre la mesa; nos falta el gesto que las une.

Ese gesto es el tema de este capítulo. Para que las siete coordenadas dejen de ser cajones de un archivador y empiecen a contar la historia de la venta de Marco, necesitamos una unidad mínima de afirmación: la pieza más pequeña con la que se puede decir algo sobre el mundo. La llamaremos el hecho atómico, y su forma es desconcertantemente simple.

La forma de un hecho

Un hecho atómico es siempre una frase de exactamente tres partes (una tripleta): un sujeto, un predicado y un objeto.

venta_001O agenteM(O→Q) vendedor_17Q

Se lee de izquierda a derecha como una oración del castellano: «la venta 001 tiene como agente al vendedor 17». El sujeto y el objeto son individuos que sacamos de alguna de las cajas de valor (un evento del eje O, una persona del eje Q, un número del eje N). El predicado es el cable conector que vimos en el capítulo anterior: un habitante del eje M, el cómo, que une los dos extremos. Y eso es todo. No hay un cuarto campo escondido, ni una nota al pie, ni una excepción para los casos difíciles.

La afirmación que sostiene este capítulo (y que al principio cuesta creer) es esta: absolutamente toda la información que el sistema sabe del mundo se construye con esta misma forma exacta, repetida una y otra vez. Las ventas, las jugadas de fútbol, las películas, las ordenanzas de un municipio, las llamadas a un agente de inteligencia artificial. Todo. El resto del capítulo se dedica a demostrarlo y, sobre todo, a explicar por qué esa terquedad por una sola forma es justamente lo que hace que el sistema no se rompa nunca.

La misma forma viaja entre dominios sin deformarse. Mira cinco hechos sacados de cinco industrias que no tienen nada en común. Cambian los individuos, cambian los cables; la estructura, jamás.

tripletas
(venta_001,      vendedor,       vendedor_17)          ∈ M(O, Q)   👕
(gol_001,        agente,         messi)                ∈ M(O, Q)   ⚽
(pelicula_marea, directora,      serra)                ∈ M(O, Q)   🎬
(ordenanza_142,  fecha_publicacion, 2026-05-14)        ∈ M(O, T)   🏛️
(sesion_ia_5521, tokens_entrada, 4180)                 ∈ M(O, N)   🤖

Cinco cables distintos (vendedor, agente, directora, fecha_publicacion, tokens_entrada) y cinco pares de cajas distintos. Pero las cinco líneas son, estructuralmente, la misma línea. Esa uniformidad no es un capricho estético para que el código se vea ordenado: es la propiedad arquitectónica de la que cuelga todo lo demás. Vale la pena, entonces, escribirla en piedra.

La decisión D3

Ya tomamos dos decisiones de diseño en los capítulos previos (D1 y D2). La que sigue es, con diferencia, la más pesada del libro, porque el resto de la arquitectura se apoya literalmente sobre ella.

D3 El átomo de la información

Cualquier hecho de la realidad se representa siempre como una tripleta atómica de la forma (sujeto, cable, objeto). El cable debe estar tipado (saber qué cajas conecta) para que el sistema pueda validar si el dato es lógico o absurdo. Las descripciones de cosas complejas jamás se construyen inventando estructuras nuevas ni tablas más anchas: se construyen apilando decenas de estas tripletas simples sobre un mismo sujeto.

Léela despacio, porque tiene dos prohibiciones tan importantes como sus permisos. La primera: un cable sin tipo no es un cable válido. La segunda: ante un dato más rico, la respuesta nunca es «cambiemos la estructura», sino «agreguemos más tripletas». Todo lo que sigue es la consecuencia directa de habernos atrevido a tomar esta decisión.

Tres exigencias que el átomo debe cumplir

Para que esta unidad mínima funcione como cimiento de cualquier base de datos del mundo, debe satisfacer tres exigencias estrictas. No son adornos: si fallara cualquiera de las tres, el modelo se vendría abajo.

Exigencia 1 — Tipada: protección contra el caos

Cada cable lleva pegada su propia regla de seguridad, su signatura: la declaración de qué caja admite a la izquierda y qué caja admite a la derecha. El cable monto_usd sabe de fábrica que conecta un objeto del eje O con un número del eje N. Esa es exactamente la parte ∈ M(O, N) que aparece al final de cada línea.

tripletas
(venta_001, monto_usd, 49.90)      ∈ M(O, N)   // válido: 49.90 vive en la caja N
(venta_001, monto_usd, "caro")     ✗ rechazada  // "caro" no es un número

Si un programador cansado, a las dos de la tarde, intenta registrar (venta_001, monto_usd, "caro"), el sistema lo rechaza al instante: la palabra «caro» no habita la caja de los números. Esta protección, que ocurre en tiempo real, es lo que convierte la tripleta en un bloque de información seguro y validable. Un dato absurdo no llega siquiera a guardarse.

Exigencia 2 — Independiente: cada hecho se sostiene solo

Cada hecho atómico debe tener sentido por sí mismo, sin depender de ningún otro. La tripleta (gol_001, agente, messi) significa exactamente lo mismo aunque nadie haya anotado todavía en qué minuto del partido ocurrió, o con qué resultado quedó el marcador. Quitar contexto no la corrompe; solo la deja menos detallada.

Esa independencia es un superpoder silencioso: permite guardar el hecho en un archivo de texto, en una base de datos relacional o enviarlo por internet a otro continente sin que pierda una gota de su significado. El átomo es portátil porque no arrastra dependencias ocultas.

Exigencia 3 — Componible: los átomos se apilan

Aunque cada hecho es independiente, su verdadera potencia se libera cuando los apilas sobre un mismo sujeto. Una venta no se describe en una frase gigante; se describe con una lluvia de átomos que comparten a venta_001 como sujeto, cada uno aportando una coordenada distinta.

tripletas
(venta_001, instancia_de,  venta)            ∈ M(O, K)
(venta_001, vendedor,      vendedor_17)      ∈ M(O, Q)
(venta_001, cliente,       cliente_1042)     ∈ M(O, Q)
(venta_001, objeto,        camiseta_88)      ∈ M(O, O)
(venta_001, talla,         talla_m)          ∈ M(O, K)
(venta_001, color,         azul)             ∈ M(O, K)
(venta_001, cantidad,      1)                ∈ M(O, N)
(venta_001, monto_usd,     49.90)            ∈ M(O, N)
(venta_001, medio_pago,    tarjeta)          ∈ M(O, K)
(venta_001, momento,       2026-05-14T16:32:00-05:00)  ∈ M(O, T)

Diez pequeñas piezas de Lego que, juntas, dibujan la operación entera: qué se vendió, quién la atendió, a qué cliente, en qué talla y color, cuántas unidades, por cuánto, con qué medio de pago y a qué hora. Cada pieza se entiende por separado; sumadas, forman el retrato completo de la venta.

Lo verdaderamente revelador llega cuando el negocio quiere ser más preciso. Supongamos que la tienda decide auditar el lote de inventario del que salió cada artículo, con su fecha de ingreso. En una base de datos tradicional esto obligaría a alterar la tabla de ventas, añadirle columnas y migrar miles de filas (tocar la estructura, con todo el riesgo que eso implica). En nuestra arquitectura, la estructura no cambia jamás. Simplemente se eleva la entrega del artículo a la categoría de evento (algo que ya aprendimos a llamar reificación) y se le cuelgan sus propias tripletas:

tripletas
(entrega_001, parte_de,    venta_001)        ∈ M(O, O)
(entrega_001, articulo,    camiseta_88)      ∈ M(O, O)
(entrega_001, lote,        lote_2026_044)    ∈ M(O, K)
(entrega_001, cantidad,    1)                ∈ M(O, N)
(entrega_001, ingresado_el, 2026-05-02)      ∈ M(O, T)

Idea clave

El sistema escala acumulando bloques de información, no obligando a nadie a rediseñar la base de datos. Más detalle siempre significa más tripletas, nunca otra estructura. Esta es, quizá, la ventaja más práctica de todo el modelo.

El universo de datos es una pizarra de tripletas

Cuando una empresa empieza a guardar miles (y luego millones) de estos hechos atómicos, va tejiéndose una red inmensa de nodos conectados por cables. A esa red se le llama un grafo. Y conviene precisar qué es, técnicamente, una base de datos WQuestions: no es más que un conjunto gigantesco de oraciones de tres partes escritas en una pizarra común. Ni más, ni menos.

El estado entero de la realidad, para el sistema, se reduce a contar cables sobre una pizarra. No hay archivos ocultos ni arquitecturas secretas que solo entiendan los creadores del software.El principio de la pizarra

Esa transparencia es liberadora. Si le preguntas a la máquina «¿quién dirigió la película Marea?», no hay misterio que resolver: solo busca cables que arranquen en pelicula_marea y lleven la etiqueta directora. Y si pides algo más ambicioso («dame todas las directoras de largometrajes estrenados después de 2020»), el sistema hace un trabajo tonto pero velocísimo: localiza los cables año_estreno cuyo número final supere 2020, mira a qué películas están pegados, y rastrea quién figura como su directora en cada una. Cada paso es, simplemente, saltar de una tripleta a la siguiente. Fin del enigma.

Cuando tres palabras no alcanzan: la reificación

A veces la realidad se niega a caber en una sola tripleta. Piensa en esta crónica deportiva, de las que se narran en una sola respiración:

«Messi le pasó el balón a Di María en el minuto 87 con un toque de pierna izquierda.»

Esa frase es una veta de oro: tiene un autor (Messi), un beneficiario (Di María), un objeto (el balón), un momento (minuto 87) y un instrumento (la pierna izquierda). Si quisiéramos meterla a la fuerza en una tripleta simple ((messi, paso_el_balon_a, di_maria)) estaríamos tirando a la basura casi toda la información. ¿Cómo lo resolvemos sin violar la D3?

Con la reificación, que ya asomó en capítulos anteriores. La maniobra es elegante: elevamos ese pase al estatus de evento con nombre propio dentro del eje O (lo bautizamos pase_001) y colgamos a cada participante con su propia tripleta, todas apuntando a ese evento central.

tripletas
(pase_001, instancia_de,  accion_pasar)               ∈ M(O, K)
(pase_001, agente,        messi)                      ∈ M(O, Q)
(pase_001, beneficiario,  di_maria)                   ∈ M(O, Q)
(pase_001, objeto_pase,   balon_partido_001)          ∈ M(O, O)
(pase_001, minuto,        87)                         ∈ M(O, N)
(pase_001, instrumento,   pierna_izquierda)           ∈ M(O, K)

Lo que era un nudo lingüístico imposible de meter en una fila de tabla se desarmó en seis hechos atómicos independientes, cada uno tipado, cada uno sostenido por sí solo. La estructura n-aria (un evento con muchos participantes) se preservó entera sin abandonar la forma de la tripleta. La figura siguiente muestra cómo se ve esa estrella de hechos alrededor del evento central.

instancia_de agente beneficiario objeto_pase minuto instrumento pase_001 evento · O accion_pasar messi di_maria balon_p_001 87 pierna_izq
Figura 7.1. El pase de Messi, reificado como el individuo pase_001 en el eje O, con sus seis participantes colgados por roles canónicos (agente, beneficiario, objeto_pase, minuto, instrumento, instancia_de). La estructura n-aria se conserva entera sin abandonar la forma de la tripleta.

Conviene una regla práctica, de las que un ingeniero de datos hace bien en tatuarse: reifica solo cuando te falte espacio. Si la relación es entre dos individuos y nada más ((pelicula_marea, directora, serra)), basta una tripleta directa. Si el hecho involucra a más participantes o arrastra detalles propios (tiempo, lugar, instrumento), entonces sí: elévalo a evento con nombre propio y cuélgale sus tripletas. Ni más reificación de la necesaria, ni menos de la que el detalle exige.

El modelo y el lenguaje humano son gemelos

Aquí ocurre algo que, la primera vez que lo notas, parece magia, y conviene resaltarlo de inmediato. Toma un artículo de prensa cualquiera y pásaselo a un modelo de lenguaje moderno (Claude, por ejemplo) con esta instrucción: «Resume paso a paso quién hizo qué en esta noticia». La respuesta casi siempre vuelve como una lista de líneas limpias, sin que nadie se lo haya pedido en ese formato:

Lo que la IA devuelve, sola

  • El alcalde Reyes promulgó la ordenanza de micromovilidad.
  • La ordenanza entra en vigor a los 30 días de su publicación.
  • La medida afecta a la gerencia de tránsito.
  • La medida afecta a la gerencia de fiscalización.

Cuatro líneas, cuatro hechos. Y cada línea tiene su sujeto, su verbo y su objeto. La IA no responde así porque haya leído este libro: responde así porque así funciona el lenguaje humano cuando intenta describir la realidad. Las oraciones simples que nos enseñaron en la escuela (sujeto, verbo, predicado) son idénticas, molécula a molécula, a nuestros hechos atómicos tipados.

El impacto de esta coincidencia es enorme. Si tu base de datos guarda la información como tripletas, y la inteligencia artificial piensa en tripletas, entonces la comunicación entre la IA y tu empresa se vuelve casi automática. No hace falta programar costosos algoritmos de comprensión del lenguaje natural ni levantar capas de traducción frágiles: existe un enchufe directo entre lo que la IA dice y lo que tu sistema guarda. Esa es la llave maestra del agente que el mercado persigue (uno capaz de conversar, auditar y registrar información en cualquier empresa) sin obligarlo a memorizar la estructura interna de la base de datos de cada cliente. Es el tema que el capítulo 26 lleva hasta el fondo.

Consultar es tapar un hueco

Si toda la información se guarda como tripletas, buscar en ella se vuelve un juego de niños. Hacer una consulta es, literalmente, escribir una tripleta pero tapando uno de sus tres campos con un signo de interrogación (dejando un hueco que el sistema debe rellenar). Mira tres patrones de búsqueda sobre nuestros ejemplos:

patrones
(serra,          ?,           ?)         // "Dime todo lo que sepas de Serra"
(?,              directora,   serra)      // "¿Qué obras dirigió Serra?"
(?,              agente,      messi)      // "Busca todas las jugadas de Messi"

Y si necesitas una consulta digna de un analista, no hay que aprender un lenguaje nuevo: basta encadenar varias «tripletas con huecos» y pedirle al sistema los datos que encajen en todas a la vez. Las variables que se repiten (las que empiezan con ?) son las junturas: amarran un patrón con el siguiente.

patrones
(?gol,     agente,   messi)
(?gol,     parte_de, ?partido)
(?partido, fecha,    [2026-01-01, 2026-12-31])
// → "Todos los goles de Messi en partidos del año 2026"

Así de simple. No hacen falta diagramas enrevesados ni consultas eternas: consultar es decirle a la máquina que busque un patrón de cables dentro de la red. Y la operación matemática es idéntica en cualquier industria y a cualquier escala: exactamente lo que la vieja torre de Babel de los datos, que vimos en el capítulo 1, nos impedía hacer.

Un cable repetido es una columna

Apilar tripletas produce un efecto lateral que se ve mejor desde ya. Cuando mil ventas distintas llevan todas el mismo cable monto_usd, ese cable deja de ser un dato suelto de venta_001 y se vuelve, de hecho, una columna que se puede recorrer entera. Lo mismo pasa con agente: escribirlo sobre cada gol es, sin proponérselo, dejar armada la lista de todas las jugadas que comparten ese cable. Por eso el patrón (?, agente, messi) de hace un momento no era un truco aislado, sino la forma natural de leer esa columna de punta a punta. Cada hecho que registras sobre un sujeto es, a la vez, una fila en el reporte de todos los sujetos que comparten ese cable: lo que parece guardar un dato individual está construyendo, sin avisar, la semilla de la consulta colectiva.

El contraste con SQL

Para medir la diferencia, traduzcamos esa última pregunta (goles de Messi en 2026) al mundo relacional clásico. Allí los hechos no viven en una pizarra común, sino repartidos en tablas que muchas veces ni siquiera se diseñaron para conversar. Recuperar el dato obliga a coserlas con JOINs, una operación que el grafo no necesita porque nunca separó la información en primer lugar.

SQL
SELECT j.nombre, g.minuto
FROM goles g
JOIN jugadores j ON j.id = g.jugador_id
JOIN partidos  p ON p.id = g.partido_id
WHERE j.nombre = 'Messi'
  AND p.fecha BETWEEN '2026-01-01' AND '2026-12-31';

No es que el SQL esté mal escrito; es que carga con un trabajo que el modelo de tripletas ni siquiera tiene. Cada JOIN es la cicatriz de una decisión previa de partir el mundo en tablas; y si mañana el negocio quiere registrar el asistente de cada gol, habrá que alterar el esquema. En la pizarra de tripletas, recordemos, eso era una línea más.

El mismo átomo, viajando por el cable

Cuando un hecho necesita salir del sistema y viajar a otro (una API, un agente, otra empresa), se serializa sin perder un solo eje. La reificación se vuelve un objeto JSON casi sin esfuerzo: el sujeto es el id, cada cable es una clave y cada objeto es el valor. Así se ve una venta sobre el cable:

JSON
{
  "id": "venta_74921",
  "instancia_de": "venta",
  "agente": "vendedor_17",
  "cliente": "cliente_1042",
  "objeto": "camiseta_88",
  "monto": { "valor": 49.90, "unidad": "Currency:USD" },
  "momento": "2026-05-14T16:32:00-05:00"
}

Cada clave es un cable; cada valor, un individuo en su eje. El mismo átomo que dibujamos como una estrella de nodos en la Figura 7.1 es, sobre el cable, un objeto que cualquier sistema (o cualquier IA) lee sin manual de instrucciones. La figura siguiente cierra el círculo: una sola afirmación, vista de tres maneras que son la misma.

como tripleta (venta_001, monto_usd, 49.90) como grafo venta_001 monto_usd 49.90 como JSON "monto_usd": 49.90 // dentro de venta_001 Una sola afirmación. Tres ropajes. El mismo átomo.
Figura 7.2. El hecho «la venta 001 tiene un monto de 49.90 dólares» expresado como tripleta, como arista de un grafo y como par clave-valor en JSON. Las tres notaciones son intercambiables: el modelo no privilegia ninguna, porque todas describen la misma coordenada.

El repertorio entero, pasado por el átomo

Para cerrar con los pies en la tierra, recorramos los cinco escenarios de este capítulo y veámoslos descompuestos en hechos atómicos. La lección, repetida cinco veces, es siempre la misma: basta apilar tripletas sobre un sujeto, y reificar solo cuando un evento lo pide.

👕 La venta. Ya la desmenuzamos: diez tripletas bastan para el retrato general de la operación, y si la tienda exige trazar el lote de inventario, se reifica la entrega del artículo sumando cinco tripletas más (sin tocar el diseño base).

⚽ El gol. El fútbol se describe apilando roles tácticos sobre el evento. Seis hechos atómicos conservan al autor, al asistente, el partido, el minuto y la pierna. Suficiente detalle para una casa de apuestas o un analista de rendimiento, sin reducir la jugada a una fila gris de hoja de cálculo:

tripletas
(gol_001, instancia_de, gol_jugada_abierta)    ∈ M(O, K)
(gol_001, agente,       messi)                 ∈ M(O, Q)
(gol_001, asistente,    di_maria)              ∈ M(O, Q)
(gol_001, parte_de,     partido_arg_per_2026)  ∈ M(O, O)
(gol_001, minuto,       87)                    ∈ M(O, N)
(gol_001, pierna,       zurda)                 ∈ M(O, K)

🎬 La película. Una obra cinematográfica se describe apilando autoría (que tiene roles distintos: dirigir no es escribir) y composición recursiva, porque una escena es «parte de» la película:

tripletas
(pelicula_marea, instancia_de, largometraje)         ∈ M(O, K)
(pelicula_marea, genero,       genero_drama)         ∈ M(O, K)
(pelicula_marea, directora,    serra)                ∈ M(O, Q)
(pelicula_marea, guionista,    haddad)               ∈ M(O, Q)
(pelicula_marea, año_estreno,  2026)                 ∈ M(O, N)
(escena_42,      parte_de,     pelicula_marea)       ∈ M(O, O)
(escena_42,      tiempo_narrativo, fin_segundo_acto) ∈ M(O, K)

Siete hechos en los que directora y guionista son cables distintos (Serra y Haddad cumplen papeles que no se confunden) y donde escena_42 se cuelga de la película por parte_de, abriendo la puerta a describir cada escena con su propia lluvia de tripletas. La composición no tiene fondo.

🏛️ La ordenanza. Un acto de gobierno combina fechas, vigencias y entidades afectadas. Nótese que afecta_a es un cable múltiple: el mismo sujeto lo usa varias veces, una por cada gerencia tocada.

tripletas
(ordenanza_142, instancia_de,     ordenanza_municipal)   ∈ M(O, K)
(ordenanza_142, promulgada_por,   alcalde_reyes)         ∈ M(O, Q)
(ordenanza_142, organo,           municipalidad_centro)  ∈ M(O, Q)
(ordenanza_142, fecha_publicacion, 2026-05-14)           ∈ M(O, T)
(ordenanza_142, entra_en_vigor,   2026-06-13)            ∈ M(O, T)
(ordenanza_142, afecta_a,         gerencia_transito)     ∈ M(O, Q)
(ordenanza_142, afecta_a,         gerencia_fiscalizacion) ∈ M(O, Q)

La fecha de entrada en vigor (30 días después de la publicación) no se inventa a mano: es un tiempo derivado por reglas, un tema que el capítulo siguiente y los de la Parte V exploran. Si alguien pregunta «¿qué normas promulgó el alcalde Reyes este año?», la máquina cruza las primeras dos tripletas y responde sin demora.

🤖 El agente de IA. Y el dominio más moderno de todos: la telemetría de una sesión con un modelo de lenguaje. Diez hechos atómicos que registran qué usuaria preguntó, qué modelo respondió, cuántos tokens costó y qué herramientas tuvo que invocar el agente.

tripletas
(sesion_ia_5521, instancia_de,   sesion_modelo_lenguaje)  ∈ M(O, K)
(sesion_ia_5521, modelo,         modelo_lumen_2026)       ∈ M(O, K)
(sesion_ia_5521, usuaria,        paredes)                 ∈ M(O, Q)
(sesion_ia_5521, tokens_entrada, 4180)                    ∈ M(O, N)
(sesion_ia_5521, tokens_salida,  920)                     ∈ M(O, N)
(sesion_ia_5521, latencia_ms,    2100)                    ∈ M(O, N)
(sesion_ia_5521, costo_usd,      0.015)                   ∈ M(O, N)
(sesion_ia_5521, temperatura,    0.7)                     ∈ M(O, N)
(sesion_ia_5521, herramienta,    busqueda_web)            ∈ M(O, K)
(sesion_ia_5521, herramienta,    consulta_grafo)          ∈ M(O, K)

Toda la telemetría que un ingeniero moderno exige (quién, qué modelo, cuánto costó, si tuvo que buscar en la web o consultar el propio grafo) vive en diez líneas tipadas. Es incomparablemente más limpio, y más consultable, que un volcado de logs sin estructura.

En la práctica

Fíjate en el patrón que se repite en los cinco dominios: la primera tripleta casi siempre es instancia_de (ancla el sujeto en su clase del eje K), y a partir de ahí cuelgan los atributos. Cuando empieces a modelar un dominio propio, abre por ahí: nombra el sujeto, declara su clase y deja que las coordenadas vayan cayendo, una tripleta cada vez.

Lo que llevamos, y lo que viene

El hecho atómico es la piedra fundacional de toda la arquitectura. Tiene siempre la misma forma rígida de tres partes ((sujeto, cable, objeto)); lleva protección interna que impide mezclar cosas absurdas; y se compone consigo mismo para describir realidades tan complejas como queramos, sin pedir jamás un cambio de programación. En este modelo, la base de datos es, sin metáfora, un océano de estos hechos.

Lo hermoso del hallazgo no es haber inventado un código nuevo, sino haber descubierto que esta forma matemática coincide al milímetro con la manera en que los seres humanos (y la inteligencia artificial) hablan cuando describen el mundo. El modelo no obliga a nadie a aprender un idioma robótico: toma la estructura natural del lenguaje y la convierte en tecnología consultable.

Hasta aquí hemos tratado cada hecho como una pieza solitaria. Pero cuando se amontonan por millones, emerge algo nuevo: un espacio geométrico. No una metáfora, sino una herramienta matemática real, donde consultar masivamente equivale a poner restricciones sobre coordenadas (como jugar a la batalla naval a escala planetaria). Ese espacio es el tema del próximo capítulo.