SHACL as Input Validation

Reuse your shapes as a write-time security policy.

0/3 done

Theory

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.

Worked example — :Comment validation shape

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.

Reading in progress · 0 of 3 activities done