Summary

  • W3C's Data Shapes Working Group published the First Public Working Draft named SHACL 1.2 Inference Rules on 17 September 2026. A related SHACL 1.2 Rules first draft had already appeared in December 2025.
  • The new text distinguishes asserted input from inferred triples and lets engines attach sh:sourceRule to a derived triple. That origin-tracking option is a MAY, not a universal requirement.
  • A draft on the Recommendation track is not a W3C-endorsed Recommendation. Its own text also warns that test-suite success covers only tested behavior, and that rule execution can exhaust computation or memory.

Imagine two identical RDF statements in a data service. One was entered from a documented source. The other emerged after a rule ran against a changing graph. Their subject, predicate and object may match, but their grounds do not. When a downstream system stores only the statement, the difference is easy to lose.

That is the consequential feature of the Data Shapes Working Group's 17 September publication. SHACL 1.2 Inference Rules specifies how rules can derive new RDF triples from existing data. SHACL Core is primarily concerned with shapes and validation; this document covers inference. The move is not the invention of SHACL rules: W3C published a SHACL 1.2 Rules First Public Working Draft on 9 December 2025. This publication gives the named inference-rules text its own visible working-draft stage.

The draft's execution model makes a useful boundary explicit. The supplied data are the base graph. New statements form an inference graph. The evaluation graph joins the two while rules run. Rule sets can group work in layers and order execution. Intermediate triples can be marked temporary and removed after the final result is computed. These distinctions make the engine's behavior describable; they do not automatically ensure that an exported result carries its whole history.

A permitted trace, not a required one

Section 9 provides a precise example of the gap. A rule engine may have an option to generate extra triples linking a derived triple to the rule that produced it through sh:sourceRule. The suggested rule identifier should be an IRI. If such tracking triples are generated, they must not themselves be visible to executing rules. This is a valuable way to avoid letting metadata alter the inference it describes. It is not a promise that every conforming engine emits a provenance trail, nor does a rule name alone establish the version of the input or the authority of a later decision.

Consider an organisation enriching a registry or policy knowledge base. A rule can add a classification or link that an analyst later sees in a consolidated view. That is a possible application, not an allegation about a named deployment. The practical question is whether the analyst can still tell which statements were asserted, which were derived, which rule set ran, and whether the run completed within its limits. A timestamp on the final graph is not a substitute for those distinctions.

The draft also specifies failure boundaries. If an engine cannot execute any supported type for a rule it encounters, it reports failure. It may be configured to fail when iteration or inferred-triple limits are exceeded. The security section warns that rule sets can consume significant computation and memory or create arbitrary application data. A truncated run should not be silently promoted to a complete result; that is an operational conclusion drawn from the stated failure model, not a new W3C conformance clause.

Status requires the same restraint. The text is a First Public Working Draft on the Recommendation track. W3C says that status implies neither its own nor its members' endorsement, and the text may change. Passing its test suite covers the tested aspects, not every specification requirement. Lu Heng's running-code principle is useful here as an editorial discipline: distinguish a published procedure from behavior that another operator can reproduce. It does not make Lu Heng an authority over W3C's draft.

Sources