A validation report is evidence about declared constraints, not a certificate that the world is true
SHACL compares an RDF data graph with a shapes graph. It identifies focus nodes, applies constraints and returns a report whose results can be inspected, reproduced and governed.
Linked data can parse perfectly while still omitting a required identifier, using a value of the wrong datatype or linking an entity through an unexpected path. SHACL makes those structural expectations explicit as RDF shapes and produces machine-readable validation evidence.
The discipline lies in reading the report narrowly. A conforming graph satisfies the activated shapes under the chosen engine and settings. It does not prove factual accuracy, lawful processing, scientific validity or fitness for every use.
Chapter contents
- 1. Separate the data graph from the shapes graph
- 2. Define targets and focus nodes deliberately
- 3. Distinguish node shapes, property shapes and value nodes
- 4. Read validation reports and severities without flattening them
- 5. Worked example: validate one dataset description
- 6. Use constraint components as reusable evidence
- 7. Control targets, inference and execution options
- 8. Turn results into repair workflows without damaging data
- 9. Preserve validation provenance and regression evidence
- 10. Publish conformance claims with explicit boundaries
Choose a reading route
- Route 1: Frame validation — data graphs, shapes graphs and scope
- Route 2: Read results — focus nodes, paths and severities
- Route 3: Work a report — constraints, evidence and repair
- Route 4: Govern execution — targets, inference and versions
- Route 5: Publish trust — provenance, regression and limits
How to use this guide
Start with the chapters that match your immediate decision, then return to the worked example and audit chapters. Each chapter separates a model from the evidence needed to use it responsibly. A claim is not strengthened merely by being technical; it is strengthened when assumptions, observations, alternatives and limits can be inspected.
| Layer | Question | Minimum record |
|---|---|---|
| Concept | What exactly is being represented? | Definitions and boundary |
| Method | How will the reasoning be carried out? | Steps, inputs and assumptions |
| Transfer | Would it work in a changed setting? | A deliberately altered case |
| Audit | What could prove it wrong? | Evidence, limits and revision trigger |
Chapter 1. Separate the data graph from the shapes graph
The idea
The data graph contains the RDF being assessed. The shapes graph contains the conditions used for assessment. They may share vocabularies, but they play different roles and should be identified separately in the record.
A disciplined method
Freeze or identify both graphs, record their formats and base IRIs, load them through the same documented RDF dataset rules and retain the exact shapes version used for the run.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is which triples are evidence under test and which triples define the test. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A catalogue record is the data graph; a profile requiring one title and one issued date is the shapes graph. The validator reports on the catalogue record, not on the shape definition as if it were data.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Move a vocabulary definition into an imports graph and decide explicitly whether it participates in validation or only supplies entailment.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: Engines differ in graph loading, imports and inference behaviour; an unspecified execution environment can change the result.
Evidence to retain: data graph digest, shapes graph digest, parser, base IRI, imports policy, engine and run time
Common misconception: A shapes graph is simply another copy of the data graph.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 2. Define targets and focus nodes deliberately
The idea
Targets determine which RDF terms become focus nodes for a shape. A focus node is the node against which that shape is evaluated; it is not necessarily the value that caused a failure.
A disciplined method
Use explicit target nodes, target classes, subjects-of or objects-of only when they match the profile. List the selected focus nodes before interpreting results and test empty-target cases.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is which nodes enter the validation scope and why. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A PersonShape targets instances of ex:Person. Alice becomes a focus node; her malformed birth date may be the value node mentioned by the result.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Remove the rdf:type triple and see whether Alice silently leaves scope; add a subjects-of target if the profile intends to validate anyone using ex:birthDate.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: A graph can conform because no focus nodes were selected. Targeting every subject can also create noisy, misleading failures.
Evidence to retain: target declarations, selected focus nodes, counts, exclusions and test fixtures
Common misconception: Every node mentioned in the data graph is automatically validated by every shape.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 3. Distinguish node shapes, property shapes and value nodes
The idea
A node shape applies constraints directly to focus nodes. A property shape follows a path from each focus node and constrains the resulting value nodes or value set.
A disciplined method
For every result, recover the source shape, focus node, result path and value when present. Read the property path before assuming which triple should change.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is whether the violated condition concerns the focus node itself or values reached through a path. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A property shape on ex:email reaches two literals from Alice and violates maxCount 1. Alice is the focus node; the email literals are values; ex:email is the result path.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Replace a simple predicate with an alternative or sequence path and trace which triples feed the same constraint.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: Complex paths can make repair non-obvious, and a reported value may be absent for cardinality failures.
Evidence to retain: source shape, component, focus node, path, values and relevant triples
Common misconception: The value displayed in a result is always the focus node.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 4. Read validation reports and severities without flattening them
The idea
A SHACL validation report states whether the data graph conforms and may contain one or more validation results. Each result can carry severity, message, source shape, constraint component, focus node, path and value.
A disciplined method
Preserve the RDF report, group results by source shape and focus node, distinguish Violation, Warning and Info, and document the policy that converts severities into an acceptance decision.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is which severities affect conformance in this workflow and which remain advisory. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A missing identifier is a Violation, a deprecated term is a Warning and a style suggestion is Info. The pipeline blocks only on the first, while retaining all three.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Change the governance rule so warnings block a regulated release and publish that rule version rather than changing the report.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: Severity is assigned by shapes authors and does not measure real-world harm. Duplicate-looking results can arise from distinct constraints.
Evidence to retain: report graph, conforms flag, result count, severity policy, messages and acceptance decision
Common misconception: Warnings never matter because only violations can be serious.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 5. Worked example: validate one dataset description
The idea
A small example should connect a declared profile, activated targets, constraint evaluation, the report and a bounded repair. Hand inspection makes the meaning of each report term visible.
A disciplined method
Validate a fictional dataset node that must have exactly one string title, at least one creator IRI and one issued date. Introduce one missing creator and one invalid date, run the validator and reconcile every result with the graph.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is which evidence shows the validator tested the intended node under the intended shape. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
The report names ex:dataset-17 as focus node. One result uses the creator property shape with minCount; another uses the issued path with datatype. After repair, a second report conforms and links back to the first run.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Allow several creators and a language-tagged title, then revise only the constraints whose policy changed.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: Passing the toy case does not prove the shapes cover all profile obligations or that the values are factually correct.
Evidence to retain: input graphs, expected results, actual reports, repair patch, rerun and reviewer sign-off
Common misconception: A green report proves that the metadata describes a real and trustworthy dataset.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
| Report field | Example | Interpretation |
|---|---|---|
| focus node | ex:dataset-17 | resource being evaluated |
| result path | dcterms:issued | route to constrained values |
| source shape | ex:IssuedShape | declared rule source |
| component | sh:DatatypeConstraintComponent | kind of failed constraint |
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 6. Use constraint components as reusable evidence
The idea
Core components such as class, datatype, node kind, cardinality, pattern, language and closed-shape constraints express recurring structural expectations. The component names the rule family; parameters on the source shape state the actual requirement.
A disciplined method
Record the component and parameter values, create passing and failing fixtures, and avoid translating a component into a broader claim than it tests.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is what exact condition was evaluated and with which parameter. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A pattern constraint checks the lexical form of an identifier. It does not verify that the identifier resolves, belongs to the claimed person or remains stable.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Replace the pattern with nodeKind IRI plus a separate link-checking process and compare the evidence each produces.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: Constraint combinations can interact; closed shapes may reject harmless extension properties; regexes can encode accidental policy.
Evidence to retain: component, parameters, fixtures, engine result and human interpretation
Common misconception: A datatype or pattern constraint establishes semantic correctness.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 7. Control targets, inference and execution options
The idea
Results depend on the graph presented to the engine and on optional entailment, imports, advanced features or custom functions. Reproducibility requires these choices to be part of the validation evidence.
A disciplined method
Declare the SHACL version and feature set, inference regime, imports policy, graph union rules, custom code, engine version and timeout behaviour. Test the same bundle in an independent environment where possible.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is which triples are explicit, inferred or produced by extensions during the run. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
With RDFS entailment, a subclass instance becomes a target-class focus node; without it, the same node is not selected. Both outcomes are explainable when the regime is recorded.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Move from a local engine to a hosted service and compare target counts, results and unsupported features.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: SHACL processors may implement optional features differently, and a timeout or engine error must not be reported as conformance.
Evidence to retain: configuration, feature support, inferred graph policy, logs, timeouts and comparison run
Common misconception: SHACL validation has one universal result independent of processor settings.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 8. Turn results into repair workflows without damaging data
The idea
A report identifies failed constraints; it does not always prescribe the correct repair. Deleting a value, inventing a placeholder or weakening a shape may make the report green while making the information worse.
A disciplined method
Classify each result as data error, mapping error, shape error, unsupported case or accepted exception. Propose a patch, review its meaning, apply it to a controlled version and rerun all relevant shapes.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is whether the repair improves the data or merely satisfies the test. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A missing birth date is not repaired with 1900-01-01. The workflow records an authorised absence or changes the profile if unknown values are valid.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Apply the same process to a closed shape that rejects a legitimate local extension; revise the shape instead of stripping the property.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: Automated repair can erase nuance, merge identities or create false facts; high-impact changes need domain review.
Evidence to retain: triage decision, patch, justification, reviewer, before-and-after graphs, regression report and exception
Common misconception: The fastest way to conformance is always the best repair.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 9. Preserve validation provenance and regression evidence
The idea
Validation is an event with inputs, software, settings, outputs and responsibility. Reports should remain traceable to the graph versions they assessed, especially when they support release or conformance claims.
A disciplined method
Assign identifiers to runs, hash or version graphs and shapes, record software and settings, link reports to releases, retain superseded reports and rerun after material changes.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is which run supports the current public claim and whether its inputs still match. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
Release 4 links to report R4, its shapes bundle and engine version. A later shapes update creates R4b without rewriting the historical record.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Discover an engine bug and revalidate affected releases, marking which claims were withdrawn or corrected.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: Provenance makes the process inspectable but does not itself show that the shapes were sufficient or impartial.
Evidence to retain: run identifier, timestamps, agents, graph digests, shapes version, engine, report, decision and corrections
Common misconception: The latest green report can replace all earlier reports without loss.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 10. Publish conformance claims with explicit boundaries
The idea
Conformance should name the profile, version, shapes, data graph scope, execution policy and unresolved exceptions. Human-readable summaries should link to the complete report rather than replace it.
A disciplined method
Publish a concise claim, report counts by severity, expose the RDF report, document excluded graphs and optional requirements, and state what was not tested.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is what a consumer may safely infer from the validation evidence. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A catalogue says its metadata graph conforms to profile P version 2 under shapes S, while link resolution and factual accuracy were reviewed separately.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Harvest only one distribution into another catalogue and narrow the claim to that representation.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: A profile may include prose requirements that shapes do not encode; external resources can change after validation.
Evidence to retain: profile, version, scope, report, exceptions, separate checks, validity period and contact
Common misconception: A conforms flag is a complete and permanent quality certificate.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Field workbook
Create a data graph with two focus nodes and a shapes graph with cardinality, datatype and node-kind constraints. Predict the results, run a validator, explain every report field, repair one data error, revise one shape error and preserve both reports with provenance.
- Write the decision question in one sentence and name the decision owner.
- List observations separately from interpretations, with dates and provenance.
- Record at least two plausible alternatives before choosing a preferred account.
- Run the changed-context test and note which assumptions fail.
- State the limit, confidence and next review trigger in plain language.
| Layer | Evidence | Failure signal |
|---|---|---|
| Scope | targets and focus-node list | empty or accidental target |
| Rule | source shape and parameters | vague message only |
| Execution | engine, options and graphs | irreproducible result |
| Claim | report plus stated boundary | green equals true |
Continue through the verified ecosystem
- Data Quality Vocabulary — measurements, annotations and conformance evidence
- Dataset distribution discovery — DCAT resources and access routes
- Content negotiation by profile — profile identification and representation selection
- PREMIS preservation evidence — events, agents, objects and audit trails
- ResourceSync — change, fixity and synchronisation
Frequently asked questions
What does SHACL validate?
It validates an RDF data graph against constraints and targets declared in a shapes graph under a specified execution environment.
What is a focus node?
It is a node selected for evaluation against a shape. A result value reached through a property path may be different.
Does a conforming report prove the data is true?
No. It supports a bounded structural-conformance claim, not factual accuracy, legality or universal fitness.
Can warnings be ignored?
Their effect depends on the workflow policy, but they should remain visible and their governance should be documented.
Why can two validators differ?
Graph loading, inference, optional features, custom functions, engine behaviour and version differences can alter scope or results.
Should every failed constraint be auto-repaired?
No. Some failures reveal shape errors, legitimate exceptions or missing knowledge; automatic edits can create false information.
Authoritative sources and further reading
- W3C: Shapes Constraint Language — core model, targets, constraints and validation reports
- W3C: SHACL Advanced Features — rules, functions, expressions and advanced targets
- W3C: SHACL Use Cases and Requirements — validation needs and design requirements
- W3C: RDF 1.1 Concepts and Abstract Syntax — graphs, nodes, literals and datasets
- W3C: PROV-O — entities, activities and agents for validation provenance
This guide explains SHACL validation evidence. It does not certify factual truth, legal compliance, accessibility, scientific validity, security or fitness for a particular decision unless those obligations are separately defined and tested.