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:
  1. Ontology: Build an ontology representing your domain.
  2. SHACL Shapes: Generate shapes from that ontology.
  3. Data Graph: Prepare your knowledge graph.
  4. Validation: Validate the knowledge graph against the SHACL shapes.
  5. Violation Report: Analyze the report for errors.
  6. Remediation: Fix the data or pipeline and re-validate.

Universal Example: Employee & Department

Let’s look at a simple, universally understood example: ensuring every Employee 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.
The generated shapes tell you what the pipeline observed. They do not yet encode what your domain requires. The next section shows how to inject domain-specific mandatory constraints.

Step 3 — Inject domain constraints

Add mandatory PropertyShape constraints the pipeline cannot infer from data alone.
You can also construct shapes manually from scratch — useful when you need to express constraints the generator would never infer, such as a regex pattern on a CVE ID field:

Step 4 — Run validation and read the report

Serialize the graph to RDF, then run _run_pyshacl against the shapes.
The summary tells you something is wrong. Now drill into the details.

Step 5 — Understand the violations

Each SHACLViolation identifies the node, property path, and fix required.
The output maps directly to remediation tasks: 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: SHACLGenerator generates 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 ContextGraph directly to SHACL validators: The _run_pyshacl function expects an RDF string (like Turtle format), not a raw Python dictionary or ContextGraph object.
  • 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_count and address the issues negates the purpose of SHACL validation.

Domain Examples

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.