Cuándo usar Dublin Core para describir un recurso lo decide el trabajo que el registro tiene que hacer, no el modelo. De todos los formatos que un catalogador maneja, Dublin Core es el que menos pide. Quince elementos —título, creador, materia, descripción, editor, colaborador, fecha, tipo, formato, identificador, fuente, idioma, relación, cobertura y derechos— y ninguno obligatorio. Esa economía no es un descuido: Dublin Core nació para que recursos descritos por gente distinta, en sistemas distintos, pudieran encontrarse y entenderse entre sí. La descripción fina se deja para el formato que corresponda; el común denominador se mantiene deliberadamente corto.
Para qué sirve un formato simple
El caso donde Dublin Core rinde es el del intercambio. Un repositorio institucional que expone sus registros para que otros los cosechen —vía OAI-PMH, por ejemplo— necesita un formato que cualquier recolector entienda sin acuerdos previos. Ahí quince elementos bastan y su simplicidad es la virtud: no hay reglas de subcampo que interpretar ni perfiles locales que negociar.
También sirve como capa de descubrimiento sobre colecciones heterogéneas. Si un acervo mezcla documentos, imágenes, datos y objetos de naturaleza distinta, un esquema común permite listarlos y buscarlos juntos aunque cada tipo, por separado, merezca una descripción más rica en su propio formato. Dublin Core es entonces la vista compartida, no el registro definitivo de cada pieza.
Cuándo quince elementos se quedan cortos
El límite aparece cuando la institución necesita expresar algo que los
quince elementos no distinguen. “Fecha” no separa la fecha de creación de
la de publicación o la de digitalización. “Relación” agrupa bajo una sola
etiqueta vínculos que pueden ser “es parte de”, “es versión de” o
“reemplaza a”. Para esos casos existe la versión extendida, los DCMI
Metadata Terms: un vocabulario más amplio que refina los quince elementos
originales —created, issued, isPartOf, hasVersion, spatial,
temporal, entre otros— sin abandonar el marco de Dublin Core.
La extensión resuelve la ambigüedad sin obligar a saltar a un formato pesado. La decisión práctica es identificar qué distinciones necesita de verdad la institución antes de configurar el esquema, y añadir solo esos términos. Un registro con tres refinamientos bien usados comunica más que uno que declara doce y llena la mitad por inercia.
Cuándo conviene otro formato
Elegir Dublin Core para el trabajo equivocado cuesta más que no haberlo elegido.
Para descripción bibliográfica fina —control de autoridades, puntos de
acceso, número de clasificación, mención de responsabilidad estructurada—
existe MARC21. Dublin Core puede llevar un autor en
el elemento creator, pero no distingue autor de compilador de traductor
con la precisión que un catálogo de biblioteca da por supuesta. Cómo se
produce ese registro está en Cómo generar registros MARC21 y UNIMARC con
IA.
Para descripción archivística —donde importan la procedencia, el contexto de producción y la jerarquía de fondo, sección y serie— el formato indicado es ISAD-G. Dublin Core describe el ítem aislado; no tiene forma nativa de expresar que un documento es una pieza dentro de una serie dentro de un fondo. Esa descripción está en Cómo describir un archivo en ISAD-G con IA.
Dublin Core no compite con esos formatos: cubre un tramo distinto. Sirve para el descubrimiento amplio y el intercambio entre sistemas; no reemplaza al registro detallado que cada tipo de acervo necesita por dentro. Muchas instituciones usan los dos niveles a la vez —MARC o ISAD-G como registro completo, Dublin Core como la vista que se comparte hacia afuera— y esa convivencia es el uso más común.
Cómo lo produce Collect
Janium Collect genera Dublin Core, en su forma simple y en la extendida, desde el mismo flujo con que produce los demás formatos: lee el documento, propone el registro y lo entrega para revisión. Dos cuidados son propios de este trabajo.
El primero es la protección de campos. Los valores que no deben alterarse —identificadores, fechas, nombres propios— se trasladan; la lectura del documento no los reescribe. Un identificador que cambia es un enlace roto, y en un formato pensado para el intercambio ese daño se propaga a cada sistema que cosechó el registro.
El segundo es la traducción selectiva del vocabulario descriptivo. Cuando el material está en otro idioma, se traduce el contenido descriptivo —la materia, la descripción, el tipo— mientras el título original, los nombres y los datos de control se conservan tal cual. El objetivo es que el registro sea legible en el idioma de la institución sin falsear lo que dice la fuente.
Ninguno de esos dos pasos convierte a Dublin Core en lo que no es. Sigue siendo un formato simple, y esa es la razón para usarlo cuando el trabajo pide un común denominador interoperable. Cuando pide descripción bibliográfica o archivística fina, el formato correcto es otro, y Collect también lo produce.
Límites
Collect no decide por la institución si el catálogo de trabajo es Dublin Core, MARC o ISAD-G. Esa elección la fija el uso: intercambio y descubrimiento, o descripción fina. La versión extendida añade distinciones; no convierte quince elementos en un formato bibliográfico.
El modelo de lenguaje completa el registro con lo que la fuente no traía cuando puede sostenerlo, y deja marcado lo inferido: un dato inferido no se presenta como verificado, y lo que no se puede sostener no se rellena para cumplir el esquema. La simplicidad de Dublin Core no es motivo para saltarse esa marca.
Para continuar la conversación
Si tu institución expone sus registros para que otros los cosechen, o mantiene una vista de descubrimiento sobre colecciones de distinta naturaleza, y estás decidiendo dónde usar Dublin Core y dónde conviene un formato más detallado, escríbenos a info@janium.com. Nos interesa entender cómo describes tu acervo hoy y qué necesitas intercambiar.