[data-shapes] Definition(s) of "Shapes Graph" (#861)

mgberg has just created a new issue for https://github.com/w3c/data-shapes:

== Definition(s) of "Shapes Graph" ==
@ajnelson-nist and I were talking about how to phrase certain things regarding shapes graphs yesterday in the Profiling group and we got caught up on the fact that the term "shapes graph" appears in the spec with a few subtly different meanings that are never explicitly distinguished. I've run into this issue before when reading the spec and have had to double check the context to be sure I'm thinking about it the right way.

Here are what I think are the three different usages/definitions related to shapes graphs:

### 1. _Shapes Graph_ (reusable module/artifact)

Any RDF graph that contains SHACL shapes, existing as a publishable, importable unit independent of any validation process. This is what the newly defined `sh:ShapesGraph` represents.

For example:
- The Core abstract uses the plural: *"RDF graphs called shapes graphs"*, and in this context there is no validation happening yet
- `owl:imports` and `sh:shapesGraph` reference individual shapes graphs that get composed together
- The informative text in Core section 6.1 describes shapes graphs as *"reusable validation modules"*

### 2. _Input Shapes Graph_ (what is originally provided)

The specific graph originally provided to a SHACL processor, _before_ `owl:imports` resolution.

For example:
- The Core spec distinguishes *"the originally provided shapes graph"* from *"the resulting graph"* after transitive import resolution
- This is the starting point of the composition process

### 3. _Resolved Shapes Graph_ (the fully resolved graph used during validation)

The single, unified, immutable graph resulting from composing the input shapes graph with all transitively imported graphs that is actually queried during validation.

For example:
- The immutability requirement in Core section 6.1 applies to this graph: it *"MUST NOT be further modified during the validation process"*
- Shape definitions, constraint components, and validators are all discovered *"in the shapes graph"*, which requires the fully resolved graph to find content from imported modules
- In the SPARQL spec, prefix declarations are currently collected via `sh:prefixes/owl:imports*/sh:declare`. This path works because imported content is already present in the resolved graph including any `owl:imports` triples

### Potential Resolution

Explicitly distinguish three terms in normative text:

1. **Shapes Graph**: any RDF graph containing shapes (the module/artifact sense, can be plural)
2. **Input Shapes Graph**: The specific graph originally provided to a SHACL processor before import resolution
3. **Resolved Shapes Graph**: The fully resolved graph resulting from composing the input shapes graph with all `owl:imports` and `sh:shapesGraph` references. It is immutable during validation. Most current normative references to "the shapes graph" or "in the shapes graph" across the spec actually refer to this graph.

Note that any case, a shapes graph in practice may contain more than just shapes (e.g. RDFS/OWL class hierarchies, entailment declarations, SPARQL prefix declarations, etc.) and the processor relies on this broader content being present and queryable for certain features to work.


Please view or discuss this issue at https://github.com/w3c/data-shapes/issues/861 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 17 April 2026 13:08:01 UTC