ISAD(G), Dublin Core y CIDOC-CRM: cuál usar y cuándo
ISAD(G), ISAAR(CPF), ISDIAH, Dublin Core, CIDOC-CRM, EAD. La sopa de siglas confunde a cualquiera. Cada una resuelve un problema distinto, y en la práctica conviven.
Actualizado el 23 de julio de 2026
El problema de la sopa de siglas
Llegan tres propuestas para el sistema del archivo. Una dice que "cumple ISAD(G) y EAD". Otra, "Dublin Core y CIDOC-CRM". La tercera, "todos los estándares internacionales". Hay que elegir, y no hay forma de comparar: parecen listas de lo mismo escritas distinto.
La confusión no es tuya. Las siglas no son alternativas del mismo tipo. Unas dicen qué datos registrar sobre un documento. Otras, en qué formato entregárselos a otro sistema. Otras, cómo modelar las relaciones entre objetos, personas y hechos. Elegir "entre ISAD(G) y Dublin Core" es como elegir entre el contenido de una carta y el sobre: no compiten, se apilan.
Dos palabras que el resto de la guía usa. Metadato es un dato que describe otro dato: el título, la fecha y el productor de un expediente son metadatos de ese expediente. Interoperabilidad es que dos sistemas distintos entiendan lo mismo al recibir la misma ficha; es lo que permite que un buscador o un portal nacional muestren tu acervo sin que nadie recargue nada a mano.
Y hay una novedad de 2023 que conviene conocer antes de firmar un contrato: el Consejo Internacional de Archivos publicó una norma que sucede a cuatro de las siglas de esta lista.
Qué resuelve cada estándar
Las cuatro normas del Consejo Internacional de Archivos (ICA). Piezas de un mismo rompecabezas: describir por separado los documentos, quién los produjo, qué actividad documentan y quién los custodia hoy.
- ISAD(G), la norma general internacional de descripción archivística. Primera edición en 1994, segunda en 2000. Describe los documentos y sus agrupaciones de lo general a lo particular, con 7 áreas y 26 elementos. Es la base de NUDA, la norma uruguaya.
- ISAAR(CPF) describe al productor —una institución, una persona, una familia— en una ficha aparte llamada registro de autoridad: se escribe una vez y se enlaza desde cada fondo que produjo —el conjunto de documentos generados por esa entidad en el ejercicio de su actividad—, en lugar de repetirla en cada uno. Segunda edición adoptada por el ICA en Canberra, en octubre de 2003.
- ISDF describe funciones: la actividad que dio origen a los documentos. Primera edición, Dresde, mayo de 2007. Sirve porque las funciones son, dice el texto, "generalmente más estables que las estructuras administrativas".
- ISDIAH describe a la institución que custodia los archivos: dirección, horarios, condiciones de acceso, servicios al usuario. Primera edición, Londres, marzo de 2008. Es la ficha del archivo como lugar, no la del acervo.
El propio ICA es franco sobre cuánto se usan: ISAD(G) fue la más adoptada, ISAAR(CPF) tiene "algún uso", e ISDF e ISDIAH, "muy poco".
RiC, la norma que las sucede. En noviembre de 2023 el ICA publicó Records in Contexts (RiC) en versión 1.0, que —en sus propias palabras— "extiende y reemplaza" a esas cuatro normas, las cuales, aclara, siguen disponibles. Cambia la forma de describir: donde ISAD(G) arma una jerarquía cerrada (fondo, serie, expediente), RiC modela una red de 22 entidades —cada tipo de cosa que describe por separado: documentos, conjuntos, personas, grupos, cargos, actividades, normas, fechas, lugares— y sus relaciones.
Para un decisor importa lo que el propio documento admite: la transición "será gradual", muchas instituciones "simplemente no van a tener los recursos para adoptar RiC-CM de inmediato", y la descripción jerárquica de ISAD(G) "sigue siendo, y es probable que siga siendo, el enfoque predominante". No hay que migrar con urgencia; sí conviene preguntarle al proveedor qué plan tiene.
Dublin Core: el mínimo común denominador. Lo mantiene la Dublin Core Metadata Initiative (DCMI). Son 15 elementos genéricos —título, creador, fecha, tipo, formato, identificador, derechos y otros—, normalizados como ISO 15836-1:2017. No sirve para describir un fondo con su contexto: no tiene noción de fondo, ni de serie, ni de valoración documental (qué documentos conservar, cuáles descartar y por cuánto tiempo). Sirve para lo contrario: que cualquier sistema entienda algo de tu ficha sin negociar nada.
CIDOC-CRM: el estándar de museos. Lo mantiene el CIDOC CRM Special Interest Group, bajo CIDOC, el comité de documentación del Consejo Internacional de Museos (ICOM). Es la norma ISO 21127:2023, y su versión comunitaria oficial es la 7.1.3, de febrero de 2024. No es una planilla de campos: es una ontología, un modelo que describe hechos y quiénes participaron en ellos. En lugar de anotar "autor: tal", registra que el objeto fue producido en un evento, por una persona, en un lugar y en una fecha. Así se cruzan preguntas que una ficha plana no responde.
EAD: el sobre, no la carta. EAD (Encoded Archival Description) no dice qué describir: define un formato XML para transportar y publicar un instrumento de descripción que ya existe. La versión vigente es EAD3, con su diccionario de etiquetas 1.1.2 de junio de 2023; la mantiene el subcomité TS-EAS de la Society of American Archivists junto con la Library of Congress, que aloja la documentación. EAD 2002 está declarada obsoleta y sin soporte.
Cuál usar según tu acervo
| Estándar | Para qué sirve | Cuándo usarlo |
|---|---|---|
| ISAD(G) | Describir documentos de archivo y sus agrupaciones, del fondo al expediente | Cuando tu acervo es documental y necesitás describirlo con contexto y jerarquía |
| NUDA | Aplicar ISAD(G) con las precisiones y los elementos obligatorios que fijó el Archivo General de la Nación (AGN) | Siempre que tu institución sea uruguaya: es la única con respaldo nacional |
| ISAAR(CPF) | Describir al productor de los documentos en una ficha reutilizable | Cuando un mismo productor generó varios fondos, o cambió de nombre con los años |
| ISDIAH | Describir a la institución que custodia el acervo y sus condiciones de acceso | Cuando publicás un portal y el usuario necesita saber dónde y cómo consultar |
| ISDF | Describir las funciones y actividades que dieron origen a los documentos | Cuando la estructura administrativa cambió tanto que ya no explica de dónde salió cada serie |
| RiC | Modelar la descripción como red de entidades relacionadas, no como jerarquía única | Cuando arrancás de cero con recursos técnicos, o planificás la migración a mediano plazo |
| Dublin Core | Exponer una ficha mínima que cualquier sistema externo pueda leer | Siempre que publiques en línea o entregues datos a un buscador o agregador |
| CIDOC-CRM | Modelar objetos patrimoniales junto con las personas, lugares y hechos vinculados | Cuando tu acervo es de objetos —museo, colección patrimonial— y no de expedientes |
| EAD3 | Empaquetar en XML un instrumento de descripción ya elaborado | Cuando tenés que entregar tus inventarios a otra institución o a un portal |
En criollo: si administrás un archivo institucional uruguayo, tu norma es NUDA, y ya estás usando ISAD(G) sin decirlo. Si administrás un museo o una colección de objetos, tu modelo es CIDOC-CRM. Y si vas a publicar en línea, Dublin Core no es una opción entre otras: es la salida, y convive con cualquiera de las anteriores.
Cómo conviven en la práctica
Casi ninguna institución usa un solo estándar. Lo habitual es describir con uno y exponer con otro.
Describir con NUDA o ISAD(G), publicar en Dublin Core. Es la combinación más común. La descripción interna conserva la jerarquía, el contexto y la valoración; hacia afuera, el sistema traduce cada ficha a los 15 elementos de Dublin Core mediante una tabla de equivalencias, un mapa que dice qué campo de la norma alimenta cada elemento. Se pierde profundidad en la salida, y está bien: el buscador no necesita el cuadro de clasificación, necesita título, fecha y autor.
Describir el productor una sola vez, con ISAAR(CPF). Un ministerio que cambió de nombre tres veces produjo fondos que hoy figuran bajo tres denominaciones. Si la historia institucional se escribe dentro de cada fondo, se desactualiza en tres lugares. Con un registro de autoridad se escribe una vez y los fondos la enlazan.
Describir con la norma, intercambiar con EAD3. El día que haya que entregar los inventarios a un portal o a otra institución, EAD3 es el formato del envío: no reemplaza la descripción, la empaqueta.
Un acervo mixto usa dos modelos a la vez. Un museo que además custodia el archivo de su fundador describe los objetos con CIDOC-CRM y el fondo documental con NUDA, en el mismo sistema, y expone ambos en Dublin Core. Son dos naturalezas distintas: el objeto se describe por sí mismo, el documento por el lugar que ocupa en un conjunto.
Que esto sea sostenible depende menos de la norma que del sistema: si cada estándar obliga a recargar el acervo desde cero, la convivencia no se sostiene. Un sistema como Memora parte de una sola descripción y expone las distintas salidas —soporta ISAD(G), CIDOC-CRM, Dublin Core, EAD, ISAAR(CPF) e ISDIAH— sin duplicar la carga.
Errores frecuentes
Tratar los estándares como opciones excluyentes. Es el error de origen. ISAD(G) y Dublin Core no compiten: uno describe hacia adentro, el otro publica hacia afuera. Un pliego que pide "elegir un estándar de descripción" ya está mal planteado.
Elegir sistema por la cantidad de siglas del folleto. Que un sistema "soporte" un estándar puede significar que exporta un archivo o que modela la descripción según esa norma. Son cosas muy distintas. La pregunta que sirve es concreta: ¿puedo describir un fondo con sus niveles y exportarlo completo el día que me vaya a otro sistema?
Creer que ISAD(G) quedó obsoleto porque salió RiC. El propio ICA dice que la transición será gradual y que la descripción jerárquica seguirá siendo predominante. Describir hoy con NUDA no es trabajo perdido.
Usar CIDOC-CRM para un archivo administrativo. Modela objetos y hechos, no series documentales ni ciclo de vida. Aplicarlo a expedientes de licitación agrega complejidad sin resolver lo que la normativa uruguaya exige.
Confundir el formato con la norma de contenido. "Exportamos en EAD" no dice nada sobre la calidad de la descripción: un instrumento mal descrito exportado en XML sigue mal descrito.
Publicar en Dublin Core y creer que eso es describir. Quince elementos genéricos no registran el productor, ni la función, ni la valoración documental. Sirven de salida, nunca de punto de partida.