#1166: WG Revision: SHACL 1.2 Core

Visit on Github

Opened Nov 6, 2025

Specification

https://w3c.github.io/data-shapes/shacl12-core/

Explainer

https://w3c.github.io/data-shapes/shacl12-overview/#whatsnew

Links

  • The WG's request for this TAG review: https://www.w3.org/2025/11/03-data-shapes-minutes.html
  • TAG review of the previous version of this specification, if any: I can't find links to the review back in 2017
  • A description of what has changed since our previous review: As per the features below.

Feature 1:
Derived Properties
In the original SHACL specifications, shapes and constraints could only operate on asserted triples in a graph, and inferencing was left as an optional pre-processing step using languages like RDF Schema and OWL. SHACL 1.2 introduces its own inferencing and reasoning capabilities, which make SHACL more self-contained and cover different use cases than RDFS/OWL.

Feature 2:
Better Syntax for Unions of Datatypes and Classes In the original SHACL specifications, when you wanted to express that the datatype of a property was either xsd:string, rdf:langString, or rdf:HTML, you needed to use a verbose, repetitive construct. In SHACL 1.2, this can be written as a single list.

Feature 3:
Constraints on RDF 1.2 Reification
The major new feature in RDF 1.2 is reification, enabling RDF statements to be easily made about other RDF statements. SHACL 1.2 introduces new constraint properties (sh:reifierShape and sh:reificationRequired) which allow a shape targeting a triple to be chained to another shape targeting reification elements.

Feature 4:
Use of Reification in Constraint Definitions
In the original SHACL specifications, the severity and messages of a constraint had to be declared for the surrounding shape, sometimes requiring artificial intermediate shapes to be introduced to change only the severity or a message. SHACL 1.2 syntax is more flexible, allowing severity and messages to be directly attached to individual constraint triples.

Feature 5:
The sh:ShapeClass Metaclass
A new class, sh:ShapeClass, comparable to owl:Class, is used to define classes that can declare constraints that apply to all instances of the class. It is equivalent to OWL syntax for declaring a class that may hold OWL axioms. This allows SHACL to be a more self-contained ontology modeling language.

Feature 6:
Cleaner Separation between Core and SPARQL
We now have a cleaner separation of Core and SPARQL concerns into separate specifications. This helps indicate SHACL Core is not dependent on SPARQL, clarify other dependencies, and make some implementations easier.

The specification

Where and by whom is the work is being done?

  • GitHub repo: https://github.com/w3c/data-shapes/
  • Primary contacts:
    • @HolgerKnublauch, Top Quadrant, main editor
    • @bergos, Top Quadrant, main editor
    • @YoucTagh, Inria, main editor
    • @jeswr, Oxford University, main editor
    • @nicholascar, KurrawongAI, WG co-chair
    • @PapoutsoglouE, Y.digital, WG co-chair
  • Organization/project driving the specification: Top Quadrant, INRIA, KurrawongAI, Y.digital
  • This work is being funded by: in-kind only from editors' & co-charis' orgs
  • Primary standards group developing this feature: Data Shapes WG
  • Incubation and standards groups that have discussed the design: This is build on top of RDF 1.2 work and we have members in common with that WG and discussed it with them

Feedback so far

You should also know that...

No response

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1166

Discussions

Log in to see TAG-private discussions.

Discussed Dec 1, 2025 (See Github)

Jeffrey: I've not had a chance to look at this.

Discussed Dec 15, 2025 (See Github)

Skipped.

Comment by @csarven Jan 22, 2026 (See Github)

The TAG thanks the Data Shapes WG for requesting this review.

The TAG recommends the following:

The Derived Properties feature description mentions that it introduces its own inferencing and reasoning capabilities. The specification's Relationship between SHACL and RDFS inferencing seems to clarify that SHACL delegates reasoning to external entailment regimes via sh:entailment. We suggest that the summary is revised to avoid giving the impression that SHACL defines new semantics or hidden inferencing.

SHACL 1.2 Core specifies that entailment support is optional and that processors must signal failure when encountering an unrecognised entailment. Could this affect deployment or interoperability across the ecosystem?

This review reflects the TAG's current assessment to support the WG's next steps.