Implantación práctica de DCAT-AP-ES con CKAN y servicios HVD: dudas sobre DataService, contactPoint, versiones y stack recomendado

[alonsomarcosm99]

Hola,

Desde tragsatec ImpulsaData/Plataformas, estamos implantando DCAT-AP-ES en un conversor/ETL que se desplegará en varios organismos de la AGE (mapeo desde modelos/fichas internas → JSON estándar → DCAT-AP-ES → CKAN/RDF).

Para ello tenemos estas piezas encima de la mesa:

• Guía técnica de implementación y modelo DCAT-AP-ES.
• Guía de Convenciones (incluyendo HVD, adms:identifier, contactPoint, etc.).
• Ejemplos oficiales de dcat:DataService HVD.
• Catálogo nacional datos.gob.es como consumidor/federador.
• CKAN + ckanext-scheming + ckanext-schemingdcat como stack típico para catálogos.

Me gustaría plantear algunas dudas y contrastar si estoy interpretando bien el estado actual.

---

1. dcat:DataService HVD en datos.gob.es

En la sección “Servicios de datos” de datos.gob.es solo aparecen, a día de hoy, dos dcat:DataService HVD (API de datos del MITECO e INE/WSTEMPUS), modelados como servicios “globales” que sirven muchos datasets HVD de cada organismo.

Otros organismos que tienen datasets HVD federados todavía no tienen un dcat:DataService explícito.

La Convención 12 dice que cada dataset HVD DEBE tener al menos un servicio de datos con un conjunto amplio de propiedades obligatorias (dcat:endpointURL, dcat:endpointDescription, dcat:contactPoint con vCard, dcatap:applicableLegislation, dcatap:hvdCategory, foaf:page, dcat:servesDataset, etc.).

Preguntas:

• ¿El modelo objetivo es “un servicio global por organismo” que sirva todos sus HVD, o “uno o varios servicios por dataset HVD”?
• ¿La situación actual (solo dos servicios, un organismo = un servicio) es transitoria/piloto o forma parte del diseño estable?
• ¿Hay algún documento que explique este criterio a efectos de cumplimiento de la Convención 12?

---

2. Stack CKAN + ckanext-schemingdcat y limitaciones prácticas

Contexto técnico actual:

• CKAN 2.10.x en Docker (imagen oficial).
• ckanext-scheming + ckanext-schemingdcat (https://github.com/mjanez/ckanext-schemingdcat).
• Esquema YAML adaptado a DCAT-AP-ES 3.x para datasets, distribuciones y servicios de datos.

Patrón de modelado que estamos usando (similar al de MITECO):

• Cada resource de CKAN ≈ dcat:Distribution.
• Campo repetible access_services en la distribución para dcat:accessService.
• Cada entrada de access_services lleva los campos de dcat:DataService (id, título, endpointURL, hvdCategory, applicableLegislation, servesDataset, etc.), que el plugin usa para generar nodos dcat:DataService.

Problemas que hemos encontrado:

2.1. Contact point estructurado por servicio (vCard anidado)

Para ser fiel a DCAT-AP-ES, querríamos:

distribution -> access_services[] -> contact_point (vcard:Kind) con subcampos (fn, organization-name, hasEmail, hasURL, …).

Esto requiere repeating_subfields anidados (subcampos repetibles dentro de otros repetibles):

• access_services es una lista de diccionarios.
• Dentro de cada servicio, querríamos otro diccionario vCard con sus subcampos.

En la práctica:

• ckanext-scheming hoy no gestiona bien este patrón: la UI permite introducir datos, pero el diccionario vCard no se almacena o se pierde silenciosamente (no hay error).
• Resultado: no se puede modelar correctamente dcat:contactPoint por servicio solo con YAML y el plugin actual.

A efectos prácticos, solo es viable:

• “Aplanar” la información de contacto (ej. dataservice_contact_email, dataservice_contact_url), o
• renunciar a un vCard completo a nivel de servicio.

2.2. Desalineación esquema YAML ↔ serializador RDF

Hemos extendido el YAML para cubrir mejor adms:Identifier, alternate_identifier y provenance.

Al descargar el .rdf de un dataset (añadiendo la extensión a la URL) nos encontramos con:

• Errores de serialización relacionados con provenance y adms:Identifier (por ejemplo, notación múltiple en la clase identificador/identificador alternativo).
• Campos nuevos que simplemente no aparecen en el RDF, porque el serializador trabaja con un mapeo interno y no con el YAML directamente.

Esto sugiere que la función que genera el .rdf usa un serializador distinto o un perfil anterior (por ejemplo, el de ckanext-dcat), y que no está alineado con el esquema DCAT-AP-ES actual que define ckanext-schemingdcat.

Resultado: puedes tener la BD de CKAN bien alineada con DCAT-AP-ES/HVD pero el RDF del endpoint seguir un perfil/mapeo más antiguo o incompleto.

---

3. Relación con la especificación / modelo

En paralelo a esta discusión, estamos preparando issues más acotadas sobre:

• La documentación de la clase adms:Identifier (solo aparece skos:notation en Guía/modelo relacional, mientras que la Convención 24 propone un patrón más rico).
• La representación de vcard:Kind como rango de dcat:contactPoint y la regla de la Convención 18 (obligatoriedad de hasEmail o hasURL para servicios HVD), que no se refleja claramente en el modelo relacional ni en el diagrama UML.

---

4. Versionado: perfil vs plugins de referencia

Entendemos que DCAT-AP-ES 1.0.0 es un perfil mínimo y que las Convenciones pueden evolucionar más rápido que el resto de documentación y que las implementaciones.

Justo por eso, nos preocupa que:

• Algunos requisitos importantes (especialmente HVD, adms:Identifier enriquecido, vCard de contactPoint) solo estén reflejados en las Convenciones, pero no se proyecten al modelo relacional/UML.
• Los plugins habituales de CKAN (ckanext-dcat, ckanext-schemingdcat) parezcan alineados con perfiles anteriores y no exista una “matriz de compatibilidad” clara entre versión de DCAT-AP-ES y stack software recomendado.

Sería muy útil disponer de alguna indicación del tipo:

• “Versión recomendada de CKAN + extensiones para DCAT-AP-ES 1.0.0 (+ Convenciones HVD a fecha X)”.
• “Cambios en la especificación que se consideran incompatibles con implementaciones anteriores”.
• “Buenas prácticas para migrar catálogos existentes (MITECO, INE, etc.) a la versión actual del perfil sin romper la federación”.

Esto nos ayudaría a versionar correctamente nuestros mapeos y a decidir si debemos adaptar el conversor a las capacidades actuales de los plugins o esperar a futuras versiones.

Muchas gracias por adelantado.

[mjanez]

Gracias por las consultas detalladas. Intentaré abordar cada una de ellas.

1. dcat:DataService HVD en datos.gob.es

En lo que respecta a la presencia de servicios en el catálogo, esto viene determinado por la progresiva implantación de DCAT-AP-ES y la nueva descripción de servicios, que van haciendo los organismos.

La elección depende de la arquitectura técnica del organismo:

• Si existe una API unificada que proporciona acceso a múltiples datasets (ej. CKAN Datastore) → modelo "servicio global" es más natural.
• Si cada dataset tiene endpoints específicos/independientes → modelar servicios individuales puede ser más preciso.

En esencia, lo crítico es garantizar la trazabilidad mediante la descripción de las relaciones entre dataset-distribución-servicio y cumplir los metadatos obligatorios HVD, si aplica.

No se prescribe un modelo único "un servicio global por organismo" vs "un servicio por dataset". A lo que debe atenerse el publicador es al modelo/convenciones: lo obligatorio es que cada dataset HVD tenga asociado al menos un dcat:DataService y que cumpla los requisitos establecidos en las convenciones de federación. Para ello la vinculación se realiza mediante dcat:servesDataset (desde el servicio) o dcat:accessService (desde la distribución), como mejor considere el organismo.

2. Limitaciones técnicas CKAN-scheming-dcat

Aplanar los elementos de vCard puede ser una opción válida, sin embargo, el uso de los repeating_subfields (contact) dentro de otro (access_service), debería dar el resultado esperado. Depurar esa parte para ver, en el momento de creación del dataset, o en la serialización con el perfil, dónde se esta perdiendo. No veo Issues en ckanext-dcat/ckanext-scheming, que en su esquema DCAT-AP Full, los incluyen.

Voy a revisar en ckanext-schemingdcat, a ver si puedo reproducirlo y lo corrijo. Siempre es preferible tener un vcard funcional, más en servicios, dónde es muy relevante.

3.Desalineación esquema YAML ↔ serializador RDF

Este es una casuistica tradicional del stack CKAN, ckanext-dcat serializa/parsea, ckanext-scheming modela. Con lo que las modificaciones en el esquema YAML que genera loa formularios deben acompañarse de la ampliación del perfil (es_dcat_ap_2.py).

Si podemos ver los cambios o el YAML actualizado, o una issue en el repositorio, alineo ambos contextos.

4. Relación con la especificación

He visto las issues, estupendo, gracias por la retroalimentacion.

5. Recomendaciones, migración y compatibilidad

En lo que respecta a la migración de catálogos existentes, NTI-RISP (2013) a DCAT-AP-ES, existe la Guía práctica para migrar a DCAT-AP-ES (datos.gob.es), puede ser interesante hacer una mayor referencia en la guía online de DCAT-AP-ES o incluir una sección específica seleccionando sus apartados más relevantes.

Con respecto a ckanext-schemingdcat, en su versión actual (v4.5.7) es compatible con NTI-RISP (2013), perfil serializador es_dcat y DCAT-AP-ES (es_dcat_ap_2), ambos federan adecuadamente con el catálogo nacional. He planteado la inclusión de DCAT-AP-ES como esquema y perfil en ckanext-dcat, por si pudiera ser útil tenerlos en una extensión más canónica.

Anoto algunas sugerencias interesantes que propones, por si se pueden incluir.

Gracias de nuevo.

[alonsomarcosm99]

Hola @mjanez ,

Muchas gracias por la respuesta tan detallada y por todo el trabajo alrededor de DCAT-AP-ES y los plugins de CKAN. Comparto algunos puntos de seguimiento por si ayudan a afinar nuestro enfoque.

---

1) dcat:DataService HVD y patrón de modelado

La explicación sobre el modelo “servicio global por organismo” vs. “servicios por dataset” nos aclara muy bien el margen que tenemos.

En nuestro caso concreto, el conversor genera para cada dataset sus distribuciones y, desde cada una de ellas, estamos referenciando los servicios de datos mediante la propiedad de la distribución dcat:Distribution → dcat:accessService (“Servicio de acceso” en la guía: metadato opcional, cardinalidad 0..n, rango dcat:DataService, con la nota de uso «se debe incluir la referencia al servicio de datos que proporciona acceso a la distribución que se describe»). Es decir, la cadena completa que estamos utilizando es:

dcat:Dataset → dcat:distribution → dcat:accessService → dcat:DataService.

En el CKAN propuesto a los organismos está previsto usar el Datastore como API unificada, por lo que es probable que empecemos con un servicio global del organismo que sirva varios HVD y, sobre ese patrón, estudiar caso a caso la creación de servicios adicionales más específicos por dataset cuando la arquitectura técnica de cada organismo lo requiera.

Entendemos que esta combinación (un dcat:DataService “global” más otros servicios específicos por dataset, todos correctamente enlazados mediante dcat:accessService y/o dcat:servesDataset) también es conforme siempre que cada HVD tenga al menos un servicio de datos que cumpla las convenciones HVD. ¿Lo estamos interpretando correctamente?

---

2) vCard anidada en servicios (repeating_subfields)

Nos parece muy buena noticia que vayas a revisar el comportamiento de los repeating_subfields anidados en ckanext-schemingdcat. Para nosotros sería clave poder modelar el patrón:

distribution → access_services[] → contact[] (vcard:Organization / vcard:Kind)

de modo que cada dcat:DataService tenga su dcat:contactPoint completo (vcard:organization-name, vcard:hasEmail, vcard:hasURL, vcard:hasTelephone, vcard:hasUID, etc.), tal y como se describe en la guía y en las convenciones de puntos de contacto.

Mientras tanto estamos utilizando un modelo aplanado (campos tipo dataservice_contact_email, dataservice_contact_url…), pero lo vemos como una solución transitoria. Si finalmente se puede corregir el soporte de diccionarios anidados en access_services, será mucho más sencillo mantener la alineación con DCAT-AP-ES sin recurrir a workarounds.

---

3) YAML extendido vs. perfil de serialización RDF

Totalmente de acuerdo en la separación de responsabilidades: ckanext-scheming modela formularios/esquemas y ckanext-dcat serializa a RDF mediante perfiles tipo es_dcat_ap_2.py.

En nuestro caso, el punto de partida ha sido exactamente el esquema:

ckanext-schemingdcat/schemas/dcat_ap/es_dcat_ap_full.yaml (v4.5.7)

y a partir de ahí lo hemos extendido para cubrir todo lo que hoy aparece en la documentación de:

https://datosgobes.github.io/DCAT-AP-ES

Nuestro objetivo es que el conversor soporte DCAT-AP-ES completo, entendido como:

• DCAT-AP 2.1.1 (base),
• DCAT-AP HVD 2.2.0,
• más las especificaciones adicionales del perfil español (convenciones, propiedades ampliadas, etc.),

no solo el mínimo obligatorio. Por eso, en el YAML hemos incorporado también propiedades recomendadas y opcionales (provenance, identificadores enriquecidos, resoluciones, relaciones cualificadas, etc.), manteniendo la cardinalidad múltiple allí donde el modelo lo permite.

El efecto que vemos ahora mismo es:

• Los formularios de CKAN y la llamada
  /api/3/action/scheming_dataset_schema_show?type=dataset
  reflejan correctamente el YAML extendido (todos los campos aparecen en la definición de esquema).
• El RDF descargado vía .rdf sigue, sin embargo, el alcance del perfil es_dcat_ap_2.py: los campos añadidos (por ejemplo, los de adms:Identifier enriquecido o parte de dct:provenance) no se serializan. En algunos casos, como dct:provenance, al configurarlo como lista (para respetar la cardinalidad múltiple del modelo) el perfil actual espera un único literal y el plugin termina lanzando un error 500.

Estaríamos encantados de compartir el YAML extendido y un ejemplo de respuesta de la Action API para un dataset de prueba, por si resulta útil para valorar:

• si tiene sentido ampliar el propio es_dcat_ap_2.py para alinearlo con el es_dcat_ap_full.yaml actual, o
• si preferís definir un perfil adicional (por ejemplo, es_dcat_ap_full) y dejar el actual como mínimo de compatibilidad.

Nos ayudaría saber si contempláis alguna de estas opciones a medio plazo o si deberíamos asumir que cada organismo tendrá que mantener su propia extensión del perfil de serialización.
Adjunto en la issue el es_dcat_ap_full.yaml actual y el JSON de la llamada a la API scheming_dataset_schema_show.json, que reflejan correctamente el YAML extendido.

---

4) Issues en ckanext-schemingdcat

Gracias también por revisar las issues de DCAT-AP-ES.

En paralelo a esta discusión hemos abierto la issue:

mjanez/ckanext-schemingdcat#151

donde hemos incluido el YAML relevante y el patrón concreto de access_services + vCard que nos está dando problemas, así como los síntomas en la UI (datos que se introducen pero no se almacenan). Si puedes reproducirlo y confirmarnos si se trata de un bug o de una limitación de diseño de scheming, nos ayudará a decidir si aplicar un parche local o esperar a una corrección en el plugin.

---

5) Guía de migración y stack de referencia CKAN/DCAT-AP-ES

Hemos revisado también la “Guía para migrar a DCAT-AP-ES” (octubre 2025). Es muy útil para catálogos que ya exponen RDF NTI-RISP (2013) y necesitan evolucionar al perfil DCAT-AP-ES mínimo: describe muy bien los ajustes imprescindibles para federar con datos.gob.es y data.europa.eu y cómo ir incorporando progresivamente servicios, puntos de contacto y HVD.

En nuestro escenario el reto es algo distinto: estamos desplegando un CKAN base unificado, propuesto a todos los organismos, y un conversor que conecta directamente las fuentes internas con DCAT-AP-ES (incluyendo HVD y contactPoint). Por tanto, la pregunta clave es más de “stack de referencia” que de migración de RDF:

• qué combinación de versiones de CKAN,
• con qué versiones de ckanext-dcat / ckanext-scheming / ckanext-schemingdcat,
• y con qué perfiles activos (es_dcat, es_dcat_ap_2, etc.),

consideráis hoy alineada con DCAT-AP-ES 1.0.0 + Convenciones vigentes y con el funcionamiento del catálogo nacional.

Sabemos que el portal datos.gob.es está en producción sobre CKAN + Drupal y que la federación desde múltiples CKAN de organismos funciona bien, lo que indica que internamente disponéis ya de un stack y unos perfiles actualizados. Sin embargo, desde fuera:

• los repositorios públicos relacionados con el portal llevan aproximadamente tres años sin cambios en la parte CKAN, y
• hay issues abiertas por otras personas preguntando precisamente por nuevas versiones e imágenes actualizadas.

Para proyectos como el nuestro, que deben desplegar el conversor y CKAN en varios organismos de la AGE, sería de enorme ayuda disponer de:

• una referencia pública actualizada del stack recomendado (versiones de CKAN, extensiones, perfiles de serialización, configuración de cosecha y endpoints RDF), o
• al menos una indicación clara de qué partes del stack del portal nacional están por delante de lo disponible en GitHub y se prevé publicar más adelante.

Si en algún momento podéis publicar una actualización del repositorio de datos.gob.es para la parte CKAN o un pequeño “bundle” de configuración DCAT-AP-ES para CKAN (aunque sea marcado como baseline susceptible de adaptación), lo tomaríamos como referencia para nuestro despliegue y, en la medida de lo posible, podríamos devolver mejoras, PRs o casos de prueba desde el proyecto GDDP.

---

De nuevo, muchas gracias por la respuesta y por la disposición a revisar tanto los plugins como las issues. Todo lo que vayáis aclarando o publicando lo incorporaremos al diseño del conversor para que nazca ya alineado con el modelo DCAT-AP-ES y con la federación del catálogo nacional.

[dportoles]

Hola @alonsomarcosm99 , gracias por tus aportaciones. Para ir avanzando, comento de algunos apartados, a partir de tus consideraciones

1) dcat:DataService HVD y patrón de modelado

Entendemos que esta combinación (un dcat:DataService “global” más otros servicios específicos por dataset, todos correctamente enlazados mediante dcat:accessService y/o dcat:servesDataset) también es conforme siempre que cada HVD tenga al menos un servicio de datos que cumpla las convenciones HVD. ¿Lo estamos interpretando correctamente?

Exacto, se está interpretando correctamente. De hecho es como está ahora mismo hecho los HVD de MITECO y el INE en el catálogo nacional.

5) Guía de migración y stack de referencia CKAN/DCAT-AP-ES

Comentarte en primer lugar que se espera que el código del portal se actualicen y publiquen en las próximas semanas.

Además, comentas que:

una referencia pública actualizada del stack recomendado (versiones de CKAN, extensiones, perfiles de serialización, configuración de cosecha y endpoints RDF), o

Se tendrá en consideración para la generación de materiales de referencia pero hay que destacar también que deberá estar conforme al principio de neutralidad tecnológica, según el cual no procede el recomendar unas versiones o productos comerciales concretos frente a otros.