SHACL-AF Non-Blocking Data-Quality Rules
Context
A pattern has emerged across four kind: pattern ODRs ratified through 2026-05-27: each authored a SHACL-AF rule (sh:rule / sh:sparql) that materialises a non-blocking data-quality assertion — succession, deprecation, lineage — into the validation report at sh:Info or sh:Warning severity, NOT as sh:Violation. The data being asserted is correct under its temporal or contextual scope (UPRN succession is administrative; deprecation is a lifecycle state; INSPIRE succession is rare-but-real); the rule is informative, not normative-breaking.
The four citing sites:
- ODR-0005 §6a — UPRN succession chain (Cagle Q4 amendment, S005). Materialises
opda:previousUPRN→opda:uprnchain atsh:Info; rebuts Hellmann et al. (DBpedia 2017) LLM-fallback-to-owl:sameAsfailure mode for identifier succession. - ODR-0009 (Claims, Evidence & Provenance — when S009 runs). Anticipated: PROV-O Activity reification +
prov:wasDerivedFromchain materialisation for evidence-collection events. - ODR-0015 §4a — INSPIRE Identifier / OS AddressBase succession (S015 Q4); re-instantiates the §6a pattern for the Address Kind’s contingent identifier (per S005’s Quality-on-Substance-Kind precedent).
- ODR-0011 §5a — Concept deprecation-chain (Cagle Q5 amendment, S011). Materialises
owl:deprecated true+dct:isReplacedBychain atsh:Info(with-succession) orsh:Warning(without-succession).
Per ODR-0001 A9 §Artefact identity test — the fourth-citing-site threshold for pattern-extraction is satisfied. S011 §Consequences flagged the spawn-rule as fired. This ODR extracts the pattern as a reusable artefact-engineering decision; the four citing sites become implements: of it; future SHACL-AF rule authoring re-instantiates the pattern rather than re-deciding the discipline per ODR.
The pattern is kind: pattern per ODR-0001 A9 §What an ODR records (a)/(b)/(c) discipline: UFO/DOLCE meta-category (Method/plan code per ODR-0011 §8a — the rule is a procedural plan for materialising data-quality assertions), IC over named hard cases (rule severity; rule placement in graph; rule consumption by tooling), artefact realisation (sh:rule / sh:sparql SHACL-AF Turtle template).
Decision
The diagram below illustrates how a SHACL-AF non-blocking rule routes a data-quality assertion to sh:Info/sh:Warning rather than sh:Violation, contrasting it with ordinary normative-blocking SHACL constraints.
(succession / deprecation / lineage)"]:::process A --> B{"Normative-breaking?
Would corrupt downstream?"}:::warning B -->|"yes"| C["sh:Violation
(SHACL Core constraint)"]:::error B -->|"no — informative only"| D{"Substantive succession
recorded?
(prov:wasDerivedFrom /
dct:isReplacedBy present)"}:::warning D -->|"yes"| E["sh:Info
(SHACL-AF rule in
opda-shapes.ttl)"]:::success D -->|"no"| F["sh:Warning
(SHACL-AF rule in
opda-shapes.ttl)"]:::success E --> G["ValidationReport entry
— machine-parseable
sh:resultMessage"]:::process F --> G
Adopt the SHACL-AF non-blocking data-quality rules pattern as the canonical mechanism for materialising data-quality assertions that are informative, not normative-breaking: a sh:rule (or sh:sparql form) on the targeted class, returning the assertion’s value via SELECT $this ?fact …, with sh:severity sh:Info (state-with-substantive-succession) or sh:Warning (state-without-succession), placed in the shapes graph (opda-shapes.ttl per ODR-0004 §3a). The rule’s output is machine-consumable data — read by SHACL validators, LLM tooling (per Hellmann et al. DBpedia 2017 LLM-fallback rebuttal), odr-review lint extensions, audit-trail consumers. The rule is never sh:Violation severity (Violation is reserved for normative-breaking; the assertions this pattern materialises are correct under their temporal/contextual scope).
Rules
These rules constrain every implements: of this pattern.
sh:ruleorsh:sparqlform. The rule is authored as either ash:Rule(SHACL Advanced Features Recommendation §2) or ash:sparqlconstraint withsh:selectbody (SHACL Core §5.2.6 SPARQL-based constraints). Both forms admissible; choice depends on whether the materialised triples need to enter the data graph (usesh:Rule) or only the validation report (usesh:sparql).- Severity at
sh:Infoorsh:Warning, NEVERsh:Violation. The data is correct; the rule is informative.sh:Infofor assertions with substantive succession recorded (prov:wasDerivedFrom/dct:isReplacedBychains present).sh:Warningfor assertions without substantive succession (deprecation-without-replacement; retirement-without-successor). - Placement in shapes graph (
opda-shapes.ttl). Per ODR-0004 §3a three-graph separation, the rule lives in the shapes graph, NOT the annotation graph (opda-annotations.ttl). The CI testASK { GRAPH opda:annotations { ?s a sh:NodeShape } }returns false; this rule’ssh:NodeShapedeclaration is inopda:shapes. SELECT $this ?fact ?successionSPARQL skeleton. The rule’s SPARQL body returns at minimum the target node ($this) and the materialised assertion. Thesh:messagetemplate references the captured variables for human-readable reporting AND machine-readable downstream parsing.sh:messageis machine-parseable. The message template uses{?var}placeholders that the SHACL validator interpolates; downstream tooling (LLM consumers, lint extensions) parses the rendered message to extract the structured assertion. AVOID natural-language paragraphs insh:message; PREFER structured key-value or template-literal form.- No
owl:sameAsmaterialisation. A non-blocking data-quality rule MUST NOT produceowl:sameAstriples (inherits ODR-0005 Rule 5 anti-pattern —owl:sameAspropagates irreversibly under reasoning). Materialise viaprov:wasDerivedFrom,dct:isReplacedBy,skos:exactMatch, oropda:identifiesSamePropertyper the consuming ODR’s discipline. - Consuming ODR cites this pattern via
implements:. Each consuming ODR declaresimplements: [..., ODR-0017]in its frontmatter (alongside its otherimplements:of ODR-0003). The## Referencessection cites this ODR’s pattern URL for the authoring discipline.
Operational specifications
1a. Canonical template (SHACL-AF rule form)
opda:<DomainQuality>NonBlockingRule a sh:NodeShape ;
sh:targetClass <opda:TargetKind> ;
sh:sparql [
sh:select """
SELECT $this ?currentFact ?priorFact WHERE {
$this <opda:currentPredicate> ?currentFact .
OPTIONAL { $this <opda:priorPredicate> ?priorFact }
}
""" ;
sh:severity sh:Info ; # sh:Warning if no substantive succession
sh:message "{$this} <opda:domain-quality-relationship> {?currentFact} ← {?priorFact} (where defined)"
] .
Per ODR-0004 §3a three-graph separation: the rule sits in opda-shapes.ttl; the data graph (e.g. opda-instances.ttl or per-Property graphs) carries the data the rule reads; the validation report is the rule’s output channel.
2a. Three-tier severity decision rule
| Rule fires | Severity | Use case |
|---|---|---|
Quality state with substantive succession (prov:wasDerivedFrom / dct:isReplacedBy chain present + dereferenceable predecessor) | sh:Info | UPRN succession with reified event (ODR-0005); deprecation-with-successor (ODR-0011); INSPIRE feature re-issue (ODR-0015) |
| Quality state without substantive succession (deprecation/retirement standalone; lineage absent) | sh:Warning | EPC band retirement without replacement (hypothetical ODR-0011 case); orphan UPRN (rare) |
| Quality state under normative-breaking (would corrupt downstream consumer) | NEVER this pattern | Use ordinary sh:Violation SHACL Core constraint instead — the assertion is normative, not informative |
The following flowchart traces the evaluation path of a single SHACL-AF rule instance from the shapes graph through the validator to its downstream consumers.
sh:NodeShape + sh:sparql
sh:severity sh:Info/sh:Warning"]:::process D["opda-instances.ttl
(data graph)"]:::process S --> V["SHACL-AF validator
executes SELECT query
against data graph"]:::process D --> V V --> R["sh:ValidationReport
sh:resultMessage (structured template)
sh:focusNode / sh:resultSeverity"]:::success R --> C1["SHACL validators
(sh:ValidationReport triples)"]:::process R --> C2["odr-review lint
(verifies severity, placement,
message template)"]:::process R --> C3["LLM tooling
(parses sh:resultMessage;
substitutes rdfs:comment fallback)"]:::process R --> C4["Audit-trail consumers
(data-quality lineage records)"]:::process
3a. Machine-consumability requirement
Per Hellmann et al. (DBpedia 2017) LLM-fallback rebuttal (Cagle S005 §6a + S011 §5a citations): the rule’s output MUST be machine-parseable by:
- SHACL validators (the canonical consumer — produces
sh:ValidationReporttriples; consumer queriessh:resultMessageandsh:focusNode). odr-reviewlint extensions — reads the rule’s source fromopda-shapes.ttl; verifies severity is in {sh:Info,sh:Warning} (rejectssh:Violation); verifies placement in shapes graph; verifiessh:messagetemplate uses placeholder form.- LLM tooling — queries the validation report for
sh:resultMessageliterals; parses the structured template form for the non-blocking-quality assertion content; substitutes the assertion forrdfs:comment-based natural-language fallback (which Hellmann et al. documented as failing on rename/paraphrase/translation). - Audit-trail consumers — read the
sh:Info/sh:Warningentries as data-quality lineage records; correlate with the data graph’s reified event resources.
4a. UFO/DOLCE meta-category — Method/plan code (A9 (a) discharge)
Per ODR-0011 §8a’s seven-category UFO framework, this pattern is a Method/plan code — the SHACL-AF rule is a procedural plan for materialising a data-quality assertion into the validation report. The plan is reusable across domains (UPRN succession; deprecation; INSPIRE re-issue; future Person-ID succession). The plan’s executor is the SHACL-AF-aware validator (the canonical consumer); other consumers (lint, LLM, audit) read the executed plan’s output.
dct:source on the UFO category: Guizzardi & Wagner 2010 (action-modelling / method-codes in UFO-A) + Guizzardi 2005 Ch. 4 + ODR-0011 §8a (Council-authored SKOS-binding) + ODR-0017 (this pattern’s plan-code specialisation).
5a. IC over named hard cases (A9 (b) discharge)
A SHACL-AF non-blocking-data-quality rule r₁ at time t₁ and a candidate-individual rule r₂ at time t₂ > t₁ are the same individual iff (i) their sh:targetClass is the same; (ii) their sh:select SPARQL body is structurally equivalent (same WHERE-clause patterns modulo variable renaming); (iii) their severity is the same. Under the following hard cases:
- Rule extension. A rule’s SPARQL body gains a new OPTIONAL clause without changing the existing patterns → same individual (extension preserves identity).
- Severity adjustment. A rule’s severity changes between
sh:Info↔sh:Warning→ same individual (severity tier is a refinement, not an identity change). Severity changing tosh:Violation→ rule ceases to exist under this pattern; a new (non-pattern) SHACL constraint replaces it. - Target-class change. Rule’s
sh:targetClasschanges → new individual;prov:wasDerivedFromchains the new rule to the predecessor. - Message-template refinement. The
sh:messagetemplate is rephrased without changing variable references → same individual. - Graph relocation. Rule moves from one shapes graph to another (e.g. extracted from one ODR’s profile shapes into a shared shapes module) → same individual; the move is
dct:isReplacedBy(in the OLD location’s deprecation) +prov:wasGeneratedBy(in the new location’s instantiation).
6a. Artefact realisation (A9 (c) discharge)
The artefact realisation is the Turtle SHACL-AF rule above (§1a), placed in opda-shapes.ttl per ODR-0004 §3a. The rule is emitted by the generator (per ODR-0004 §6a deterministic-emission discipline) reading from a rule-source declaration; the rule’s structure follows the §1a template; the generator MAY parameterise the rule via inputs (target-class, predicates, severity) so each implements: site supplies only the parameters, not the full Turtle.
Alternatives
The diagram below maps each considered alternative to the decision driver that disqualified it, with the chosen pattern shown as the accepted outcome.
(opda-annotations.ttl)"]:::error A2["Alt: OWL property chains
(owl:propertyChainAxiom)"]:::error A3["Alt: rdfs:comment only"]:::error A4["Alt: bake into each
consuming ODR (no extraction)"]:::error A1 -->|"Rejected: ODR-0004 §3a
CI test 1 — SHACL in
annotation graph breaks
three-graph separation"| X{"Driver check"}:::warning A2 -->|"Rejected: ODR-0005 Rule 5
irreversible owl:sameAs
propagation under reasoning"| X A3 -->|"Rejected: Hellmann et al. 2017
LLM fallback failure on
rename/paraphrase/translation"| X A4 -->|"Rejected: ODR-0001 A9
fourth-citing-site threshold —
four divergent rule authorings"| X X --> C["Chosen: SHACL-AF sh:rule/sh:sparql
in opda-shapes.ttl
sh:Info / sh:Warning severity
machine-parseable sh:message"]:::success
- Materialise data-quality assertions in the annotation graph (
opda-annotations.ttl). Rejected per ODR-0004 §3a CI test 1 (ASK { GRAPH opda:annotations { ?s ?p ?o . FILTER(STRSTARTS(STR(?p), "shacl-prefix")) } }must return false). SHACL rules in the annotation graph break the three-graph separation; LLM consumers querying the annotation graph would receive shape-graph content as if it were advisory annotations, corrupting both layers. - Use OWL reasoning +
owl:propertyChainAxiomto materialise the succession chain. Rejected per ODR-0005 Rule 5 anti-pattern (noowl:sameAs-equivalent propagation across contexts). OWL property chains produce inferred triples that propagate irreversibly under reasoning; the use case is informative materialisation, not normative-equivalence assertion. - Encode the data-quality assertion in
rdfs:commentonly. Rejected per Hellmann et al. (DBpedia 2017) LLM-fallback failure mode — natural-languagerdfs:commentis consumed by LLM heuristics, which fail on rename/paraphrase/translation. The structured SHACL-AF rule is the mechanically-readable substitute. - Bake the rule into each consuming ODR without
pattern-extraction. Rejected by ODR-0001 A9 §Artefact identity test fourth-citing-site threshold — the pattern has crossed the threshold for shared abstraction; baking it into each ODR creates four parallel-but-divergent rule authorings, and a future maintainer cannot extract the common discipline.
Consequences
- Four-site
implements:retrofitting. ODR-0005 §6a, ODR-0009 (when S009 ratifies its PROV-O rule), ODR-0015 §4a, ODR-0011 §5a all addODR-0017to theirimplements:frontmatter and cite this pattern in their## References. The retrofit is a follow-up author-only edit; flagged as housekeeping for the next /loop fire or Queen-convened session. - A9 pressure-test continues to operate. This is the first
kind: patternODR that is itself a pattern-extraction record (not a domain-modelling pattern). The (a)/(b)/(c) discipline applies; this ODR discharges all three (Method/plan code UFO category; five named hard cases for rule identity; Turtle template artefact). odr-reviewlint extension. Beyond the existing planned extensions (per ODR-0004 §Consequences), the lint should verify: any SHACL-AF rule declaringsh:Infoorsh:Warningseverity isimplements: ODR-0017; conversely, any ODRimplements: ODR-0017MUST place its SHACL-AF rule inopda-shapes.ttl(not annotation graph) AND MUST use the §1a template structure.- Future succession patterns. ODR-0006 (Agents & Roles, Phase 3a) may produce a fifth citing site (e.g. NI-number renumbering; passport-renewal succession for Person identity). When it does, ODR-0017 is the canonical pattern to
implements:; the new rule re-instantiates the template rather than re-deciding the discipline. - Namespace ratified; record
accepted. The inherited ODR-0004 namespace block is lifted (theopda:string was ratified 2026-05-27 — greenfield; no WG), so ODR-0017 isaccepted. Generator output for the rule’sopda:declarations may still carrydct:status "draft"as a publication-grade marker, independent of record ratification.
References
- Methodology: ODR-0001 §What an ODR records (per-kind discipline) — A9 amendment 2026-05-27; §Artefact identity test (the fourth-citing-site threshold this ODR satisfies); ODR-0011 §8a (Method/plan code UFO category source).
- Foundation: ODR-0004 §3a (three-graph separation — shape lives in
opda-shapes.ttl); §6a (generator-first deterministic-emission discipline). - W3C / spec: SHACL Core Recommendation §5.2.6 (SPARQL-based constraints); SHACL Advanced Features (
sh:rule,sh:Rule) — W3C Working Group Note; SHACL Core §6.5 (severity); PROV-O Recommendation (Moreau & Missier 2013); RDF 1.1 Semantics (Hayes & Patel-Schneider 2014) §6 (owl:sameAs). - Foundational ontology: Guizzardi 2005 Ontological Foundations Ch. 4 (UFO Method/plan codes); Guizzardi & Wagner 2010 (action-modelling).
- AI-RDF citation: Hellmann et al. 2017 DBpedia 2017 release notes — LLM fallback to
owl:sameAs/ heuristic class-name matching when assertions are inrdfs:commentonly. - Citing sites (
implements:retrofit pending):- ODR-0005 §6a — UPRN succession-chain rule (Cagle S005 Q4 amendment).
- ODR-0009 — PROV-O Claims/Evidence rule (anticipated when S009 ratifies).
- ODR-0015 §4a — INSPIRE / OS AddressBase succession (S015 Q4).
- ODR-0011 §5a — Concept deprecation-chain rule (Cagle S011 Q5 amendment).
- Council deliberation provenance: spawned by session-011 §Synthesis + §Consequences (fourth-citing-site spawn-rule fires); authored as Author-only follow-up to S011’s closure per ODR-0001 §Self-amendment process + §Artefact identity test.
- Related ODRs: programme anchor ODR-0003; methodology ODR-0001 §What an ODR records (per-kind discipline for
kind: pattern).
The graph below shows ODR-0017’s dependency and implementing relationships as declared in the frontmatter.
SHACL-AF Non-Blocking
Quality Rules Pattern"]:::user ODR01["ODR-0001
Council Methodology"]:::process ODR04["ODR-0004
PDTF Ontology Foundation"]:::process ODR05["ODR-0005
Property-Land Identity"]:::process ODR03["ODR-0003
PDTF Ontology Programme"]:::process ODR05B["ODR-0005 §6a
(UPRN succession rule)"]:::success ODR09["ODR-0009
(Claims/Evidence — anticipated)"]:::success ODR11["ODR-0011 §5a
(Concept deprecation rule)"]:::success ODR15["ODR-0015 §4a
(INSPIRE succession rule)"]:::success ODR17 -->|"depends-on"| ODR01 ODR17 -->|"depends-on"| ODR04 ODR17 -->|"depends-on"| ODR05 ODR17 -->|"implements"| ODR03 ODR05B -->|"implements"| ODR17 ODR09 -->|"implements"| ODR17 ODR11 -->|"implements"| ODR17 ODR15 -->|"implements"| ODR17
Comments