- This specification defines elements of the SHACL Shapes Constraint Language created to allow for profiles of SHACL and profiling with SHACL. -
-- SHACL is a language for validating RDF graphs against a set of conditions, so this document's scope is limited to profiling of RDF graphs, including graphs containing SHACL Shapes. -
- -
- The namespace for SHACL Profiling terms is http://www.w3.org/ns/shpr#
-
- The suggested prefix for the SHACL Profiling namespace is shpr
-
- The introduction provides background concepts of profiling and states this specification's scope. -
-- Sections 2 & 3 cover the two main elements within the stated scope. -
-- 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. -
-- 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 that was validated. 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 W3C's Profiles Vocabulary [[dx-prof]] has defined "data profiling" in the context of specifications or data specifications: -
-- A data specification that constrains, extends, combines, or provides guidance or explanation about the use of other data specifications. -
-- If a shapes graph is taken to be a "data 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. -
-- With the above section's concepts in mind, this specification defines the following: -
-- Terminology used throughout this specification is taken from several sources: -
-- The SHACL & RDF terms include: - - binding - - , - - blank node - - , - - conformance - - , - - constraint - - , - - constraint component - - , - - data graph - - , - - datatype - - , - - failure - - , - - focus node - - , - - RDF graph - - , - ill-formed - , - IRI - , - - literal - - , - - local name - - , - - member - - , - - node - - , - - node shape - - , - - object - - , - - parameter - - , - - pre-binding - - , - - predicate - - , - - property path - - , - - property shape - - , - - RDF term - - , - - SHACL instance - - , - - SHACL list - - , - - SHACL subclass - - , - - shape - - , - - shapes graph - - , - - solution - - , - - subject - - , - - target - - , - - triple - - , - validation - , - - validation report - - , - - validation result - - , - - validator - - , - - value - - , - - value node - - . -
-- The general profiling terms include: - - specification - - , - - [data] profile - - , - - metadata - - . -
-- Within this specification, the following namespace prefix definitions are used: -
-| Prefix | -Namespace | -
|---|---|
rdf: |
- http://www.w3.org/1999/02/22-rdf-syntax-ns# |
-
rdfs: |
- http://www.w3.org/2000/01/rdf-schema# |
-
sh: |
- http://www.w3.org/ns/shacl# |
-
xsd: |
- http://www.w3.org/2001/XMLSchema# |
-
ex: |
- http://example.com/ns# |
-
- Within this specification, the following JSON-LD context is used: -
-{
+ tabs.prepend(selectors);
+ }
+
+ // Add example button selection logic
+ for (const button of document.querySelectorAll(".ds-selector-tabs .selectors button")) {
+ button.onclick = () => {
+ const ex = button.closest(".ds-selector-tabs");
+ ex.querySelector("button.selected").classList.remove("selected");
+ ex.querySelector(".selected").classList.remove("selected");
+ button.classList.add('selected');
+ ex.querySelector("." + button.dataset.selects).classList.add("selected");
+ }
+ }
+ });
+
+ var respecConfig = {
+ localBiblio: {
+ LDP: {
+ title: "LinkedData",
+ href: "https://www.w3.org/wiki/LinkedData",
+ publisher: "W3C",
+ },
+ PYSH: {
+ title: "pySHACL - A Python validator for SHACL",
+ href: "https://pypi.org/project/pyshacl",
+ publisher: "RDFLib Community",
+ },
+ },
+
+ specStatus: "ED",
+ group: "wg/data-shapes",
+ github: "w3c/data-shapes",
+ //preProcess: [ ],
+ edDraftURI: "https://w3c.github.io/data-shapes/shacl12-profiling/",
+ shortName: "shacl12-profiling",
+ copyrightStart: "2025",
+ xref: ["RDF12-CONCEPTS", "SHACL-CORE"],
+
+ // (fix and) RemoveMe
+ lint: {"no-unused-dfns": false},
+
+ editors: [
+ {
+ name: "Nicholas Car",
+ company: "KurrawongAI",
+ companyURL: "https://kurrawong.ai/",
+ mailto: "nick@kurrawong.ai",
+ w3cid: 70131
+ },
+ {
+ name: "Alex Nelson",
+ company: "National Institute of Standards and Technology",
+ companyURL: "https://nist.gov/",
+ mailto: "alexander.nelson@nist.gov",
+ w3cid: "163719"
+ },
+ {
+ name: "Yousouf Taghzouti",
+ company: "Inria",
+ companyURL: "https://www.inria.fr/",
+ mailto: "yousouf.taghzouti@inria.fr",
+ w3cid: 143054
+ },
+ {
+ name: "Scott Henninger",
+ company: "JPMorgan Chase & Co.",
+ companyURL: "https://www.jpmorganchase.com/",
+ mailto: "scotthenninger@gmail.com",
+ w3cid: 80464
+ },
+ {
+ name: "Simon Werner",
+ company: "Y.digital",
+ companyURL: "https://www.y.digital/",
+ mailto: "simon@y.digital",
+ w3cid: 164386
+ }
+ ]
+ };
+
+
+
+
+
+
+ This specification defines elements of the SHACL Shapes Constraint Language created to allow for profiles of SHACL
+ and profiling with SHACL.
+
+
+ SHACL is a language for validating RDF graphs against a set of conditions, so this document's scope is limited to
+ profiling of RDF graphs, including graphs containing SHACL Shapes.
+
+
+
+ The namespace for SHACL Profiling terms is http://www.w3.org/ns/shpr#
+
+
+ The suggested prefix for the SHACL Profiling namespace is shpr
+
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+ Introduction
+
+ 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 that was validated. 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:
+
+
+ - packaging SHACL
+ - profiles of SHACL
+ - 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 the specification's rules, but no other rules
+
+
+
+ Warning: The definition of null profile may be up-streamed to an updated version of [[dx-prof]].
+
+
+ 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:
+
+
+
+ Prefix
+ Namespace
+
+
+ owl:http://www.w3.org/2002/07/owl#
+
+ rdfs:http://www.w3.org/2000/01/rdf-schema#
+
+ sh:http://www.w3.org/ns/shacl#
+
+ ex:http://example.com/ns#
+
+
+
+ Within this specification, the following JSON-LD context is used:
+
+ {
"@context": {
- "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
+ "owl": "http://www.w3.org/2002/07/owl#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"sh": "http://www.w3.org/ns/shacl#",
- "xsd": "http://www.w3.org/2001/XMLSchema#",
"ex": "http://example.com/ns#"
}
}
-
- 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.
- The JSON-LD specification fragments use the context given above.
- Only the Turtle specifications will have parts highlighted.
-
-
-
-
-# This box represents an input shapes graph
-
-<s> <p> <o> .
-
-
- // This box represents an input shapes graph
- {
+
+ 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.
+ The JSON-LD specification fragments use the context given above.
+ Only the Turtle specifications will have parts highlighted.
+
+
+
+
+ # This box represents an input shapes graph
+
+ <s> <p> <o> .
+
+
+ // This box represents an input shapes graph
+ {
"@id": "ex:s",
"ex:p": {
"@id": "ex:o"
}
}
-
-
-
-
-
-# This box represents an input data graph.
-# When highlighting is used in the examples:
-
-# Elements highlighted in blue are focus nodes
-ex:Bob a ex:Person .
-
-# Elements highlighted in red are focus nodes that fail validation
-ex:Alice a ex:Person .
-
-
- // This box represents an input data graph
- {
+
+
+
+
+
+ # This box represents an input data graph.
+ # When highlighting is used in the examples:
+
+ # Elements highlighted in blue are focus nodes
+ ex:Bob a ex:Person .
+
+ # Elements highlighted in red are focus nodes that fail validation
+ ex:Alice a ex:Person .
+
+
+ // This box represents an input data graph
+ {
"@graph": [
{
"@id": "ex:Alice",
@@ -511,151 +490,679 @@ Document Conventions
}
]
}
-
-
-
-
-
-# This box represents an output results graph
-
-
- // This box represents an output results graph
-
-
-
-
- Grey boxes such as this include syntax rules that apply to the shapes graph.
-
-
-
- true denotes the RDF term "true"^^xsd:boolean.
- false denotes the RDF term "false"^^xsd:boolean.
-
-
-
-
- TODO
-
-
-
-
- Profiles of SHACL
+
+
+
+
+
+ # This box represents an output results graph
+
+
+ // This box represents an output results graph
+
+
+
+
+ Grey boxes such as this include syntax rules that apply to the shapes graph.
+
+
+
+ true denotes the RDF term "true"^^xsd:boolean.
+ false denotes the RDF term "false"^^xsd:boolean.
+
+
+
+
+
+ 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]
+
+
+
+
+
+ Packaging SHACL
+
+ Packaging of SHACL is the presentation of SHACL elements - shapes, rules, etc. - in relation to container objects.
+
+
+ Motivation
+
+ There are multiple reasons to want to identify groups of SHACL Elements and to be able to know the relations between groups and individual Elements.
+ These reasons include wanting to understand the purpose of groups, how changes in one group affect other groups, and how to create new groups.
+ 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
+
+
+
+
+
+
+ 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 owl:Ontology to group SHACL Elements:
+
+
+ - Instances of
owl:Ontology SHOULD be used to group instance of SHACL Elements
+ - An instance of a SHACL Element SHOULD indicate the instance of an
owl:Ontology that defines it with the rdfs:isDefinedBy predicate
+ - An instance of
owl:Ontology 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
owl:Ontology being used to group SHACL Elements SHOULD indicate dependence on other groups of SHACL Elements identified using instances of owl:Ontology with the owl:imports predicate
+
+
+ The following subsections detail each of these recommendations.
+
+
+
+
+ Identifying groups of SHACL Elements
+
+
+ Instances of owl:Ontology SHOULD be used to group instance of SHACL Elements.
+
+
+
+ SHACL Elements, like much other RDF definitional data, is often 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:Property within a Turtle
+ file. The file also contains an instance of owl:Ontology presenting metadata for the validator, such as its
+ modified date, a license for its use, and so on.
+
+
+ This recommendation formalizes that style of packaging.
+
+
+ The use of a specialised object, perhaps a subclass of owl:Ontology, for grouping of SHACL Elements
+ was considered for this recommendation but rejected since it's easy enough to understand what kind of
+ ontology is identified by an instance of owl:Ontology by just inspecting its contained elements.
+ See the following recommendations for ontology/element linking.
+
+
+
+ Indicating Element definition
+
+
+ An instance of a SHACL Element SHOULD indicate the instance of an owl:Ontology 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 an owl:Ontology 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 SHACL Element creator should indicate the group within which a SHACL Element
+ is defined. An example of such an assertion in RDF is as follows:
+
+
+
+ex:ont-M
+ a owl:Ontology ;
+.
+
+ex:shape-1
+ a sh:NodeShape ;
+ rdfs:isDefinedBy ex:ont-M ;
+.
+
+
+ {
+ "@graph": [
+ {
+ "@id": "ex:ont-M",
+ "@type": "owl:Ontology"
+ },
+ {
+ "@id": "ex:shape-1",
+ "@type": "sh:NodeShape",
+ "rdfs:isDefinedBy": {
+ "@id": "ex:ont-M"
+ }
+ }
+ ]
+}
+
+
+
+
+ Indicating Element use
+
+
+ An instance of owl:Ontology 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 the rdfs:isDefinedBy, as in the example above, is as follows:
+
+
+
+# 'Ontology M' uses a Shape defined by 'Ontology Other'
+ex:ont-M
+ a owl:Ontology ;
+ rdfs:member ex:shape-1 ;
+.
+
+ex:ont-Other
+ a owl:Ontology ;
+.
+
+ex:shape-1
+ a sh:NodeShape ;
+ rdfs:isDefinedBy ex:ont-Other ;
+.
+
+
+ {
+ "@graph": [
+ {
+ "@id": "ex:ont-M",
+ "@type": "owl:Ontology",
+ "rdfs:member": {
+ "@id": "ex:shape-1"
+ }
+ },
+ {
+ "@id": "ex:ont-Other",
+ "@type": "owl:Ontology"
+ },
+ {
+ "@id": "ex:shape-1",
+ "@type": "sh:NodeShape",
+ "rdfs:isDefinedBy": {
+ "@id": "ex:ont-Other"
+ }
+ }
+ ]
+}
+
+
+
+
+ Indicating group dependence
+
+
+ Instances of owl:Ontology being used to group SHACL Elements SHOULD indicate dependence on other groups of SHACL Elements identified using instances of owl:Ontology 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 ;
+.
+
+
+ {
+ "@graph": [
+ {
+ "@id": "ex:ont-M",
+ "@type": "owl:Ontology"
+ },
+ {
+ "@id": "ex:ont-N",
+ "@type": "owl:Ontology",
+ "owl:imports": {
+ "@id": "ex:ont-M"
+ }
+ }
+ ]
+}
+
+
+
+
+ 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
+
+
+
+
+ Profiles of SHACL
+
+ This section describes some profiles of SHACL 1.2 that were created alongside the
+ SHACL 1.2 Specifications. It also indicates how to create more profiles of SHACL.
+
+
+ To validate RDF data against any of these Specification Profiles, or the Union Profile defined below, use the
+ validators listed in the SHACL 1.2 Overview's SHACL-SHACL appendix.
+
+
+ Specification Profiles
+
+ The Specification Profiles are profiles of SHACL 1.2 defined in each of the
+ specifications listed above.
+
+
+ When described using terminology from [[[dx-prof]]], the online document form of each specification is just one
+ of many resources that altogether make the specification. It 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 validator for each
+ profile that plays the role of Validation -
+ "Supplies instructions about how to verify conformance of data to the profile". These validation resources are
+ listed in SHACL 1.2 Overview's SHACL-SHACL appendix.
+
+
+ Together, these Base Profiles cover all of SHACL 1.2 and they are bundled together within the
+ Union Profile, defined below.
+
+
+
+ Union Profile
+
+ The Union profil
+
+
+
+ Creating other Profiles
+
+
+
+
+ Profiling with SHACL
+
+ This section describes how to profile specifications with SHACL.
+
+
+ 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 be applied to the role of Validation within a profile and perhaps also to
+ 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 resources can also document the constraints they implement validation shapes for, therefore they can also be
+ applied to the Constraints role.
+
+
+ They could also be applied to the Mapping role, if SHACL
+ Rules are implemented to transform data from one model to another.
+
+
+ SHACL lists of values required for use with a model could be applied to the Vocabulary role.
+
+
+
+ Profile Hierarchies
+
+
+ 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.
+
+
- This section describes profiles of the total SHACL 1.2 specification and how to create other profiles of SHACL.
+ While null profiles of specifications can be created using mechanism other than SHACL, here we focus only on the
+ use of SHACL.
-
- Base Profiles
-
- Base profiles of SHACL are profiles that correspond to the individual SHACL 1.2 specifications listed in the Specifications section, above.
-
-
- Together, these Base Profiles cover all of SHACL and, when used together in the Union Profile, they can validate whether any graph is valid SHACL 1.2 data.
-
-
-
- Non-base Profiles
-
- Non-base profiles of SHACL are profiles that do not correspond directly to a SHACL 1.2 specification. These profiles include supersets of the specification-derived base profiles, such as the Union Profile defined below, as well as other profiles of parts of SHACL, such as Profile X that contains SHACL elements that, when used for validation, require no more than XXX computational complexity.
-
-
- Union Profile
-
-
- Profile X
-
-
-
- Creating other Profiles
-
-
-
-
- Profiling with SHACL
-
- This section describes how to profile specifications with SHACL.
+
+ An example of a non-SHACL validator for RDF data that acts as a null profile is the W3C's [[[prov-constraints]]]
+ which provides a list of constraints that apply to provenance data formulated according to [[[prov-o]]].
+ [[[prov-constraints]]] implements no constraints beyond those stated or implied in [[[prov-o]]] and the
+ conceptual [[[prov-dm]]], 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.
-
- 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 be applied to the role of Validation within a profile and perhaps also to 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 resources can also document the constraints they implement validation shapes for, therefore they can also be applied to the Constraints role.
-
+
+
+
+
+
+ Summary of Syntax Rules from this Specification
+
+
+
+ Security and Privacy Considerations
+
+ 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.
+
+
+
+
+ Acknowledgements
+ Many people contributed to this specification, including members of the RDF Data Shapes Working Group.
+
+
+
+ Internationalization Considerations
+ TODO
+
+
+
+
+
+
+
+
+
+ Specification Profiles Listing
+
+ Descriptions of each SHACL 1.2 specification as a Profiles Vocabulary profile,
+ including a listing of all their resources and the roles they play, is given in Appendix G below.
+
+
+ The individual profiles are as follows:
+
+
+
+ -
+ SHACL 1.2 Core Profile
+
+ -
- They could also be applied to the Mapping role, if SHACL Rules are implemented to transform data from one model to another.
+ http://www.w3.org/ns/shacl#shacl12-core-profile
- SHACL lists of values required for use with a model could be applied to the Vocabulary role.
+ The set of SHACL 1.2 elements defined in the SHACL 1.2 Core specification.
-
-
- Profile Hierarchies
-
-
- Creating Null Profiles
+
+
+ SHACL 1.2 SPARQL Profile
+
+
- A "null" profile of a specification, created using SHACL, is a profile of that specification in which SHACL is used to implement some, and potentially all the specification's rules, but no other rules, in SHACL.
+ http://www.w3.org/ns/shacl#shacl12-sparql-profile
- 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.
+ The set of SHACL 1.2 elements defined in the SHACL 1.2 SPARQL specification.
-
-
- 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 [[[prov-constraints]]] which provides a list of constraints that apply to provenance data formulated according to [[[prov-o]]]. [[[prov-constraints]]] implements no constraints beyond those stated or implied in [[[prov-o]]] and the conceptual [[[prov-dm]]], 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.
-
-
-
-
- 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. -
-