What is profiling?

Profiling is the act of creating a "profile" of something.

Generically, in English, a "profile" of something is as follows:

The outline of a physical object or feature, or a representation of this

- Oxford English dictionary, use of the word "profile" since the 17th century

Within the world of data, a derived definition of "profile" consistent with the above is:

A summary or an extraction

In this definition, the essence of the English word is retained, since a summary or extraction of or from a data object may be an outline of it; for example, a 2D representation of a 3D spatial object. or a statistical summary of a dataset having lots of parts.

Warning: This background of profiling up to this point in the Introduction may be up-streamed to an updated version of [[[dx-prof]]].

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 in the context of a specification to be:

a specification that constrains, extends, combines, or provides guidance or explanation about the use of other specifications

If a shapes graph is taken to be a "specification," 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 SHACL shapes created for each of the SHACL Specifications.

Scope

With the above section's concepts in mind, this specification defines the following:

1. packaging SHACL
2. profiles of SHACL
3. profiling with SHACL

Terminology

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

[[[dx-prof]]]

general profiling terminology and profiling ontology terms

SHACL 1.2 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:

null profile

A profile of a specification in which implements some, and likely all, of the specification's rules, but definitely no additional rules.

The purpose of a null profile is to provide profiling artefacts, such as an executable validator, when the specification being profiled does not.

SHACL Element

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

Warning: The definition of null profile may be up-streamed to an updated version of [[[dx-prof]]]. See Issue dx-prof/56.

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/" ,
    "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#",
    "shpr": "http://www.w3.org/ns/shpr#"
  }
}

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

There are multiple reasons one might want to identify groups of SHACL elements and to know the relations between groups and individual SHACL elements. These reasons include wanting to understand the purpose(s) of a group, how a change in one group affects another group, and how to create a new group. Three Use Cases have been articulated for this:

1. Identify groups of SHACL elements
2. Find all the SHACL elements that a group depends on
3. Find all the groups of SHACL elements that a group depends on

Recommendations Summary

Solutions to the Use Cases indicated above result in the following recommendations that build on well-established practice, such as the use of instances of sh:ShapesGraph to group SHACL elements:

1. Instances of sh:ShapesGraph SHOULD be used to group instances of SHACL elements
2. An instance of a SHACL element 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, 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 SHOULD indicate dependence on other groups of SHACL elements identified using instances of sh:ShapesGraph with the owl:imports predicate

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 element.

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 subclass of owl:Ontology, be used to group SHACL elements. This is to avoid ambiguous grouping objects.

Indicating Element definition

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

Common practice when placing SHACL elements into groups identified by use of an sh:ShapesGraph 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 an sh:ShapesGraph 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 suggests 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, 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 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.

Calculating Dependencies

Dependency implications can be drawn from the use of the four recommendations above which can be used to answer the three Use Cases indicated in the Motivation section.

TODO

Indicating Validity

It may be necessary to persist the result of a validation action performed on a data graph by a shapes graph in RDF. If so, a data graph DG MAY be indicated as being conformant to the shapes graph SG using the predicate shpr:conformsTo. In this situation, DG will be inferred to be an instance of sh:DataGraph and SG an instance of sh:ShapesGraph.

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 2015 and that it has two profile resources: a specification and a 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.

The shapes graph validation resources are given in SHACL 1.2 Overview's SHACL-SHACL appendix.

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

Describe how to pick and choose SHACL elements to support in your profile using Packaging of SHACL.

Known Profiles of SHACL

A profile of SHACL 1.2 for each of the specifications listed above is known at the time of this specification's publication. In addition, a union profile - all the specification profiles combined - is also known.

A computational effort-defined profile of SHACL and a SHACL UI implementation effort-defined profile of SHACL are also known.

These known profiles are listed in Appendix A and future profiles of SHACL are to be listed in the W3C SHACL community controlled repository at https://github.com/w3c/shacl-resources.

Other Profiles

Here are some other profiles of SHACL that use different logic to scope their contents.

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 computation 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.

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 — the Specification Profiles and the Union Profile — 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. Define the profile as profiles of SHACL 1.2 as defined in this specification
   • See Appendix A
3. Share the profile with the SHACL user community
   • See the SHACL Resources Repository for information on SHACL community resource sharing

Profiling Specifications

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

Profiling Data

Section content removed as duplicative of Profiling Specifications above.

Profile Part Roles

SHACL is a language that can implement constraints and inference rules for RDF data. These two things are not the complete set of things that a profile designer may wish to do; for example, they may want to include documentation about why and how the profile was created, or provide new model elements (classes, predicates, etc.) within an extended schema.

Since SHACL cannot be used for all possible profile parts, profile designers need to look to specifications outside the SHACL family of specifications for guidance on a profile's total set of parts and how to relate them to one another. [[[dx-prof]]] is expected to be used for this.

Referencing [[[dx-prof]]]'s vocabulary of Resource Role Instances, it seems clear that SHACL graphs can perform the role of Validation within a profile and perhaps also the role of Specification, since SHACL can be used to declare Node and Property Shapes just as OWL can be used to declare Classes and Properties.

SHACL shapes naturally constrain models and data, therefore if used to indicate how a profile constrains a thing — a standard or another profile — they could perform the role of Constraints.

They could also perform the role of Mapping, if SHACL Rules are implemented to transform data from one model to another.

Profile Hierarchies

Profile hierarchies are arrangements in which a profile is a specialization of another, forming a chain where more specific profiles inherit constraints from broader ones. As per the rules of the [[[dx-prof]]], if C is a profile of B and B is a profile of A, then data wanting to be conformant to C can only be valid if it is also conformant to B and A.

Checking conformance of data to profiles means testing the data with a profile resource with the Validation role.

Incomplete

Creating Null Profiles

A null profile of a specification, created using SHACL, is a profile of that specification in which SHACL is used to implement some, and likely all the specification's rules, but no other rules, in SHACL.

The main purpose of creating a null profile of a specification using SHACL is to enable the testing of conformance to that specification by SHACL validation. This purpose exists because many RDF data models exist that have a model specification, perhaps an OWL model or only a natural-language document of a model, but do not provide a mechanism for data validation, such as a SHACL validator. Examples of such models are: [[[vocab-dcat-3]]], [[[schema-org]]], [[[vocab-data-cube]]], and many W3C standards.

No universal and precise methodology can be given for creation of a null profile of a specification, because, by the task's very nature, the specification's rule(s) may be imprecisely defined, and thus the method used to characterize them in SHACL, which is precise, will vary just as the imprecise rule definition does.

See [[[#null-profile-examples]]] for examples of null profiles of other specifications.

Class: Shapes Graph

Class: Data Graph

Class: Validation Report

Class: Shape

Rule: conforms to

The rule 'conforms to' is a reasoning rule that allows for a Data Graph to be indicated as conforming to a Shapes Graph if there is a Validation Report associated with the Data Graph which indicates the Shapes Graph was used for validation and the 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.