What is SHACL profiling?

By definition, SHACL constrains RDF data, therefore, any data that is valid according to a shapes graph will be a profile of the data graph. If a shapes graph validates all elements of a data graph, the resulting valid data will be a "null" profile of the data graph, meaning it is identical to the original data graph.

[[[dx-prof]]] defines a profile to be:

a standard that constrains, extends, combines, or provides guidance or explanation about the use of other standards

If a shapes graph is taken to be a "standard", then not only is the data that is valid according to the shapes graph a profile of the validated data graph, but the shapes graph itself also serves as a profile of the data model used for the data graph.

Within this document, we describe how to package SHACL information for optimal profiling, and we exemplify this with packaging of the RDF data created for each of the SHACL Specifications.

Scope

With the above section's concepts in mind, this specification defines the following, numbered as per their sections:

2. Packaging SHACL
3. Profiling of SHACL
4. Profiling with SHACL
5. SHACL Profiling Vocabulary

Terminology

Terminology used throughout this specification is either defined here or taken from one of several sources:

[[[dx-prof]]]

general profiling terminology and profiling ontology terms

[[[shacl12-core]]]

SHACL technical terminology

[[[rdf12-concepts]]]

RDF terminology

Terms taken from other sources are linked to their definitions in text.

The terms defined here are:

SHACL Element

An RDF/OWL class or property defined by one of the SHACL specifications.

All the defined terms used in this specification are listed in the index.

Document Conventions

Within this specification, the following namespace prefix definitions are used:

Within this specification, the following JSON-LD context is used:

{
  "@context": {
    "dcterms": "http://purl.org/dc/terms/",
    "ex": "http://example.com/ns#",
    "owl": "http://www.w3.org/2002/07/owl#",
    "prof": "http://www.w3.org/ns/dx/prof/" ,
    "prov": "http://www.w3.org/ns/prov#" ,
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#" ,
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "role": "http://www.w3.org/ns/dx/prof/role/" ,
    "sh": "http://www.w3.org/ns/shacl#"
  }
}

Note that the URI of the graph defining the SHACL vocabulary itself is equivalent to the namespace above, i.e., it includes the #. References to the SHACL vocabulary, e.g., via owl:imports should include the #.

Throughout the specification, color-coded boxes containing RDF graphs in Turtle and JSON-LD will appear. The color and title of a box indicate whether it is a shapes graph, a data graph, or something else. The Turtle specification fragments use the prefix bindings given above. Only the Turtle specifications will have parts highlighted.

Conventions within figures are described by this key:

This document defines extensions to the data model of the SHACL Core specification [shacl12-core] for the purposes of profiling.

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The syntactic rules specified here are given in English and use keywords MAY, MUST, MUST NOT, RECOMMENDED, SHOULD, and SHOULD NOT that are to be interpreted as described in BCP 14 [[RFC2119]] [[RFC8174]] when, and only when, they appear in all capitals, as shown here.

Conformance claims of data to this specification's rules can be tested by validation using the SHACL-SHACL Profiling validator in the SHACL-SHACL Annex of the SHACL Overview specification [shacl12-overview].

Motivation

Four Use Cases have been articulated that are resolved with guidance on the packageing of SHACL elements:

1. Identifying groups of SHACL elements
2. Finding all the SHACL elements that a group depends on
3. Finding all the groups of SHACL elements that a group depends on
4. Storing the validation results with context

Recommendations Summary

Guidance for the Use Cases indicated above are provided in the following recommendations that build on well-established practice W3C practice from the [[[rdf-schema]]], [[[owl2-overview]]] and [[[prov-o]]] specifications:

1. Instances of sh:ShapesGraph SHOULD be used to group instances of SHACL elements used for validation
2. An instance of a SHACL element used for validation SHOULD indicate the instance of a sh:ShapesGraph that defines it with the rdfs:isDefinedBy predicate
3. An instance of sh:ShapesGraph that uses a SHACL element for validation, but does not define it, SHOULD indicate the SHACL element as a member with the rdfs:member predicate
4. Instances of sh:ShapesGraph being used to group SHACL elements used for validation SHOULD indicate dependence on other groups of SHACL elements identified using instances of sh:ShapesGraph with the owl:imports predicate
5. When persisting results graph elements results, context for validation report, SHOULD be given by using elements of the SHACL Profiling Vocabulary

The following subsections detail each of these recommendations.

Identifying groups of SHACL elements

Instances of sh:ShapesGraph SHOULD be used to group instances of SHACL elements used for validation.

SHACL elements, like much other RDF definitional data, have often been grouped within instances of [[[owl2-rdf-based-semantics]]]'s owl:Ontology class.

For example, the Open Geospatial Consortium's GeoSPARQL 1.1 standard for spatial RDF data provides a SHACL validator containing 27 instances of sh:NodeShape and a similar number of instances of sh:PropertyShape within a Turtle file. The file also contains an instance of owl:Ontology presenting metadata for the validating resource, such as its modified date, a license for its use, and so on.

This recommendation supersedes that practice and recommends that sh:ShapesGraph, a specialised class defined in [[[shacl12-core]]] specifically for grouping SHACL elements, be used instead.

For mixed SHACL and OWL elements, such as NodeShapes and Class definitions, owl:Ontology SHOULD continue to be used.

Indicating Element definition

An instance of a SHACL element used for validation SHOULD indicate the instance of a sh:ShapesGraph that defines it with the rdfs:isDefinedBy predicate.

Common practice when placing SHACL elements into groups identified by use of an owl:Ontology instance has been to just contain the elements and the ontology instance in an RDF file. This is reasonable for data exchange but, when exchanged files are stored in an RDF database, associations between a container instance and the SHACL elements defined within it may be lost. If loaded into a named graph, the association might be kept with the named graph grouping the ontology and the SHACL elements but this is a non-semantic association, i.e. one not seen directly in a graph.

This recommendation is that the creator of a SHACL element SHOULD indicate the group within which the SHACL element is defined. An example of such an assertion in RDF is as follows:

In Section 2.5 Syntactic Variations of Shapes and Classes of [[[shacl12-core]]], a warning is issued that while property shapes may be declared as blank nodes, it is preferable to declare them as IRIs as this enables better reuse across graphs. If including information about the shapes as per this section, IRIs SHOULD be used.

Indicating Element use

An instance of sh:ShapesGraph that uses a SHACL element for validation, but does not define it, SHOULD indicate the SHACL element as a member with the rdfs:member predicate.

When a SHACL element is used within a group of elements but not defined by it, it SHOULD NOT be indicated as being defined by that group, so the recommendation in the section above is irrelevant. Reuse of SHACL elements within groups that do not define them is expected and encouraged, according to Linked Data principles [[?LDP]].

An example of the use of the rdfs:member predicate to indicate inclusion of a SHACL element in a group that does not define it, as well use of rdfs:isDefinedBy, as in the example above, is as follows:

Indicating group dependence

Instances of sh:ShapesGraph being used to group SHACL elements used for validation SHOULD indicate dependence on other groups of SHACL elements identified using instances of sh:ShapesGraph with the owl:imports predicate.

It is established practice within SHACL validation tooling to import SHACL elements from one collection, such as a file containing RDF data, into another via an owl:imports instruction. Many SHACL validation engines do this, such as pySHACL [[?PYSH]], and this practice is recommended to indicate dependence from one collection/group to another, even if no particular validation engine's actions are expected to arise from the assertion: it is likely usefully informative for SHACL data management too.

An example of owl:imports is as per the example below.

Persisting validation results with context

When persisting results graph elements results, context for validation report, SHOULD be given by using elements of the SHACL Profiling Vocabulary.

To persist a results graph with that can be understood into the future, it may be necessary to associate context with the validation report. The context that is likely important to know are the validation's inputs - data graph and shapes graph - the timing of the validation and details of the systems used to perform the validation.

These details of an event - the validation - are standard things characterized by [[[prov-o]]] which provides a general model for the retention of context: provenance. We specialize the basic elements of PROV-O here in the SHACL Profiling Vocabulary below, which is a subset of [[[shacl12-core]]]'s vocabulary.

The general PROV-O provenance model, as per its starting point diagram in Figure 1, sees prov:Activity instances representing temporal events consuming - prov:used - and producing - prov:generated - things - prov:Entity instances - while being conducted by - prov:wasAssociatedWith - persons, organizations or systems - prov:Agent instances.

SHACL validation events - processing - are represented as a specialized form of prov:Activity: sh:ValidationActivity. processor objects as a specialized form of prov:Agent: sh:ValidationAgent.

SHACL 1.2 Core's Validation section specifies that the necessary inputs to processing are a data graph - sh:DataGraph - and a shapes graph - sh:ShapesGraph and processor implementations may also cater for additional resources, perhaps used for reasoning, and also defines processing as producing sh:ValidationReport instances. All these are specialized forms of prov:Entity.

Since a sh:ValidationActivity must have at least a data graph and a shapes graph as inputs, and they have very different roles, two specialized forms of prov:used are supplied to indicate them: sh:usedDataGraph and sh:usedShapesGRaph.

The figure below shows the SHACL elements mentioned above related to one another using PROV-O properties and shaped and colored according to PROV-O's Figure 1.

Using the modeling above, 'activity-centric' and 'output-linked' forms of processing may be modeled, as per the examples below. This allows for provenance with temporality and simpler provenance, respectively.

This document's conforms to shapes graph rule may be used to create a direct relationship between the data graph and shapes graph, as per 'output-liked' example above.

Defining Profiles of SHACL

Profiles of SHACL SHOULD be declared using [[[dx-prof]]]. The declaration of the Core profile of SHACL 1.2 is as follows:

This declaration identifies the Core profile with the IRI <http://www.w3.org/ns/shacl/profile/core> and indicates it is an instance of prof:Profile, that it is a profile of the original SHACL publication from 2017 and that it has three profile resources: a specification, a schema and a validator.

Due to SHACL being used to validate SHACL (see SHACL-SHACL, the data model to which the schema is indicated as conforming is this Core profile's own validator.

When described using terminology from [[[dx-prof]]], the online document form of each specification linked to above is just one of many resources that together make a profile of SHACL 1.2. The document plays the resource role of Specification — "Defining the profile in human-readable form" — and other resources play other roles. Of particular interest to SHACL users is the SHACL shapes graph for each profile that plays the role of Validation — "Supplies instructions about how to verify conformance of data to the profile". The various profiles of SHACL 1.2 may supply additional resources with other profile resource roles, for example the Core supplies the core schema — the SHACL ontology — and SHACL UI presents an extended vocabulary of terms as well as a vocabulary of UI widgets.

To validate RDF data against any of these Specification Profiles, or the Union Profile defined below, use their validation profile resources which are listed as SHACL-SHACL shapes graphs in the SHACL 1.2 Overview's SHACL-SHACL appendix.

Creating other Profiles

Additional profiles of SHACL 1.2 may be created using any criteria. For example, it may be desirable to have profiles of SHACL 1.2 Core that only implement shape types limited to particular computational complexities, much like the profiles of OWL [[[?owl2-profiles]]]. In this case, a profile definition could be made that uses the mechanisms given in the Packaging SHACL section above, to only include some of SHACL 1.2 Core's elements.

Any other criteria can be used to select SHACL elements or to constrain their use, not just computational complexity and the examples in [[[#profiles]]] show profiles created with different criteria.

When making profiles of SHACL 1.2, it is important to identify and present the profile as per the currently known profiles of SHACL 1.2 so they can be used effectively, including by others. Creators of profiles of SHACL 1.2 SHOULD:

1. Identify the profile with an IRI
2. Describe the profile using [[[dx-prof]]]
3. Define the profile building on the profiles of SHACL 1.2, as defined in this specification
   • See Appendix A
4. Share the profile with the SHACL user community
   • See the SHACL Resources Repository for information on SHACL community resource sharing

Known Profiles of SHACL

A profile of SHACL 1.2 for each of the SHACL 1.2 specifications, listed above, as known at the time of this specification's publication are given below in Appendix A's Specification Profiles. In addition, a union profile - all the specification profiles combined - is also given in Appendix A.

Multiple other profiles of SHACL have been created by the W3C's Data Shapes Working Group, and they are listed in Appendix A also. However, that listing is indicative of different kinds of profiles, such as specifications-based, computational effort based - similar to profiles of OWL [[?owl2-profiles]] and so on, but it is not intended to be a comprehensive listing of profiles of SHACL.

The W3C SHACL community-controlled repository at SHACL Resources Repository is proposed as a central point for the collection of SHACL profile definitions.

Profiling Specifications

Aligning with [[[dx-prof]]], we take the term Specification to be synonymous with the term Standard which it defines.

Profiling Data

Section content removed as duplicative of Profiling Specifications above.

Class: Shapes Graph

Class: Data Graph

Class: Validation Report

Class: Validation Agent

Class: Validation Activity

Class: Shape

Rule: conforms to shapes graph

The rule 'conforms to shapes graph' is a reasoning rule that allows a data graph to be indicated as conforming to a shapes graph if there is a Validation Report that used the data graph and shapes graph for validation and whose sh:conforms property indicates true.

This reasoning rule cannot be articulated as an OWL property chain axiom due to the test of the sh:conforms property value, so it is presented here as both a [[[sparql12-query]]] rule and a [[[shacl12-rules]]] rule.

Rule: conforms to standard

The rule 'conforms to standard' is a reasoning rule that allows for a data graph to be indicated as conforming to a Standard if the data graph conforms to a shapes graph that is a profile of that Standard. This reasoning allows for static conformance claims of data to profiles of standards and standards themselves to be made, which will have utility for data whose conformance to these things must be known but which cannot be continuously validated.

This reasoning rule is presented here as both a [[[sparql12-query]]] rule and a [[[shacl12-rules]]] rule.

The result of this rule also enables the [[[dx-prof]]] property chain axiom dcterms:conformsTo owl:propertyChainAxiom ( dcterms:conformsTo prof:isProfileOf ) to propagate conformance claims up a profile hierarchy.