The Shape Templates algorithm

Draft Community Group Report,

More details about this document
This version:
Feedback: with subject line “[ShapeTemplates] … message topic …” (archives)
Issue Tracking:
Pieter Colpaert


This algorithm defines what quads are part of an entity description. It uses the concepts of Concise Bounded Descriptions, adds well-defined support for named graphs, and introduces the concept of a shape template. A shape template is a structure of an entity description that follows similar design principles as SHACL Node Shapes. The algorithm returns the quads that match, and also provides hooks for the client to fetch more quads elsewhere (i.e. by dereferencing the subject).

Status of this document

1. The algorithm



  1. When a shape template was set, execute the shape template extraction algorithm, yet exclude all quads that have another member (from the current context) set as their named graph

  2. If no shape template was set, extract all quads with subject the focus node, and recursively include its blank nodes (see also [CBD])

  3. Extract all quads with the graph name matching the focus node

  4. When no quads were extracted from steps 1-3, a client MUST fetch more information about the focus node (i.e. by dereferencing it) and re-execute 1-3.

1.1. Shape Template extraction

The Shape Template is a structure that looks as follows:

class ShapeTemplate {
    closed: boolean;
    requiredPaths: Path[];
    optionalPaths: Path[];
    nodelinks: NodeLink[];
    atLeastOneLists: [ Shape[] ];
class NodeLink {
    shape: ShapeTemplate;
    path: Path;

Paths in the shape templates are SHACL Property Paths.

A Shape Template has

Note: Certain quads are going to be matched by the algorithm multiple times. Each quad will of course be part of the member only once.

This results in this algorithm:

  1. If it is open, a client MUST extract all quads, after a potential HTTP request to the focus node, with subject the focus node, and recursively include its blank nodes

  2. If the current focus node is a named node and it was not requested before:

    • test if all required paths are set, if not do an HTTP request, if they are set, then,

    • test if at least one of each list in the atLeastOneLists was set. If not, do an HTTP request.

  3. Visit all paths (required, optional, nodelinks and recursively the shapes in the atLeastOneLists if the shape is valid) paths and add all quads necessary to reach the targets to the result

  4. For the results of nodelinks, if the target is a named node, set it as a focus node and repeat this algorithm with that nodelink’s shape as a shape

1.1.1. Generating a shape template from SHACL

On a tree:Collection, a SHACL shape MAY be provided with the tree:shape property. In that case, the SHACL shape MUST be processed towards a Shape Template as follows:

  1. Checks if the shape is deactivated (:S sh:deactivated true), if it is, don’t continue

  2. Check if the shape is closed (:S sh:closed true), set the closed boolean to true.

  3. All sh:property elements with an sh:node link are added to the shape’s NodeLinks array

  4. Add all properties with sh:minCount > 0 to the Required Paths array, and all others to the optional paths.

  5. Processes the conditionals sh:xone, sh:or and sh:and (but doesn’t process sh:not):

    • sh:and: all properties on that shape template MUST be merged with the current shape template

    • sh:xone and sh:or: in both cases, at least one item must match at least one quad for all required paths. If not, it will do an HTTP request to the current namednode.


Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.


Normative References

Patrick Stickler, Nokia. CBD - Concise Bounded Description. 3 June 2005. W3C Member Submission. URL:
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: