Puentes: objetos, bits, grafos y cadenas

Imagina a un programador con quince años de oficio leyendo este libro por encima del hombro de un colega. Hacia el capítulo 7 levanta una ceja. «¿Tripletas? —dice—. Eso ya existe. Yo modelo con clases y objetos desde que aprendí a programar; mis datos viven en tablas que se consultan en milisegundos; y eso de los hechos que no se pueden borrar suena a blockchain, una moda que ya pasó.» Tiene razón en cada observación, y por eso vale la pena tomárselo en serio. WQuestions no se inventó en un vacío: respira el mismo aire que la programación orientada a objetos, los bits, las bases de grafos y los libros mayores inmutables. Este capítulo se dedica a contestarle, una objeción a la vez.

El método será siempre el mismo. Para cada tecnología familiar tenderemos un puente (un mapa que muestra qué pieza de WQuestions corresponde a qué pieza que el lector ya conoce) y luego marcaremos el punto exacto donde el puente deja de sostener peso. Porque la analogía sirve para entrar, pero engaña si se la lleva demasiado lejos. Cuatro puentes, cuatro secciones.

Puente uno · Objetos: la programación orientada a objetos

La primera reacción de cualquier ingeniero es la más natural: «esto ya lo hago con clases». Y en parte lleva razón. La programación orientada a objetos (POO) lleva medio siglo organizando el software alrededor de la misma intuición que WQuestions (que el mundo se describe con cosas que pertenecen a categorías y que se relacionan entre sí). El parecido es tan profundo que conviene hacerlo explícito antes de señalar la grieta.

Tres conceptos de la POO tienen un gemelo casi perfecto en el modelo. Cuando un programador escribe v = Venta(...), está instanciando: fabricando un individuo a partir de un molde. Nosotros decimos exactamente lo mismo con el cable instancia_de, que ancla un sujeto del eje O en su clase del eje K. Cuando una clase VentaOnline hereda de Venta, declara que todo lo que vale para una venta vale para una venta en línea; nosotros lo escribimos con subtipo_de entre dos conceptos del eje K. Y los atributos y asociaciones de un objeto (su monto, su vendedor) no son otra cosa que nuestros predicados del eje M.

(venta_online,  subtipo_de,    venta)          ∈ M(K, K)   // herencia
(venta_001,     instancia_de,  venta_online)   ∈ M(O, K)   // instanciación
(venta_001,     vendedor,      vendedor_17)     ∈ M(O, Q)   // asociación
(venta_001,     monto_usd,     49.90)           ∈ M(O, N)   // atributo

Para fijar el paralelo, traduzcamos la misma entidad (nuestra venta canónica) a una clase de Python y, justo al lado, a las tripletas equivalentes. Mira primero el código que el programador escéptico reconoce a primera vista:

class Venta:
    def __init__(self, id, vendedor, cliente, articulo, monto, momento):
        self.id       = id
        self.vendedor = vendedor      # asociación  → Vendedor
        self.cliente  = cliente       # asociación  → Cliente
        self.articulo = articulo      # asociación  → Articulo
        self.monto    = monto         # atributo    (float)
        self.momento  = momento       # atributo    (datetime)

    def aplicar_descuento(self, pct):     # comportamiento, acoplado al dato
        self.monto *= (1 - pct / 100)

v = Venta("venta_001", vendedor_17, cliente_1042,
          camiseta_88, 49.90, "2026-05-14T16:32")

Y ahora la misma venta como hechos atómicos. Fíjate en que no hay método: el dato está separado de lo que se le hace.

(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, monto_usd,    49.90)          ∈ M(O, N)
(venta_001, momento,      2026-05-14T16:32) ∈ M(O, T)

Línea por línea, los atributos de la clase reaparecen como tripletas. La figura siguiente pone las dos representaciones frente a frente: a la izquierda, el objeto como caja cerrada con sus casillas; a la derecha, el mismo hecho desplegado como estrella de nodos en el grafo.

Dónde se rompe el puente

La analogía es buena para entrar, y traicionera si se la lleva más allá. Hay dos diferencias que no son de grado, sino de naturaleza, y conviene nombrarlas con precisión.

La primera: la POO acopla datos y comportamiento; WQuestions los desacopla. Un objeto Venta guarda el monto y sabe aplicarse un descuento: el dato y el código que lo toca viven en la misma caja. Eso es elegante para programar, pero ata la información a un lenguaje y a una versión del software. Nuestras tripletas no saben hacer nada: son afirmaciones inertes sobre el mundo. El comportamiento (cómo calcular un descuento, cómo validar una venta) vive en otra capa, separado del hecho. Un dato que no carga lógica es un dato que cualquier sistema puede leer sin importar en qué lenguaje fue escrito.

La segunda: la POO fija el esquema en el código (mundo cerrado); WQuestions es de mundo abierto. En cuanto compilas la clase Venta, sus campos quedan tallados en piedra. Si mañana el negocio quiere registrar el lote de inventario del artículo, alguien debe abrir el archivo, añadir un atributo, recompilar y migrar los datos viejos. Añadir un cable nuevo a un sujeto del grafo, en cambio, es escribir una tripleta más; no hay esquema que recompilar porque el esquema nunca estuvo cerrado. Esta es, en una frase, la diferencia entre un mundo que solo admite lo previsto y uno que admite lo que la realidad traiga.

Un último hilo conecta esta sección con el capítulo anterior. En la POO, dos variables que apuntan al mismo objeto comparten su referencia (ese puntero invisible que distingue «el mismo objeto» de «un objeto igual»). Esa referencia es, ni más ni menos, lo que en el capítulo 11 llamamos el identificador único: el ancla que permite a un hecho hablar de venta_001 y a otro, en otro sistema, hablar de la misma venta sin confundirla con su gemela. El puntero del objeto y el UID del grafo cumplen la misma función: dar identidad estable a una cosa.

Resumamos el puente entero en una sola tabla. A la izquierda, el vocabulario que el ingeniero ya domina; a la derecha, su correspondiente en el modelo.

Puente dos · Bits

Pasada la primera objeción, el programador afina la segunda, y es más visceral. «Vale —dice—, entiendo el mapa con la POO. Pero descomponer cada venta en seis, diez, veinte tripletas parece un caos. Donde yo guardaba una fila ahora tengo veinte líneas. Eso es muchísimo más almacenamiento, y leer veinte líneas para entender una venta es agotador.» La objeción es legítima, y la respuesta exige cambiar de escala mental.

Las tripletas son al conocimiento lo que los bits son a todo lo digital: atómicas, uniformes, abrumadoras de a una, e imprescindibles en masa.El principio del bit

Detengámonos en esa frase, porque es la clave de la sección. Una fotografía, vista por dentro, son millones de unos y ceros. A ningún ingeniero se le ocurriría quejarse de que «un bit no dice nada» o de que «son demasiados para leerlos». El bit no se diseñó para que un humano lo lea de a uno: se diseñó para ser la unidad uniforme y atómica sobre la que se construye todo lo digital, precisamente porque su simplicidad permite operar billones de ellos a velocidad de máquina. La tripleta aspira a ser exactamente eso para el conocimiento: el átomo uniforme de la digitalización del significado.

Queda el miedo al almacenamiento, que es el más concreto. ¿No ocupa una barbaridad guardar cada hecho como una tripleta de texto larga, con su sujeto y su predicado repetidos miles de veces? La respuesta es que no, y la razón merece detallarse, porque deshace un malentendido común.

Las bases especializadas en tripletas (los triple stores) jamás guardan el texto literal que tú escribes. Aplican codificación por diccionario: cada cadena que se repite (un predicado como monto_usd, un valor como vendedor_17) se almacena una sola vez en una tabla y, de ahí en adelante, se referencia por un número entero corto. Donde tú ves vendedor_17 mil veces, la máquina ve un entero mil veces (y los enteros se comprimen casi a la nada cuando se repiten). A eso se suma el almacenamiento columnar, que guarda juntos todos los valores de una misma posición, donde la redundancia es máxima y la compresión, brutal.

El programador escéptico empieza a aflojar. Las tripletas no son un derroche: son la versión del bit aplicada al significado, y la industria del almacenamiento ya resolvió hace décadas el problema de comprimir cosas atómicas y repetidas. Lo cual nos lleva, naturalmente, a las bases de datos que hacen justo esto.

Puente tres · Grafos: bases ya no relacionales, sino dirigidas al dato

«Está bien —concede el ingeniero—, pero todo esto, ¿en qué motor lo corro? Yo tengo PostgreSQL.» Aquí la respuesta es la más alentadora de todo el capítulo: no hace falta inventar nada. La industria lleva veinte años construyendo bases de datos que abandonaron el modelo de tablas para abrazar el modelo de la red de nodos y enlaces (el grafo). WQuestions no compite con ellas; encuentra en ellas su hogar natural. El contraste con el modelo relacional ya lo desarrollamos en el capítulo 8: aquí miramos las alternativas que sí encajan.

Esas tecnologías se agrupan en tres familias, y conviene conocerlas por su nombre, porque la afinidad con WQuestions varía mucho de una a otra.

El datom de Datomic merece quedar escrito al lado de nuestra tripleta, porque el parecido es difícil de exagerar:

// WQuestions — tripleta tipada
(venta_001, monto_usd, 49.90)                       ∈ M(O, N)

// Datomic / XTDB — datom: tripleta + tiempo de transacción
[venta_001  :monto_usd  49.90   tx-2026-05-14T16:32]

// la única diferencia: ellos añaden el "cuándo lo supo el sistema" de fábrica

Pongamos las tres familias en una tabla, marcando con claridad cuáles son las más afines al modelo. La afinidad alta significa que adoptar WQuestions sobre ese motor casi no exige traducción.

Puente cuatro · Cadenas: lo que tomamos de la blockchain

Queda la objeción que el programador soltó al principio, casi con desdén: «esto de los hechos que no se borran suena a blockchain, y eso fue una burbuja». Aquí conviene separar la tecnología de moda de la idea que la hizo valiosa, porque la idea es excelente y WQuestions la hereda casi de oficio.

Lo notable es que el modelo ya tiene, sin haberlo buscado, los dos cimientos de un libro mayor al estilo blockchain. El primero: los hechos son inmutables. En WQuestions nunca se borra ni se sobrescribe nada; corregir el mundo significa afirmar un hecho nuevo que deja en evidencia al anterior, no pisarlo. El segundo: la bitemporalidad de la regla D6 (capítulo 9), que fecha cada situación con su rango de vigencia. Junta esas dos piezas y obtienes, sin agregar línea alguna, un libro mayor de solo-anexar (append-only) y auditable: la historia completa de cómo el sistema fue creyendo lo que cree, conservada intacta.

Sobre esa base, importar el resto de la maquinaria de la blockchain es directo, y son tres piezas que se agregan encima de lo que ya existe.

Procedencia por hecho. Cada tripleta puede llevar pegada su propia credencial: quién la afirmó, en qué momento, y una firma criptográfica que lo prueba. No es metadato cosmético —es la diferencia entre un dato y un dato de quién responde por él. Esto se modela, como todo, reificando: el acto de afirmar se vuelve una situación con su agente, su instante y su firma.

{
  "hecho":      ["venta_001", "monto_usd", 49.90],
  "afirmado_por": "vendedor_17",
  "momento":      "2026-05-14T16:32:00-05:00",
  "firma":        "0x9f2a…c4",
  "hash_previo":  "0x71be…08",
  "hash":         "0xa3d0…11"
}

Hash-encadenado (Merkle). Si cada hecho guarda el hash del anterior (como en el campo hash_previo de arriba), la cadena entera se vuelve evidencia de manipulación: alterar un hecho viejo rompe todos los hashes que vinieron después, y la falsificación salta a la vista al instante. Es la misma garantía criptográfica que sostiene una blockchain, aplicada a nuestro libro de hechos.

Consenso y federación. Cuando el grafo deja de pertenecer a una sola empresa y pasa a ser compartido entre varias (el sueño de la interoperabilidad con el que abrió este libro), hace falta un protocolo que decida qué hechos entran al registro común y quién puede afirmar qué. Ahí entran las ideas de consenso y federación. Pero eso ya es terreno de la seguridad del grafo compartido, que el capítulo 29 trata a fondo.

Nótese el detalle del hecho #2 en la figura: corrige el monto a 47,90 sin borrar el 49,90 original. Eso es exactamente la inmutabilidad del modelo en acción, anudada con la vigencia del capítulo 9: el hecho viejo cierra su rango, el nuevo abre el suyo, y la cadena de hashes deja constancia firmada de quién hizo la corrección y cuándo. Un auditor que llegue dentro de cinco años podrá reconstruir la verdad completa.

El escéptico, convencido

Volvamos al programador del comienzo, que ya no levanta la ceja. Las cuatro objeciones tenían fundamento, y las cuatro tienen respuesta. WQuestions se parece a la POO en cómo piensa las cosas y las categorías, pero la supera al desacoplar el dato del comportamiento y abrir el esquema. Se parece a una avalancha de bits, y por la misma razón que los bits funcionan: la atomicidad uniforme es lo que vuelve la información operable y comprimible a escala. Vive en las bases de grafos que la industria ya construyó (y en Datomic y XTDB casi sin traducción). Y hereda lo mejor de la blockchain (el registro inmutable y auditable) sin pagar el precio de la moda.

WQuestions no pide tirar lo que ya sabes. Pide reconocer que las preguntas estaban debajo de todo eso desde el principio.El sentido de los cuatro puentes

Ninguno de estos puentes es decorativo. Cada uno responde a un lector que llega con su propia herramienta favorita y la pregunta legítima de «¿esto qué me aporta sobre lo que ya tengo?». La respuesta, repetida cuatro veces, es la misma: WQuestions no reemplaza tu pila tecnológica; le pone debajo una capa de significado (los ejes de las preguntas) que hace que tus objetos, tus bits, tus grafos y tus cadenas por fin se entiendan entre sí. Con los cuatro puentes tendidos, estamos listos para la última pieza del lenguaje a los hechos: cómo el verbo de una frase se convierte en la signatura tipada de un predicado, que es el asunto del capítulo siguiente.