SHACL as Input Validation

If a SHACL shape defines what valid data looks like, it also defines what hostile data does NOT look like. Run shapes on every write: malformed, oversized or unexpected-class submissions are rejected before they reach the store.

This is the SemWeb version of never trust client-side validation alone.

Going deeper — the constraints that make SHACL a gate

Basic cardinality and datatype checks stop malformed data. Turning SHACL into a real ingestion gate uses three more features:

• sh:closed true rejects any predicate you didn't explicitly allow. This is the antidote to property smuggling — an attacker can't slip :isAdmin true into a :Comment if the shape is closed.
• sh:pattern / sh:maxLength bound the shape of values, blocking oversized payloads and injection-shaped strings at the door.
• sh:severity lets one shape carry both hard failures (sh:Violation — reject the write) and soft signals (sh:Warning — accept but flag), so security rules and quality nudges live in one document.

For logic beyond the built-ins, sh:sparql embeds a SPARQL query as a constraint — arbitrarily expressive, at the cost of being arbitrarily slow, so keep those for rules the simple constraints genuinely can't express.

Worked example — a validation shape for :Comment.

Say a :Comment is valid only if:

• its foaf:name is present and no longer than 200 characters, and
• it has exactly one :creator.

Write one NodeShape with two sh:property entries — one per property being constrained:

@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:CommentShape a sh:NodeShape ;
  sh:targetClass :Comment ;
  sh:property [
    sh:path foaf:name ;
    sh:minCount 1 ;
    sh:maxLength 200
  ] ;
  sh:property [
    sh:path :creator ;
    sh:minCount 1 ;
    sh:maxCount 1
  ] .

At ingestion the validator rejects any :Comment that violates either rule. Same shape, two layered roles: quality contract AND security policy.