Hay tecnologías que trabajan en silencio. No tienen interfaz gráfica, no producen salidas visibles para el usuario final, y sin embargo organizan una parte sustancial de la forma en que la información científica circula, se encuentra y se cita en la web contemporánea. JSON-LD es una de ellas. Este artículo intenta hacer visible ese trabajo invisible: su historia, su propósito, el ecosistema que lo sostiene, quiénes lo consumen y, centralmente, qué significa todo eso para un editor científico latinoamericano que trabaja con recursos limitados y audiencias dispersas.
1. Historia: de los pagos web a un estándar global
La historia de JSON-LD no empieza en una universidad ni en un comité de estándares. Empieza en un problema comercial concreto.
A fines de 2008, Manu Sporny —fundador y CEO de Digital Bazaar, una empresa especializada en pagos e identidad digital basada en tecnologías web— estaba trabajando en sistemas de pagos que necesitaban representar datos estructurados de productos, recibos y contratos en formato JSON. El problema era viejo y conocido: JSON es excelente para transportar datos entre sistemas, pero no dice nada sobre el significado de esos datos. Una clave "name" puede referirse al nombre de una persona, de un producto o de un archivo; no hay forma de saberlo desde el formato mismo.
En aquel momento, las alternativas para agregar semántica al HTML eran RDFa y Microdata. Ambas requerían embeber marcas directamente en el HTML visible, lo que las hacía frágiles, verbosas y difíciles de mantener. Sporny y su colega Dave Longley, CTO de Digital Bazaar, empezaron a explorar si era posible construir algo que funcionara como JSON para programadores web, pero que al mismo tiempo fuera Linked Data, es decir, datos capaces de conectarse y ser interpretados por máquinas a escala global.
En mayo de 2010 publicaron el primer borrador de trabajo de JSON-LD. En abril de 2011 formalizaron el JSON-LD Community Group en el W3C para iniciar el proceso de estandarización. El grupo atrajo colaboradores clave: Gregg Kellogg (Kellogg Associates), Markus Lanthaler (Universidad Tecnológica de Graz, luego Google), Niklas Lindström y Pierre-Antoine Champin (Universidad de Lyon), entre otros.
La especificación JSON-LD 1.0 fue publicada como Recomendación W3C el 16 de enero de 2014, después de más de 25 meses de trabajo en el grupo comunitario. La versión 1.1, con mejoras significativas en expresividad y compatibilidad retroactiva, fue publicada como Recomendación W3C el 16 de julio de 2020. Según el charter vigente al momento de redactar este artículo, el Working Group tiene mandato hasta enero de 2028 —los charters del W3C se renuevan periódicamente y pueden modificarse—, y actualmente trabaja en extensiones como CBOR-LD (representación binaria comprimida para NFC, códigos QR y entornos embebidos) y YAML-LD (orientada a autoría humana).
Un detalle que define la naturaleza del proyecto: según el propio Sporny, el 90% del trabajo pesado que llevó la especificación al punto en que otros pudieron opinar fue realizado por cuatro o cinco personas. “Es un trabajo ingrato y en gran medida no remunerado”, escribió en 2014. “Así es como se construye la web.”
2. Objetivo: darle significado a los datos
Para entender el objetivo de JSON-LD es necesario entender primero el problema que resuelve. Consideremos este fragmento de JSON:
{
"name": "El giro lingüístico en las ciencias sociales",
"author": "García Canclini",
"date": "1995"
}
Para un humano que conoce el contexto, está claro que esto describe un artículo o libro. Para una máquina, es simplemente un objeto con tres claves de significado ambiguo: name podría ser cualquier cosa, author podría referirse a una persona o a una institución, y date no tiene unidad ni formato estandarizado.
JSON-LD resuelve esto con un mecanismo elegante: el @context. Ese contexto mapea cada clave del JSON a un concepto globalmente resolvible, expresado como un IRI (Internationalized Resource Identifier). En la práctica, esto significa que "author" deja de ser una cadena de texto arbitraria para convertirse en https://schema.org/author, un concepto perfectamente definido que cualquier sistema puede consultar y comprender.
{
"@context": "https://schema.org",
"@type": "ScholarlyArticle",
"headline": "El giro lingüístico en las ciencias sociales",
"author": {
"@type": "Person",
"name": "Néstor García Canclini"
},
"datePublished": "1995"
}
Este segundo bloque no solo contiene los mismos datos: los hace interoperables. Cualquier sistema que entienda Schema.org puede ahora procesar, comparar, conectar y razonar sobre esa información sin necesidad de documentación adicional ni acuerdos bilaterales entre sistemas.
El objetivo de JSON-LD, en sus propios términos, es crear una red de datos basada en estándares, legible por máquinas, que funcione a escala web. Permite que una aplicación comience con un dato y siga enlaces embebidos hacia otros datos relacionados, alojados en sitios completamente diferentes, de forma autónoma y sin fricción.
Una característica técnica que lo distingue de sus alternativas (RDFa y Microdata): el bloque JSON-LD vive dentro de una etiqueta <script type="application/ld+json"> completamente separada del HTML visible. Esto significa que agregar, modificar o eliminar metadatos semánticos no afecta en ningún momento la presentación visual de la página. Es mantenimiento limpio, reversible y auditable.
3. Estado del arte: de la Web Semántica a la era de la IA
En 2026, JSON-LD atraviesa un momento paradójico: su adopción masiva llegó no por la vía que sus creadores imaginaban originalmente (la Web Semántica), sino por una combinación de pragmatismo corporativo, SEO y, más recientemente, la irrupción de la inteligencia artificial generativa.
Google como catalizador. El punto de inflexión fue cuando Google adoptó JSON-LD como su formato preferido para datos estructurados, desplazando a RDFa y Microdata. Desde 2015, Google usa datos estructurados para generar rich results en sus páginas de resultados: estrellitas de valoración, información de eventos, precios de productos, FAQs interactivas, paneles de conocimiento. La recomendación explícita de Google —”use JSON-LD siempre que sea posible”— funcionó como un mandato de facto para la industria web.
Schema.org como vocabulario común. Schema.org, el vocabulario controlado que Google, Microsoft (Bing), Yahoo y Yandex desarrollaron conjuntamente desde 2011, proporciona los tipos y propiedades que JSON-LD utiliza. Para el ámbito académico, los tipos relevantes son ScholarlyArticle, Article, Person, Organization, PublicationIssue, PublicationVolume, Periodical, entre otros. Schema.org define exactamente qué campos son esperados, qué tipos de valores acepta cada uno, y cómo se anidan los objetos.
La IA como nuevo consumidor. El estado del arte en 2025-2026 tiene un elemento nuevo y que merece leerse con precisión epistémica. Los crawlers asociados a sistemas de IA generativa —GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot— descargan el HTML completo de las páginas que rastrean. Ese HTML incluye, cuando existe, el bloque <script type="application/ld+json">. Hasta ahí, el dato es verificable. Lo que no está documentado públicamente de forma detallada es si estos sistemas procesan ese bloque de forma semánticamente diferenciada respecto al resto del texto de la página: si extraen y usan activamente las relaciones expresadas en el JSON-LD para desambiguar entidades o atribuir contenido. Es una inferencia técnica razonable —los datos están ahí, bien formados, parseable como JSON— pero no una afirmación que pueda respaldarse con documentación oficial de ninguna de estas plataformas. Lo que sí está documentado es que Google AI Overviews usa datos estructurados de forma activa, dado que Googlebot tiene comportamiento y documentación pública más detallados. La recomendación práctica —servir JSON-LD en HTML estático— se sostiene en cualquier caso.
Hay una advertencia técnica importante que afecta directamente las decisiones de arquitectura editorial: los crawlers de IA mencionados —GPTBot, ClaudeBot, PerplexityBot— generalmente no ejecutan JavaScript. Esto contrasta con Googlebot, que sí tiene capacidad de renderizado JS (aunque con demoras). La consecuencia práctica es que si el JSON-LD es inyectado dinámicamente por scripts de cliente (client-side rendering), es probable que sea invisible para los crawlers de IA, que solo procesan el HTML estático servido por el servidor. Dado que esta frontera técnica puede evolucionar con el tiempo, la recomendación más robusta —y que funciona para todos los casos actuales— es garantizar que el JSON-LD esté presente en el HTML estático desde el servidor, sin depender de renderizado en el cliente.
Extensiones activas. El Working Group del W3C trabaja actualmente en CBOR-LD (compresión binaria para entornos con restricciones de espacio, como NFC o códigos QR) y YAML-LD (sintaxis más legible para autoría humana). Ambas mantienen compatibilidad conceptual con JSON-LD 1.1. La especificación principal tiene mandato vigente hasta 2028.
4. Quiénes están detrás
JSON-LD tiene una cadena de responsabilidad clara y pública.
Digital Bazaar es la empresa que está en el origen del estándar. Su CEO Manu Sporny es el fundador del JSON-LD Community Group, editor principal de la especificación 1.0 y autor central. Su CTO Dave Longley fue el arquitecto técnico clave, especialmente en la solución del problema de normalización (cómo determinar si dos documentos JSON-LD representan el mismo grafo). Ambos siguen activos en el proceso de estandarización.
El W3C JSON-LD Working Group es el organismo formal responsable de la especificación desde 2018. La edición de JSON-LD 1.1 estuvo a cargo de Gregg Kellogg, Pierre-Antoine Champin y Dave Longley. El grupo incluye participantes de Google, universidades europeas y organizaciones técnicas independientes.
Google ha sido el agente de adopción masiva más importante, al adoptarlo como formato preferido para structured data y al co-desarrollar Schema.org desde 2011 junto a Microsoft (Bing/Yahoo) y Yandex.
Schema.org es mantenido por su propia comunidad, pero con fuerte influencia de los motores de búsqueda mencionados. Para el ámbito académico, ha incorporado vocabulario específico con tipos como ScholarlyArticle, que permite representar artículos científicos con el nivel de detalle que requieren los sistemas de indexación.
La gobernanza es abierta: cualquier persona puede participar en el JSON-LD Community Group, comentar las especificaciones en GitHub, proponer cambios y contribuir a implementaciones. Esta transparencia es parte del diseño.
5. Quiénes lo consumen
Los consumidores de JSON-LD son heterogéneos y operan en capas distintas.
Motores de búsqueda generalistas. Google, Bing y otros parsean JSON-LD para habilitar rich results (resultados enriquecidos) en sus páginas de resultados. Para contenido académico, esto puede traducirse en fragmentos que muestran título, autores, fecha de publicación y revista directamente en la SERP (página de resultados), sin necesidad de que el usuario haga clic.
Google Scholar. Su mecanismo de indexación documentado se basa principalmente en metatags Highwire Press y en el rastreo de PDFs; Google Scholar no documenta públicamente el uso de JSON-LD como señal de indexación. Es razonable suponer que la presencia de metadatos bien formados en la página no perjudica la indexación, pero atribuirle a Scholar un consumo activo de JSON-LD sería extrapolar más allá de lo verificable. Lo que sí es documentado y directo es la relación entre JSON-LD y los motores de búsqueda generalistas de Google.
Motores de búsqueda académica y bases de datos. Semantic Scholar (Allen Institute for AI), con más de 200 millones de publicaciones indexadas, usa técnicas de procesamiento de lenguaje natural para construir grafos de conocimiento científico. Su pipeline documentado opera principalmente sobre PDFs, metadatos de CrossRef y APIs de repositorios; no hay documentación pública de que consuma activamente JSON-LD embebido en páginas HTML de terceros. Plataformas como BASE (Bielefeld Academic Search Engine) o CORE sí procesan metadatos en distintos formatos, aunque el alcance exacto de su soporte para JSON-LD varía por implementación.
Sistemas de gestión de identidad. ORCID, CrossRef y DataCite mantienen grafos de conocimiento académico. JSON-LD con identificadores permanentes (DOI, ORCID iD, ROR) facilita la reconciliación de entidades entre estos sistemas.
Motores de IA generativa. GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot y los crawlers de Google para AI Overviews descargan el HTML de las páginas que rastrean, incluyendo los bloques JSON-LD cuando están presentes en el HTML estático. Si ese marcado influye de forma diferenciada en cómo estos sistemas comprenden, citan o atribuyen el contenido es algo que ninguna de estas plataformas documenta públicamente con detalle. Lo que sí está documentado es que Google usa datos estructurados de forma activa en sus productos de búsqueda, incluyendo AI Overviews. Para los demás, la inferencia técnica razonable es que datos bien formados y no ambiguos en el HTML completo del que se alimentan sus modelos probablemente contribuyen a una representación más precisa del contenido, aunque no puede afirmarse como mecanismo establecido.
Agregadores y repositorios. Sistemas como OpenAIRE en Europa, o repositorios institucionales que implementan protocolos OAI-PMH, pueden beneficiarse de JSON-LD como capa adicional de metadatos cuando el contenido es publicado en HTML.
Desarrolladores y aplicaciones. JSON-LD es procesable programáticamente por cualquier aplicación que entienda JSON. Herramientas de análisis bibliométrico, visualizadores de redes de citas, sistemas de recomendación y buscadores especializados pueden consumir este marcado directamente desde las páginas HTML de una revista sin necesidad de APIs adicionales.
6. Qué le aporta a un editor científico
Aquí es donde la tecnología toca tierra. Un editor científico latinoamericano, especialmente uno al frente de una revista de acceso abierto con recursos técnicos limitados, enfrenta un problema estructural: produce conocimiento de calidad que, por razones de visibilidad técnica, no llega a los circuitos de descubrimiento que determinan el impacto real de una publicación. JSON-LD es una de las herramientas más eficientes para atacar ese problema.
Visibilidad en búsquedas. Un artículo marcado con ScholarlyArticle y sus propiedades completas (DOI, ISSN, autores con ORCID, fecha de publicación, resumen, palabras clave, paginación) tiene más probabilidades de generar un fragmento enriquecido en Google que un artículo sin esos datos. Ese fragmento aparece antes de que el usuario haga clic, transmite confianza institucional y aumenta la tasa de clics orgánicos.
Indexación académica. Los sistemas de indexación modernos procesan metadatos en múltiples formatos. Una revista que publica sus artículos en HTML con JSON-LD completo reduce la ambigüedad para cualquier sistema que rastreé esas páginas: desde los crawlers de Google hasta plataformas como BASE o CORE, que sí procesan metadatos embebidos en HTML. Para sistemas como Semantic Scholar, cuyo pipeline documentado opera principalmente sobre PDFs y APIs de repositorios, el canal más directo sigue siendo el depósito estructurado de metadatos vía CrossRef o repositorios compatibles —aunque tener el HTML bien marcado nunca perjudica.
Interoperabilidad con identificadores persistentes. Incluir el DOI como @id del objeto ScholarlyArticle, el ORCID de cada autor en el nodo Person, y el ROR de cada institución en el nodo Organization convierte cada artículo en un nodo de un grafo global de conocimiento académico. Esto no es abstracción: es la base técnica sobre la que funcionan sistemas como el gráfico de conocimiento de CrossRef o el perfil de autores en ORCID.
Visibilidad en la era de la IA. Con la proliferación de motores de respuesta generativa (ChatGPT, Gemini, Perplexity, Claude), el contenido que es citado en esas respuestas tiene una ventaja de descubrimiento cualitativamente diferente al posicionamiento tradicional. Los datos estructurados en JSON-LD son uno de los factores que aumentan la probabilidad de esa citación, porque le dan a los modelos información explícita, no ambigua, sobre qué es el contenido y quién lo produjo.
Bajo costo de implementación. A diferencia de otras estrategias de visibilidad (negociación con bases de datos, integración de APIs, desarrollo de parsers específicos), JSON-LD es texto embebido en el HTML de cada artículo. No requiere infraestructura adicional, no tiene costo de licencia, no depende de terceros. Una vez implementado en el pipeline de generación HTML, funciona para todos los artículos presentes y futuros sin esfuerzo incremental.
Autonomía editorial. Un editor que publica su contenido con metadatos semánticos completos no depende de que una base de datos acepte su solicitud de indexación: los datos están ahí, disponibles para cualquier sistema que quiera consumirlos. Esto es especialmente relevante para revistas latinoamericanas que históricamente han quedado al margen de los grandes circuitos de indexación anglosajones.
7. Diagnóstico: quién más lo hace, y por qué tantos no
Quién lo hace por defecto
gbpublisher incluye JSON-LD en todas sus salidas HTML por defecto, generado directamente desde los metadatos de la base de datos con propiedades completas: ScholarlyArticle, autores con ORCID, institución con ROR, DOI, ISSN, fechas de recepción/aceptación/publicación, palabras clave, resumen. No es una funcionalidad opcional ni un plugin: es parte del pipeline de generación.
En el ecosistema de gestión editorial, OJS (Open Journal Systems) no incluye JSON-LD en su salida por defecto. Lo ofrece como plugin externo: existe un plugin desarrollado por terceros que inyecta ScholarlyArticle en las páginas de artículos, pero requiere instalación y activación manual. En una instalación estándar de OJS, las páginas de artículos salen sin JSON-LD.
Elsevier, Springer, Taylor & Francis incluyen JSON-LD en sus páginas de artículos, generalmente con tipo ScholarlyArticle y propiedades completas. Estas editoriales tienen equipos técnicos dedicados a SEO y metadatos, y adoptaron el estándar hace años, principalmente motivadas por visibilidad en Google Scholar y en motores generalistas.
PLOS ONE y sus journals asociados incluyen JSON-LD en sus páginas HTML, con marcado cuidadoso de autores, afiliaciones y DOIs.
SciELO presenta una situación heterogénea. La plataforma central tiene capacidades de metadatos estructurados, pero la implementación varía por país y por colección. No es sistemáticamente consistente en términos de JSON-LD en todas sus instancias.
Por qué tantos no lo hacen
El diagnóstico es más interesante que la lista de los que sí lo hacen, porque revela fracturas estructurales en la publicación científica latinoamericana.
Desconocimiento técnico en el nivel editorial. La mayoría de los editores científicos latinoamericanos son académicos, no técnicos. El conocimiento sobre HTML, metadatos estructurados y estándares web simplemente no forma parte de su formación ni de sus redes de consulta habituales. Lo que no se conoce no se implementa.
OJS como norma implícita, y OJS no lo hace por defecto. OJS tiene una penetración extraordinariamente alta entre las revistas de acceso abierto latinoamericanas. Si OJS no incluye una funcionalidad por defecto, la gran mayoría de las revistas no la tiene. El plugin de JSON-LD para OJS existe, pero instalar plugins requiere acceso administrativo al servidor, conocimiento técnico mínimo y una decisión deliberada. Pocas revistas llegan ahí.
El modelo “PDF como producto final”. Una fracción importante de las revistas latinoamericanas sigue publicando el PDF como único o principal formato de salida. Sin HTML, no hay JSON-LD. Este modelo es heredado de la era pre-web y resiste porque es lo que las revistas saben hacer. La producción de HTML con metadatos estructurados implica un salto cualitativo en el pipeline editorial que muchas revistas no están en condiciones de dar solas.
Confusión entre metadatos OAI-PMH y metadatos web. Muchas revistas que sí implementan correctamente su interfaz OAI-PMH (para ser harvested por repositorios) asumen que eso es suficiente para la visibilidad web. No lo es. OAI-PMH es un protocolo que permite que dos sistemas informáticos intercambien metadatos entre sí de forma automática: un repositorio o base de datos “cosecha” los datos de la revista sin que ningún humano ni ningún motor de búsqueda esté presente en ese intercambio. JSON-LD, en cambio, es información embebida en la página HTML pública del artículo, la misma página que leen los lectores y rastrean los motores de búsqueda. Son dos canales que resuelven problemas distintos: OAI-PMH conecta sistemas institucionales entre sí; JSON-LD hace que el contenido sea legible y clasificable para cualquier software que visite la página, desde Google hasta un crawler de inteligencia artificial. Tener uno no reemplaza al otro.
Ausencia de incentivos medibles a corto plazo. Los efectos de JSON-LD sobre la visibilidad son reales pero difusos y de mediano plazo. No hay un número en el panel de control que diga “estos 47 accesos vinieron porque el artículo tiene JSON-LD”. En un entorno donde los recursos son escasos y la presión por resultados es inmediata, es difícil justificar una inversión de tiempo en una tecnología cuyo retorno es indirecto.
Dependencia de proveedores externos para la producción HTML. Varias revistas tercerizan la producción de sus páginas web a servicios que generan HTML básico sin semántica adicional. Si el proveedor no sabe o no quiere implementar JSON-LD, la revista no lo tiene, aunque tenga toda la información necesaria en sus bases de datos.
Cierre: metadatos como política editorial
Hay una forma de pensar la decisión de incluir o no JSON-LD que va más allá de la técnica: es una decisión política.
Una revista que publica sus artículos con metadatos semánticos completos está afirmando que su contenido merece ser encontrado, interpretado correctamente y conectado con el resto del conocimiento científico global. Está apostando por la interoperabilidad como valor, no como accidente. Está construyendo, artículo por artículo, un nodo en el grafo de la ciencia abierta.
Una revista que publica solo PDF, o que publica HTML sin metadatos, no está tomando una decisión neutral: está eligiendo la invisibilidad por defecto. Esa invisibilidad no es técnica; es política y cultural.
Para los editores latinoamericanos que trabajan con recursos limitados, la pregunta no debería ser “¿podemos darnos el lujo de implementar JSON-LD?” sino “¿podemos darnos el lujo de no hacerlo?”. En un ecosistema donde el descubrimiento de contenido científico es cada vez más mediado por algoritmos —de búsqueda tradicional, de IA generativa, de sistemas de recomendación—, los metadatos semánticos son infraestructura, no decoración.
gbpublisher incorpora JSON-LD por defecto precisamente por esta razón: porque una herramienta para la producción editorial académica que no hace visibles sus salidas no cumple con su función fundamental. La visibilidad no es una característica opcional. Es parte del acto de publicar.
