Skip to content

feat(pipeline-shacl-validator): add conformanceDisallows severity set#564

Merged
ddeboer merged 1 commit into
mainfrom
feat/shacl-validator-severity-threshold
Jul 8, 2026
Merged

feat(pipeline-shacl-validator): add conformanceDisallows severity set#564
ddeboer merged 1 commit into
mainfrom
feat/shacl-validator-severity-threshold

Conversation

@ddeboer

@ddeboer ddeboer commented Jul 7, 2026

Copy link
Copy Markdown
Member

Adds an optional conformanceDisallows setting to ShaclValidator, implementing the SHACL 1.2 conformance-disallow set: the set of severity IRIs whose presence among validation results makes validation fail.

Why

shacl-engine’s report.conforms hardcodes the SHACL 1.2 default set – any sh:Violation, sh:Warning or sh:Info result fails validation. Consumers such as the Dataset Knowledge Graph want warnings to be advisory (SHOULD-level findings, including requirements staged via nde:futureChange), matching the Dataset Register’s violation-only semantics – see netwerk-digitaal-erfgoed/dataset-knowledge-graph#411. Other users do want warnings to fail validation, so the default is unchanged.

SHACL 1.2 models this as a set of disallowed severities rather than a “minimum severity”, since severities (including custom ones) have no normative ordering – an ordered threshold was explicitly rejected in w3c/data-shapes#453. The spec sanctions this option: “The conformance-disallow set is defined by the validation engine. A validation engine MAY provide mechanisms to customize this set.”

What

  • conformanceDisallows?: readonly string[] on ShaclValidatorOptions; defaults to the SHACL 1.2 default set (sh:Violation, sh:Warning, sh:Info), preserving existing behaviour. Custom severity IRIs are supported.
  • conforms and violations are computed from result severities against the set, instead of reading report.conforms (also fixing violations counting results the engine did not treat as non-conforming).
  • Reports are streamed to reportWriters whenever there are results – below-threshold results (e.g. warnings) stay visible to consumers even when the dataset conforms.
  • Forward support for SHACL 1.2 ahead of the engine: when the option is set, the written report carries sh:conformanceDisallows triples and an sh:conforms recomputed against the set, keeping stored reports self-describing.
  • Exports a severity constant with the three SHACL Core level IRIs.

@ddeboer ddeboer force-pushed the feat/shacl-validator-severity-threshold branch 3 times, most recently from 390b61b to ac8b2e6 Compare July 8, 2026 07:43
- Add a conformanceDisallows option implementing the SHACL 1.2
  conformance-disallow set: a result fails validation only if its
  severity IRI is in the set, with custom severities supported
- Default to the SHACL 1.2 default set (Violation, Warning, Info),
  preserving existing behaviour when the option is absent
- Compute conforms and violations from result severities instead of
  report.conforms, which hardcodes the default set in shacl-engine
- Stream reports to writers whenever there are results, so
  below-threshold results such as warnings stay visible to consumers
- Amend written reports with sh:conformanceDisallows triples and a
  recomputed sh:conforms when the option is set, as forward support
  for SHACL 1.2 ahead of engine support
- Export severity constants for the three SHACL Core levels
@ddeboer ddeboer force-pushed the feat/shacl-validator-severity-threshold branch from ac8b2e6 to 50a5723 Compare July 8, 2026 07:48
@ddeboer ddeboer merged commit d02ed4a into main Jul 8, 2026
2 checks passed
@ddeboer ddeboer deleted the feat/shacl-validator-severity-threshold branch July 8, 2026 07:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant