SHACL 1.2 Profiling W3C First Public Working Draft 02 July 2026 More details about this document This version: https://www.w3.org/TR/2026/WD-shacl12-profiling-20260702/ Latest published version: https://www.w3.org/TR/shacl12-profiling/ Latest editor's draft: https://w3c.github.io/data-shapes/shacl12-profiling/ History: https://www.w3.org/standards/history/shacl12-profiling/ Commit history Editors: Nicholas Car ( KurrawongAI ) Alex Nelson ( National Institute of Standards and Technology ) Yousouf Taghzouti ( Inria ) Scott Henninger ( JPMorgan Chase & Co. ) Matt Goldberg ( Corning ) Feedback: GitHub w3c/data-shapes ( pull requests , new issue , open issues ) Copyright © 2025-2026 World Wide Web Consortium . W3C ® liability , trademark and permissive document license rules apply. Abstract This document defines SHACL Profiling . SHACL, the Shapes Constraint Language, is a language for describing the structure of RDF graphs. SHACL may be used for a variety of purposes such as validating, inferencing, modeling domains, generating ontologies to inform other agents, building user interfaces, generating code, and integrating data. SHACL Profiling defines elements of the SHACL Shapes Constraint Language created to allow for profiles of SHACL and profiling with SHACL. This document's scope is limited to profiling of RDF graphs, including graphs containing SHACL Shapes. This specification is published by the Data Shapes Working Group . Status of This Document This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index . This document was published by the Data Shapes Working Group as a First Public Working Draft using the Recommendation track . Publication as a First Public Working Draft does not imply endorsement by W3C and its Members. This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress. This document was produced by a group operating under the W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy . This document is governed by the 18 August 2025 W3C Process Document . Table of Contents Abstract Status of This Document SHACL Specifications Document Outline 1. Introduction 1.1 What is profiling? 1.2 Scope 1.3 Terminology 1.4 Document Conventions 1.5 Conformance 2. Packaging SHACL 2.1 Motivation 2.2 Recommendations Summary 2.3 Identifying groups of SHACL elements 2.4 Indicating Element definition 2.5 Indicating Element use 2.6 Indicating group dependence 2.7 Calculating Dependencies 2.8 Indicating Validity 3. Profiling of SHACL 3.1 Defining Profiles of SHACL 3.2 Known Profiles of SHACL 3.3 Other Profiles 3.4 Creating other Profiles 4. Profiling with SHACL 4.1 Profiling Specifications 4.1.1 Characterizing the profiling situation 4.1.2 Implications for data 4.2 Profiling Data 4.3 Profile Part Roles 4.4 Profile Hierarchies 4.5 Creating Null Profiles 5. SHACL Profiling Vocabulary 5.1 Class: Shapes Graph 5.1.1 Property: imports 5.1.2 Property: member 5.2 Class: Data Graph 5.2.1 Property: conforms to 5.2.2 Property: validation report 5.3 Class: Validation Report 5.3.1 Property: used shapes graph 5.3.2 Property: conforms 5.4 Class: Shape 5.4.1 Property: is defined by 5.5 Rule: conforms to A. Profiles of SHACL A.1 Specification Profiles A.2 Union Profile A.3 SHACL 1.2 UI Profile A.4 CD1 Profile A.5 SHACL 1.0 Profile A.6 Pretty Print Profile A.7 OWL Consistent Profile B. Null Profile Examples B.1 Null Profile of POS B.2 Null Profile of PROF C. Security and Privacy Considerations D. Acknowledgements E. Internationalization Considerations F. Index F.1 Terms defined by this specification F.2 Terms defined by reference G. Issue summary H. References H.1 Normative references H.2 Informative references SHACL Specifications This specification is part of the SHACL 1.2 family of specifications. See the SHACL 1.2 Overview for a more detailed introduction to them. The specifications are as follows: Working Drafts: SHACL 1.2 Core defines the Core of SHACL SHACL 1.2 SPARQL Extensions defines SPARQL-related extensions of SHACL SHACL 1.2 Node Expressions defines graph expressions used to determine focus nodes in SHACL SHACL 1.2 Rules defines SHACL's methods of rule-based inference SHACL 1.2 UI defines SHACL's use for User Interface generation SHACL 1.2 Profiling defines the use of SHACL for profiling data, including SHACL data Working Group Note Drafts: SHACL 1.2 Overview overviews the set of SHACL specifications SHACL 1.2 Compact Syntax defines an RDF syntax for expressing SHACL concepts Note Implementers can partially check their level of conformance with the above specifications by successfully passing the test cases of the SHACL 1.2 test suite . Note, however, that passing all the tests in the test suite does not imply complete conformance to the specifications. It only implies that the implementation conforms to the aspects tested by the test suite. Document Outline The introduction provides background concepts of profiling and states this specification's scope. It also provides term definitions and describes document conventions. Section 2 covers packaging of SHACL for management. Sections 3 & 4 cover the two main modes of profiling with SHACL, building on packaging. 1. Introduction 1.1 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 The Profiles Vocabulary . 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. The Profiles Vocabulary 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 . 1.2 Scope With the above section's concepts in mind, this specification defines the following: packaging SHACL profiles of SHACL profiling with SHACL 1.3 Terminology Terminology used throughout this specification is either defined here or taken from one of several sources. Those other sources are: The Profiles Vocabulary general profiling terminology and profiling ontology terms SHACL 1.2 Core SHACL technical terminology RDF 1.2 Concepts and Abstract Data Model 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 The Profiles Vocabulary . See Issue dx-prof/56 . All the defined terms used in this specification are listed in the index . 1.4 Document Conventions Within this specification, the following namespace prefix definitions are used: Prefix Namespace 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# 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. # This box presents RDF data in the Turtle syntax
<s> <p> <o> . Conventions within figures are described by this key: Figure 1 Figure key 1.5 Conformance 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 key words MAY , MUST , MUST NOT , RECOMMENDED , SHOULD , and SHOULD NOT in this document are to be interpreted as described in BCP 14 [ RFC2119 ] [ RFC8174 ] when, and only when, they appear in all capitals, as shown here. 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 ] 2. Packaging SHACL Packaging of SHACL is the presentation of SHACL elements in relation to container objects. 2.1 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: Identify groups of SHACL elements Find all the SHACL elements that a group depends on Find all the groups of SHACL elements that a group depends on Issue 624 : Identify groupings of SHACL elements Profiles UCR Identify the SHACL Elements grouped together for a stated purpose. Issue 622 : Find all the SHACL Elements depended upon by a grouping Profiles UCR Find all the Shapes that a Profile depends on. Issue 623 : Find all the groupings of SHACL Elements depended upon by a grouping Profiles UCR Find all the Profiles that a Profile depends on. 2.2 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 : Instances of sh:ShapesGraph SHOULD be used to group instances of SHACL elements An instance of a SHACL element SHOULD indicate the instance of a sh:ShapesGraph that defines it with the rdfs:isDefinedBy predicate 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 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. 2.3 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 OWL 2 Web Ontology Language RDF-Based Semantics (Second Edition) '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. 2.4 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: ex:ont-M a sh:ShapesGraph ; .
ex:shape-1 a sh:NodeShape ; rdfs:isDefinedBy ex:ont-M ; . Note In Section 2.5 Syntactic Variations of Shapes and Classes of SHACL 1.2 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. 2.5 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: # 'Ontology M' uses a Shape defined by 'Ontology Other' ex:ont-M a sh:ShapesGraph ; rdfs:member ex:shape-1 ; .
ex:ont-Other a sh:ShapesGraph ; .
ex:shape-1 a sh:NodeShape ; rdfs:isDefinedBy ex:ont-Other ; . 2.6 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. # 'Ontology N' imports 'Ontology M' ex:ont-M a owl:Ontology ; .
ex:ont-N a owl:Ontology ; owl:imports ex:ont-M ; . 2.7 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 2.8 Indicating Validity Issue 770 : Record the shape of a dataset via SHACL validation Profiles UCR Is this UC answered here? 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 . 3. Profiling of SHACL This section describes how existing profiles of SHACL 1.2 are made, gives examples of some and indicates how to create more profiles of SHACL. See Annex A for a listing of profiles of SHACL known at the time of this specification's publication and for links to community managed profiles. 3.1 Defining Profiles of SHACL Profiles of SHACL should be declared using The Profiles Vocabulary . The declaration of the Core profile of SHACL 1.2 is as follows: # declaration of the Core profile <http://www.w3.org/ns/shacl/profile/core> a prof:Profile ; prof:isProfileOf <https://www.w3.org/TR/shacl/> ; prof:hasResource <https://www.w3.org/TR/shacl12-core/> , <http://www.w3.org/ns/shacl-shacl/core> ; .
# Core specification <https://www.w3.org/TR/shacl12-core/> a prof:ResourceDescriptor ; prof:hasRole role:Specification ; dcterms:format "text/html" ; dcterms:conformsTo <http://www.w3.org/TR/html5/> ; prof:hasArtifact <https://www.w3.org/TR/shacl12-core/> ; .
# Core validator <http://www.w3.org/ns/shacl-shacl/core> a prof:ResourceDescriptor ; prof:hasRole role:Validation ; dcterms:format "text/turtle" ; dcterms:conformsTo <https://www.w3.org/TR/shacl/> ; prof:hasArtifact <http://www.w3.org/ns/shacl-shacl/core> ; . 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 The Profiles Vocabulary , 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 . Note 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. 3.2 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 . 3.3 Other Profiles Here are some other profiles of SHACL that use different logic to scope their contents. Issue 826 : Indicate an existing computationally-defined profile of SHACL Profiles Indicate a computationally-defined profile of SHACL to showcase the Packaging SHACL and Profiles of SHACL mecahnics in the SHACL Profiling specification. 3.4 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 OWL 2 Web Ontology Language Profiles (Second Edition) . 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 : Identify the profile with an IRI Define the profile as profiles of SHACL 1.2 as defined in this specification See Appendix A Share the profile with the SHACL user community See the SHACL Resources Repository for information on SHACL community resource sharing 4. Profiling with SHACL Issue 546 : [PROF] Scope of Profiling with SHACL Profiles This section describes how to create profiles of different kinds of things with SHACL. General profiling terms and elements from The Profiles Vocabulary are used as well as more specialised SHACL profiling elements defined in the 5. SHACL Profiling Vocabulary . 4.1 Profiling Specifications Note Aligning with The Profiles Vocabulary , we take the term Specification to be synonymous with the term Standard . Figure 2 Figure of profiling of specifications, characterizing an example following the style guidance of The Profiles Vocabulary 4.1.1 Characterizing the profiling situation Issue 617 : [PROF] Use case: SKOS profiles Profiles UCR Is the situation characterization part of this UC answered here? Issue 764 : Use case for SHACL profiling of data: multi-model interoperability Profiles UCR Is this UC answered here? SHACL is often used to test whether data matches a known Specification . If the SHACL used for such testing implements no rules other than those in the specification, the SHACL shapes graph creates a null profile of the specification. If a Shapes Graph implements more/different rules than just those in the specification, then it is testing for a (non-null) profile of the specification. If a Shapes Graph SG1 is profiling a specification S1 then, following the characterisation of The Profiles Vocabulary : <SG1> a prof:Profile ; prof:isProfileOf <S1> ; . However, SG1 is also playing the role of Validation , so a more complete The Profiles Vocabulary characterisation of the situation would be: <SG1> a prof:Profile ; prof:isProfileOf <S1> ; prof:hasResource [ prof:hasArtifact <SG1> ; prof:hasRole role:validation ; ] ; . This is an unexpected use of The Profiles Vocabulary , where the profile is also playing a role usually performed by a part of, or one of, the resources of the profile, rather than having a single profile resource playing all roles, but it is legitimate, and will still achieve the PROF goal of allowing a conceptual profile to indicate a resource that performs a common profiling resource role — validation. To indicate that a profile resource is using SHACL 1.2 Core and available in Turtle, the following can also be added to the characterisation: <SG1> a prof:Profile ; prof:isProfileOf <S1> ; prof:hasResource [ prof:hasArtifact <S1> ; prof:hasRole role:validation ; dcterms:conformsTo <https://www.w3.org/TR/shacl12-core/> ; dcterms:format "text/turtle" ; ] ; . If SG1 is also considered the normative expression of the profile's requirements, as opposed to perhaps a separate human language document containing them, then the prof:hasRole value of role:constraints may also be applied to the resource. If there is no separate human language document about the profile, then the prof:hasRole value of role:specification may also be applied to the resource. This is not optimal, however, as role:specification is specified to "[define] the profile in human-readable form" and while SHACL is human-readable, natural language prose is expected. <SG1> a prof:Profile ; prof:isProfileOf <S1> ; prof:hasResource [ prof:hasArtifact <S1> ; prof:hasRole role:constraints , role:specification , role:validation ; dcterms:conformsTo <https://www.w3.org/TR/shacl12-core/> ; dcterms:format "text/turtle" ; ] ; . What Use Cases does this reasoning address? 4.1.2 Implications for data As per 2.8 Indicating Validity , we can indicate the validity of a data graph according to a shapes graph with the predicate sh:conformsTo . This predicate is a sub property of the [ DCTERMS ] predicate dcterms:conformsTo used in The Profiles Vocabulary . Following Figure 2 , if we have <DG1> sh:conformsTo <SG1> , which may have been asserted after testing the conformance of the Data Graph to the Shapes Graph by validation we can infer that: <DG1> dcterms:conformsTo <SG1> . # via RDFS or OWL-RL reasoning Following the The Profiles Vocabulary axiom of dcterms:conformsTo owl:propertyChainAxiom ( dcterms:conformsTo prof:isProfileOf ) then, if given <DG1> dcterms:conformsTo <SG1> . and <SG1> prof:isProfileOf <S1> . we can conclude that <DG1> dcterms:conformsTo <S1> . This reasoning allows for static conformance claims of data to profiles of specifications and specifications themselves to be made which will have utility for data whose conformance to these things must be known but which cannot be continuously validated. 4.2 Profiling Data Section content removed as duplicative of Profiling Specifications above. 4.3 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. The Profiles Vocabulary is expected to be used for this. Referencing The Profiles Vocabulary '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. 4.4 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 The Profiles Vocabulary , 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 4.5 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: Data Catalog Vocabulary (DCAT) - Version 3 , Schema.org , The RDF Data Cube Vocabulary , and many W3C standards. Note While null profiles of specifications can be created using mechanism other than SHACL, here we focus only on the use of SHACL. An example of a non-SHACL validator for RDF data that acts as a null profile is the W3C 's Constraints of the PROV Data Model which provides a list of constraints that apply to provenance data formulated according to PROV-O: The PROV Ontology . Constraints of the PROV Data Model implements no constraints beyond those stated or implied in PROV-O: The PROV Ontology and the conceptual PROV-DM: The PROV Data Model , however it does include tests for things that the models do not explicitly model but whose proper use requires, e.g., for ordering of temporal entities. Implementations of those constraints have been made as Python scripts that execute SPARQL queries, allowing for RDF data validation. 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 B. Null Profile Examples for examples of null profiles of other specifications. 5. SHACL Profiling Vocabulary Figure 3 SHACL Profiling Vocabulary Issue 805 : Profile generalization and implications for dcterms:conformsTo reasoning Profiles All elements of this vocabulary are members of the SHACL Core vocabulary, which has RDF serializations available at its namespace location of http://www.w3.org/ns/shacl# . 5.1 Class: Shapes Graph RDF Class: sh:ShapesGraph Is defined by: SHACL 1.2 Core Sub-class of: owl:Ontology Definition: A shapes graph is an RDF graph containing zero or more shapes that is passed into a SHACL validation process so that a data graph can be validated against the shapes. See also: SHACL 1.2 Core: Shapes Graph Scope note: For the purposes of SHACL profiling, this class is to be used to group SHACL elements together, as per Section 2.3 Identifying groups of SHACL elements . 5.1.1 Property: imports RDF Property: owl:imports Is defined by: OWL Web Ontology Language Reference Definition: The property that is used for importing other ontologies into a given ontology. Domain: owl:Ontology Range: owl:Ontology See also: OWL Web Ontology Language Reference: importing an ontology Scope note: For the purposes of SHACL profiling, this predicate is to be used to indicate dependency between Shapes Graphs, as per Section 2.6 Indicating group dependence . 5.1.2 Property: member RDF Property: rdfs:member Is defined by: RDF 1.2 Schema Definition: A member of the subject resource. Domain: Resource Range: Resource See also: RDF 1.2 Schema: member Scope note: For the purposes of SHACL profiling, this predicate is to be used to associate a Shapes Graph with each Shape that it uses, whether defined by it or elsewhere, as per Section 2.5 Indicating Element use . 5.2 Class: Data Graph RDF Class: sh:DataGraph Is defined by: SHACL 1.2 Core Definition: Any RDF graph can be a data graph. Usage note: Use this class to represent RDF graphs that you wish to make conformance claims for. For example, record graphs of RDF data as Data Graphs when testing their conformance according to the GeoSPARQL 1.1 standard's Shapes Graph ( http://www.opengis.net/def/geosparql/validator ). See also: SHACL 1.2 Core: Data Graph Scope note: For the purposes of SHACL profiling, this class is to be used to represent RDF data that is to have SHACL-related claims made about it. 5.2.1 Property: conforms to RDF Property: sh:conformsTo Is defined by: SHACL 1.2 Core Sub-property of: dcterms:conformsTo Definition: The subject conforms to the object if validated did not produce any validation results with a severity level of the set of disallowed levels. Domain: Data Graph Range: Shapes Graph 5.2.2 Property: validation report RDF Property: sh:validationReport Is defined by: SHACL 1.2 Core Definition: A Validation Report that exists for the subject. Domain: Data Graph Range: Validation Report 5.3 Class: Validation Report RDF Class: sh:ValidationReport Is defined by: SHACL 1.2 Core Definition: A validation report is the result of a validation process that reports the conformance and the set of all validation results of a Data Graph with respect to a Shapes Graph. See also: SHACL 1.2 Core: Validation Report 5.3.1 Property: used shapes graph RDF Property: sh:usedShapesGraph Is defined by: SHACL 1.2 Core Definition: The subject Validation Report was generated using the object Shapes Graph. Domain: Validation Report Usage note: The version IRI of a Shapes Graph may also be used as an object for this property. Range: Shapes Graph 5.3.2 Property: conforms RDF Property: sh:conforms Is defined by: SHACL 1.2 Core Definition: Represents the outcome of the conformance checking the Validation Report is describing. Domain: Validation Report Range: boolean See also: SHACL 1.2 Core: conforms 5.4 Class: Shape RDF Class: sh:Shape Is defined by: SHACL 1.2 Core Definition: A shape is a collection of constraints that may be targeted for certain nodes. See also: SHACL 1.2 Core: Shape 5.4.1 Property: is defined by RDF Property: rdfs:isDefinedBy Is defined by: RDF 1.2 Schema Definition: The subject used the object when determining validity of a tested Data Graph. Domain: Validation Report Range: Shapes Graph See also: RDF 1.2 Schema: isDefinedBy 5.5 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 SPARQL 1.2 Query Language rule and a SHACL 1.2 Rules rule. CONSTRUCT { ?x sh:conformsTo ?z } WHERE { ?x sh:validationReport ?y .
?y sh:usedShapesGraph ?z ; sh:conforms true ; . } RULE { ?x sh:conformsTo ?z } WHERE { ?x sh:validationReport ?y .
?y sh:usedShapesGraph ?z ; sh:conforms true ; . } A. Profiles of SHACL This appendix lists profiles of SHACL 1.2 known at the time of this specification's publication, formulated as per the section Profiling of SHACL . It also indicates where the W3C 's SHACL community maintains an informal register of profiles of SHACL that can be added to after this document has been finalised A.1 Specification Profiles The definition of each of the 7 Specification Profiles in RDF are available here: Core Profile SPARQL Profile Node Expressions Profile Rules Profile UI Profile Profiling Profile The Union Profile definition is available in RDF too: Union Profile A.2 Union Profile The Union Profile of SHACL 1.2 is the conceptual whole of SHACL 1.2 which covers all aspects of the SHACL 1.2 series of Specifications . There is no single human-readable Union Profile specification document — you must read all the documents individually, as linked from the specification section — but there is a single validation resource: a shapes graph comprising all the individual profiles' validation shapes graphs . The Union Profile shapes graph is given in the SHACL 1.2 Overview's SHACL-SHACL appendix . A.3 SHACL 1.2 UI Profile Issue 827 : [PROF/UI] SHACL UI Profiling Use Case UI Profiles UCR Allow SHACL UI implementations to define a profile of SHACL UI that explicitly states the set of features they support The SHACL 1.2 UI profile of SHACL is a subset of the vocabulary elements of SHACL Core selected for their ease of implementation as user interface components as implemented for the SHACL 1.2 UI specification. TODO A.4 CD1 Profile Issue 847 : Create a computational complexity-defined profile of SHACL Profiles UCR Exemplify a computational complexity-defined profile of SHACL and show how to create others Issue 242 : define sh:ReferenceShape, sh:SimpleShape to be able to limit validation effort Postponed Profiles The CD1 ("Computationally-Defined #1") profile of SHACL is a subset of the vocabulary elements of SHACL Core, SPARQL and Node Expressions vocabulary elements selected for their computational simplicity. The reason for defining this CD1 profile is twofold: Profile a real, computational complexity-defined profile Indicate how other profiles using similar logic may be defined This profile is defined in the resource http://www.w3.org/ns/shacl/profile/cd1 , a portion of which is as follows: <http://www.w3.org/ns/shacl/profile/cd1> a owl:Ontology , prof:Profile ; prof:isProfileOf sh: ; rdfs:label "CD1 Profile of SHACL"@en ; rdfs:comment """This is a Profile of SHACL 1.2 that excludes shapes found to be computationally intensive.
Vocabulary elements of SHACL that are not listed as members of this profile may not be used for implementations claiming conformance to this profile."""@en ; rdfs:member sh:AbstractResult , sh:AndConstraintComponent , # ... many skipped members sh:xone , sh:zeroOrMorePath , sh:zeroOrOnePath ; . All the class and property elements of SHACL 1.2 are listed where ... many skipped members is indicated above except for: blah:BlahBlah blah:OtherBlah TODO A.5 SHACL 1.0 Profile Issue 872 : SHACL 1.0 Profile of SHACL Profiles UCR A.6 Pretty Print Profile The Pretty Print profile of SHACL is a subset of the vocabulary elements of SHACL that are selected to ensure "pretty" - easy to read - error messages are generated by validation processes. A.7 OWL Consistent Profile The Owl Consistent profile of SHACL is a subset of the vocabulary elements of SHACL that are selected to ensure shapes definitions do not violate OWL constraints on the classes and predicates they target. B. Null Profile Examples This section is non-normative. This appendix contains examples of null profiles of other specifications. B.1 Null Profile of POS This profile is a null profile of the Basic Geo (WGS84 lat/long) Vocabulary . The purpose of this profile is to demonstrate what a null profile of a very simple RDF vocabulary looks like. TODO - see file pos.ttl in repo B.2 Null Profile of PROF This profile is a null profile of The Profiles Vocabulary . The purposes of this profile are to both provide a SHACL-based validator for PROF data and to demonstrate what a slightly more complex null profile of a vocabulary looks like. This null profile implements all the OWL rules of PROF as well as some rules stated in the PROF specification that are not implemented in the PROF ontology. TODO C. Security and Privacy Considerations This section is non-normative. Like most RDF-based technologies, SHACL processors may operate on graphs that are assembled from various sources. Some applications may have an open "linked data" ("LD") architecture and dynamically assemble RDF triples from sources that are outside an organization's network of trust. Since RDF allows anyone to add statements about any resource, triples may modify the originally intended semantics of shape definitions or nodes in a data graph and thus feed into misleading results. Protection against this (and the following) scenario is achievable by using only trusted and verified RDF sources and eliminating the possibility that graphs are dynamically added via owl:imports and sh:shapesGraph . When creating profiles of other specifications, profile creators need to ensure that their constraints do not violate those specification's rules. If any did so, and if only the profile's rules, but not the specification's rules, were used to check for data validity, by accident or by design, data could be wrongly calculated to be valid. This could lead to accidental data release or use, potentially introducing security issues. D. Acknowledgements This section is non-normative. Many people contributed to this specification, including members of the RDF Data Shapes Working Group. E. Internationalization Considerations TODO F. Index F.1 Terms defined by this specification null profile §1.3 SHACL Element §1.3 F.2 Terms defined by reference [ DX-PROF ] defines the following: profile specification [ OWL2-SYNTAX ] defines the following: version IRI [ RDF12-CONCEPTS ] defines the following: IRIs named graph [ RDF12-SCHEMA ] defines the following: RDF 1.2 Schema: isDefinedBy RDF 1.2 Schema: member [ SHACL12-CORE ] defines the following: 2.5 Syntactic Variations of Shapes and Classes blank nodes data graph property shapes SHACL 1.2 Core: conforms SHACL 1.2 Core: Shape SHACL 1.2 Core: Validation Report shapes graph validated validation G. Issue summary Issue 624 : Identify groupings of SHACL elements Issue 622 : Find all the SHACL Elements depended upon by a grouping Issue 623 : Find all the groupings of SHACL Elements depended upon by a grouping Issue 770 : Record the shape of a dataset via SHACL validation Issue 826 : Indicate an existing computationally-defined profile of SHACL Issue 546 : [PROF] Scope of Profiling with SHACL Issue 617 : [PROF] Use case: SKOS profiles Issue 764 : Use case for SHACL profiling of data: multi-model interoperability Issue 805 : Profile generalization and implications for dcterms:conformsTo reasoning Issue 827 : [PROF/UI] SHACL UI Profiling Use Case Issue 847 : Create a computational complexity-defined profile of SHACL Issue 242 : define sh:ReferenceShape, sh:SimpleShape to be able to limit validation effort Issue 872 : SHACL 1.0 Profile of SHACL H. References H.1 Normative references [DCTERMS] DCMI Metadata Terms . DCMI Usage Board. DCMI. 20 January 2020. DCMI Recommendation. URL: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/ [dx-prof] The Profiles Vocabulary . Nicholas Car. W3C. 18 December 2019. W3C Working Group Note. URL: https://www.w3.org/TR/dx-prof/ [owl-ref] OWL Web Ontology Language Reference . Mike Dean; Guus Schreiber. W3C. 10 February 2004. W3C Recommendation. URL: https://www.w3.org/TR/owl-ref/ [owl2-rdf-based-semantics] OWL 2 Web Ontology Language RDF-Based Semantics (Second Edition) . Michael Schneider. W3C. 11 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-rdf-based-semantics/ [owl2-syntax] OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition) . Boris Motik; Peter Patel-Schneider; Bijan Parsia. W3C. 11 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-syntax/ [rdf12-concepts] RDF 1.2 Concepts and Abstract Data Model . Andy Seaborne; Gregg Kellogg; Olaf Hartig; Pierre-Antoine Champin. W3C. 7 April 2026. W3C Candidate Recommendation. URL: https://www.w3.org/TR/rdf12-concepts/ [rdf12-schema] RDF 1.2 Schema . Dominik Tomaszuk. W3C. 28 March 2026. W3C Working Draft. URL: https://www.w3.org/TR/rdf12-schema/ [RFC2119] Key words for use in RFCs to Indicate Requirement Levels . S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc2119/ [RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words . B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc8174/ [schema-org] Schema.org . W3C Schema.org Community Group. W3C. 6.0. URL: https://schema.org/ [shacl12-core] SHACL 1.2 Core . Holger Knublauch; Thomas Bergwinkl; Yousouf Taghzouti; Jesse Wright. W3C. 22 June 2026. W3C Working Draft. URL: https://www.w3.org/TR/shacl12-core/ [shacl12-rules] SHACL 1.2 Rules . Robert David; David Habgood; Andy Seaborne; Simon Steyskal. W3C. 19 June 2026. W3C Working Draft. URL: https://www.w3.org/TR/shacl12-rules/ [sparql12-query] SPARQL 1.2 Query Language . Olaf Hartig; Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 25 June 2026. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-query/ [vocab-data-cube] The RDF Data Cube Vocabulary . Richard Cyganiak; Dave Reynolds. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/vocab-data-cube/ [vocab-dcat-3] Data Catalog Vocabulary (DCAT) - Version 3 . Simon Cox; Andrea Perego; Alejandra Gonzalez Beltran; Peter Winstanley; Riccardo Albertoni; David Browning. W3C. 22 August 2024. W3C Recommendation. URL: https://www.w3.org/TR/vocab-dcat-3/ H.2 Informative references [LDP] LinkedData . W3C. URL: https://www.w3.org/wiki/LinkedData [owl2-profiles] OWL 2 Web Ontology Language Profiles (Second Edition) . Boris Motik; Bernardo Cuenca Grau; Ian Horrocks; Zhe Wu; Achille Fokoue. W3C. 11 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-profiles/ [prov-constraints] Constraints of the PROV Data Model . James Cheney; Paolo Missier; Luc Moreau. W3C. 30 April 2013. W3C Recommendation. URL: https://www.w3.org/TR/prov-constraints/ [prov-dm] PROV-DM: The PROV Data Model . Luc Moreau; Paolo Missier. W3C. 30 April 2013. W3C Recommendation. URL: https://www.w3.org/TR/prov-dm/ [prov-o] PROV-O: The PROV Ontology . Timothy Lebo; Satya Sahoo; Deborah McGuinness. W3C. 30 April 2013. W3C Recommendation. URL: https://www.w3.org/TR/prov-o/ [PYSH] pySHACL - A Python validator for SHACL . RDFLib Community. URL: https://pypi.org/project/pyshacl [w3c-basic-geo] Basic Geo (WGS84 lat/long) Vocabulary . Dan Brickley. W3C Semantic Web Interest Group. 1 February 2006. URL: https://www.w3.org/2003/01/geo/ ↑ Permalink Referenced in: § 4.1.1 Characterizing the profiling situation § 4.5 Creating Null Profiles § B. Null Profile Examples § B.1 Null Profile of POS § B.2 Null Profile of PROF Permalink Referenced in: § 2. Packaging SHACL § 2.1 Motivation (2) (3) (4) § 2.2 Recommendations Summary (2) (3) (4) (5) (6) (7) § 2.3 Identifying groups of SHACL elements (2) (3) (4) § 2.4 Indicating Element definition (2) (3) (4) (5) (6) § 2.5 Indicating Element use (2) (3) (4) (5) § 2.6 Indicating group dependence (2) (3) § 5.1 Class: Shapes Graph Permalink Referenced in: § 1.1 What is profiling? § 4.1.1 Characterizing the profiling situation Permalink Referenced in: § 1.1 What is profiling? Permalink Referenced in: § 5.3.1 Property: used shapes graph Permalink Referenced in: § 2.4 Indicating Element definition Permalink Referenced in: § 2.4 Indicating Element definition Permalink Referenced in: § 5.4.1 Property: is defined by Permalink Referenced in: § 5.1.2 Property: member Permalink Referenced in: § 2.4 Indicating Element definition Permalink Referenced in: § 2.4 Indicating Element definition Permalink Referenced in: § 1.1 What is profiling? (2) (3) (4) (5) § 1.4 Document Conventions § 2.8 Indicating Validity § 4.1.2 Implications for data § 5.2 Class: Data Graph § C. Security and Privacy Considerations Permalink Referenced in: § 2.4 Indicating Element definition Permalink Referenced in: § 5.3.2 Property: conforms Permalink Referenced in: § 5.4 Class: Shape Permalink Referenced in: § 5.3 Class: Validation Report Permalink Referenced in: § 1.1 What is profiling? (2) (3) (4) (5) § 1.4 Document Conventions § 2.8 Indicating Validity § 3.1 Defining Profiles of SHACL (2) (3) § 4.1.1 Characterizing the profiling situation § 4.1.2 Implications for data § 5.1 Class: Shapes Graph § A.2 Union Profile (2) (3) Permalink Referenced in: § 5.2.1 Property: conforms to Permalink Referenced in: § 4.1.2 Implications for data