DCAT-AP-ES: cómo publicar tu catálogo de datos como datos abiertos en España

AI Open Space

DCAT-AP-ES: cómo publicar tu catálogo de datos como datos abiertos en España

Cualquier ayuntamiento, diputación o consejería que gestione datos abiertos se ha encontrado antes o después con la misma pregunta: ¿cómo hago que mi catálogo de datos sea visible y reutilizable más allá de mi propio portal? Publicar un conjunto de datos en una web municipal está bien, pero si ese dato no habla el mismo idioma que el resto de administraciones, se queda aislado. Ahí es donde entra DCAT-AP-ES, el perfil de metadatos que permite que un catálogo de datos español sea entendido, indexado y reutilizado por portales de nivel nacional y europeo.

El problema no es la falta de datos, sino la falta de un lenguaje común para describirlos. Cada organismo suele estructurar sus metadatos a su manera: unos indican la licencia, otros no; unos versionan sus conjuntos de datos, otros los sustituyen sin dejar rastro. Cuando datos.gob.es o data.europa.eu intentan recolectar esta información de forma automática, necesitan un estándar que garantice que "título", "editor" o "fecha de actualización" significan siempre lo mismo, se mire donde se mire.

En este artículo explicamos qué es DCAT-AP-ES, por qué es la puerta de entrada obligada para cualquier administración que quiera que sus datos abiertos tengan recorrido real, y cómo un espacio de datos moderno puede automatizar buena parte de ese trabajo técnico.

 

Qué es DCAT-AP-ES y de dónde viene

DCAT-AP-ES es la adaptación española del perfil europeo DCAT-AP (Data Catalogue Vocabulary Application Profile), a su vez basado en el vocabulario DCAT del W3C. En términos sencillos, es un conjunto de reglas que define qué campos debe tener la ficha de un conjunto de datos y cómo deben rellenarse para que cualquier sistema automatizado pueda leerlos sin ambigüedad.

Un catálogo de datos publicado según DCAT-AP-ES describe, entre otros elementos:

  • El dataset (conjunto de datos): título, descripción, temática, cobertura geográfica y temporal.

  • La distribución: el fichero o servicio concreto (CSV, API, JSON), su formato y su URL de acceso.

  • El editor: qué organismo público es responsable de esos datos.

  • La licencia: en qué condiciones se puede reutilizar la información.

  • La frecuencia de actualización y las fechas de publicación y modificación.

Esta estandarización es la que permite que un portal de transparencia autonómico, uno provincial y datos.gob.es puedan intercambiar registros automáticamente mediante cosecha (harvesting), sin que un técnico tenga que volcar manualmente cada ficha.

 

Por qué importa para una administración local o regional

Para una diputación, un ayuntamiento mediano o una consejería, cumplir con DCAT-AP-ES no es un capricho técnico, es lo que determina si sus datos abiertos son visibles fuera de su propia web.

Imaginemos el caso de un ayuntamiento de Castilla y León que publica en su portal municipal el censo de comercios, los presupuestos anuales y los datos de consumo de agua. Si esos conjuntos de datos no están descritos con metadatos DCAT-AP-ES, datos.gob.es no puede indexarlos correctamente, y un ciudadano, una empresa o un investigador que busque "presupuestos municipales Castilla y León" nunca los encontrará desde el portal nacional.

Con metadatos correctos, en cambio, ese mismo conjunto de datos aparece automáticamente en las búsquedas de datos.gob.es y, potencialmente, en data.europa.eu, el portal europeo de datos abiertos. Esto amplía la audiencia real de la información pública sin que la administración tenga que hacer difusión activa: el estándar hace el trabajo de conectar catálogos.

Además, cumplir con el perfil evita duplicidades y errores de interpretación. Cuando varios organismos usan la misma estructura, resulta mucho más fácil comparar y combinar datos de distintas fuentes, algo especialmente útil en materia de transparencia, contratación pública o gestión medioambiental.

 

De los metadatos a la interoperabilidad real

DCAT-AP-ES no es solo una cuestión de visibilidad, es la base técnica de la interoperabilidad entre catálogos. Cuando los metadatos siguen el mismo esquema, un sistema puede:

  • Detectar automáticamente si un conjunto de datos ya existe en otro catálogo o es una copia desactualizada.

  • Comparar la frecuencia de actualización declarada frente a la real.

  • Enlazar conjuntos de datos relacionados de distintos organismos usando identificadores comunes.

  • Generar catálogos agregados (por ejemplo, uno autonómico que recoja los datos de todos los municipios de una provincia) sin reescribir metadatos a mano.

Esta interoperabilidad es también la que permite que los datos abiertos convivan con esquemas de gobernanza más exigentes, como los que se usan en un espacio de datos, donde no solo importa que el metadato sea legible, sino que se pueda verificar de dónde viene y bajo qué condiciones se puede usar.

 

Pasos técnicos para publicar un catálogo compatible con DCAT-AP-ES

Adaptar un catálogo de datos existente a DCAT-AP-ES suele seguir un recorrido parecido, independientemente del tamaño del organismo:

  1. Auditar el catálogo actual. Revisar qué conjuntos de datos existen, qué metadatos tienen ya y cuáles faltan (licencia, editor, cobertura temporal, etc.).

  2. Mapear los campos propios al vocabulario DCAT-AP-ES. Traducir la estructura interna (por ejemplo, una hoja de cálculo con nombres de columnas propios) a las propiedades estándar del perfil.

  3. Elegir el formato de serialización. DCAT-AP-ES se expresa habitualmente en RDF, aunque también se admiten representaciones en XML o JSON-LD según el sistema receptor.

  4. Generar el fichero de catálogo o exponer un endpoint. El catálogo puede publicarse como fichero descargable o, de forma más robusta, como un servicio que se pueda consultar y cosechar automáticamente.

  5. Validar contra el perfil oficial. Comprobar que los campos obligatorios están presentes y bien formados antes de anunciar el catálogo a datos.gob.es.

  6. Dar de alta el catálogo para su cosecha periódica. A partir de aquí, cualquier actualización del catálogo de origen se refleja automáticamente en los portales que lo recolectan.

Este proceso, hecho a mano, puede llevar semanas en organismos con cientos de conjuntos de datos y equipos técnicos pequeños, que es precisamente el perfil habitual de muchos ayuntamientos y diputaciones de Castilla y León.

 

Cómo un espacio de datos simplifica la publicación DCAT-AP-ES

Aquí es donde un espacio de datos aporta un salto de eficiencia. Un espacio de datos moderno incluye un catálogo federado pensado para exportarse de forma nativa a DCAT-AP-ES.

En la práctica, esto significa que una entidad, ya sea una empresa de servicios públicos o una administración provincial, puede dar de alta sus conjuntos de datos una sola vez en la interfaz de administración del espacio de datos, describiendo título, licencia, formato y periodicidad mediante un panel sin código. El propio sistema se encarga de traducir esa información al vocabulario DCAT-AP-ES y de exponerla en un formato listo para ser cosechado por datos.gob.es o data.europa.eu.

Esto resuelve dos problemas a la vez. Por un lado, evita el trabajo manual de mapeo y validación contra el perfil, que suele ser la parte más lenta del proceso. Por otro, mantiene sincronizados el catálogo interno de gobernanza de datos y el catálogo público de datos abiertos, de forma que cualquier cambio en las condiciones de acceso o en la actualización de un conjunto de datos se refleje automáticamente en ambos sitios, sin depender de que alguien recuerde actualizar dos sistemas distintos.

 

Datos abiertos y datos soberanos: dos caras de la misma estrategia

Conviene aclarar una confusión habitual: publicar datos abiertos según DCAT-AP-ES no compite con la soberanía del dato, la complementa. Un espacio de datos permite gestionar en un mismo entorno tanto los conjuntos de datos que se abren libremente a cualquier reutilización, como aquellos que solo se comparten bajo condiciones concretas con socios autorizados, aplicando políticas de acceso diferenciadas para cada caso.

Esto es especialmente relevante para administraciones que combinan obligaciones de transparencia con datos sensibles: una diputación puede publicar en abierto sus indicadores de gestión y, al mismo tiempo, compartir de forma controlada datos de infraestructuras críticas solo con determinados organismos, usando el mismo catálogo federado como punto de partida y decidiendo en cada caso el nivel de apertura.

En última instancia, DCAT-AP-ES resuelve el problema de la descripción de los datos, mientras que la capa de políticas de acceso resuelve el problema de quién puede usarlos y cómo. Un espacio de datos bien diseñado permite gestionar ambas capas sin duplicar esfuerzos ni sistemas.

 

Da el siguiente paso con tu catálogo de datos

Si tu administración quiere que sus datos abiertos sean realmente visibles y reutilizables, adaptarlos a DCAT-AP-ES es un paso ineludible, y no tiene por qué ser un proyecto largo ni costoso. Un espacio de datos moderno ofrece un catálogo federado preparado para exportar metadatos compatibles con datos.gob.es y data.europa.eu desde una interfaz sencilla, sin necesidad de conocimientos técnicos avanzados.

Si quieres conocer cómo aplicarlo a tu organismo o resolver dudas concretas sobre tu catálogo actual, busca un socio tecnológico con experiencia en espacios de datos que pueda acompañarte en el proceso.