sh:NodeShape & sh:targetClass

A sh:NodeShape is a constraint document targeting a class:

@prefix sh: <http://www.w3.org/ns/shacl#> .

:NinjaShape a sh:NodeShape ;
  sh:targetClass :Ninja ;
  sh:property [ sh:path foaf:name ; sh:minCount 1 ; sh:datatype xsd:string ] .

A validator reports any :Ninja instance missing a string foaf:name.

Validation, not entailment — the exact opposite of OWL. OWL/RDFS make your graph grow by adding inferred triples; SHACL leaves the graph alone and produces a report listing every node that violates a shape. Same data, two complementary questions: OWL asks what else is true?, SHACL asks is this data well-formed? Use OWL to enrich, SHACL to gatekeep.

Going deeper — closed thinking in an open world

Why SHACL exists. RDF/OWL are open-world and non-unique-name: missing data is merely unknown, never invalid. That's perfect for integrating data you don't control, and useless when you need to guarantee an input is complete before loading it. SHACL bolts a closed-world, fail-loud check onto an open-world model — exactly the validation layer the rest of the stack deliberately omits.

Where it bites.

• SHACL validates the graph as written, not as entailed — unless you explicitly run reasoning first. A node that is only a :Ninja by inference (via subclass) won't be caught by sh:targetClass :Ninja unless the inferred rdf:type triple has actually been materialized. Decide up front: validate raw data, or validate the reasoned graph.
• sh:minCount 1 means 'at least one asserted'. Because of the open world, SHACL can't know whether a value merely wasn't stated; it reports the absence as a violation, which is precisely why you reach for it. That's a feature, but it surprises people coming from OWL.
• Shapes are themselves just triples. Your constraints live in the same graph language as your data, so they're versionable, diffable, and queryable — but also easy to typo into a shape that silently targets nothing. Always test a shape against a known-bad instance first.

Think of a SHACL shape as a code review checklist for your graph: not how the data should look in detail, but what must be true for it to be considered well-formed.

And like a good code-review checklist, the value is in the rejection: shapes catch the malformed pull-request before it lands in main, so the rest of your pipeline can assume well-formed inputs.

A shape sits next to your data and asks: does every targetClass instance satisfy these constraints?

Read the diagram left-to-right: the dashed box on the left is the shape (the rules); the solid box on the right is the data (the :Master rows). The validator walks every targeted instance and emits a report — the data itself is never modified.