Modelo - SHACL 1.0.0 Case 1 no ejecuta con pySHACL por sh:uniqueLang en NodeShape y patrón regex (?s)

[jjalcolea]

Tipo de incidencia

• Error en la definición de una propiedad
• Inconsistencia en el modelo de datos
• Problema de compatibilidad con DCAT-AP
• Ambigüedad en la interpretación
• Problema de implementación
• Otro (especificar)

Elemento afectado

• Clase/Propiedad: sh:uniqueLang, sh:pattern, :UniqueLangLiteralRestriction, :NonEmptyLiteralConvention
• Ubicación en el perfil:
  • shacl/1.0.0/shacl_common_shapes.ttl
  • :UniqueLangLiteralRestriction
  • :NonEmptyLiteralConvention
  • Perfil DCAT-AP-ES 1.0.0, validación Case 1

Situación actual en DCAT-AP-ES

Al ejecutar las shapes oficiales DCAT-AP-ES 1.0.0 Case 1 con pySHACL, la validación no llega a producir un informe SHACL porque falla durante la carga/ejecución de las shapes.

Se han detectado dos puntos en shacl_common_shapes.ttl:

1. Patrón regex:

sh:pattern "^(?s)(?=.*\\S).*$" ;

2. Uso de sh:uniqueLang en una sh:NodeShape:

:UniqueLangLiteralRestriction
    a sh:NodeShape ;
    ...
    sh:uniqueLang true ;

Problema detectado

Con pySHACL==0.40.0 y Python 3.12, el patrón regex produce primero:

global flags not at the start of the expression at position 1

Si se corrige localmente solo en memoria el patrón anterior a:

sh:pattern "(?s)^(?=.*\\S).*$" ;

la ejecución avanza, pero después falla con:

ConstraintLoadError: UniqueLangConstraintComponent can only be present on a PropertyShape, not a NodeShape.
For reference, see https://www.w3.org/TR/shacl/#UniqueLangConstraintComponent

Por tanto, la validación Case 1 no puede ejecutarse con pySHACL sobre las shapes oficiales sin una adaptación previa.

Evidencia

Entorno probado:

DCAT-AP-ES: 1.0.0
Commit: 324866f491cf4adf8a47a75f1a8a40db010310c0
Caso: Case 1
Python: 3.12
pySHACL: 0.40.0
rdflib: 7.6.0

Shapes utilizadas:

shacl/1.0.0/shacl_common_shapes.ttl
shacl/1.0.0/shacl_catalog_shape.ttl
shacl/1.0.0/shacl_dataservice_shape.ttl
shacl/1.0.0/shacl_dataset_shape.ttl
shacl/1.0.0/shacl_distribution_shape.ttl
shacl/1.0.0/shacl_mdr-vocabularies.shape.ttl

Fragmento afectado:

@prefix sh: <http://www.w3.org/ns/shacl#> .

:UniqueLangLiteralRestriction
    a sh:NodeShape ;
    sh:uniqueLang true ;
    sh:message "Más de un valor comparten la misma etiqueta de idioma. Ver: https://datosgobes.github.io/DCAT-AP-ES/convenciones/#convencion-02"@es ;
    sh:message "More than one value shares the same language tag. See: https://datosgobes.github.io/DCAT-AP-ES/conventions/#convention-02"@en ;
    sh:severity sh:Violation .

Error observado:

ConstraintLoadError: UniqueLangConstraintComponent can only be present on a PropertyShape, not a NodeShape.

Posible Solución

Revisar las shapes oficiales para que sean ejecutables con motores SHACL estándar como pySHACL.

En concreto:

1. Cambiar el patrón:

sh:pattern "^(?s)(?=.*\\S).*$" ;

por:

sh:pattern "(?s)^(?=.*\\S).*$" ;

2. Revisar :UniqueLangLiteralRestriction, ya que sh:uniqueLang parece estar definido sobre una sh:NodeShape, mientras pySHACL lo acepta únicamente en sh:PropertyShape.

También sería útil documentar explícitamente qué motor SHACL y versión se considera soportado/recomendado para validar DCAT-AP-ES 1.0.0.

Ejemplo de Implementación Correcta

Para el caso del patrón regex:

:NonEmptyLiteralConvention
    a sh:NodeShape ;
    sh:nodeKind sh:Literal ;
    sh:minLength 1 ;
    sh:pattern "(?s)^(?=.*\\S).*$" ;
    sh:severity sh:Violation .

Para sh:uniqueLang, no propongo un cambio cerrado porque puede requerir una decisión semántica sobre cómo reutilizar la restricción común. La expectativa sería que sh:uniqueLang true quede en una sh:PropertyShape o se modele mediante una restricción equivalente compatible con SHACL.

Información Adicional

La incidencia se detectó durante un piloto de validación DCAT-AP-ES en el que:

• el RDF generado parseaba correctamente;
• no había URLs internas/locales en el RDF;
• las shapes oficiales se descargaron desde el commit indicado y se verificaron por hash;
• la validación SHACL no pudo completarse por los errores anteriores.

El bloqueo impide obtener un informe de conformidad SHACL, por lo que no permite distinguir si el RDF validado es conforme o no conforme: la ejecución se detiene en la carga/validación de las propias shapes.

[jjalcolea]

Hemos ampliado la prueba de compatibilidad con un segundo motor SHACL, usando exactamente la misma entrada RDF y las shapes oficiales de DCAT-AP-ES sin modificaciones.

Línea base probada

• DCAT-AP-ES: 1.0.0

• Caso de validación: Case 1

• Commit upstream: 324866f491cf4adf8a47a75f1a8a40db010310c0

• SHA-256 del bundle combinado de shapes oficiales:

  0e78323cc7a7b556a8a6ea7f3fb5980986f24ca229299235bbef1c2126cac07f

• SHA-256 del RDF/XML:

  eb3536f1eb02abaaa948072cebb70fffcb03a83491803bd9d0d85b05cd866c9c

• SHA-256 del Turtle:

  4809eeede3ed01fc100c56fd88494aa14f395fb4f02211f795576c1d4043bedf

Resultados

pySHACL 0.40.0

Las shapes fallan durante la carga, antes de que pueda generarse un sh:ValidationReport:

shape_load_error
global flags not at the start of the expression at position 1

Apache Jena SHACL 6.1.0

Jena también falla al cargar las shapes oficiales, antes de validar el RDF:

shape_load_error
ShaclParseException: More than one match ... sh:message

Por tanto, el problema no parece limitado a pySHACL. Dos motores SHACL diferentes, documentados como opciones válidas de validación, rechazan las shapes oficiales intactas antes de producir un informe de validación.

¿Podríais confirmar, por favor:

1. Qué motor SHACL y qué versión se utilizaron para validar las shapes publicadas de DCAT-AP-ES 1.0.0.
2. Si existe un bundle corregido o más reciente para el Case 1.
3. Si se espera algún paso previo de preprocesado o normalización antes de cargar las shapes.
4. Qué motor debe considerarse implementación de referencia para la validación oficial de DCAT-AP-ES.

[eminguel]

Mirando los shacl, el patron sh:pattern "^(?s)(?=.\S).$" ; no aparece en la última versión de shacl_common_shapes.ttl. Sí parece que estuvo así hasta aproximadamente octubre de 2025.

[jjalcolea]

Muchas gracias por la aclaración. Hemos comprobado que el commit utilizado corresponde a la etiqueta oficial 1.0.0, creada el 14 de abril de 2025. Sin embargo, los ficheros de main/shacl/1.0.0/ han recibido correcciones posteriores, incluidas modificaciones de octubre de 2025, sin que aparentemente se haya publicado una nueva etiqueta o versión.

Para validaciones reproducibles y de producción, ¿debemos considerar como referencia oficial la etiqueta Git 1.0.0 o el contenido actual de main/shacl/1.0.0/? En caso de ser este último, ¿existe algún commit posterior concreto que recomienden fijar?

¡Gracias!