Automatización de la producción editorial

La automatización de la producción editorial organiza el artículo aceptado como una fuente estructurada desde la cual se preparan PDF, HTML y XML JATS, en vez de rehacer el mismo contenido por separado para cada salida. Reduce trabajo repetitivo, pero no reemplaza la decisión editorial ni la revisión técnica.

En la práctica de OJS ONE, una marcación XML JATS para SciELO realizada a mano toma cerca de 4 horas por artículo; con la automatización de Jatson toma minutos. El tiempo real depende del estado del documento, sus tablas, figuras, referencias y correcciones pendientes.

Automatización de la producción editorial: qué cambia

Automatizar no es pulsar un botón al final del proceso. Es preparar una representación común del artículo que conserva estructura, metadatos y relaciones entre sus partes: título, autorías, afiliaciones, resumen, secciones, citas, referencias, tablas, figuras y notas.

JATS utiliza etiquetas para describir esa estructura editorial. Su biblioteca incluye un elemento específico para los metadatos del artículo, denominado article-meta.[1] En la práctica, esa fuente estructurada permite transformar la misma información en formatos de lectura distintos sin volver a transcribirla desde cero.

El objetivo práctico es claro: que una corrección autorizada en una afiliación, una leyenda o una referencia se aplique en la fuente editorial y luego llegue a las salidas que correspondan. Si cada formato se mantiene por separado, el equipo debe localizar el cambio en más de un archivo, verificar que no dejó versiones distintas y volver a publicar.

La automatización tampoco significa que cualquier Word esté listo para convertirse sin preparación. Un archivo aceptado puede contener estilos inconsistentes, citas sin resolver, tablas que se cortan, imágenes de baja calidad o decisiones editoriales aún abiertas. El proceso gana velocidad cuando identifica esos elementos antes de generar las pruebas.

Una fuente editorial común evita rehacer el artículo

La principal decisión es dejar de tratar el PDF, el HTML y el XML JATS como tres encargos independientes. El PDF sirve para descarga, circulación formal e impresión; el HTML permite lectura directa en pantalla; el XML JATS conserva estructura reutilizable para flujos académicos. Cada salida cumple una función, pero debe contar la misma versión del artículo.

PKP ha presentado una hoja de ruta para que OJS trabaje con contenido estructurado y exportaciones a HTML, PDF y JATS XML. Es una planificación de producto, no una función que deba darse por disponible en una instalación actual.[2] La señal es relevante porque confirma la dirección del flujo: estructurar el contenido antes de convertirlo a formatos de publicación.

También existen herramientas que separan importación, marcado semántico, previsualización y exportación. JATS Studio describe ese recorrido y ofrece tanto uso del aplicativo como servicio de marcado.[3] Esto no prueba que una herramienta resuelva por sí sola el cierre editorial de una revista; muestra que producir formatos desde una estructura común requiere etapas y responsabilidades explícitas.

Para una revista, la pregunta útil no es si debe tener XML a cualquier costo. Es cuál será su fuente de verdad, quién puede modificarla, qué salida se volverá a generar después de una corrección y cómo se aprueba el paquete final.

El trabajo que deja de repetirse artículo a artículo

Un flujo común reduce tareas de copia, traspaso y conciliación. No elimina el trabajo editorial sustantivo; evita repetir tareas que ya se hicieron bien una vez.

Las siguientes son preguntas de control propuestas, no resultados medidos:

• Repetir nombres, afiliaciones e información de autor al preparar salidas diferentes.
• Corregir una referencia en una salida, sin saber si la misma corrección llegó a las demás.
• Ajustar manualmente títulos, jerarquías de secciones o pies de figura para cada formato.
• Enviar versiones distintas a diagramación, marcación y carga en OJS.
• Comparar pruebas al cierre porque no existe registro de qué documento es la versión aprobada.

La solución no es automatizar una cadena desordenada. Primero define un punto de entrada: documento aceptado, metadatos completos, archivos de figuras y autorización editorial. Después asigna una versión identificable y un canal para resolver consultas. Solo entonces la producción puede transformar y propagar cambios con trazabilidad.

En Jatson, OJS ONE recibe el artículo ya aceptado, sus metadatos y recursos gráficos; luego produce y verifica PDF, HTML y XML JATS desde un flujo común. La revista conserva la aprobación de las pruebas antes de publicar.[4] Es pertinente cuando el equipo quiere evitar coordinar formatos con proveedores o archivos separados, sin cambiar su proceso de evaluación por pares.

Qué decisiones siguen siendo humanas

Una automatización bien diseñada libera tiempo de tareas repetitivas, no delega decisiones que requieren criterio editorial. Conviene declarar desde el inicio cuáles preguntas deben responder las personas responsables.

La revista debe aprobar la versión de contenido que ingresa a producción. También debe resolver dudas sobre la forma correcta de una autoría, afiliación, nota de financiamiento, cita, referencia o imagen. Ninguna regla técnica puede decidir legítimamente una ambigüedad del manuscrito por cuenta propia.

La revisión visual también sigue siendo necesaria. Una tabla puede estar estructurada de forma válida y resultar difícil de leer en móvil. Las fórmulas, tablas anchas y figuras con texto pequeño merecen una prueba de lectura en las salidas reales. El control no termina cuando el XML pasa una validación.

Separa tres tipos de revisión:

1. Editorial: contenido aprobado, autorías, textos, traducciones y decisiones de estilo.
2. Técnica: estructura, archivos asociados, identificadores, enlaces y advertencias del formato requerido.
3. De lectura: PDF, HTML y visualización de tablas, figuras, fórmulas y referencias en el entorno donde se publicarán.

La misma persona puede realizar más de un control en una revista pequeña, pero el registro debe indicar qué revisó y qué quedó pendiente. Así no se presenta una prueba técnica como aprobación editorial.

Cómo rediseñar el cierre editorial sin interrumpir la revista

Puedes adoptar el flujo de manera gradual. No hace falta rediseñar la revisión por pares ni reemplazar OJS para ordenar la producción. Empieza al terminar la edición de contenido y antes de preparar las galeradas.

Usa este recorrido como base:

1. Cierra el artículo de producción. Reúne documento aprobado, metadatos confirmados, figuras, tablas y permisos necesarios.
2. Normaliza el insumo. Identifica estilos irregulares, referencias incompletas, nombres ambiguos y archivos faltantes antes de producir.
3. Estructura una fuente común. Representa el contenido y los metadatos para que las salidas provengan de la misma versión.
4. Genera las pruebas. Produce PDF, HTML y XML JATS según el alcance definido para esa revista.
5. Revisa las tres capas. Obtén aprobación editorial, control técnico y revisión de lectura.
6. Registra correcciones. Toda corrección posterior debe indicar qué cambió, quién la aprobó y qué salidas se regeneraron.
7. Publica y conserva el paquete. Carga las versiones autorizadas en OJS y mantiene la copia identificable de los archivos entregados.

Esta secuencia sirve tanto si la producción se hace internamente como si se contrata. Cambia quién ejecuta cada paso, no la necesidad de que exista una fuente controlada y una aceptación documentada.

Diagrama propio: el control humano revisa contenido, calidad y aprobación antes de publicar.

Control de calidad: qué debes pedir antes de publicar

El paquete final debe permitir que la revista compruebe el resultado, no solo recibir archivos adjuntos. Define la evidencia de cierre antes de enviar el primer artículo.

Pide, como mínimo:

• Identificación de la versión de entrada y fecha de aprobación editorial.
• PDF revisable y HTML accesible mediante la ruta que usará el lector.
• XML JATS junto con el reporte de validaciones o advertencias aplicadas.
• Relación de figuras, tablas, anexos y archivos suplementarios incluidos.
• Registro de consultas resueltas y correcciones incorporadas.
• Responsable de cargar el paquete en OJS y de comprobar la publicación.

Si el destino exige un perfil particular, descríbelo en el encargo. Un XML JATS no es automáticamente equivalente a un paquete aceptado por cualquier plataforma. Para flujos SciELO, revisa además la guía de errores de control editorial en XML JATS: un archivo estructuralmente válido puede conservar errores de contenido o de metadatos.

Errores comunes al automatizar la producción editorial

El problema más frecuente es tratar la automatización como reemplazo de una rutina editorial. Evita estos atajos:

• Convertir un Word sin revisión previa. La conversión puede conservar las inconsistencias del insumo.
• Usar el PDF como fuente maestra. Si una corrección nace sobre la maqueta, será más difícil propagarla al HTML y al XML.
• Ocultar las consultas de producción en correos dispersos. Conserva las decisiones junto con la versión que las motivó.
• Aceptar solo una validación técnica. Revisa también lectura, composición y consistencia editorial.
• Separar formato y publicación como si no estuvieran conectados. Define quién carga las galeradas, revisa enlaces y confirma la disponibilidad en OJS.
• Presentar la automatización como garantía de indexación. La producción ordenada ayuda a preparar archivos, pero no decide la evaluación de SciELO ni de otro índice.

Preguntas frecuentes

¿La automatización editorial reemplaza la diagramación?

No necesariamente. Puede generar un PDF desde una estructura común y una plantilla, pero la revista sigue definiendo su identidad visual, revisando la legibilidad y autorizando las pruebas. Una plantilla personalizada también requiere decisiones de diseño y control editorial.

¿Puedo automatizar solo HTML y PDF sin producir XML JATS?

Sí, el alcance depende de tu objetivo y del flujo elegido. La hoja de ruta de PKP incluso contempla un HTML intermedio para algunas exportaciones.[2] Si después necesitarás XML JATS para un circuito específico, conviene resolverlo desde el diseño de la fuente editorial y no agregarlo al cierre como una tarea aislada.

¿Qué ocurre cuando llega una corrección después de aprobar las pruebas?

Registra el cambio, obtén su autorización y regenera las salidas afectadas desde la fuente común. Después comprueba que el paquete anterior no siga disponible por error en OJS o en los archivos de trabajo.

Lleva la automatización a un flujo editorial comprobable

Si tu revista acumula correcciones entre archivos, parte de la solución está en la secuencia de trabajo y no solo en la herramienta. Define primero qué información entra aprobada, qué controles requiere cada artículo y quién acepta las salidas.

Jatson es el servicio de OJS ONE para producir PDF, HTML y XML JATS desde el artículo aceptado. En la práctica de OJS ONE, el marcado manual puede tomar cerca de 4 horas por artículo y la automatización minutos; el resultado depende del insumo y de las decisiones pendientes. Revisa el flujo de producción editorial con Jatson y evalúa si se ajusta al cierre de tu revista.

Fuentes

1. Element: Article Metadata, NISO JATS Version 1.4 — consultado 2026-10-22.
2. Article Production in PKP Software: Directions and Plans — consultado 2026-10-22.
3. JATS Studio — consultado 2026-10-22.
4. Producción editorial para revistas OJS | OJS One Jatson — consultado 2026-10-22.