Shape Trees Specification

Editor’s Draft,

This version:
https://shapetrees.org/spec
Issue Tracking:
GitHub
Inline In Spec
Editors:
Eric Prud'hommeaux
Justin Bingham
Josh Collins

Abstract

Semantic Web Applications interoperate by sharing semantics of terms and constellations of resource-oriented data structures. This specification defines shape trees, a mechanism for declaring and operating over constellations of resource-oriented data structures.

Status of this document

1. Introduction

This section is non-normative.

Realizing the value proposition of the Semantic Web lies in building useful and robust applications that can interoperate over linked data. Protocols such as [LDP] and Solid organize linked data graphs into resource hierarchies, providing a foundation upon which these robust and interoperable applications can be created.

Application interoperability depends on applications sharing semantics for relationships and data structures. Existing technologies fulfill portions of those dependencies:

For applications that operate on more complex and interconnected resources, Shape Trees express the layout of those resources and associate them with their respective shapes.

Shape trees marry RDF vocabularies, shapes, and resources into "little trees" that provide machine to machine interoperability, combining them into concepts that humans can easily comprehend, such as medical records, notes, notebooks, calendars, and financial records.

This allows one to treat a set of related resources as a single grouping, and apply that to a range of operations including access control, data organization, data validation, and data migration.

Shape trees are defined as an RDF graph structure that expresses a set of expected behaviors by agents that work with them. These semantics CAN be implemented by a server, or a client-side agent that pre-processes requests to a server.

While shape trees are intended to adapt to different technology platforms that support the notion of containers and resources, examples in this specification will reflect usage in an [LDP] environment.

2. Structure

A shape tree is a machine-readable template describing the expected layout of a tree of resources in a container-based ecosystem.

The terms used to express a shape tree are described using an RDF vocabulary.

The realization of a shape tree is a planted shape tree. The upper-most Container of that tree is the instance root.

Let ST be a shape tree;

Let T be a corresponding instance tree.

For any shape tree S linked in ST:

A { st:hasShapeTreeDecoratorIndex Si } arc indicates the location of an index of SKOS hierarchies that describe ST.

ShEx validation of a Shape Tree
prefix st: <http://www.w3.org/ns/st#>.
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
prefix xsd: <http://www.w3.org/2001/XMLSchema#>.

<#ShapeTree> {
  a st:ShapeTree ;
  (
    st:expectsType [st:ShapeTreeContainer] ;
    st:contains @<#ShapeTree> +
  ) ;
  (rdfs:label xsd:string | st:matchesUriTemplate xsd:string) ;
  st:references @<#ReferencedShapeTree> * ;
  st:validatedBy IRI ? ;
  st:contains IRI ? ;
  st:supports IRI ? ;
}

<#ReferencedShapeTree> {
  st:hasShapeTree IRI ;
  st:traverseViaShapePath xsd:string
}

3. Shape Tree Operations

Working with shape trees entails using several higher-level operations —each of which may represent one or more HTTP requests and/or pieces of processing logic.

The key operations used to manage shape trees are:

These operations make use of reusable, internal algorithms defined in Shape Tree Algorithms.

3.1. Discover Shape Tree

The discover shape tree operation entails discovering what, if any, shape trees are managing a given container.

3.1.1. Inputs

3.1.2. Outputs

3.1.3. Operation Summary

# Step Interaction
1 Perform a HEAD on uri to discover Shape Tree metadata URI Request Response
2 Perform a GET on the discovered Shape Tree metadata resource Request Managed Response
Unmanaged Response
3 Collect any navigable shape trees N/A - Logic only

3.1.4. Operation Details

3.1.4.1. Perform a HEAD on the provided uri to discover Shape Tree metadata URI

Note: This step SHOULD be performed by a client-side agent.

uri = /data/CommonNotes/
HEAD /data/CommonNotes/
Discover Container Shape Tree Metadata - HEAD container - Response
HTTP/1.1 200 OK
Link: </data/CommonNotes/meta/UUID>; rel="http://shapetrees.org/#ShapeTree"
Link: <http://www.w3.org/ns/ldp#Container>; rel="type"
...other headers omitted...

Discovering shape trees only applies to URIs of containers. A status code of 400 MUST be returned if no Link headers with a relation type which maps to the implementation’s notion of a container (e.g. http://www.w3.org/ns/ldp#Container in an LDP context) exists.

Let metauri be the URI of the shape tree metadata resource pertaining to uri through the Link header with relation http://shapetrees.org/#ShapeTree.

3.1.4.2. Perform a GET on the discovered Shape Tree metadata resource (metauri)

Note: This step SHOULD performed by a client-side agent.

Discover Container Shape Tree Metadata - Get Shape Tree metadata - Request
GET /data/CommonNotes/meta/UUID
Discover Container Shape Tree Metadata - GET Shape Tree metadata - Managed Container Response
prefix st: <http://www.w3.org/ns/st#>.
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
prefix xsd: <http://www.w3.org/2001/XMLSchema#>.

<#shapetree>
  st:hasShapeTreeLocator <#bc1b490a-537d-4749-b778-cd7d6da3ac56> .

<#bc1b490a-537d-4749-b778-cd7d6da3ac56>
  a st:ShapeTreeLocator ;
  st:hasRootShapeTree <http://commonnote.example/commonnote#container-tree> ;
  st:hasShapeTree <http://commonnote.example/commonnote#container-tree> ;
  st:hasShapeTreeInstanceRoot </data/CommonNotes/> .
Discover Container Shape Tree Metadata - GET Shape Tree metadata - Unmanaged Container Response
HTTP/1.1 404 NOT FOUND

A 404 status code indicates that no shape trees manage this container, and so it MUST be considered an Unmanaged Container.

3.1.4.3. Collect any navigable shape trees

Note: This step SHOULD performed by a client-side agent.

If the <#shapetree> subject has one or more st:hasShapeTreeLocator predicates it means this container MUST be considered a Managed Container.

Let mc be this managed container.

The st:hasShapeTree of each st:ShapeTreeLocator subject specifies what shape tree manages mc.

The IRI of each st:ShapeTreeLocator describing a shape tree managing mc SHOULD be returned.

3.2. Plant Shape Tree

Note: A plant operation MAY be performed by either a client or server-side agent.

The plant operation marks a container (new or existing) as being managed by one or more shape trees.

3.2.1. Inputs

3.2.2. Outputs

3.2.3. Key Terms for Planting

3.2.4. Operation Summary

# Step Interaction
1 Preconditions:
  • Discover Shape Tree(s) for Parent Container (pc)

  • Discover Shape Tree(s) for Target Container (tc)

See Discovery
2 Static Validation of Shape Trees for Conflicts N/A - Logic only
3 Validate Graph Body N/A - Logic only
4 Validate against Parent Container (pc) See Validate Proposed Resource
5 Create Target Container (tc), if necessary Request Response
6 Update Shape Tree Meta Data for Target Container (tc) See Update Container Metadata
7 Initialize Static Content See Initialize Static Content

3.2.5. Operation Details

3.2.5.1. Preconditions

Note: This step SHOULD be performed by a client-side agent.

  1. Ensure the Parent Container (pc) exists. If not, this operation MUST return a 404 status code.

  2. Discover any planted shape tree IRIs managing pc.

    1. Let parentst be the collection of dereferenced shape tree IRIs discovered for pc

  3. If the Target Container (tc) already exists, discover any previously planted shape tree IRIs.

    1. Collect any existing shape tree IRIs and combine with the IRIs of the linkst provided via the request Link header to represent the full collection of existing and proposed shape trees for tc.

    2. Let allst be the collection of dereferenced shape tree IRIs representing both existing and linkst IRIs

3.2.5.2. Static Validation of Shape Trees for Conflicts

Note: This step MAY be performed by either a client or server-side agent..

  1. Iterate allst to validate that none of the following conditions are met:

    • any shape tree has a st:expectsResourceType with a value other than st:ShapeTreeContainer

    • more than one shape tree has a st:validatedBy value

    • more than one shape tree has a st:contains value

If any of the above static validations fail, this operation MUST return a 400 status code.

3.2.5.3. Validate graph body

Note: This step MAY be performed by either a client or server-side agent..

Must detail how to differentiate between ShEx and SHACL validation

  1. Let vst be the validating shape tree that is identified by the only shape tree in allst having a st:validatedBy value

  2. If vst is present and the plant operation (req) includes an RDF graph body and ShEx validation is used and a Focus Node (linkfn) is not present, this operation MUST return a 422 status code

  3. Perform a validation of the RDF graph body of req using the vst st:validatedBy shape, targeting the graph’s linkfn. If validation fails, this operation MUST return a 422 status code

3.2.5.4. Validate against parent container

Note: This step MAY be performed by either a client or server-side agent..

  1. Determine if the Parent Container (pc) is a Managed Container by evaluating if parentst is not empty

  2. If pc is a Managed Container call the validate proposed resource algorithm with parameters:

Parameter Value Notes
uri pc The parent container that will contain the target container
rn If req is a POST then slug
If req is a PUT then name
The name of the resource
sth linktst Link header with the relation of "http://shapetrees.org/#TargetShapeTree"
rt st:ShapeTreeContainer The resource type being created/modified
3.2.5.5. Create Target Container (tc), if necessary

Note: This step MAY be performed by either a client or server-side agent..

  1. If tc does not exist, create it.

    Create Target Container - Request
    POST /<pc>/
    Slug: <tc>;
    Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"
    
    Create Target Container - Response
    HTTP 201 CREATED
    Location: http://pod.example/<pc>/<tc>/
    Content-type: text/turtle; charset=utf-8
    Content-length: 396
    
3.2.5.6. Update Shape Tree Meta Data for Target Container (tc)

Note: This step MAY be performed by either a client or server-side agent..

  1. Update Target Container tc Metadata (metauri)

    1. Iterate the collection of shape trees to be planted (linkst), let linksti be the current shape tree in context.

    2. Call algorithm Update Container Metadata with parameters:

    Parameter Value Notes
    tc tc The target container to that will contain instance data of the shape tree
    rootst linksti The root shape tree at the top of the hierarchy
    st linksti The shape tree managing the target container
    rootpath tc The target container to that will contain instance data of the shape tree
3.2.5.7. Initialize Static Content

Note: This step MAY be performed by either a client or server-side agent..

  1. Let cst be the shape tree having a st:contains value (if one exists) from the list of shape trees that were planted linkst

  2. Iterate any st:contains IRIs within cst, letting csti be the current IRI in context

  3. Let cstist be the shape tree resulting in dereferencing IRI csti

  4. If cstist has a rdfs:label value, let label be the value of rdfs:label for cstist, and call algorithm Initialize Statics with parameters:

Parameter Value Notes
pc tc The target container to that will contain instance data of the shape tree
sst cstist The matching contained shape tree
rst cst The shape tree containing a st:container
rc tc The target container to that will contain instance data of the shape tree

3.3. Create Data Instance

The create data instance operation creates an instance of a shape tree within a managed container.

3.3.1. Inputs

3.3.2. Outputs

3.3.3. Key Terms for Creating Data Instances

3.3.4. Operation Summary

# Step Interaction
1 Discover Shape Tree(s) for Target Container (tc) See Discovery
2 Validate against parent container See Validate Proposed Resource
3 Create Proposed Resource
4 Initialize Static Content See Initialize Static Content

3.3.5. Operation Details

3.3.5.1. Preconditions

Note: This step SHOULD be performed by a client-side agent.

  1. Ensure the Parent Container (pc) exists. If not, return this operation MUST return a 404 status code.

  2. Discover any planted shape tree IRIs managing pc.

    1. Let parentst be the collection of dereferenced shape tree IRIs discovered for pc

3.3.5.2. Validate against parent container

Note: This step MAY be performed by either a client or server-side agent.

  1. Determine if the Parent Container (pc) is a Managed Container by evaluating if parentst is not empty

  2. If pc is a Managed Container call the validate proposed resource algorithm with parameters:

Parameter Value Notes
uri pc The parent container to that will contain the target container
rn If req is a POST then slug
If req is a PUT then name
The name of the resource
sth linktst The shape tree managing the target container
rt st:ShapeTreeContainer or st:ShapeTreeResource or st:ShapeTreeNonRDFResource The resource type being created
3.3.5.3. Create Resource

Note: This step MAY be performed by either a client or server-side agent..

3.3.5.4. Initialize Static Content

Note: This step MAY be performed by either a client or server-side agent.

  1. Iterate any st:contains IRIs within mcst, letting csti be the current IRI in context

  2. Let cstist be the shape tree resulting in dereferencing IRI csti

  3. If cstist has a rdfs:label value, let label be the value of rdfs:label for cstist, and call algorithm Initialize Statics with parameters:

Parameter Value Note
pc tc The target container that will contain instance data of the shape tree
sst cstist The matching shape tree
rst cst The parent shape tree managing the parent container
rc tc The target container that will contain instance data of the shape tree

3.4. Update Data Instance

The update data instance operation updates an instance of a shape tree within a managed container.

3.4.1. Inputs

3.4.2. Outputs

3.4.3. Key Terms for Updating Data Instances

3.4.4. Operation Summary

# Step Interaction
1 Discover Shape Tree(s) for Parent Container (pc) See Discovery
2 Validate against parent container See Validate Resource
3 Update Resource

3.4.5. Operation Details

3.4.5.1. Preconditions

Note: This step SHOULD be performed by a client-side agent.

  1. Ensure the Parent Container (pc) exists. If not, this operation MUST return a 404 status code.

  2. Discover any planted shape tree IRIs managing pc.

    1. Let parentst be the collection of dereferenced shape tree IRIs discovered for pc

3.4.5.2. Validate against parent container

Note: This step MAY be performed by either a client or server-side agent.

  1. Determine if the Parent Container (pc) is a Managed Container by evaluating if parentst is not empty

  2. If pc is a Managed Container call the validate proposed resource algorithm with parameters:

Parameter Value Notes
uri pc The parent container that will contain the target container
rn name The resource name
sth linktst The shape tree managing the target container
rt rt The resource type being modified
3.4.5.3. Update Resource

Note: This step MAY be performed by either a client or server side agent.

3.5. Delete Data Instance

The delete data instance operation deletes an instance of a shape tree within a managed container.

3.5.1. Inputs

3.5.2. Outputs

3.5.3. Key Terms for Deleting Data Instances

3.5.4. Operation Summary

# Step Interaction
1 Delete Resource

3.5.5. Operation Details

3.5.5.1. Delete Resource

Note: This step MAY be performed by either a client or server-side agent.

3.6. Unplant Shape Tree

The unplant shape tree operation unassigns the provided shape tree from the provided container. If there are no remaining shape trees managing the container, it would no longer be considered a managed container.

3.6.1. Inputs

3.6.2. Outputs

3.6.3. Key Terms for Unplanting Shape Trees

3.6.4. Operation Summary

# Step Interaction
1 Update metadata container to remove ShapeTreeLocator for the provided shape tree

3.6.5. Operation Details

3.6.5.1. Remove Shape Tree Metadata

Note: This step MAY be performed by either a client or server-side agent.

Call the remove shape tree metadata algorithm with parameters:

Parameter Value Notes
uri tc The target container that the [shape tree] is being removed from
st linktst The shape tree no longer managing the tc

4. Shape Tree Algorithms

The below algorithms detail key pieces of logic required for shape tree implementations.

4.1. Validate Proposed Resource Against Parent Container

This algorithm is responsible for determining if a proposed resource (which may more specifically be a container, resource, or non-RDF source) is valid to be created within a given container.

Note: This algorithm MAY be performed by either a client or server-side agent.

Inputs

Outputs

Algorithm Details

  1. Determine if the Parent Container (pc) is a Managed Container by evaluating if parentst is not empty

  2. If pc is a Managed Container, let mcst be the matching contained shape tree which is the result of calling the matching contained shape tree algorithm with parameters:

    Parameter Value Notes
    uri pc The parent container to discover shape trees for
    rn If req is a POST then slug
    If req is a PUT then name
    The resource name
    sth sth The shape tree hint provided as a Link header
    rt rt The resource type being created/modified
  3. If rt does not match mcst’s st:expectsType value, this operation MUST return a 422 status code

  4. If mcst has a st:validatedBy value, and the plant operation (req) includes an RDF graph body and ShEx validation is used and a Focus Node (linkfn) is not present, this operation MUST return a 422 status code

  5. Perform a validation of the RDF graph body of req using the mcst st:validatedBy shape, targeting the graph’s linkfn. If validation fails, this operation MUST return a 422 status code

4.2. Find Matching Contained Shape Tree

This algorithm is responsible for determining which shape tree within a set of shape trees mentioned in st:contains is applicable for a given proposed resource.

Note: This algorithm MAY be performed by either a client or server-side agent.

Inputs

Outputs

Algorithm Details

  1. Let mst be the shape trees managing uri found by discovering the shape trees

  2. Let cst be the shape tree within mst with a st:contains value(s)

  3. Let ccst be the candidate shape trees for matching - populated by each st:contains of cst

  4. If sth is specified

    1. and sth does NOT exist within ccst this algorithm MUST return a 400 status code

    2. and sth exists within ccst return sth

  5. If ccst does not contain any of st:AllowAll, st:AllowResources, st:AllowContainers, st:AllowNonRDFSources, this algorithm MUST return a status code of 422

  6. If st:AllowNone exists within ccst, this algorithm MUST return a status code 422

  7. If st:AllowAll exists within ccst, return null - indicating that while no match was found, pc has been configured to allow resources of any type to be created without matching the shape tree

  8. If st:AllowResources exists within ccst:

    1. And the resource type (rt) is not a Resource, this algorithm MUST return a status code of 422

    2. And the resource type (rt) is a Resource, return null - indicating that while no match was found, pc has been configured to allow Resources to be created without matching the shape tree

  9. If st:AllowContainers exists within ccst:

    1. And the resource type (rt) is not a Container, this algorithm MUST return a status code of 422

    2. And the resource type (rt) is a Container, return null - indicating that while no match was found, pc has been configured to allow Containers to be created without matching the shape tree

  10. If st:AllowNonRDFSources exists within ccst:

    1. And the resource type (rt) is not a Non-RDF Source, this algorithm MUST return a status code of 422

    2. And the resource type (rt) is a Non-RDF Source, return null - indicating that while no match was found, pc has been configured to allow non-RDF Sources to be created without matching the shape tree

4.3. Initialize Static Content

This algorithm is responsible for initializing static content that is implied through the creation of its parent. When called, it recursively seeks out resources to be statically created.

Note: This algorithm MAY be performed by either a client or server-side agent.

Inputs

Outputs

Algorithm Details

  1. Let label be the rdfs:label value of the provided "static" shape tree (sst)

  2. Create the expected resource using a PUT in order to have control of resource naming, letting cr be the resulting resource that was created

    1. Set the appropriate Link header with "type" relation based on the st:expectsType value of sst

  3. If the st:expectsType value of sst is st:ShapeTreeContainer:

    1. Call algorithm Update Container Metadata with parameters:

      Parameter Value Notes
      tc cr Created static resource
      rootst rst The root shape tree of the hierarchy
      st sst The shape tree to assign to cr
      rootpath rc The root container at the top of this shape tree hierarchy
    2. If sst has any values for st:contains:

      1. Iterate any st:contains IRIs within sst, letting cssti be the current IRI in context

      2. Let csstit be the shape tree resulting in dereferencing IRI cssti

      3. If csstit has a rdfs:label value then recursively call algorithm Initialize Statics with parameters:

        Parameter Value Notes
        pc cr Created static resource, now the parent
        sst csstit A shape tree to be recursively planted
        rst rst The root shape tree of the hierarchy
        rc rc The root container at the top of this shape tree hierarchy

4.4. Update Container Metadata

This algorithm is responsible for updating the shape tree metadata for a container to reflect what shapetree(s) manage that container and the container’s location relative to the broader hierarchy of shape trees.

Note: This algorithm MAY be performed by either a client or server-side agent.

Inputs:

Outputs:

Algorithm Details

  1. Perform a HEAD on Target Container tc

    Discover Target Container Shape Tree Metadata URI - Request
    HEAD /data/CommonNotes/
    
    Discover Target Container Shape Tree Metadata URI - Response
    HTTP/1.1 200 OK
    Link: </data/CommonNotes/meta/UUID>; rel="http://shapetrees.org/#ShapeTree"
    ...other headers omitted...
    

    Let metauri be the URI of the shape tree metadata resource pertaining to uri.

  2. Perform a GET on the Target Container’s Shape Tree metadata (metauri)

    Dereference Target Container Shape Tree Metadata URI - Request
    GET /data/CommonNotes/meta/UUID
    
    Dereference Target Container Shape Tree Metadata URI - Managed Response
    @prefix st: <http://www.w3.org/ns/st#>.
    
    <#shapetree>
      st:hasShapeTreeLocator <#bc1b490a-537d-4749-b778-cd7d6da3ac56> .
    
    <#bc1b490a-537d-4749-b778-cd7d6da3ac56>
      a st:ShapeTreeLocator ;
      st:hasRootShapeTree <http://commonnote.example/commonnote#container-tree> ;
      st:hasShapeTree <http://commonnote.example/commonnote#container-tree> ;
      st:hasShapeTreeInstanceRoot </data/CommonNotes/> .
    
    Dereference Target Container Shape Tree Metadata URI - Unmanaged Response
    HTTP/1.1 404 NOT FOUND
    

    If a 404 is returned that indicates that no shape trees manage this container. Let eg be the existing metadata graph resulting from dereferencing and parsing metauri.

  3. Populate the metadata graph with triples

    Using eg, if it exists, otherwise a new graph, the following triples should be added:

    Subject Predicate Object Description
    <#generated UUID> rdf:type st:ShapeTreeLocator Indicates the RDF class of the subject
    <#generated UUID> st:hasRootShapeTree rootst Describes the shape tree planted at the root of this shape tree hierarchy
    <#generated UUID> st:hasShapeTree st Describes the shape tree planted at this container
    <#generated UUID> st:hasShapeTreeInstanceRoot rootpath Describes the URI to the root container of this shape tree hierarchy
    <#shapetree> st:hasShapeTreeLocator <#generated UUID> Describes a navigable relationship to a given st:ShapeTreeLocator
  4. Persist the above triples to metauri.

4.5. Remove Shape Tree From Container Metadata

This algorithm is responsible for updating the shape tree metadata for a container to remove a shape tree from managing a container.

Note: This algorithm MAY be performed by either a client or server-side agent.

Inputs:

Outputs:

Algorithm Details

  1. Perform a HEAD on Target Container tc

    Discover Target Container Shape Tree Metadata URI - Request
    HEAD /data/CommonNotes/
    
    Discover Target Container Shape Tree Metadata URI - Response
    HTTP/1.1 200 OK
    Link: </data/CommonNotes/meta/UUID>; rel="http://shapetrees.org/#ShapeTree"
    ...other headers omitted...
    

    Let metauri be the URI of the shape tree metadata resource pertaining to uri.

  2. Perform a GET on the Target Container’s Shape Tree metadata (metauri)

    Dereference Target Container Shape Tree Metadata URI - Request
    GET /data/CommonNotes/meta/UUID
    
    Dereference Target Container Shape Tree Metadata URI - Managed Response
    @prefix st: <http://www.w3.org/ns/st#>.
    
    <#shapetree>
      st:hasShapeTreeLocator <#bc1b490a-537d-4749-b778-cd7d6da3ac56> .
    
    <#bc1b490a-537d-4749-b778-cd7d6da3ac56>
      a st:ShapeTreeLocator ;
      st:hasRootShapeTree <http://commonnote.example/commonnote#container-tree> ;
      st:hasShapeTree <http://commonnote.example/commonnote#container-tree> ;
      st:hasShapeTreeInstanceRoot </data/CommonNotes/> .
    
    Dereference Target Container Shape Tree Metadata URI - Unmanaged Response
    HTTP/1.1 404 NOT FOUND
    

    If a 404 is returned that indicates that no shape trees manage this container. Let eg be the existing metadata graph resulting from dereferencing and parsing metauri.

  3. Remove pertinent shape tree triples

    Let s be the subject of type ShapeTreeLocator with a st:hasShapeTree matching st.

    Remove the subject s along with the st:hasShapeTreeLocator referencing s from the metadata graph.

  4. Persist the updated graph to metauri.

5. Describing Shape Trees

While the RDF structure of shape trees enable machine readability, additional context is needed to make it human-friendly.

External SKOS graphs can be OPTIONALLY linked to describe the shape tree in human-readable terms.

SKOS constructs such as skos:narrower MAY be used to group or organize related shape trees.

6. Definitions

The following terms are used throughout this specification:

Conformance

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.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

Index

Terms defined by this specification

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

Informative References

[LDP]
Steve Speicher; John Arwe; Ashok Malhotra. Linked Data Platform 1.0. 26 February 2015. REC. URL: https://www.w3.org/TR/ldp/
[RDF11-PRIMER]
Guus Schreiber; Yves Raimond. RDF 1.1 Primer. 24 June 2014. NOTE. URL: https://www.w3.org/TR/rdf11-primer/
[RFC6570]
J. Gregorio; et al. URI Template. March 2012. Proposed Standard. URL: https://tools.ietf.org/html/rfc6570
[SHACL]
Holger Knublauch; Dimitris Kontokostas. Shapes Constraint Language (SHACL). 20 July 2017. REC. URL: https://www.w3.org/TR/shacl/
[ShEx]
Eric Prud'hommeaux; et al. Shape Expressions Language 2.1. URL: http://shex.io/shex-semantics/index.html
[SKOS-REFERENCE]
Alistair Miles; Sean Bechhofer. SKOS Simple Knowledge Organization System Reference. 18 August 2009. REC. URL: https://www.w3.org/TR/skos-reference/

Issues Index

Must detail how to differentiate between ShEx and SHACL validation