Hay una escena que se repite en las editoriales universitarias latinoamericanas. Un flujo de trabajo produce HTML, EPUB, XML-JATS, salidas para CrossRef, para SciELO, para DOAJ. Y aun así, cuando llega el momento de corregir, alguien pide el PDF. No el HTML, que es lo que leerá el lector. No la fuente estructurada, que es de donde todo lo demás se deriva. El PDF.
La pregunta obvia es por qué. Y la respuesta obvia —que el PDF “se ve terminado”— es verdadera pero perezosa. Conviene desconfiar de ella, porque debajo hay algo más interesante que la nostalgia.
Este texto no pretende resolver nada. Al contrario: quiere sostener una serie de preguntas abiertas el mayor tiempo posible, porque sospecho que la edición científica está atravesando un cambio cuya última palabra nadie tiene todavía. Pero hay una excepción a esa suspensión, y es el nudo del asunto: un sistema de software no puede permitirse la duda del ensayista. Un ensayo puede dejar todo abierto. Un programa tiene que decidir qué botón poner, qué formato es la fuente de verdad, qué se corrige y qué no. gbpublisher —el sistema desde el cual escribo estas notas— toma posición donde el pensamiento todavía titubea. Ese contraste, entre la pregunta que no cierra y el software que igual debe decidir, es el verdadero tema.
Primera pregunta: ¿qué corrige el editor cuando corrige el PDF?
Donald Winnicott describió el objeto transicional: el osito, la manta, ese primer “no-yo” que el niño usa para tolerar la ausencia de la madre. Es tentador usar la imagen para descartar el PDF como una muleta infantil. Sería un error, y sobre todo sería mala lectura de Winnicott.
Para Winnicott el objeto transicional no es patológico. Es sano y necesario. Es el puente que hace tolerable el pasaje de la fusión a la autonomía. Y no se arranca: se abandona, solo, cuando ya no hace falta.
Si tomamos eso en serio, cambia todo el diagnóstico. El editor que exige el PDF no está corrigiendo el PDF. Está corrigiendo su confianza en un flujo que todavía no domina. El PDF es el puente sobre el cual se anima a cruzar hacia una producción que aún no comprende del todo. Y de ahí una consecuencia práctica incómoda para cualquier tecnólogo apurado: el puente tiene que ser sólido. Un PDF mal compuesto no acelera la transición; la sabotea, porque confirma el miedo de que “esto ya no es un libro”.
Acá aparece la primera decisión de diseño, y es contraintuitiva. Un sistema cuya filosofía dice “el documento verdadero es el estructurado, el PDF es apenas una materialización” podría tener la tentación de tratar al PDF como ciudadano de segunda. gbpublisher hace lo contrario: le dedica una infraestructura entera —tabla de formatos, geometría de márgenes calculada, visor propio de páginas, control fino de composición— precisamente porque el puente debe aguantar peso. La coherencia no está en despreciar el PDF por fidelidad a la filosofía. Está en entender que un buen puente es lo que permite la filosofía.
¿Pero cuánto debe durar ese puente? ¿Un sistema debería, deliberadamente, hacer el PDF cada vez menos central para acompañar una maduración que quizás nunca llegue? No lo sé. Y desconfío de quien lo tenga claro.
Guardemos la imagen del puente. Vamos a necesitarla otra vez, y de un modo que ahora no anticipo: no como objeto que se cruza, sino como lugar donde alguien decide quién cruza.
Segunda pregunta: ¿y si la página no sobrevive solo por nostalgia?
Es cómodo contar la historia así: cambian las condiciones materiales —acceso abierto, presupuestos que caen— y el paradigma de la página cae con ellas. Es la lectura materialista, y es en buena medida correcta. Los paradigmas rara vez se rinden por convicción; se rinden cuando el entorno deja de financiarlos.
Pero esa historia es demasiado limpia. La historia de la tecnología está llena de paradigmas “ineficientes” que sobrevivieron porque codificaban un valor que el sucesor perdía. Así que la pregunta honesta no es cómo derribar la cultura de la página, sino: ¿qué codifica la página que la estructura semántica todavía no reemplaza?
Y hay una respuesta que no es psicológica ni sentimental: la fijeza.
El PDF es citable de manera estable —hay un número de página—, es razonablemente inmutable, y por eso funciona como objeto probatorio, archivístico, casi legal. Un documento estructurado, en cambio, es mutable por diseño: vive en un grafo que cambia, se versiona, se enriquece. La ciencia necesita puntos fijos de referencia, y la web todavía no resolvió bien la fijeza. La prueba está dentro del propio estándar: el elocation-id de JATS existe justamente porque, cuando desaparece la página, hay que inventar un ancla que ocupe su lugar. El estándar reconoce el problema en su propia gramática.
Entonces la página no resiste solo por costumbre. Resiste porque hace algo que todavía hacemos mal sin ella. Descartar eso como “resistencia al cambio” es no haber entendido el problema.
Acá gbpublisher toma una posición fuerte, y conviene mirarla despacio porque encierra una trampa que tardé en ver. El sistema se declara fuente autoritativa de los metadatos: CrossRef, SciELO, los indexadores, son espejos. La comparación entre el sistema y el indexador no sirve para negociar diferencias, sino para detectar errores de transmisión.
La objeción salta de inmediato, y es la mejor objeción posible: si el conocimiento vive en las relaciones y no en los documentos —si esa es la premisa del grafo—, entonces declarar un punto autoritativo parece reintroducir el original que el resto de este texto quiere desmontar. ¿No es la base de datos local un nuevo papel sagrado, apenas disfrazado de tabla MySQL?
La respuesta requiere una distinción que, confieso, no tenía clara hasta que la objeción me la forzó. No hay diferencia de tipo entre la autoridad de la edición impresa y la de la base: al fondo de ambas cadenas hay siempre un humano que decidió. No existe un punto donde la autoridad deje de ser una decisión y se vuelva un hecho de la naturaleza. Toda autoridad es, en última instancia, el lugar donde acordamos dejar de preguntar.
Pero sobre qué se apoya cada autoridad, y qué pretende, sí difiere. El original impreso reclamaba autoridad por fijeza y finalidad: un humano decidió una vez, la decisión se congeló en un objeto, y desde entonces el objeto cargaba la autoridad sin depender ya de nadie. Su poder era, precisamente, haber dejado de ser una decisión para volverse un hecho. Se naturalizó. “El libro dice” borra que alguien, alguna vez, eligió que dijera eso.
La base autoritativa reclama lo contrario: no fijeza sino responsabilidad localizada y revisable. No dice “esto es verdad”. Dice “acá hay alguien que responde por esto, y puede corregirlo”. Es un nodo versionado, fechado, editable, atribuible. La decisión no se congela: se mantiene líquida y pegada a un responsable. De ahí la formulación que me parece que salva la posición:
El original era una decisión que se olvidó de que era una decisión. La base autoritativa es una decisión que se acuerda de que lo es.
Esa es toda la diferencia. No verdad contra error. Amnesia contra memoria sobre la propia contingencia.
Y por eso “error de transmisión” no es arrogancia epistémica —”yo tengo razón”— sino una afirmación sobre la topología de la cadena: CrossRef recibió su registro de la base; una discrepancia significa que la copia derivó del upstream, no que el upstream posea la verdad. La base es autoritativa como origen de un flujo, no como dueña de un hecho.
Hago, eso sí, la concesión que la honestidad exige: todo esto es una disciplina, no una garantía de la arquitectura. Si en la práctica el editor empieza a tratar la fila de la tabla como un nuevo original inmutable —”la base lo dice, entonces es cierto”—, entonces el sistema no disolvió el original: lo reubicó, del papel a MySQL. Mismo dogma, otro soporte. El schema habilita la versión buena —versionable, revisable, atribuible— pero no la obliga. La distinción entre “ancla de responsabilidad” y “nuevo papel sagrado” no la garantiza el diseño; la garantiza el uso. Y eso es exactamente lo que un sistema no puede resolver solo: puede hacer la base editable, pero no puede impedir que la traten como intocable.
Tercera pregunta: ¿todo es nodo?
“El editor científico será un editor de nodos dentro de un grafo mayor.” La frase es potente y creo que es verdadera. Pero conviene tratarla con la misma desconfianza que a las otras certezas, porque tiene una versión tecno-utópica en la que todo se disuelve en relaciones, y esa versión es falsa.
Hay conocimiento irreductiblemente secuencial. Una demostración matemática. Un argumento filosófico. Una narración histórica. El grafo privilegia la conexión sobre el orden, pero hay un tipo de verdad que solo existe en el despliegue lineal, en el “por lo tanto” que sigue a lo anterior y no puede reordenarse sin destruirse. Si el editor deja de custodiar el argumento lineal para convertirse solo en curador de relaciones, ¿quién cuida la coherencia interna del razonamiento?
La versión defendible de la tesis, entonces, no es “el documento desaparece en la red”. Es más sutil: el documento coexiste con la red como una vista particular —la vista secuencial— entre otras vistas posibles. El grafo no elimina la línea; la contiene como uno de sus recorridos.
Y esto no es abstracto: es una decisión de arquitectura. Un sistema de single source publishing que deriva todo de una fuente estructurada está afirmando, en su diseño mismo, que existe una fuente única de la cual el documento lineal y la red de metadatos son ambos proyecciones. El orden editorial de los capítulos, la distinción entre cuerpo y paratexto, la secuencia del argumento: gbpublisher los preserva como estructura, no como accidente tipográfico. El sistema decide que la linealidad es dato, no presentación. Esa es una posición epistemológica escondida en una decisión técnica.
¿Es la posición correcta? La pregunta sigue abierta. Pero fíjese cómo la duda del ensayista y la decisión del ingeniero conviven: puedo no saber si la linealidad sobrevivirá al grafo, y aun así el sistema tiene que elegir hoy si la trata como contenido o como forma. Eligió contenido.
Cuarta pregunta: ¿para quién estamos estructurando?
Esta es, creo, la pregunta que el debate suele saltear, y la que más lo reordena todo.
Cuando estructuramos un artículo en JATS, cuando poblamos ROR, ORCID, CrossRef, cuando emitimos JSON-LD con Schema.org, buena parte de ese trabajo no es para un lector humano. Es para máquinas: indexadores, agregadores, grafos de conocimiento y, cada vez más, modelos de lenguaje que ingieren literatura científica. “Hacer el conocimiento computable” significa, sin eufemismo, publicar para lectores no humanos.
Reencuadra la historia entera. El PDF era el formato del lector humano: una superficie para que unos ojos recorran un texto. La estructura semántica es, en proporción creciente, el formato del lector algorítmico. Y entonces la muerte anunciada de la página adquiere otra causa. La página no muere porque aparezca un formato mejor para humanos. Muere porque el lector decisivo —el que determina si un trabajo es hallado, citado, contado— dejó de ser humano.
Esto obliga a una pregunta de diseño que casi nadie formula en voz alta: cuando las necesidades del lector humano y las del lector-máquina entran en conflicto, ¿a quién sirve la interfaz? gbpublisher responde con su arquitectura de roles: no es un sistema para autores. Es un sistema para editores. Y un editor, en esta lectura, es exactamente la persona que trabaja en la frontera entre ambos lectores: garantiza que el texto le hable al humano y que la estructura le hable a la máquina. La decisión de excluir al autor de la interfaz no es un detalle de permisos. Es una afirmación sobre quién es responsable de la doble audiencia.
Y acá aparece, por primera vez con nitidez, la figura que va a organizar el resto de estas notas. El editor no es solo un intermediario entre dos lectores. Es quien está parado en el punto de tránsito entre lo privado del manuscrito y lo público del grafo. Es una barrera. Volveremos a eso: es, creo, el concepto que faltaba.
¿Deberíamos estar cómodos con esto? Publicar para máquinas tiene consecuencias que no controlamos: los modelos que ingieren esta literatura la reproducen, la resumen, la deforman. Estructurar mejor es, también, alimentar mejor a sistemas cuyo comportamiento no decidimos. No tengo una respuesta tranquilizadora. Solo la convicción de que fingir que seguimos publicando únicamente para humanos es la ceguera más costosa del sector.
Quinta pregunta: ¿y si la periferia va adelante, pero a la fuerza?
El acceso abierto y los presupuestos bajos suelen tratarse como dos fuerzas genéricas. En América Latina son algo más concreto y más político.
El modelo de acceso abierto de la región —SciELO, Redalyc, AmeliCA— es diamante: abierto para el lector y sin cargos al autor. Es una posición explícita en la economía política global de la publicación científica, opuesta al modelo comercial del Norte, donde el acceso abierto se financia cobrándole al autor un APC que en la periferia es sencillamente impagable.
Y acá el argumento materialista se vuelve filoso, porque el software no es neutral respecto de esto. gbpublisher lo inscribe en su propia licencia: la única condición de uso que impone es la prohibición de cobrar APC a los autores. El sistema encarna una tesis política en su cláusula legal. No es una herramienta que “también sirve” para el modelo diamante; es una herramienta que se niega a servir a otro.
De ahí una hipótesis que merece nombre propio: la periferia como vanguardia forzada. El Sur no puede pagar el paradigma comercial, y por eso es empujado hacia la producción semántica automatizada antes que el Norte —no por virtud, no por clarividencia, sino por restricción presupuestaria. La automatización que en el Norte es optimización, en el Sur es supervivencia. Lo que parece atraso institucional —editoriales que “todavía” no imprimen, que “solo” ofrecen el PDF— podría ser, mirado con otro lente, un laboratorio adelantado de lo que viene.
Pero la pregunta que no debe cerrarse es la incómoda: ¿es esto emancipación o es hacer de la necesidad virtud? ¿Estamos celebrando como innovación lo que en el fondo es la respuesta forzada a una carencia? Sospecho que ambas cosas son ciertas a la vez, y que separarlas limpiamente sería mentir.
Sexta pregunta: ¿quién paga la transición?
El diálogo sobre eficiencia tiene un punto ciego, y hay que nombrarlo o el análisis se vuelve apología. “Reducir el costo estructural de producir conocimiento” suena impecable hasta que uno pregunta qué costo y descubre que el costo tiene cara: los departamentos de diseño y composición que pasan de varias personas a una, o a ninguna.
Automatizar la maqueta es también descualificar y desplazar trabajo. Décadas de oficio tipográfico —el ojo entrenado para el interletrado, el ajuste de viudas y huérfanas, la sensibilidad de página— se vuelven, de golpe, un archivo XSLT. Un texto intelectualmente honesto tiene que decir esto aunque defienda que la transición es inevitable. La inevitabilidad no cancela la pérdida.
Y sin embargo hay una ironía que quizás sea la salida, y que está inscrita —otra vez— en una decisión de diseño. En la arquitectura de roles de gbpublisher, la figura que la automatización vuelve teóricamente prescindible, el maquetador, es el único rol con acceso completo al repositorio git.
Conviene decir con precisión qué ocurrió ahí, porque no es una “promoción” ni un consuelo. El maquetador del paradigma viejo también era una barrera: su umbral era estético, decidía qué composición pasaba y cuál no. Lo que la automatización jubila no es la función-barrera; es el criterio de esa barrera. El interletrado y las viudas dejan de ser el umbral, y en su lugar aparece la integridad de las aserciones del grafo. Misma posición topológica, nuevo material a filtrar. El maquetador no perdió su barrera: cambió lo que su barrera deja pasar. Por eso conserva el acceso git —el nuevo umbral no se opera desde la página, se opera desde la estructura versionada.
Eso permite un cierre honesto sin mentir sobre lo que se pierde. Pero la pregunta queda, filosa: ¿toda persona desplazada por la automatización tiene ese camino de reconversión disponible? Casi seguro que no. Y un sistema que se enorgullece de bajar costos tiene la obligación mínima de mirar de frente a quién se los baja.
La barrera: por qué el editor, y no el autor ni el revisor
Vengo posponiendo una figura que ahora tiene que ocupar el centro, porque resuelve —hasta donde puede resolverse— la objeción de la segunda pregunta.
Dije que el editor es el buck-stops del sistema: el punto donde se detiene la responsabilidad. Pero “buck-stops” en su sentido clásico —el de Truman, the buck stops here— es un punto de decisión final: acá se resuelve, acá se termina. Y esa imagen es engañosa, porque sugiere que el editor decide el contenido de la verdad. No lo hace. La figura correcta no es la del que decide el contenido, sino la del que decide el paso. El editor es una barrera: no fabrica lo que atraviesa, controla qué cruza y qué no. Y —esto es decisivo— es una barrera, no la única que controla el flujo.
La distinción no es cosmética. Un original es un punto de control único: su poder viene justamente de no depender de nadie más. Una barrera, en cambio, presupone un sistema alrededor. Hay un antes —el autor que aporta, el manuscrito que llega—; hay reglas de paso que la barrera no inventó —JATS, ROR, las convenciones de la disciplina—; y hay un después —los indexadores que reciben, los pares que pueden objetar—. La barrera es responsable dentro de un flujo que la excede. El original pretendía ser el flujo entero congelado en un objeto. Por eso la barrera no reintroduce el paradigma que este texto desmonta: un original no admite que exista nada aguas arriba ni aguas abajo con autoridad propia; una barrera vive precisamente de que los haya.
Entonces la reformulación que propongo, y que me parece más fuerte que “punto autoritativo”:
El editor no es el dueño de la verdad de la red. Es el guardabarrera responsable: el punto donde una aserción cruza de lo privado del manuscrito a lo público del grafo, y donde queda registrado quién autorizó ese cruce.
La palabra que hace todo el trabajo es cruce. La autoridad de la barrera es la del umbral, no la del contenido. El editor no produce el ORCID, ni la afiliación, ni el dato; verifica que la aserción esté en condiciones de entrar al grafo, y responde por ese acto de dejarla pasar.
Y esto responde con precisión la pregunta de gobernanza que quedó abierta: ¿por qué el editor, y no el autor, no el revisor? No porque el editor sepa más. Porque es quien ocupa el punto de tránsito. El autor produce, pero está de un solo lado, el suyo; no está en la frontera. El revisor evalúa calidad, pero no controla el paso al ecosistema: puede recomendar el rechazo y aun así no es él quien opera la compuerta hacia CrossRef. El editor es el único que está físicamente parado donde lo interno se vuelve externo. La responsabilidad recae ahí por posición topológica en el flujo, no por jerarquía epistémica. Es una respuesta estructural, y por eso puede defenderse sin arrogancia.
Conviene, además, no olvidar la advertencia de la segunda pregunta: que el editor sea una barrera y no un original es una propiedad que la arquitectura habilita pero no garantiza. Un guardabarrera que deja de revisar, que sella por costumbre, que trata su propio registro como intocable, deja de ser barrera y se vuelve —de nuevo— papel sagrado. El diseño puede abrir la compuerta a la revisión; no puede obligar a mirar antes de sellar.
Coda: el borde donde el software se queda sin respuesta
Reformular al editor como barrera resuelve más de lo que esperaba. Pero —y esto es lo que quiero dejar como final, sin taparlo— la propia formulación abre una grieta que ninguna decisión de arquitectura puede cerrar.
Si el editor es una barrera y no la única, si el control está distribuido, entonces la pregunta migra. Ya no es “quién es el punto de responsabilidad”, que quedó contestada. Es: ¿qué pasa cuando dos barreras discrepan? Dos editores, dos instituciones, dos nodos que dejaron pasar aserciones incompatibles sobre la misma entidad —la misma afiliación, el mismo identificador, el mismo dato. Cada uno respondió correctamente por su cruce local. Y sin embargo el grafo queda con dos aristas que se contradicen.
El original viejo no tenía este problema, y no por virtud: lo evitaba por ser único. Donde hay un solo punto de control, no hay dos versiones que dirimir. El precio de abandonar el control único —el precio de ganar responsabilidad revisable, memoria de la propia contingencia, un sistema en lugar de un dogma— es que reaparece, entre pares, la pregunta de la dirimencia.
Y acá gbpublisher se queda sin respuesta, y creo que es honesto que así sea. El sistema puede garantizar quién responde por cada cruce. Puede versionar, fechar, atribuir, detectar que una copia derivó de su origen. Lo que no puede es decidir cuál de dos responsables tiene razón cuando ambos actuaron de buena fe sobre la misma entidad. Eso ya no es una decisión de arquitectura. Es una decisión de gobernanza institucional que todavía no existe.
Es exactamente el punto donde vuelve, transformada, la pregunta más profunda de todas: durante quinientos años la universidad certificó documentos —objetos acotados, con bordes, validables de a uno. Una red no tiene borde. Cuando el objeto validado se disuelve en un tejido de aserciones distribuidas, la universidad tiene que aprender a hacer algo que nunca hizo: certificar redes, no documentos. Y certificar una red incluye, ineludiblemente, tener un procedimiento para cuando dos barreras confiables se contradicen. Ese procedimiento no lo da la epistemología —que solo nos dice que no hay un original al cual apelar— ni lo da el software —que llega hasta la responsabilidad del cruce y no más allá. Lo tiene que poner la institución. Y hoy, en la mayoría de los casos, no está puesto.
Ahí termino, no porque el tema se agote, sino porque ahí es donde el software honestamente se detiene. La barrera es lo más lejos que un sistema puede llegar solo: puede decir con exactitud quién autorizó cada cruce. Quién dirime entre autorizaciones legítimas en conflicto ya no es una pregunta de diseño. Es política, en el sentido más serio de la palabra —el de decidir en común lo que ninguna regla previa resuelve.
Un ensayo puede permitirse suspender el juicio indefinidamente; es casi su virtud. Un sistema de software no: tuvo que decidir, antes de resolver ninguna de estas preguntas, si el PDF sería central o marginal, si la fuente de verdad sería local o delegada, si la linealidad sería contenido o forma, si el autor entraría a la interfaz, si la licencia dejaría cobrar al autor, si el maquetador sobreviviría reconvertido, dónde sentar la barrera. Cada una es una hipótesis materializada, provisional pero comprometida, sobre qué será la edición científica cuando termine de dejar de ser lo que era.
Su ventaja sobre el ensayo no es que sepa más. Es que sus respuestas se pueden probar contra la realidad, y corregir. La duda pura no deja rastro contra el cual aprender; la decisión materializada, sí. Y quizás por eso el borde donde el software se detiene —el conflicto entre barreras confiables— sea también el borde donde empieza el trabajo que ninguna herramienta puede hacer por nosotros: el de construir, entre instituciones, las reglas de dirimencia de una red de conocimiento que todavía no sabe que las va a necesitar.
