What Is SHACL Validation?
SHACL (Shapes Constraint Language) is a standard for validating graph-based data. While an ontology defines the conceptual schema (the “what” exists in your domain), SHACL defines the structural rules and constraints (the “how” it should be structured). In Semantica,SHACLGenerator produces constraint rules (shapes) based on your ontology, and _run_pyshacl evaluates your actual data against these rules. If a node violates a rule (e.g., missing a required property or using the wrong datatype), a detailed violation report is generated.
Why Use SHACL Validation?
Data validation is critical before running analytics, exporting data, or feeding it into production models. SHACL acts as a data quality gate that ensures your graph data is structurally sound. Use it to catch:- Missing required properties (e.g., a customer without an email address).
- Datatype mismatches (e.g., a string where a number was expected).
- Cardinality breaches (e.g., a person with three primary addresses).
When To Use / When Not To Use
- When to Use: You have a complex, interconnected knowledge graph and need to validate the relationships and structural integrity of the nodes across the graph. SHACL excels at ensuring that merged, highly connected data conforms to your business rules.
- When NOT to Use: If you are simply validating a flat JSON payload or a single incoming API request. For flat data or single records, use simpler, faster libraries like Pydantic or JSONSchema.
Key Terms Explained
Before diving in, here are a few concepts you’ll encounter:- RDF (Resource Description Framework): A standard way of representing data as a graph. It treats information as connected “triplets” (Subject → Predicate → Object).
- OWL (Web Ontology Language): A language used to build ontologies. It defines the classes and properties that exist in your domain.
- SHACL Shapes: The actual validation rules. A “Shape” targets a specific class in your data (like
Person) and defines the constraints it must follow (like “must have one birthdate”). - Turtle (.ttl): A popular, human-readable file format for storing RDF graph data and SHACL shapes.
Typical Workflow
A typical SHACL validation pipeline follows this lifecycle:- Ontology: Build an ontology representing your domain.
- SHACL Shapes: Generate shapes from that ontology.
- Data Graph: Prepare your knowledge graph.
- Validation: Validate the knowledge graph against the SHACL shapes.
- Violation Report: Analyze the report for errors.
- Remediation: Fix the data or pipeline and re-validate.
Universal Example: Employee & Department
Let’s look at a simple, universally understood example: ensuring everyEmployee belongs to a Department and has an employee_id.
Now, let’s explore the workflow in more depth.
Step 1 — Build the ontology from your merged graph
SHACL shapes are derived from an ontology. If you already have one from a previous run, skip this step.Step 2 — Generate SHACL shapes from the ontology
SHACLGenerator produces a SHACLGraph with one NodeShape per OWL class.
Step 3 — Inject domain constraints
Add mandatoryPropertyShape constraints the pipeline cannot infer from data alone.
Step 4 — Run validation and read the report
Serialize the graph to RDF, then run_run_pyshacl against the shapes.
Step 5 — Understand the violations
EachSHACLViolation identifies the node, property path, and fix required.
malware-002 needs a family property added; vuln-003 needs a cvss_score and its cve_id corrected to the canonical format.
Step 6 — Auto-remediate common violations
Flag or patch nodes missing required properties, then re-validate to confirm.Common Pitfalls
- Assuming the ontology automatically enforces data quality:
SHACLGeneratorgenerates shapes based on what it observes in the data. If your data is missing a field, the generator won’t know it was mandatory unless you explicitly inject the constraint (as shown in Step 3). - Passing
ContextGraphdirectly to SHACL validators: The_run_pyshaclfunction expects an RDF string (like Turtle format), not a raw Python dictionary orContextGraphobject. - Forgetting RDF serialization: You must serialize your graph (often via a temporary file using
export_rdf) before validating it. - Treating validation as a one-time step: Validation should be integrated as an automated step in your CI/CD pipeline or data ingestion flow, acting as a recurring gatekeeper rather than a one-off script.
- Ignoring validation reports: A graph that does not conform must be remediated. Failing to review the
violation_countand address the issues negates the purpose of SHACL validation.
Domain Examples
- Defense — CTI/Threat
- Security — SOC/Incident
- Life Science — Clinical/Pharma
- Banking — Risk/Compliance
A DoD CTI team enforces STIX-compatible constraints on a threat graph before sharing it with ISAC partners. Every
ThreatActor must declare a name and every Vulnerability must carry a cvss_score. The validation gate runs automatically on each nightly sync.Using SHACL validation as a CI/CD gate
Call this function as a pre-publish gate; exit code 1 blocks the pipeline.Related Guides
- Ontology Management — generate the OWL ontology that SHACL shapes are derived from
- Reasoning & Rules — complement SHACL structural constraints with logical inference rules
- Export & Serialization — serialize graph data to Turtle/RDF/XML for
_run_pyshaclinput - Conflict Resolution — detect and resolve data conflicts before SHACL validation
- Change Management — version-gate SHACL shapes alongside ontology versions
