<!DOCTYPE html>
<html>
<head>
<title>Shapes Constraint Language (SHACL)</title>
<meta charset="utf-8">
<script src="https://www.w3.org/Tools/respec/respec-w3c-common" async class="remove"></script>
<script class="remove">
var prepareSyntaxRules = function() {
var ttl = $("#shacl-shacl-pre").html();
$("[data-syntax-rule]").each(function(index, element) {
var ruleId = $(element).attr("data-syntax-rule");
var tr = $("<tr class=\"syntax-rule-tr\"><td class=\#syntax-rule-id\"><a class=\"syntax-rule-id-a\" href=\"#syntax-rule-" + ruleId + "\">" + ruleId + "</a></td><td>" + $(element).html() + "</td></tr>");
tr.find("dfn").replaceWith(function(el) { return $("<a>" + $(this).text() + "</a>"); });
$("#syntax-rules-table").append(tr);
$(element).attr("id", "syntax-rule-" + ruleId);
if("shape" !== ruleId) {
ttl = ttl.split("# " + ruleId).join("<a href=\"#syntax-rule-" + ruleId + "\"># " + ruleId + "</a>");
}
});
$("#shacl-shacl-pre").html(ttl);
};
var prepareValidators = function() {
$("[data-validator]").each(function(index, element) {
var validatorId = $(element).attr("data-validator") + "ConstraintComponent";
var tr = $("<tr class=\"validator-tr\"><td><a class=\"validator-id-a\" href=\"#validator-" + validatorId + "\">sh:" + validatorId + "</a>: " + $(element).html() + "</td></tr>");
$("#validators-table").append(tr);
$(element).attr("id", "validator-" + validatorId);
});
};
var respecConfig = {
edDraftURI: "https://w3c.github.io/data-shapes/shacl/",
issueBase: "http://www.w3.org/2014/data-shapes/track/issues/",
specStatus: "ED",
crEnd: "2017-05-09",
// publishDate: "2017-04-11",
implementationReportURI: "http://w3c.github.io/data-shapes/data-shapes-test-suite/",
preProcess : [ prepareSyntaxRules, prepareValidators ],
previousPublishDate: "2017-03-03",
previousMaturity: "WD",
shortName: "shacl",
editors: [
{
name: "Holger Knublauch",
url: "http://knublauch.com/",
company: "TopQuadrant, Inc.",
companyURL: "http://topquadrant.com/",
w3cid: 46500
},
{
name: "Dimitris Kontokostas",
url: "http://Kontokostas.com",
company: "University of Leipzig",
companyURL: "http://informatik.uni-leipzig.de/",
w3cid: 58399
}
],
otherLinks: [
{
key: "Repository",
data: [
{
value: "GitHub",
href: "https://github.com/w3c/data-shapes"
},
{
value: "Issues",
href: "https://github.com/w3c/data-shapes/issues"
}
]
},
{
key: "Test Suite",
data: [
{
value: "SHACL Test Suite",
href: "http://w3c.github.io/data-shapes/data-shapes-test-suite/"
}
]
}
],
errata: "https://www.w3.org/2017/shacl/errata",
wg: "RDF Data Shapes Working Group",
wgURI: "https://www.w3.org/2014/data-shapes/",
wgPublicList: "public-rdf-shapes",
wgPatentURI: "https://www.w3.org/2004/01/pp-impl/73865/status",
noHighlightCSS: true
};
</script>
<style>
pre {
tab-size: 3;
-moz-tab-size: 3; /* Code for Firefox */
-o-tab-size: 3; /* Code for Opera */
}
th {
text-align: left;
}
table.rule { background-color: #EBEBE0; }
table.rule td { text-align: center; }
td.up { border-bottom:1px solid black; }
td {
vertical-align: top;
}
.algorithm {
background: #fafafc;
border-left-style: solid;
border-left-width: .5em;
border-color: #c0c0c0;
margin-bottom: 16px;
padding: 8px;
}
.arg {
font-weight: bold;
color: #000080;
}
.def {
background: #fcfcfc;
border-left-style: solid;
border-left-width: .5em;
border-color: #c0c0c0;
margin-bottom: 16px;
}
.def-sparql {
}
.def-sparql-body {
margin-top: 0px;
margin-bottom: 0px;
}
.def-text {
}
.def-text-body {
}
.def-header {
color: #a0a0a0;
font-size: 16px;
padding-bottom: 8px;
}
.diagram-class {
border: 1px solid black;
border-radius: 4px;
width: 360px;
}
.diagram-class-name {
font-size: 16px;
font-weight: bold;
text-align: center;
}
.diagram-class-properties {
border-top: 1px solid black;
}
.diagram-class-properties-start {
padding: 8px;
}
.diagram-class-properties-section {
border-top: 1px dashed #808080;
padding: 8px;
}
.focus-node-selected {
color: blue;
}
.focus-node-error {
color: red;
}
.triple-can-be-skipped {
color: grey;
}
.focus-node-error {
color: red;
}
.target-can-be-skipped {
color: darkslategray;
font-style: italic;
}
.component-class {
font-weight: bold;
font-size: 16px;
}
.parameter-context {
font-weight: bold;
font-size: 16px;
}
.parameters {
font-weight: bold;
font-size: 16px;
}
.part-header {
font-weight: bold;
}
.syntax {
border-left-style: solid;
border-left-width: .5em;
border-color: #d0d0d0;
margin-bottom: 16px;
padding: .5em 1em;
background-color: #f6f6f6;
}
.syntax-rule-id {
padding-right: 10px;
}
.syntax-rule-id-a {
white-space: nowrap;
}
.validator-id-a {
font-weight: bold;
white-space: nowrap;
}
.term {
font-style: italic;
}
.term-def-header {
font-style: italic;
font-weight: bold;
}
.term-table {
border-collapse: collapse;
border-color: #000000;
margin: 16px;
}
.term-table td, th {
border-width: 1px;
border-style: solid;
padding: 5px;
}
.todo {
color: red;
}
pre {
word-wrap: normal;
}
/* example pre taken / adapted from R2RML */
pre.shapes, pre.example-shapes, pre.example-data, pre.example-results, pre.example-other { margin-left: 0; padding: 0 2em; margin-top: 1.5em; padding: 1em; }
pre.example-shapes:before, pre.example-data:before, pre.example-results:before, pre.example-other:before { background: white; display: block; font-family: sans-serif; margin: -1em 0 0.4em -1em; padding: 0.2em 1em; }
pre.shapes, pre.example-shapes { background: #deb; }
pre.shapes, pre.example-shapes, pre.example-shapes:before { border: 1px solid #bbb; }
pre.example-shapes:before { color: #888; content: "Example shapes graph"; width: 13em; }
pre.example-data { background: #eeb; }
pre.example-data, pre.example-data:before { border: 1px solid #cc9; }
pre.example-data:before { color: #996; content: "Example data graph"; width: 13em; }
.example-results { background: #edb; }
.example-results, .example-results:before, .example-results th, .example-results td { border: 1px solid #cca; }
pre.example-results:before { color: #997; content: "Example validation results"; width: 13em; }
pre.example-other { background: #bed; }
pre.example-other, pre.example-other:before { border: 1px solid #ddd; }
pre.example-other:before { color: #888; content: "Example"; width: 13em; }
/* our syntax menu for switching */
div.syntaxmenu {
border: 1px dotted black;
padding:0.5em;
margin: 1em;
}
@media print {
div.syntaxmenu { display:none; }
}
</style>
</head>
<body>
<section id="abstract">
<p>
This document defines the SHACL Shapes Constraint Language, a language for validating RDF graphs against a set of conditions.
These conditions are provided as shapes and other constructs expressed in the form of an RDF graph.
RDF graphs that are used in this manner are called "shapes graphs" in SHACL and
the RDF graphs that are validated against a shapes graph are called "data graphs".
As SHACL shape graphs are used to validate that data graphs satisfy a set of conditions
they can also be viewed as a description of the data graphs that do satisfy these conditions.
Such descriptions may be used for a variety of purposes beside validation, including
user interface building, code generation and data integration.
</p>
</section>
<section id="sotd">
</section>
<section class="introductory">
<h2>Document Outline</h2>
<p>
The introduction includes a <a href="#terminology">Terminology</a> section.
</p>
<p>
The sections 2 - 4 cover the <a>SHACL Core</a> language and may be read independently from the later sections.
</p>
<p>
The sections 5 and 6 are about the features that <a>SHACL-SPARQL</a> has in addition to the Core language.
These advanced features are SPARQL-based constraints and constraint components.
</p>
<p>
The syntax of SHACL is RDF.
The examples in this document use Turtle [[!turtle]] and (in one instance) JSON-LD [[json-ld]].
Other RDF serializations such as RDF/XML may be used in practice.
The reader should be familiar with basic RDF concepts [[!rdf11-concepts]] such as triples and, for the advanced concepts of SHACL, with SPARQL [[!sparql11-query]].
</p>
</section>
<section id="introduction">
<h2>Introduction</h2>
<p>
This document specifies SHACL (Shapes Constraint Language), a language for describing and validating RDF graphs.
This section introduces SHACL with an overview of the key terminology and an example to illustrate basic concepts.
</p>
<section id="terminology">
<h3>Terminology</h3>
<p>
Throughout this document, the following terminology is used.
</p>
<p>
Terminology that is linked to portions of RDF 1.1 Concepts and Abstract
Syntax is used in SHACL as defined there. Terminology that is linked to
portions of SPARQL 1.1 Query Language is used in SHACL as defined there. A
single linkage is sufficient to provide a definition for all occurences of a
particular term in this document.
</p>
<p>
Definitions are complete within this document, i.e., if there is no rule to
make some situation true in this document then the situation is false.
</p>
<div class="def" id="rdf-terminology">
<div class="term-def-header">Basic RDF Terminology</div>
<div>
This document uses the terms
<a href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-graph"><dfn data-lt="graph|graphs|RDF graphs">RDF graph</dfn></a>,
<a href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-triple"><dfn data-lt="triple|triples">RDF triple</dfn></a>,
<a href="http://www.w3.org/TR/rdf11-concepts/#dfn-iri"><dfn data-lt="IRI|IRIs">IRI</dfn></a>,
<a href="http://www.w3.org/TR/rdf11-concepts/#dfn-literal"><dfn data-lt="literal|literals">literal</dfn></a>,
<a href="http://www.w3.org/TR/rdf11-concepts/#dfn-blank-node"><dfn data-lt="blank node|blank nodes">blank node</dfn></a>,
<a href="http://www.w3.org/TR/rdf11-concepts/#dfn-node"><dfn data-lt="node|nodes">node</dfn></a> of an RDF graph,
<a href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-term"><dfn>RDF term</dfn></a>, and
<a href="https://www.w3.org/TR/rdf11-concepts/#dfn-subject"><dfn data-lt="subject|subjects">subject</dfn></a>,
<a href="https://www.w3.org/TR/rdf11-concepts/#dfn-predicate"><dfn data-lt="predicate|predicates">predicate</dfn></a>, and
<a href="https://www.w3.org/TR/rdf11-concepts/#dfn-object"><dfn data-lt="object|objects">object</dfn></a> of RDF triples, and
<a href="https://www.w3.org/TR/rdf11-concepts/#dfn-datatype"><dfn data-lt="datatypes">datatype</dfn></a>
as defined in RDF 1.1 Concepts and Abstract Syntax [[!rdf11-concepts]].
<dfn data-lt="language tag">Language tags</dfn> are defined as in [[!BCP47]].
</div>
</div>
<div class="def">
<div class="term-def-header">Property Value and Path</div>
<div>
A <dfn data-lt="properties">property</dfn> is an <a>IRI</a>.
An <a>RDF term</a> <code>n</code> has a <dfn data-lt="values|property value|property values">value</dfn> <code>v</code>
for property <code>p</code> in an <a>RDF graph</a> if there is an <a>RDF triple</a> in the graph
with <a>subject</a> <code>n</code>, <a>predicate</a> <code>p</code>, and <a>object</a> <code>v</code>.
The phrase "Every value of P in graph G ..." means "Every object of a triple in G with predicate P ...".
(In this document, the verbs <em>specify</em> or <em>declare</em> are sometimes used to express the fact that an RDF term has values for a given predicate in a graph.)
<br />
<dfn data-lt="SPARQL property path">SPARQL property paths</dfn> are defined as in <a href="https://www.w3.org/TR/sparql11-query/#pp-language">SPARQL 1.1</a>.
An RDF term <code>n</code> has value <code>v</code> for <a>SPARQL property path</a> expression
<code>p</code> in an RDF graph <code>G</code> if there is a solution mapping in the result of the SPARQL query
<code>SELECT ?s ?o WHERE { ?s p' ?o }</code> on <code>G</code> that binds <code>?s</code> to
<code>n</code> and <code>?o</code> to <code>v</code>, where <code>p'</code> is SPARQL surface syntax for <code>p</code>.
</div>
</div>
<div class="def">
<div class="term-def-header">SHACL Lists</div>
<div>
<span data-syntax-rule="SHACL-list">A <dfn data-lt="SHACL lists">SHACL list</dfn> in an RDF graph <code>G</code> is an <a>IRI</a> or a <a>blank node</a>
that is either <code>rdf:nil</code> (provided that <code>rdf:nil</code> has no <a>value</a>
for either <code>rdf:first</code> or <code>rdf:rest</code>), or has exactly one <a>value</a>
for the property <code>rdf:first</code> in <code>G</code> and exactly one <a>value</a>
for the property <code>rdf:rest</code> in <code>G</code> that is also a SHACL list in <code>G</code>,
and the list does not have itself as a value of the property path <code>rdf:rest+</code> in <code>G</code>.</span>
<br />
The <dfn data-lt="member">members</dfn> of any SHACL list except <code>rdf:nil</code> in an RDF
graph <code>G</code> consist of its value for <code>rdf:first</code> in <code>G</code> followed by
the members in <code>G</code> of its value for <code>rdf:rest</code> in <code>G</code>.
The SHACL list <code>rdf:nil</code> has no members in any RDF graph.
</div>
</div>
<div class="def">
<div class="term-def-header">Binding, Solution</div>
<div>
A <dfn data-lt="bindings">binding</dfn> is a pair (<a href="https://www.w3.org/TR/sparql11-query/#defn_QueryVariable">variable</a>, <a>RDF term</a>), consistent with the term's use in <a href="https://www.w3.org/TR/sparql11-query/">SPARQL</a>.
A <dfn data-lt="solutions">solution</dfn> is a set of bindings, informally often understood as one row in the body of the result table of a SPARQL query.
Variables are not required to be bound in a solution.
</div>
</div>
<div class="def">
<div class="term-def-header">SHACL Subclass, SHACL superclass</div>
<div>
A <a>node</a> <code>Sub</code> in an <a>RDF graph</a> is a <dfn data-lt="subclasses|subclass|SHACL subclasses">SHACL subclass</dfn> of another <a>node</a> <code>Super</code>
in the <a>graph</a> if there is a sequence of <a>triples</a> in the <a>graph</a> each with predicate <code>rdfs:subClassOf</code> such that the <a>subject</a> of the first <a>triple</a> is <code>Sub</code>,
the <a>object</a> of the last triple is <code>Super</code>, and the <a>object</a> of each <a>triple</a> except the last is the <a>subject</a> of the next.
If <code>Sub</code> is a <a>SHACL subclass</a> of <code>Super</code> in an <a>RDF graph</a> then <code>Super</code>
is a <dfn data-lt="superclass|superclasses|SHACL superclasses|">SHACL superclass</dfn> of <code>Sub</code> in the <a>graph</a>.
</div>
</div>
<div class="def">
<div class="term-def-header">SHACL Type</div>
<div>
The <dfn data-lt="type|types|SHACL type">SHACL types</dfn> of an <a>RDF term</a> in an <a>RDF graph</a> is the set of its <a>values</a> for <code>rdf:type</code> in the
<a>graph</a> as well as the <a>SHACL superclasses</a> of these <a>values</a> in the <a>graph</a>.
</div>
</div>
<div class="def">
<div class="term-def-header">SHACL Class</div>
<div>
<a>Nodes</a> in an <a>RDF graph</a> that are subclasses, superclasses, or types of <a>nodes</a> in the <a>graph</a> are referred to as <dfn data-lt="class|classes|SHACL classes">SHACL class</dfn>.
</div>
</div>
<div class="def">
<div class="term-def-header">SHACL Class Instance</div>
<div>
A <a>node</a> <code>n</code> in an <a>RDF graph</a> <code>G</code> is a <dfn data-lt="SHACL instance|SHACL instances">SHACL instance</dfn> of a <a>SHACL class</a> <code>C</code> in <code>G</code>
if one of the <a>SHACL types</a> of <code>n</code> in <code>G</code> is <code>C</code>.
</div>
</div>
<div class="def">
<div class="term-def-header">SHACL Core and SHACL-SPARQL</div>
<div>
The SHACL specification is divided into SHACL Core and SHACL-SPARQL.
<dfn>SHACL Core</dfn> consists of frequently needed features for the representation of shapes, constraints and targets.
All SHACL implementations MUST at least implement SHACL Core.
<dfn>SHACL-SPARQL</dfn> consists of all features of SHACL Core plus the advanced features
of SPARQL-based constraints and an extension mechanism to declare new constraint components.
</div>
</div>
</section>
<section id="conventions">
<h3>Document Conventions</h3>
<p>
Within this document, the following namespace prefix bindings are used:
</p>
<table class="term-table">
<tr>
<th>Prefix</th>
<th>Namespace</th>
</tr>
<tr>
<td><code>rdf:</code></td>
<td><code>http://www.w3.org/1999/02/22-rdf-syntax-ns#</code></td>
</tr>
<tr>
<td><code>rdfs:</code></td>
<td><code>http://www.w3.org/2000/01/rdf-schema#</code></td>
</tr>
<tr>
<td><code>sh:</code></td>
<td><code><a href="http://www.w3.org/ns/shacl">http://www.w3.org/ns/shacl#</a></code></td>
</tr>
<tr>
<td><code>xsd:</code></td>
<td><code>http://www.w3.org/2001/XMLSchema#</code></td>
</tr>
<tr>
<td><code>ex:</code></td>
<td><code>http://example.com/ns#</code></td>
</tr>
</table>
<p>
Note that the URI of the graph defining the SHACL vocabulary itself is equivalent to
the namespace above, i.e. it includes the <code>#</code>.
References to the SHACL vocabulary, e.g. via <code>owl:imports</code> should include the <code>#</code>.
</p>
<p>
Throughout the document, color-coded boxes containing RDF graphs in Turtle will appear.
These fragments of Turtle documents use the prefix bindings given above.
</p>
<pre class="example-shapes">
# This box represents an input shapes graph
# Triples that can be omitted are marked as grey e.g.
<span class="triple-can-be-skipped"><s> <p> <o> .</span></pre>
<pre class="example-data">
# This box represents an input data graph.
# When highlighting is used in the examples:
# Elements highlighted in blue are <a>focus nodes</a>
<span class="focus-node-selected">ex:Bob</span> a ex:Person .
# Elements highlighted in red are focus nodes that fail <a href="#validation">validation</a>
<span class="focus-node-error">ex:Alice</span> a ex:Person .</pre>
<pre class="example-results">
# This box represents an output results graph</pre>
<p>
SHACL Definitions appear in blue boxes:
</p>
<div class="def def-sparql">
<div class="def-header">SPARQL or TEXTUAL DEFINITIONS</div>
<pre class="def-sparql-body">
# This box contains SPARQL or textual definitions. </pre>
</div>
<p class="syntax">
Grey boxes such as this include syntax rules that apply to the <a>shapes graph</a>.
</p>
<p>
<code>true</code> denotes the RDF term <code>"true"^^xsd:boolean</code>.
<code>false</code> denotes the RDF term <code>"false"^^xsd:boolean</code>.
</p>
</section>
<section id="conformance">
<p>
This document defines the <strong>SHACL Core</strong> language, also referred to as just <strong>SHACL</strong>, as described in Part A,
and the <strong>SHACL-SPARQL</strong> language that extends SHACL Core with constructs described in Part B.
This specification describes conformance criteria for:
</p>
<ul>
<li><strong>SHACL Core processors</strong> as processors that support validation with the SHACL Core Language</li>
<li><strong>SHACL-SPARQL processors</strong> as processors that support validation with the SHACL-SPARQL Language</li>
</ul>
<p>
This document includes syntactic rules that shapes and other nodes need to fulfill in the <a>shapes graph</a>.
These rules are typically of the form <em>A shape must have...</em> or <em>The values of X are literals</em> or <em>All objects of triples with predicate P must be IRIs</em>.
The complete list of these rules can be found in the <a href="#syntax-rules">appendix</a>.
Nodes that violate any of these rules are called <dfn>ill-formed</dfn>.
Nodes that violate none of these rules are called <dfn>well-formed</dfn>.
A <a>shapes graph</a> is ill-formed if it contains at least one ill-formed node.
</p>
<p><em>The remainder of this section is informative.</em></p>
<p>
SHACL Core processors that do not also support SHACL-SPARQL ignore any SHACL-SPARQL constructs
such as <code>sh:sparql</code> <a>triples</a>.
</p>
</section>
<section class="informative">
<h3>SHACL Example</h3>
<p>
The following example <a>data graph</a> contains three <a>SHACL instances</a> of the <a>class</a> <code>ex:Person</code>.
</p>
<pre class="example-data">
ex:Alice
a ex:Person ;
ex:ssn "987-65-432A" .
ex:Bob
a ex:Person ;
ex:ssn "123-45-6789" ;
ex:ssn "124-35-6789" .
ex:Calvin
a ex:Person ;
ex:birthDate "1971-07-07"^^xsd:date ;
ex:worksFor ex:UntypedCompany .</pre>
<p>
The following conditions are shown in the example:
<p>
<ul>
<li>
A <a>SHACL instance</a> of <code>ex:Person</code> can have at most one <a>value</a> for the property <code>ex:ssn</code>,
and this <a>value</a> is a <a>literal</a> with the datatype <code>xsd:string</code> that matches
a specified regular expression.
</li>
<li>
A <a>SHACL instance</a> of <code>ex:Person</code> can have unlimited <a>values</a> for the property <code>ex:worksFor</code>,
and these <a>values</a> are <a>IRIs</a> and <a>SHACL instances</a> of <code>ex:Company</code>.
</li>
<li>
A <a>SHACL instance</a> of <code>ex:Person</code> cannot have <a>values</a> for any other property apart from
<code>ex:ssn</code>, <code>ex:worksFor</code> and <code>rdf:type</code>.
</li>
</ul>
<p>
The aforementioned conditions can be represented as <a>shapes</a> and <a>constraints</a> in the following <a>shapes graph</a>:
</p>
<pre class="example-shapes ttl">
ex:PersonShape
a sh:NodeShape ;
sh:targetClass ex:Person ; # Applies to all persons
sh:property [ # _:b1
sh:path ex:ssn ; # constrains the values of ex:ssn
sh:maxCount 1 ;
sh:datatype xsd:string ;
sh:pattern "^\\d{3}-\\d{2}-\\d{4}$" ;
] ;
sh:property [ # _:b2
sh:path ex:worksFor ;
sh:class ex:Company ;
sh:nodeKind sh:IRI ;
] ;
sh:closed true ;
sh:ignoredProperties ( rdf:type ) .</pre>
<p>
The example below shows the same shape definition as a possible JSON-LD [[json-ld]] fragment.
Note that we have left out a <code>@context</code> declaration, and depending on the
<code>@context</code> the rendering may look quite different.
Therefore this example should be understood as an illustration only.
</p>
<pre class="example-shapes jsonld">
{
"@id" : "ex:PersonShape",
"@type" : "NodeShape",
"targetClass" : "ex:Person",
"property" : [
{
"path" : "ex:ssn",
"maxCount" : 1,
"datatype" : "xsd:string" ,
"pattern" : "^\\d{3}-\\d{2}-\\d{4}$"
},
{
"path" : "ex:worksFor",
"class" : "ex:Company",
"nodeKind" : "sh:IRI"
}
],
"closed" : true,
"ignoredProperties" : [ "rdf:type" ]
}</pre>
<p>
We can use the shape declaration above to illustrate some of the key terminology used by SHACL.
The <a>target</a> for the <a>shape</a> <code>ex:PersonShape</code> is the set of all <a>SHACL instances</a> of the <a>class</a> <code>ex:Person</code>.
This is specified using the property <code>sh:targetClass</code>.
During the validation, these target nodes become <a>focus nodes</a> for the shape.
The <a>shape</a> <code>ex:PersonShape</code> is a <a>node shape</a>, which means that it applies to the focus nodes.
It declares <a>constraints</a> on the <a>focus nodes</a>, for example using the <a>parameters</a> <code>sh:closed</code> and <code>sh:ignoredProperties</code>.
The <a>node shape</a> also declares two other constraints with the property <code>sh:property</code>,
and each of these is backed by a <a>property shape</a>.
These <a>property shapes</a> declare additional <a>constraints</a> using <a>parameters</a> such as <code>sh:datatype</code> and <code>sh:maxCount</code>.
</p>
<p>
Some of the <a>property shapes</a> specify parameters from multiple <a>constraint components</a> in order to
restrict multiple aspects of the <a>property values</a>.
For example, in the <a>property shape</a> for <code>ex:ssn</code>, parameters from three <a>constraint components</a> are used.
The <a>parameters</a> of these <a>constraint components</a> are <code>sh:datatype</code>, <code>sh:pattern</code> and <code>sh:maxCount</code>.
For each <a>focus node</a> the <a>property values</a> of <code>ex:ssn</code> will be validated against all three components.
</p>
<p>
SHACL <a>validation</a> based on the provided <a>data graph</a> and <a>shapes graph</a> would produce the following <a>validation report</a>.
See the section <a href="#validation-report">Validation Report</a> for details on the format.
</p>
<pre class="example-results">
[ a sh:ValidationReport ;
sh:conforms false ;
sh:result
[ a sh:ValidationResult ;
sh:resultSeverity sh:Violation ;
sh:focusNode ex:Alice ;
sh:resultPath ex:ssn ;
sh:value "987-65-432A" ;
sh:sourceConstraintComponent sh:RegexConstraintComponent ;
sh:sourceShape ... blank node _:b1 on ex:ssn above ... ;
] ,
[ a sh:ValidationResult ;
sh:resultSeverity sh:Violation ;
sh:focusNode ex:Bob ;
sh:resultPath ex:ssn ;
sh:sourceConstraintComponent sh:MaxCountConstraintComponent ;
sh:sourceShape ... blank node _:b1 on ex:ssn above ... ;
] ,
[ a sh:ValidationResult ;
sh:resultSeverity sh:Violation ;
sh:focusNode ex:Calvin ;
sh:resultPath ex:worksFor ;
sh:value ex:UntypedCompany ;
sh:sourceConstraintComponent sh:ClassConstraintComponent ;
sh:sourceShape ... blank node _:b2 on ex:worksFor above ... ;
] ,
[ a sh:ValidationResult ;
sh:resultSeverity sh:Violation ;
sh:focusNode ex:Calvin ;
sh:resultPath ex:birthDate ;
sh:value "1971-07-07"^^xsd:date ;
sh:sourceConstraintComponent sh:ClosedConstraintComponent ;
sh:sourceShape sh:PersonShape ;
]
] .</pre>
<p>
The <a>validation results</a> are enclosed in a <a>validation report</a>.
The first <a>validation result</a> is produced because <code>ex:Alice</code> has a <a>value</a> for <code>ex:ssn</code>
that does not match the regular expression specified by the property <code>sh:regex</code>.
The second <a>validation result</a> is produced because <code>ex:Bob</code> has more than the permitted number of <a>values</a>
for the property <code>ex:ssn</code> as specified by the <code>sh:maxCount</code> of 1.
The third <a>validation result</a> is produced because <code>ex:Calvin</code> has a <a>value</a> for <code>ex:worksFor</code>
that does not have an <code>rdf:type</code> triple that makes it a <a>SHACL instance</a> of <code>ex:Company</code>.
The forth <a>validation result</a> is produced because the <a>shape</a> <code>ex:PersonShape</code> has the property <code>sh:closed</code> set to <code>true</code>
but <code>ex:Calvin</code> uses the property <code>ex:birthDate</code> which is neither one of the predicates from any of the
<a>property shapes</a> of the shape, nor one of the properties listed using <code>sh:ignoredProperties</code>.
</p>
</section>
<section id="shacl-rdfs">
<h3>Relationship between SHACL and RDFS inferencing</h3>
<p>
SHACL uses the RDF and RDFS vocabularies, but full RDFS inferencing is not required.
</p>
<p>
However, SHACL processors MAY operate on RDF graphs that include entailments [[!sparql11-entailment]] -
either pre-computed before being submitted to a SHACL processor or performed on the fly as
part of SHACL processing (without modifying either <a>data graph</a> or <a>shapes graph</a>).
To support processing of entailments, SHACL includes the property
<code>sh:entailment</code> to indicate what inferencing is required
by a given <a>shapes graph</a>.
</p>
<p class="syntax">
<span data-syntax-rule="entailment-nodeKind">The <a>values</a> of the property <code>sh:entailment</code> are IRIs.</span>
Common values for this property are covered by [[!sparql11-entailment]].
</p>
<p>
SHACL implementations MAY, but are not required to, support entailment regimes.
If a <a>shapes graph</a> contains any <a>triple</a> with the <a>predicate</a> <code>sh:entailment</code> and <a>object</a> <code>E</code>
and the SHACL processor does not support <code>E</code> as an entailment regime for the given <a>data graph</a>
then the processor MUST signal a <a>failure</a>.
Otherwise, the SHACL processor MUST provide the entailments for all of the values of <code>sh:entailment</code> in the <a>shapes graph</a>,
and any inferred triples MUST be returned by all queries against the <a>data graph</a> during the <a>validation</a> process.
</p>
</section>
<section id="shacl-sparql" class="informative">
<h3>Relationship between SHACL and SPARQL</h3>
<p>
For <a>SHACL Core</a> this specification uses parts of SPARQL 1.1 in non-normative alternative definitions of the semantics of <a>constraint components</a> and <a>targets</a>.
While these may help some implementers, SPARQL is not required for the implementation of the SHACL Core language.
</p>
<p>
<a>SHACL-SPARQL</a> is based on SPARQL 1.1 and uses it as a mechanism to declare constraints and constraint components.
Implementations that cover only the SHACL Core features are not required to implement these mechanisms.
</p>
<p>
SPARQL variables using the <code>$</code> marker represent external <a>bindings</a> that are <a>pre-bound</a> or, in the case of <code>$PATH</code>, <a>substituted</a> in the SPARQL query before execution (as explained in <a href="#constraint-components-validation"></a>).
</p>
<p>
The definition of some <a>constraints</a> requires or is simplified through access to the <a>shapes graph</a> during query execution.
SHACL-SPARQL processors MAY <a>pre-bind</a> the variable <code>shapesGraph</code> to provide access to the <a>shapes graph</a>.
Access to the <a>shapes graph</a> is not a requirement for supporting the SHACL Core language.
The variable <code>shapesGraph</code> can also be used in <a href="#sparql-constraints">SPARQL-based constraints</a> and <a href="#sparql-constraint-components">SPARQL-based constraint components</a>.
However, such <a>constraints</a> may not be interoperable across different SHACL-SPARQL processors or not applicable to remote RDF datasets.
</p>
<p>
Note that at the time of writing, SPARQL EXISTS has been imperfectly defined and implementations vary.
While a <a href="https://www.w3.org/community/sparql-exists/">W3C Community Group</a> is working on improving this situation,
users of SPARQL are advised that the use of EXISTS may have inconsistent results and should be approached with care.
</p>
<div class="syntaxmenu">
<p>The button below can be used to show or hide the SPARQL definitions.</p>
<form>
<p>
<input id="hide-sparql" onclick="$('.def-sparql').css('display', 'none'); $('#hide-sparql').css('display', 'none'); $('#show-sparql').css('display', '');" type="button" value="Hide SPARQL Definitions" />
<input id="show-sparql" onclick="$('.def-sparql').css('display', ''); $('#show-sparql').css('display', 'none'); $('#hide-sparql').css('display', '');" style="display:none" type="button" value="Show SPARQL Definitions" />
</p>
</form>
</div>
</section>
</section>
<div style="padding-top: 30px"> <!-- ALH: really??? -->
<h1 id="part1" style="font-size: 160%; font-weight: bold">Part 1: SHACL Core</h1>
</div>
<section id="constraints-section">
<h2>Shapes and Constraints</h2>
<p><em>The following introduction is non-normative.</em></p>
<p>
The following informal diagram provides an overview of some of the key classes in the SHACL vocabulary.
Each box represents a class.
The content of the boxes under the class name lists some of the properties that instances of these classes may have, together with their value types.
The arrows indicate <code>rdfs:subClassOf</code> triples.
</p>
<div>
<div class="diagram-class" style="margin-left: 200px">
<div class="diagram-class-name"><a href="#shapes">sh:Shape</a></div>
<div class="diagram-class-properties">
<div class="diagram-class-properties-start">
<div><a href="#targetClass">sh:targetClass</a> : rdfs:Class</div>
<div><a href="#targetNode">sh:targetNode</a> : any IRI or literal</div>
<div><a href="#targetObjectsOf">sh:targetObjectsOf</a> : rdf:Property</div>
<div><a href="#targetSubjectsOf">sh:targetSubjectsOf</a> : rdf:Property</div>
</div>
<div class="diagram-class-properties-section">
<div><a href="#deactivated">sh:deactivated</a> : xsd:boolean</div>
<div><a href="#message">sh:message</a> : xsd:string or rdf:langString</div>
<div><a href="#severity">sh:severity</a> : sh:Severity</div>
</div>
</div>
</div>
<div style="height: 60px; margin-left: 260px">
<img alt="Class Diagram Arrows" src="images/Class-Diagram-Arrows.png" />
</div>
<div style="white-space: nowrap; min-width: 1000px">
<div class="diagram-class" style="float: left; margin-right: 60px;">
<div class="diagram-class-name"><a href="#node-shapes">sh:NodeShape</a></div>
<div class="diagram-class-properties">
<div class="diagram-class-properties-start">
<div><b><a href="#constraints">Constraint parameters</a></b>, for example:</div>
<div><a href="#ClosedConstraintComponent">sh:closed</a> : xsd:boolean</div>
<div><a href="#OrConstraintComponent">sh:or</a> : rdf:List</div>
<div><a href="#NotConstraintComponent">sh:not</a> : sh:Shape</div>
<div><a href="#PropertyConstraintComponent">sh:property</a> : sh:PropertyShape</div>
</div>
</div>
</div>
<div class="diagram-class" style="float: left;">
<div class="diagram-class-name"><a href="#property-shapes">sh:PropertyShape</a></div>
<div class="diagram-class-properties">
<div class="diagram-class-properties-start">
<div><b><a href="#constraints">Constraint parameters</a></b>, for example:</div>
<div><a href="#MinCountConstraintComponent">sh:minCount</a>, <a href="#MaxCountConstraintComponent">sh:maxCount</a> : xsd:integer</div>
<div><a href="#ClassConstraintComponent">sh:class</a> or <a href="#DatatypeConstraintComponent">sh:datatype</a> : rdfs:Resource</div>
<div><a href="#NodeConstraintComponent">sh:node</a> : sh:NodeShape</div>
</div>
<div class="diagram-class-properties-section">
<div><a href="#name">sh:name</a> : xsd:string or rdf:langString</div>
<div><a href="#description">sh:description</a> : xsd:string or rdf:langString</div>
<div><a href="#defaultValue">sh:defaultValue</a> : any</div>
<div><a href="#group">sh:group</a> : sh:PropertyGroup</div>
</div>
<div class="diagram-class-properties-section">
<div><a href="#property-shapes">sh:path</a> : rdfs:Resource</div>
</div>
</div>
</div>
<div style="clear: both"></div>
</div>
<p>
The <a href="http://www.w3.org/ns/shacl.ttl">Turtle serialization of the SHACL vocabulary</a> contains the complete SHACL vocabulary.
</p>
</div>
<section id="shapes">
<h3>Shapes</h3>
<div class="syntax" data-syntax-rule="shape">
A <dfn data-lt="shape|shapes">shape</dfn> is an <a>IRI</a> or <a>blank node</a> <code>s</code>
that fulfills at least one of the following conditions in the <a>shapes graph</a>:
<ul>
<li>
<code>s</code> is a <a>SHACL instance</a> of <code>sh:NodeShape</code> or <code>sh:PropertyShape</code>.
</li>
<li>
<code>s</code> is <a>subject</a> of a triple that has <code>sh:targetClass</code>, <code>sh:targetNode</code>,
<code>sh:targetObjectsOf</code> or <code>sh:targetSubjectsOf</code> as <a>predicate</a>.
</li>
<li>
<code>s</code> is <a>subject</a> of a triple that has a <a>parameter</a> as <a>predicate</a>.
</li>
<li>
<code>s</code> is a <a>value</a> of a <a>shape-expecting</a>, non-<a>list-taking</a> <a>parameter</a> such as <code>sh:node</code>,
or a <a>member</a> of a <a>SHACL list</a> that is a <a>value</a> of a <a>shape-expecting</a> and <a>list-taking</a> parameter such as <code>sh:or</code>.
</li>
</ul>
</div>
<p>
Note that the definition above does not include all of the syntax rules of <a>well-formed</a> shapes.
Those are found throughout the document and summarized in Appendix <a href="#syntax-rules"></a>.
For example, shapes that have <a>literals</a> as values for <code>sh:targetClass</code> are <a>ill-formed</a>.
</p>
<p>
Informally, a shape determines how to validate a <a>focus node</a> based on the <a>values</a> of properties and other characteristics of the focus node.
For example, shapes can declare the condition that a focus node be an IRI or that a focus node has a particular value for a property and also a minimum number of values for the property.
</p>
<p>
The SHACL Core language defines two types of shapes:
</p>
<ul>
<li>shapes about the <a>focus node</a> itself, called <a>node shapes</a></li>
<li>shapes about the <a>values</a> of a particular property or path for the focus node, called <a>property shapes</a></li>
</ul>
<p>
<code>sh:Shape</code> is the <a>SHACL superclass</a> of those two shape types in the SHACL vocabulary.
Its subclasses <code>sh:NodeShape</code> and <code>sh:PropertyShape</code> can be used as SHACL type of node and property shapes, respectively.
</p>
<section id="constraints">
<h3>Constraints, Parameters and Constraint Components</h3>
<p>
Shapes can declare <a>constraints</a> using the <a>parameters</a> of <a>constraint components</a>.
</p>
<p>
A <dfn data-lt="constraint component|constraint components|components|component">constraint component</dfn> is an <a>IRI</a>.
Each constraint component has one or more <dfn data-lt="mandatory parameter">mandatory parameters</dfn>, each of which is a property.
Each constraint component has zero or more <dfn data-lt="optional parameter">optional parameters</dfn>, each of which is a property.
The <dfn data-lt="parameter">parameters</dfn> of a constraint component are its mandatory parameters plus its optional parameters.
</p>
<p>
For example, the <a>component</a> <code>sh:MinCountConstraintComponent</code> declares the <a>parameter</a> <code>sh:minCount</code> to represent the restriction
that a <a>node</a> has at least a minimum number of <a>values</a> for a particular property.
</p>
<p>
For a <a>constraint component</a> <code>C</code> with <a>mandatory parameters</a> <code>p1</code>, ... <code>pn</code>,
a <a>shape</a> <code>s</code> in a <a>shapes graph</a> <code>SG</code> <em>declares</em> a <dfn data-lt="constraints">constraint</dfn>
that has <dfn>kind</dfn> <code>C</code> with <a>mandatory parameter</a> <a>values</a> <code><p1,v1></code>, ... <code><pn,vn></code>
in <code>SG</code> when <code>s</code> has <code>vi</code> as a <a>value</a> for <code>pi</code> in <code>SG</code>.
For constraint components with <a>optional parameters</a>, the constraint declaration consists of the <a>values</a> that the shape has for all mandatory and optional parameters of that component.
</p>
<p id="multiple-parameter-constraints-section">
Some constraint components declare only a single parameter.
For example <a href="#ClassConstraintComponent"><code>sh:ClassConstraintComponent</code></a> has the single parameter <code>sh:class</code>.
These parameters may be used multiple times in the same shape,
and each <a>value</a> of such a parameter declares an individual <a>constraint</a>.
The interpretation of such declarations is conjunction, i.e. all constraints apply.
The following example specifies that the values of <code>ex:customer</code> have to be <a>SHACL instances</a> of both
<code>ex:Customer</code> and <code>ex:Person</code>.
</p>
<pre class="example-shapes">
ex:InvoiceShape
a sh:NodeShape ;
sh:property [
sh:path ex:customer ;
sh:class ex:Customer ;
sh:class ex:Person ;
] .</pre>
<p class="syntax" data-syntax-rule="multiple-parameters">
Some constraint components such as <a href="#PatternConstraintComponent"><code>sh:PatternConstraintComponent</code></a> declare more than one parameter.
Shapes that have more than one value for any of the parameters of such components are <a>ill-formed</a>.
</p>
<p>
One way to bypass this syntax rule is to spread the constraints across multiple (property) shapes, as illustrated in the following example.
</p>
<pre class="example-shapes">
ex:MultiplePatternsShape
a sh:NodeShape ;
sh:property [
sh:path ex:name ;
sh:pattern "^Start" ;
sh:flags "i" ;
] ;
sh:property [
sh:path ex:name ;
sh:pattern "End$" ;
] .</pre>
<p>
Constraint components are associated with <dfn data-lt="validator">validators</dfn>, which provide instructions (for example expressed via SPARQL queries)
on how the parameters are used to validate data.
Validating an <a>RDF term</a> against a <a>shape</a> involves validating the term against each <a>constraint</a> where the
shape has <a>values</a> for all <a>mandatory parameters</a> of the <a>component</a> of the <a>constraint</a>,
using the validators associated with the respective component.
</p>
<p>
The list of constraint components included in SHACL Core is described in <a href="#constraints">section 4</a>.
SHACL-SPARQL can be used to declare additional <a href="#sparql-constraint-components">constraint components based on SPARQL</a>.
</p>
</section>
<section id="focusNodes">
<h3>Focus Nodes</h3>
<p>
An <a>RDF term</a> that is <a>validated</a> against a <a>shape</a> using the triples from a <a>data graph</a> is called a <dfn data-lt="focus node|focus nodes">focus node</dfn>.
</p>
<p><em>The remainder of this section is informative.</em></p>
<p>
The set of <a>focus nodes</a> for a <a>shape</a> may be identified as follows:
</p>
<ul>
<li>specified in a <a>shape</a> using <a>target declarations</a></li>
<li>specified in any <a>constraint</a> that references a <a>shape</a>
in parameters of <a>shape-expecting constraint parameters</a> (e.g. <code>sh:node</code>)</li>
<li>specified as explicit input to the SHACL processor for validating a specific RDF term against a shape</li>
</ul>
</section>
<section id="targets">
<h3>Targets</h3>
<p>
<dfn data-lt="target declaration">Target declarations</dfn> of a <a>shape</a> in a <a>shapes graph</a> are
<a>triples</a> with the <a>shape</a> as the <a>subject</a> and certain properties described in this document
(e.g., <code>sh:targetClass</code>) as <a>predicates</a>.
Target declarations can be used to produce <a>focus nodes</a> for a <a>shape</a>.
The <dfn data-lt="targets">target</dfn> of a <a>target declaration</a> is the set of RDF terms produced
by applying the rules described in the remainder of this section to the <a>data graph</a>.
The <dfn data-lt="target of the shape">target of a shape</dfn> is the union of all RDF terms produced by the individual
<a>targets</a> that are declared by the <a>shape</a> in the <a>shapes graph</a>.
</p>
<p>
SHACL Core includes the following kinds of targets:
<a href="#targetNode">node targets</a>,
<a href="#targetClass">class-based targets</a> (including <a href="#implicit-targetClass">implicit class-based targets</a>),
<a href="#targetSubjectsOf">subjects-of targets</a>, and
<a href="#targetObjectsOf">objects-of targets</a>.
</p>
<p><em>The remainder of this introduction is informative.</em></p>
<p>
RDF terms produced by targets are not required to exist as nodes in the <a>data graph</a>.
Targets of a shape are ignored whenever a focus node is provided directly as input to the validation process for that shape.
This includes the cases where the shape is a value of one of the
<a>shape-expecting constraint parameters</a> (such as <code>sh:node</code>) and
a focus node is determined during the validation of the corresponding constraint component (such as <code>sh:NodeConstraintComponent</code>).
In such cases, the provided focus node does not need to be in the <a>target of the shape</a>.
</p>
<section id="targetNode">
<h4>Node targets (sh:targetNode)</h4>
<p class="syntax">
A <dfn>node target</dfn> is specified using the <code>sh:targetNode</code> predicate.
<span data-syntax-rule="targetNode-nodeKind">Each <a>value</a> of <code>sh:targetNode</code> in a shape is either an <a>IRI</a> or a <a>literal</a>.</span>
</p>
<div class="def">
<div class="def-header">TEXTUAL DEFINITION</div>
If <code>s</code> is a <a>shape</a> in a <a>shapes graph</a> <code>SG</code> and <code>s</code> has
<a>value</a> <code>t</code> for <code>sh:targetNode</code> in <code>SG</code>
then <code>{ t }</code> is a <a>target</a> from any data graph for <code>s</code> in <code>SG</code>.
</div>
<p><em>The remainder of this section is informative.</em></p>
<p>
With the example data below, only <code>ex:Alice</code> is the target of the provided shape:
</p>
<pre class="example-shapes">
ex:PersonShape
a sh:NodeShape ;
sh:targetNode ex:Alice .</pre>
<pre class="example-data">
<span class="focus-node-selected">ex:Alice</span> a ex:Person .
ex:Bob a ex:Person .</pre>
<p class="def-sparql">
The following query expresses a potential definition of node targets in SPARQL.
The variable <code>targetNode</code> will be <a href="#pre-binding">pre-bound</a> to the given value of <code>sh:targetNode</code>.
All <a>bindings</a> of the variable <code>this</code> from the <a>solution</a> become focus nodes.
</p>
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL</div>
<pre class="def-sparql-body">
SELECT DISTINCT ?this <span class="triple-can-be-skipped"># ?this is the focus node</span>
WHERE {
BIND ($targetNode AS ?this) <span class="triple-can-be-skipped"># $targetNode is <a href="#pre-binding">pre-bound</a> to ex:Alice</span>
}</pre>
</div>
</section>
<section id="targetClass">
<h4>Class-based Targets (sh:targetClass)</h4>
<p class="syntax">
A <dfn>class target</dfn> is specified with the <code>sh:targetClass</code> predicate.
<span data-syntax-rule="targetClass-nodeKind">Each value of <code>sh:targetClass</code> in a shape is an <a>IRI</a>.</span>
</p>
<div class="def">
<div class="def-header">TEXTUAL DEFINITION</div>
If <code>s</code> is a shape in a shapes graph <code>SG</code> and <code>s</code> has <a>value</a> <code>c</code> for
<code>sh:targetClass</code> in <code>SG</code> then the set of <a>SHACL instances</a> of <code>c</code> in a data graph
<code>DG</code> is a <a>target</a> from <code>DG</code> for <code>s</code> in <code>SG</code>.
</div>
<p><em>The remainder of this section is informative.</em></p>
<pre class="example-shapes">
ex:PersonShape
a sh:NodeShape ;
sh:targetClass ex:Person .</pre>
<pre class="example-data">
<span class="focus-node-selected">ex:Alice</span> a ex:Person .
<span class="focus-node-selected">ex:Bob</span> a ex:Person .
ex:NewYork a ex:Place .</pre>
<p>
In this example, only <code>ex:Alice</code> and <code>ex:Bob</code> are focus nodes.
Note that, according to the <a>SHACL instance</a> definition, all the <code>rdfs:subClassOf</code> declarations needed to walk the class hierarchy need to exist in the <a>data graph</a>.
However, the <code>ex:Person a rdfs:Class</code> triple is not required to exist in either graphs.
</p>
<p>
In the following example, the selected focus node is only <code>ex:Who</code>.
</p>
<pre class="example-data">
ex:Doctor rdfs:subClassOf ex:Person .
<span class="focus-node-selected">ex:Who</span> a ex:Doctor .
ex:House a ex:Nephrologist .</pre>
<p class="def-sparql">
The following query expresses a potential definition of class targets in SPARQL.
The variable <code>targetClass</code> will be <a href="#pre-binding">pre-bound</a> to the given value of <code>sh:targetClass</code>.
All <a>bindings</a> of the variable <code>this</code> from the <a>solutions</a> become focus nodes.
</p>
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL</div>
<pre class="def-sparql-body">
SELECT DISTINCT ?this <span class="triple-can-be-skipped"># ?this is the focus node</span>
WHERE {
?this rdf:type/rdfs:subClassOf* $targetClass . <span class="triple-can-be-skipped"># $targetClass is <a href="#pre-binding">pre-bound</a> to ex:Person</span>
}</pre>
</div>
</section>
<section id="implicit-targetClass">
<h4>Implicit Class Targets</h4>
<p>
Informally, if a <a>shape</a> is also declared to be a <a>class</a> in the <a>shapes graph</a> then
all <a>SHACL instances</a> of this class are a target for the shape.
</p>
<p class="syntax" data-syntax-rule="implicit-targetClass-nodeKind">
If <code>s</code> is a <a>SHACL instance</a> of <code>sh:NodeShape</code> or <code>sh:PropertyShape</code>
in an RDF graph <code>G</code> and <code>s</code> is also a <a>SHACL instance</a> of
<code>rdfs:Class</code> in <code>G</code> and <code>s</code> is not an <a>IRI</a> then <code>s</code> is an <a>ill-formed</a> shape in <code>G</code>.
</p>
<div class="def">
<div class="def-header">TEXTUAL DEFINITION</div>
If <code>s</code> is a <a>SHACL instance</a> of <code>sh:NodeShape</code> or <code>sh:PropertyShape</code>
in a <a>shapes graph</a> <code>SG</code> and <code>s</code> is also a <a>SHACL instance</a> of <code>rdfs:Class</code>
in <code>SG</code> then the set of <a>SHACL instances</a> of <code>s</code> in a data graph <code>DG</code> is a <a>target</a> from <code>DG</code> for <code>s</code> in <code>SG</code>.
</div>
<p><em>The remainder of this section is informative.</em></p>
<p>
In the following example, <code>ex:Alice</code> is a focus node, because it is a <a>SHACL instance</a> of
<code>ex:Person</code> which is both a class and a shape in the <a>shapes graph</a>.
</p>
<pre class="example-shapes">
ex:Person
<b>a rdfs:Class</b>, sh:NodeShape .</pre>
<pre class="example-data">
<span class="focus-node-selected">ex:Alice</span> a ex:Person .
ex:NewYork a ex:Place .</pre>
</section>
<section id="targetSubjectsOf">
<h4>Subjects-of targets (sh:targetSubjectsOf)</h4>
<p class="syntax">
A <dfn>subjects-of target</dfn> is specified with the predicate <code>sh:targetSubjectsOf</code>.
<span data-syntax-rule="targetSubjectsOf-nodeKind">The <a>values</a> of <code>sh:targetSubjectsOf</code> in a shape are <a>IRIs</a>.</span>
</p>
<div class="def">
<div class="def-header">TEXTUAL DEFINITION</div>
If <code>s</code> is a shape in a shapes graph <code>SG</code> and <code>s</code> has <a>value</a>
<code>p</code> for <code>sh:targetSubjectsOf</code> in <code>SG</code> then the set of nodes in a
data graph <code>DG</code> that are <a>subjects</a> of triples in <code>DG</code> with <a>predicate</a>
<code>p</code> is a <a>target</a> from <code>DG</code> for <code>s</code> in <code>SG</code>.
</div>
<p><em>The remainder of this section is informative.</em></p>
<pre class="example-shapes">
ex:TargetSubjectsOfExampleShape
a sh:NodeShape ;
sh:targetSubjectsOf ex:knows .</pre>
<pre class="example-data">
<span class="focus-node-selected">ex:Alice</span> ex:knows ex:Bob .
ex:Bob ex:livesIn ex:NewYork .</pre>
<p>
In the example above, only <code>ex:Alice</code> is validated against the given shape,
because it is the <a>subject</a> of a <a>triple</a> that has <code>ex:knows</code> as its <a>predicate</a>.
</p>
<p class="def-sparql">
The following query expresses a potential definition of subjects-of targets in SPARQL.
The variable <code>targetSubjectsOf</code> will be <a href="#pre-binding">pre-bound</a> to the given value of <code>sh:targetSubjectsOf</code>.
All <a>bindings</a> of the variable <code>this</code> from the <a>solutions</a> become focus nodes.
</p>
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL</div>
<pre class="def-sparql-body">
SELECT DISTINCT ?this <span class="triple-can-be-skipped"># ?this is the focus node</span>
WHERE {
?this $targetSubjectsOf ?any . <span class="triple-can-be-skipped"># $targetSubjectsOf is <a href="#pre-binding">pre-bound</a> to ex:knows</span>
}</pre>
</div>
</section>
<section id="targetObjectsOf">
<h4>Objects-of targets (sh:targetObjectsOf)</h4>
<p class="syntax">
An <dfn>objects-of target</dfn> is specified with the predicate <code>sh:targetObjectsOf</code>.
<span data-syntax-rule="targetObjectsOf-nodeKind">The <a>values</a> of <code>sh:targetObjectsOf</code> in a shape are <a>IRIs</a>.</span>
</p>
<div class="def">
<div class="def-header">TEXTUAL DEFINITION</div>
If <code>s</code> is a shape in a shapes graph <code>SG</code> and <code>s</code> has <a>value</a>
<code>p</code> for <code>sh:targetObjectsOf</code> in <code>SG</code> then the set of nodes in a
data graph <code>DG</code> that are <a>objects</a> of triples in <code>DG</code> with <a>predicate</a>
<code>p</code> is a <a>target</a> from <code>DG</code> for <code>s</code> in <code>SG</code>.
</div>
<p><em>The remainder of this section is informative.</em></p>
<pre class="example-shapes">
ex:TargetObjectsOfExampleShape
a sh:NodeShape ;
sh:targetObjectsOf ex:knows .</pre>
<pre class="example-data">
ex:Alice ex:knows <span class="focus-node-selected">ex:Bob</span> .
ex:Bob ex:livesIn ex:NewYork .</pre>
<p>
In the example above, only <code>ex:Bob</code> is validated against the given shape,
because it is the <a>object</a> of a <a>triple</a> that has <code>ex:knows</code> as its <a>predicate</a>.
</p>
<p class="def-sparql">
The following query expresses a potential definition of objects-of targets in SPARQL.
The variable <code>targetObjectsOf</code> will be <a href="#pre-binding">pre-bound</a> to the given value of <code>sh:targetObjectsOf</code>.
All <a>bindings</a> of the variable <code>this</code> from the <a>solutions</a> become focus nodes.
</p>
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL</div>
<pre class="def-sparql-body">
SELECT DISTINCT ?this <span class="triple-can-be-skipped"># ?this is the focus node</span>
WHERE {
?any $targetObjectsOf ?this . <span class="triple-can-be-skipped"># $targetObjectsOf is <a href="#pre-binding">pre-bound</a> to ex:knows</span>
}</pre>
</div>
</section>
</section>
<section id="severity">
<h4>Declaring the Severity of a Shape</h4>
<p class="syntax">
<span data-syntax-rule="severity-maxCount">Shapes can specify one <a>value</a> for the property <code>sh:severity</code> in the <a>shapes graph</a>.</span>
<span data-syntax-rule="severity-nodeKind">Each value of <code>sh:severity</code> in a shape is an <a>IRI</a>.</span>
</p>
<p>
The values of <code>sh:severity</code> are called <dfn data-lt="severity">severities</dfn>.
SHACL includes the three IRIs listed in the table below to represent <a>severities</a>.
These are declared in the SHACL vocabulary as SHACL instances of <code>sh:Severity</code>.
</p>
<table class="term-table">
<tr>
<th>Severity</th>
<th>Description</th>
</tr>
<tr>
<td><code>sh:Info</code></td>
<td>A non-critical constraint violation indicating an informative message.</td>
</tr>
<tr>
<td><code>sh:Warning</code></td>
<td>A non-critical constraint violation indicating a warning.</td>
</tr>
<tr>
<td><code>sh:Violation</code></td>
<td>A constraint violation.</td>
</tr>
</table>
<p><em>The remainder of this section is informative.</em></p>
<p>
The specific values of <code>sh:severity</code> have no impact on the validation,
but MAY be used by user interface tools to categorize validation results.
The values of <code>sh:severity</code> are used by SHACL processors to populate the <code>sh:resultSeverity</code> field of
validation results, see <a href="#results-severity">section on severity in validation results</a>.
Any IRI can be used as a severity.
</p>
<p>
For every shape, <code>sh:Violation</code> is the default if <code>sh:severity</code> is unspecified.
The following example illustrates this.
</p>
<pre class="example-shapes">
ex:MyShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:MyInstance ;</span>
sh:property [ # _:b1
# Violations of sh:minCount and sh:datatype are produced as warnings
sh:path ex:myProperty ;
sh:minCount 1 ;
sh:datatype xsd:string ;
sh:severity sh:Warning ;
] ;
sh:property [ # _:b2
# The default severity here is sh:Violation
sh:path ex:myProperty ;
sh:maxLength 10 ;
sh:message "Too many characters"@en ;
sh:message "Zu viele Zeichen"@de ;
] .</pre>
<pre class="example-data">
ex:MyInstance
ex:myProperty "http://toomanycharacters"^^xsd:anyURI .</pre>
<pre class="example-results">
[ a sh:ValidationReport ;
sh:conforms false ;
sh:result
[ a sh:ValidationResult ;
sh:resultSeverity sh:Warning ;
sh:focusNode ex:MyInstance ;
sh:resultPath ex:myProperty ;
sh:value "http://toomanycharacters"^^xsd:anyURI ;
sh:sourceConstraintComponent sh:DatatypeConstraintComponent ;
sh:sourceShape _:b1 ;
] ,
[ a sh:ValidationResult ;
sh:resultSeverity sh:Violation ;
sh:focusNode ex:MyInstance ;
sh:resultPath ex:myProperty ;
sh:value "http://toomanycharacters"^^xsd:anyURI ;
sh:resultMessage "Too many characters"@en ;
sh:resultMessage "Zu viele Zeichen"@de ;
sh:sourceConstraintComponent sh:MaxLengthConstraintComponent ;
sh:sourceShape _:b2 ;
]
] .</pre>
</section>
<section id="message">
<h4>Declaring Messages for a Shape</h4>
<p class="syntax">
Shapes can have values for the property <code>sh:message</code>.
<span data-syntax-rule="message-datatype">The values of <code>sh:message</code> in a shape are either <code>xsd:string</code> literals or literals with a language tag.</span>
A shape should not have more than one value for <code>sh:message</code> with the same language tag.
</p>
<p>
If a shape has at least one value for <code>sh:message</code> in the shapes graph, then
all <a>validation results</a> produced as a result of the shape will have exactly these messages
as their value of <code>sh:resultMessage</code>, i.e. the values will be copied from the shapes graph
into the results graph.
(Note that in SHACL-SPARQL, <a>SPARQL-based constraints</a> and <a href="#sparql-constraint-components">SPARQL-based constraint components</a> provide additional means to declare such messages.)
</p>
<p><em>The remainder of this section is informative.</em></p>
<p>
The example from the previous section uses this mechanism to supply the second validation result
with two messages.
See the <a href="#results-message">section on <code>sh:resultMessage</code> in the validation results</a>
on further details on how the values of <code>sh:resultMessage</code> are populated.
</p>
</section>
<section id="deactivated">
<h4>Deactivating a Shape</h4>
<p class="syntax">
<span data-syntax-rule="deactivated-maxCount">Shapes can have at most one value for the property <code>sh:deactivated</code>.</span>
<span data-syntax-rule="deactivated-datatype">The value of <code>sh:deactivated</code> in a shape must be either <code>true</code> or <code>false</code>.</span>
</p>
<p>
A shape that has the <a>value</a> <code>true</code> for the property <code>sh:deactivated</code> is called <dfn data-lt="deactivate">deactivated</dfn>.
All RDF terms <a>conform</a> to a deactivated shape.
</p>
<p><em>The remainder of this section is informative.</em></p>
<p>
Use cases of this feature include shape reuse and debugging.
In scenarios where shapes from other graphs or files are imported into a given <a>shapes graph</a>,
<code>sh:deactivated</code> can be set to <code>true</code> in the local shapes graph for imported shapes
to exclude shapes that do not apply in the current application context.
This makes it possible to reuse SHACL graphs developed by others even if you disagree with certain assumptions made by the original authors.
If a shape author anticipates that a shape may need to be disabled or modified by others, it is a good practice to use <a>IRIs</a> instead of <a>blank nodes</a>
for the actual shapes. For example, a <a>property shape</a> for the property <code>ex:name</code> at the shape <code>ex:PersonShape</code> may have the IRI <code>ex:PersonShape-name</code>.
Another typical use case of <code>sh:deactivated</code> is during the development and testing of shapes, to (temporarily) disable certain shapes.
</p>
<p>
The following example illustrates the use of <code>sh:deactivated</code> to deactivate a shape.
In cases where shapes are imported from other graphs, the <code>sh:deactivated true</code> triple would be in the importing graph.
</p>
<pre class="example-shapes">
ex:PersonShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetClass ex:Person ;</span>
sh:property ex:PersonShape-name .
ex:PersonShape-name
a sh:PropertyShape ;
sh:path ex:name ;
sh:minCount 1 ;
sh:deactivated true .</pre>
<p>
With the following data, no constraint violation will be reported even though the instance does not have any value for <code>ex:name</code>.
</p>
<pre class="example-data">
ex:JohnDoe a ex:Person .</pre>
</section>
</section>
<section id="node-shapes">
<h3>Node Shapes</h3>
<p class="syntax">
A <dfn data-lt="node shapes">node shape</dfn> is a <a>shape</a> in the <a>shapes graph</a> that
is not the <a>subject</a> of a <a>triple</a> with <code>sh:path</code> as its <a>predicate</a>.
It is recommended, but not required, for a <a>node shape</a> to be declared as a <a>SHACL instance</a> of <code>sh:NodeShape</code>.
<span data-syntax-rule="NodeShape-path-maxCount"><a>SHACL instances</a> of <code>sh:NodeShape</code> cannot have a <a>value</a> for the property <code>sh:path</code>.</span>
</p>
<p>
Informally, node shapes specify constraints that need to be met with respect to <a>focus nodes</a>.
In contrast to <a>property shapes</a> they primarily apply to the focus node itself, not to its property values.
</p>
</section>
<section id="property-shapes">
<h3>Property Shapes</h3>
<p class="syntax">
<span data-syntax-rule="PropertyShape">A <dfn data-lt="property shapes">property shape</dfn> is a <a>shape</a> in the <a>shapes graph</a>
that is the <a>subject</a> of a <a>triple</a> that has <code>sh:path</code> as its <a>predicate</a>.</span>
<span data-syntax-rule="path-maxCount">A shape has at most one <a>value</a> for <code>sh:path</code>.</span>
<span data-syntax-rule="path-node">Each <a>value</a> of <code>sh:path</code> in a shape must be a <a>well-formed</a> <a>SHACL property path</a>.</span>
It is recommended, but not required, for a <a>property shape</a> to be declared as a <a>SHACL instance</a> of <code>sh:PropertyShape</code>.
<span data-syntax-rule="PropertyShape-path-minCount"><a>SHACL instances</a> of <code>sh:PropertyShape</code> have one <a>value</a> for the property <code>sh:path</code>.</span>
</p>
<p>
Informally, property shapes specify constraints that need to be met with respect to <a>nodes</a> that can be reached from the
<a>focus node</a> either by directly following a given property (specified as an <a>IRI</a>) or any other <a>SHACL property path</a>,
specified using <code>sh:path</code>.
</p>
<p>
Note that the definitions of <a>well-formed</a> <a>property shapes</a> and <a>node shapes</a> make these two sets of nodes disjoint.
</p>
<p>
The following example illustrates some syntax variations of property shapes.
</p>
<pre class="example-shapes">
ex:ExampleNodeShapeWithPropertyShapes
a sh:NodeShape ;
sh:property [
sh:path ex:email ;
sh:name "e-mail" ;
sh:description "We need at least one email value" ;
sh:minCount 1 ;
] ;
sh:property [
sh:path (ex:knows ex:email) ;
sh:name "Friend's e-mail" ;
sh:description "We need at least one email for everyone you know" ;
sh:minCount 1 ;
] .
ex:ExamplePropertyShape
a sh:PropertyShape ;
sh:path ex:email ;
sh:description "We need at least one email value" ;
sh:minCount 1 .</pre>
<section id="property-paths">
<h4>SHACL Property Paths</h4>
<p>
SHACL includes RDF terms to represent the following subset of <a>SPARQL property paths</a>:
<code>PredicatePath</code>, <code>InversePath</code>, <code>SequencePath</code>, <code>AlternativePath</code>,
<code>ZeroOrMorePath</code>, <code>OneOrMorePath</code> and <code>ZeroOrOnePath</code>.
</p>
<p>
The following sub-sections provide syntax rules of <a>well-formed</a> <a>SHACL property paths</a>
together with mapping rules to <a href="https://www.w3.org/TR/sparql11-query/#pp-language">SPARQL 1.1 property paths</a>.
These rules define the <dfn>path mapping</dfn> <code>path(p,G)</code> in an RDF graph <code>G</code> of an RDF term <code>p</code> that is a SHACL property path in <code>G</code>.
Two SHACL property paths are considered <dfn data-lt="equivalent path">equivalent paths</dfn> when they map to the exact same SPARQL property paths.
</p>
<p class="syntax">
<span data-syntax-rule="path-metarule">A node in an RDF graph is a <a>well-formed</a> <dfn data-lt="SHACL property paths">SHACL property path</dfn> <code>p</code> if it satisfies exactly one of the syntax rules in the following sub-sections.</span>
<span data-syntax-rule="path-non-recursive">A node <code>p</code> is not a <a>well-formed</a> SHACL property path if <code>p</code> is a blank node and any path mappings of <code>p</code> directly or transitively reference <code>p</code>.</span>
</p>
<p>
The following example illustrates some valid SHACL property paths, together with their SPARQL 1.1 equivalents.
</p>
<pre class="example-other">
SPARQL Property path: ex:parent
SHACL Property path: ex:parent
SPARQL Property path: ^ex:parent
SHACL Property path: [ sh:inversePath ex:parent ]
SPARQL Property path: ex:parent/ex:firstName
SHACL Property path: ( ex:parent ex:firstName )
SPARQL Property path: rdf:type/rdfs:subClassOf*
SHACL Property path: ( rdf:type [ sh:zeroOrMorePath rdfs:subClassOf ] )
SPARQL Property path: ex:father|ex:mother
SHACL Property path: [ sh:alternativePath ( ex:father ex:mother ) ]</pre>
<section id="property-path-predicate">
<h5>Predicate Paths</h5>
<p class="syntax">
A <dfn>predicate path</dfn> is an <a>IRI</a>.
</p>
<p>
If <code>p</code> is a <a>predicate path</a> then <code>path(p,G)</code> is a SPARQL <code>PredicatePath</code> with <code>p</code> as <code>iri</code>.
</p>
</section>
<section id="property-path-sequence">
<h5>Sequence Paths</h5>
<p class="syntax" data-syntax-rule="path-sequence">
A <dfn>sequence path</dfn> is a <a>blank node</a> that is a <a>SHACL list</a>
with at least two <a>members</a> and each member is a <a>well-formed</a> SHACL property path.
</p>
<p>
If <code>p</code> is a <a>sequence path</a> in <code>G</code> with list <a>members</a>
<code>v<sub>1</sub></code>, <code>v<sub>2</sub></code>, ..., <code>v<sub>n</sub></code>
then <code>path(p,G)</code> is a SPARQL <code>SequencePath</code> of
<code>path(v<sub>1</sub>,G)</code> as <code>elt1</code>, and the results of the <a>path mapping</a>
of the list node of <code>v<sub>2</sub></code> as <code>elt2</code>.
</p>
<p>
Informal note: the <a>nodes</a> in such a <a>SHACL list</a> should not have <a>values</a> for
other properties beside <code>rdf:first</code> and <code>rdf:rest</code>.
</p>
</section>
<section id="property-path-alternative">
<h5>Alternative Paths</h5>
<p class="syntax" data-syntax-rule="path-alternative">
An <dfn>alternative path</dfn> is a <a>blank node</a> that is the subject of exactly one triple in <code>G</code>.
This triple has <code>sh:alternativePath</code> as predicate, <code>L</code> as object,
and <code>L</code> is a <a>SHACL list</a> with at least two <a>members</a>
and each member of <code>L</code> is a <a>well-formed</a> SHACL property path.
</p>
<p>
If <code>p</code> is an <a>alternative path</a> in <code>G</code> then, for the members of its SHACL list <code>L</code>:
<code>v<sub>1</sub></code>, <code>v<sub>2</sub></code>, ..., <code>v<sub>n</sub></code>,
<code>path(p,G)</code> is a SPARQL <code>AlternativePath</code> with
<code>path(v<sub>1</sub>,G)</code> as <code>elt1</code> followed by an <code>AlternativePath</code>
for <code>v<sub>2</sub></code> as <code>elt2</code>, ..., up to <code>path(v<sub>n</sub>,G)</code>.
</p>
</section>
<section id="property-path-inverse">
<h5>Inverse Paths</h5>
<p class="syntax" data-syntax-rule="path-inverse">
An <dfn>inverse path</dfn> is a <a>blank node</a> that is the <a>subject</a> of exactly one <a>triple</a> in <code>G</code>.
This triple has <code>sh:inversePath</code> as predicate, and the <a>object</a> <code>v</code> is a <a>well-formed</a> SHACL property path.
</p>
<p>
If <code>p</code> is an <a>inverse path</a> in <code>G</code> then <code>path(p,G)</code> is a
SPARQL <code>InversePath</code> with <code>path(v,G)</code> as its <code>elt</code>.
</p>
</section>
<section id="property-path-zero-or-more">
<h5>Zero-Or-More Paths</h5>
<p class="syntax" data-syntax-rule="path-zero-or-more">
A <dfn>zero-or-more path</dfn> is a <a>blank node</a> that is the <a>subject</a> of exactly one <a>triple</a> in <code>G</code>.
This triple has <code>sh:zeroOrMorePath</code> as <a>predicate</a>, and the <a>object</a> <code>v</code> is a <a>well-formed</a> SHACL property path.
</p>
<p>
If <code>p</code> is a <a>zero-or-more path</a> in <code>G</code> then <code>path(p,G)</code> is a
SPARQL <code>ZeroOrMorePath</code> with <code>path(v,G)</code> as its <code>elt</code>.
</p>
</section>
<section id="property-path-one-or-more">
<h5>One-Or-More Paths</h5>
<p class="syntax" data-syntax-rule="path-one-or-more">
A <dfn>one-or-more path</dfn> is a <a>blank node</a> that is the <a>subject</a> of exactly one <a>triple</a> in <code>G</code>.
This triple has <code>sh:oneOrMorePath</code> as <a>predicate</a>, and the <a>object</a> <code>v</code> is a <a>well-formed</a> SHACL property path.
</p>
<p>
If <code>p</code> is a <a>one-or-more path</a> in <code>G</code> then <code>path(p,G)</code> is a
SPARQL <code>OneOrMorePath</code> with <code>path(v,G)</code> as its <code>elt</code>.
</p>
</section>
<section id="property-path-zero-or-one">
<h5>Zero-Or-One Paths</h5>
<p class="syntax" data-syntax-rule="path-zero-or-one">
A <dfn>zero-or-one path</dfn> is a <a>blank node</a> that is the <a>subject</a> of exactly one <a>triple</a> in <code>G</code>.
This triple has <code>sh:zeroOrOnePath</code> as <a>predicate</a>, and the <a>object</a> <code>v</code> is a <a>well-formed</a> SHACL property path.
</p>
<p>
If <code>p</code> is a <a>zero-or-one path</a> in <code>G</code> then <code>path(p,G)</code> is a
SPARQL <code>ZeroOrOnePath</code> with <code>path(v,G)</code> as its <code>elt</code>.
</p>
</section>
</section>
<section id="nonValidation" class="informative">
<h4>Non-Validating Property Shape Characteristics</h4>
<p>
While the previous sections introduced properties that represent validation conditions,
this section covers properties that are ignored by SHACL processors.
The use of these so-called <dfn data-lt="non-validating property">non-validating properties</dfn> is entirely optional and not subject to formal interpretation contracts.
They MAY be used for purposes such as form building or predictable printing of RDF files.
</p>
<section id="name">
<h5>sh:name and sh:description</h5>
<p>
Property shapes may have one or more <a>values</a> for <code>sh:name</code> to provide human-readable labels for the property in the target where it appears.
If present, tools SHOULD prefer those locally specified labels over globally specified labels at the <code>rdf:Property</code> itself.
For example, if a form displays a node that is in the target of a given property shape with an <code>sh:name</code>, then the tool SHOULD use the provided name.
Similarly, property shape may have values for <code id="description">sh:description</code> to provide descriptions of the property in the given context.
Both <code>sh:name</code> and <code>sh:description</code> may have multiple <a>values</a>, but should only have one <a>value</a> per language tag.
</p>
</section>
<section id="order">
<h5>sh:order</h5>
<p>
Property shapes may have one <a>value</a> for the property <code>sh:order</code> to indicate the relative order of the property shape for purposes such as form building.
The values of <code>sh:order</code> are decimals.
<code>sh:order</code> is not used for validation purposes and may be used with any type of subjects.
If present at property shapes, the recommended use of <code>sh:order</code> is to sort the property shapes in an ascending order, for example so that
properties with smaller order are placed above (or to the left) of properties with larger order.
</p>
</section>
<section id="group">
<h5>sh:group</h5>
<p>
Property shapes may link to an <a>SHACL instance</a> of the class <code>sh:PropertyGroup</code> using the property <code>sh:group</code> to indicate that
the shape belongs to a group of related property shapes.
Each group may have additional triples that serve application purposes, such as an <code>rdfs:label</code> for form building.
Groups may also have an <code>sh:order</code> property to indicate the relative ordering of groups within the same form.
</p>
</section>
<section id="defaultValue">
<h5>sh:defaultValue</h5>
<p>
Property shapes may have a single value for <code>sh:defaultValue</code>.
The default value does not have fixed semantics in SHACL, but MAY be used by user interface tools to pre-populate input widgets.
The value type of the <code>sh:defaultValue</code> should align with the specified <code>sh:datatype</code> or <code>sh:class</code> of the same shape.
</p>
<p>
The following example illustrates the use of these various features together.
</p>
<pre class="example-shapes">
ex:PersonFormShape
a sh:NodeShape ;
sh:property [
sh:path ex:firstName ;
sh:name "first name" ;
sh:description "The person's given name(s)" ;
sh:order 0 ;
sh:group ex:NameGroup ;
] ;
sh:property [
sh:path ex:lastName ;
sh:name "last name" ;
sh:description "The person's last name" ;
sh:order 1 ;
sh:group ex:NameGroup ;
] ;
sh:property [
sh:path ex:streetAddress ;
sh:name "street address" ;
sh:description "The street address including number" ;
sh:order 11 ;
sh:group ex:AddressGroup ;
] ;
sh:property [
sh:path ex:locality ;
sh:name "locality" ;
sh:description "The suburb, city or town of the address" ;
sh:order 12 ;
sh:group ex:AddressGroup ;
] ;
sh:property [
sh:path ex:postalCode ;
sh:name "postal code" ;
sh:name "zip code"@en-US ;
sh:description "The postal code of the locality" ;
sh:order 13 ;
sh:group ex:AddressGroup ;
] .
ex:NameGroup
a sh:PropertyGroup ;
sh:order 0 ;
rdfs:label "Name" .
ex:AddressGroup
a sh:PropertyGroup ;
sh:order 1 ;
rdfs:label "Address" .</pre>
<p>
A form building application MAY use the information above to display information as follows:
</p>
<div style="background: #f3f3f3; padding: 8px">
<div style="font-size: 18px; color: #0000a0"><b>Name</b></div>
<table>
<tr>
<td style="text-align: right; width: 160px"><b>first name:</b></td>
<td>John</td>
</tr>
<tr>
<td style="text-align: right"><b>last name:</b></td>
<td>Doe</td>
</tr>
</table>
<div style="font-size: 18px; padding-top: 6px; color: #0000a0"><b>Address</b></div>
<table>
<tr>
<td style="text-align: right; width: 160px"><b>street address:</b></td>
<td>123 Silverado Ave</td>
</tr>
<tr>
<td style="text-align: right"><b>locality:</b></td>
<td>Cupertino</td>
</tr>
<tr>
<td style="text-align: right"><b>zip code:</b></td>
<td>54321</td>
</tr>
</table>
</div>
</section>
</section>
</section>
</section>
<section id="validation">
<h2>Validation and Graphs</h2>
<p>
<a>Validation</a> takes a <a>data graph</a> and a <a>shapes graph</a> as input and produces
a <a>validation report</a> containing the results of the validation.
<a>Conformance checking</a> is a simplified version of validation, producing a boolean result.
A system that is capable of performing validation is called a <dfn>processor</dfn>,
and the verb <dfn>processing</dfn> is sometimes used to refer to the validation process.
</p>
<p>
SHACL defines an RDF <a>Validation Report Vocabulary</a> that can be used by processors that produce validation reports as RDF results graphs.
This specification uses the SHACL results vocabulary for the normative definitions of the <a>validators</a>
associated with the <a>constraint components</a>.
Only SHACL implementations that can produce all of the mandatory properties of the <a>Validation Report Vocabulary</a> are standards-compliant.
</p>
<section id="shapes-graph">
<h3>Shapes Graph</h3>
<p>
A <dfn data-lt="shapes graphs">shapes graph</dfn> is an RDF graph containing zero or more shapes
that is passed into a SHACL <a>validation</a> process so that a <a>data graph</a> can be validated against the shapes.
</p>
<p><em>The remainder of this section is informative.</em></p>
<p>
Shapes graphs can be reusable validation modules that can be cross-referenced with the predicate <a href="http://www.w3.org/TR/owl2-syntax/#Imports"><code>owl:imports</code></a>.
As a pre-validation step, SHACL processors SHOULD extend the originally provided <a>shapes graph</a> by transitively following and importing all referenced <a>shapes graphs</a>
through the <a href="http://www.w3.org/TR/owl2-syntax/#Imports"><code>owl:imports</code></a> predicate.
The resulting graph forms the input <a>shapes graph</a> for validation and MUST NOT be further modified during the validation process.
</p>
<p>
In addition to shape declarations, the shapes graph may contain additional information for the SHACL processor such as <code>sh:entailment</code> statements.
</p>
</section>
<section id="data-graph">
<h3>Data Graph</h3>
<p>
Any RDF graph can be a <dfn data-lt="data graphs">data graph</dfn>.
</p>
<p><em>The remainder of this section is informative.</em></p>
<p>
A data graph is one of the inputs to the SHACL processor for <a>validation</a>.
SHACL processors treat it as a general RDF graph and makes no assumption about its nature.
For example, it can be an in-memory graph or a named graph from an RDF dataset or a SPARQL endpoint.
</p>
<p>
SHACL can be used with RDF graphs that are obtained by any means, e.g. from the file system, HTTP requests, or <a href="http://www.w3.org/TR/rdf11-concepts/#section-dataset">RDF datasets</a>.
SHACL makes no assumptions about whether a graph contains triples that are entailed from the graph under any RDF entailment regime.
</p>
<p>
The data graph is expected to include all the ontology axioms related to the data and especially all the
<code>rdfs:subClassOf</code> triples in order for SHACL to correctly identify class targets and validate Core SHACL constraints.
</p>
</section>
<section id="sh-shapes-graph">
<h3>Linking to shapes graphs (sh:shapesGraph)</h3>
<p class="syntax">
A <a>data graph</a> can include triples used to suggest one or more graphs to a SHACL processor with the predicate <code>sh:shapesGraph</code>.
<span data-syntax-rule="shapesGraph-nodeKind">Every <a>value</a> of <code>sh:shapesGraph</code> is an <a>IRI</a></span> representing a graph that SHOULD be included into the <a>shapes graph</a> used to validate the <a>data graph</a>.
</p>
<p>
In the following example, a SHACL processor SHOULD use the union of <code>ex:graph-shapes1</code> and <code>ex:graph-shapes2</code> graphs (and their <code>owl:imports</code>) as the <a>shapes graph</a> when validating the given graph.
</p>
<pre class="example-data">
<http://example.com/myDataGraph>
sh:shapesGraph ex:graph-shapes1 ;
sh:shapesGraph ex:graph-shapes2 .</pre>
</section>
<section id="validation-definition">
<h3>Validation</h3>
<p>
<dfn data-lt="validating|validates|validated|validate">Validation</dfn> is a mapping from some input
to <a>validation results</a>, as defined in the following paragraphs.
</p>
<p>
<dfn>Validation of a data graph against a shapes graph:</dfn>
Given a <a>data graph</a> and a <a>shapes graph</a>,
the <a>validation results</a> are the union of results of the <a>validation</a> of the <a>data graph</a> against all
<a>shapes</a> in the <a>shapes graph</a>.
</p>
<p>
<dfn>Validation of a data graph against a shape:</dfn>
Given a <a>data graph</a> and a <a>shape</a> in the <a>shapes graph</a>,
the <a>validation results</a> are the union of the results of the <a>validation</a> of all
<a>focus nodes</a> that are in the <a>target</a> of the <a>shape</a> in the <a>data graph</a>.
</p>
<p>
<dfn>Validation of a focus node against a shape:</dfn>
Given a <a>focus node</a> in the <a>data graph</a> and a <a>shape</a> in the <a>shapes graph</a>,
the <a>validation results</a> are the union of the results of the <a>validation</a> of the <a>focus node</a> against all
<a>constraints</a> declared by the <a>shape</a>, unless the <a>shape</a> has been <a>deactivated</a>,
in which case the <a>validation results</a> are empty.
</p>
<p>
<dfn>Validation of a focus node against a constraint:</dfn>
Given a <a>focus node</a> in the <a>data graph</a> and a <a>constraint</a> of <a>kind</a> <code>C</code> in the <a>shapes graph</a>,
the <a>validation results</a> are defined by the <a>validators</a> of the <a>constraint component</a> <code>C</code>.
These <a>validators</a> typically take as input the <a>focus node</a>, the specific <a>values</a> of the <a>parameters</a> of <code>C</code>
of the <a>constraint</a> in the <a>shapes graph</a>, and the <a>value nodes</a> of the <a>shape</a> that declares the constraint.
</p>
<p>
During validation, the <a>data graph</a> and the <a>shapes graph</a> MUST remain immutable, i.e. both graphs at the end of the validation MUST be identical to the graph at the beginning of validation.
SHACL processors MUST NOT change the graphs that they use to construct the shapes graph or the data graph,
even if these graphs are part of an RDF store that allows changes to its stored graphs.
SHACL processors MAY store the graphs that they create, such as a graph containing validation results,
and this operation MAY change existing graphs in an RDF store, but not any of the graphs that were used to construct the shapes graph or the data graph.
SHACL processing is thus idempotent.
</p>
<section id="failures">
<h4>Failures</h4>
<p>
<a>Validation</a> and <a>conformance checking</a> can result in a <dfn data-lt="failures">failure</dfn>.
For example, a particular SHACL processor might allow recursive shapes but report a failure
if it detects a loop within the data.
Failures can also be reported due to resource exhaustion.
Failures are signalled through implementation-specific channels.
</p>
</section>
<section id="ill-formed-shape-graphs">
<h4>Handling of Ill-formed Shapes Graphs</h4>
<p>
If the <a>shapes graph</a> contains <a>ill-formed</a> nodes, then the result of the validation process is <em>undefined</em>.
A SHACL processor SHOULD produce a <a>failure</a> in this case.
See also <a href="#shapesGraphWellFormed"></a>.
</p>
</section>
<section id="shapes-recursion">
<h4>Handling of Recursive Shapes</h4>
<p>
The following properties are the so-called <dfn data-lt="shape-expecting">shape-expecting constraint parameters</dfn> in SHACL Core:
</p>
<ul>
<li><a href="#AndConstraintComponent">sh:and</a></li>
<li><a href="#NotConstraintComponent">sh:not</a></li>
<li><a href="#OrConstraintComponent">sh:or</a></li>
<li><a href="#PropertyConstraintComponent">sh:property</a></li>
<li><a href="#QualifiedValueShapeConstraintComponent">sh:qualifiedValueShape</a></li>
<li><a href="#NodeConstraintComponent">sh:node</a></li>
<li><a href="#XoneConstraintComponent">sh:xone</a></li>
</ul>
<p>
The following properties are the so-called <dfn data-lt="list-taking">list-taking constraint parameters</dfn> in SHACL Core:
</p>
<ul>
<li><a href="#AndConstraintComponent">sh:and</a></li>
<li><a href="#InConstraintComponent">sh:in</a></li>
<li><a href="#LanguageInConstraintComponent">sh:languageIn</a></li>
<li><a href="#OrConstraintComponent">sh:or</a></li>
<li><a href="#XoneConstraintComponent">sh:xone</a></li>
</ul>
<p>
A shape <code>s1</code> in an RDF graph <code>G</code> <dfn>refers</dfn> to shape <code>s2</code>
in <code>G</code> if it has <code>s2</code> as <a>value</a> for some non-list-taking,
shape-expecting parameter of some constraint component or <code>s2</code> as a <a>member</a> of
the <a>value</a> for some list-taking, shape-expecting parameter of some constraint component.
A shape in an RDF graph <code>G</code> is a <dfn data-lt="recursive">recursive shape</dfn> in <code>G</code> if it is related to
itself by the transitive closure of the <a>refers</a> relationship in <code>G</code>.
</p>
<p>
The <a>validation</a> with <a>recursive</a> shapes is not defined in SHACL and is left to SHACL processor implementations.
For example, SHACL processors may support recursion scenarios or produce a failure when they detect recursion.
</p>
<p><em>The remainder of this section is informative.</em></p>
<p>
The recursion policy above has been selected to support a large variety of implementation strategies.
By leaving recursion undefined, implementations may chose to not support recursion so that they
can issue a static set of SPARQL queries (against SPARQL end points) without having to support cycles.
The Working Group is aware that other implementations may support recursion and that some shapes graphs may
rely on these specific characteristics.
The expectation is that future work, for example in W3C Community Groups, will lead to the definition
of specific dialects of SHACL where recursion is well-defined.
</p>
</section>
</section>
<section id="conformance-definition">
<h3>Conformance Checking</h3>
<p>
A <a>focus node</a> <dfn data-lt="conform|conformance">conforms</dfn> to a <a>shape</a> if and only if
the set of result of the <a>validation</a> of the <a>focus node</a> against the <a>shape</a> is empty and no <a>failure</a>
has been reported by it.
</p>
<p>
<dfn>Conformance checking</dfn> produces <code>true</code> if and only if a given <a>focus node</a>
<a>conforms</a> to a given <a>shape</a>, and <code>false</code> otherwise.
</p>
<p id="conformance-nested">
Note that some <a>constraint components</a> of SHACL Core (e.g., those of <code>sh:not</code>, <code>sh:or</code> and <code>sh:node</code>)
rely on conformance checking.
In these cases, the <a>validation results</a> used to determine the outcome of conformance checking are
separated from those of the surrounding validation process and typically do not end up in the same validation report
(except perhaps as values of <a href="#results-detail"><code>sh:detail</code></a>).
</p>
</section>
<section id="validation-report">
<h3>Validation Report</h3>
<p>
The <dfn data-lt="validation report|report">validation report</dfn> is the result of the <a>validation</a> process that reports the <a>conformance</a> and the set of all <dfn data-lt="validation result|result">validation results</dfn>.
The validation report is described with the SHACL <dfn>Validation Report Vocabulary</dfn> as defined in this section.
This vocabulary defines the RDF properties to represent structural information that may provide guidance on how to identify or fix violations in the data graph.
</p>
<p><!-- ISSUE-181 -->
SHACL-compliant processors MUST be capable of returning a validation report with all required <a>validation results</a>
described in this specification.
SHACL-compliant processors MAY support optional arguments that make it possible to limit the number of returned results.
This flexibility is for example needed in some large-scale dataset validation use cases.
</p>
<p>
The following graph represents an example of a validation report for the validation of a data graph that conforms to a shapes graph.
</p>
<pre class="example-results">
[ a sh:ValidationReport ;
sh:conforms true ;
] .</pre>
<p>
The following graph represents an example of a validation report for the validation of a data graph that does not conform to a shapes graph.
Note that the specific value of <code>sh:resultMessage</code> is not mandated by SHACL and considered implementation-specific.
</p>
<pre class="example-results">
[ a sh:ValidationReport ;
sh:conforms false ;
sh:result [
a sh:ValidationResult ;
sh:resultSeverity sh:Violation ;
sh:focusNode ex:Bob ;
sh:resultPath ex:age ;
sh:value "twenty two" ;
sh:resultMessage "ex:age expects a literal of datatype xsd:integer." ;
sh:sourceConstraintComponent sh:DatatypeConstraintComponent ;
sh:sourceShape ex:PersonShape-age ;
]
] .</pre>
<section id="results-validation-report">
<h4>Validation Report (sh:ValidationReport)</h4>
<p>
The result of a <a>validation</a> process is an RDF graph with exactly one <a>SHACL instance</a> of <code>sh:ValidationReport</code>.
The RDF graph MAY contain additional information such as provenance metadata.
</p>
<section id="conforms">
<h5>Conforms (sh:conforms)</h5>
<p>
Each SHACL instance of <code>sh:ValidationReport</code> in the results graph has exactly one value for the property <code>sh:conforms</code> and the value is of datatype <code>xsd:boolean</code>.
It represents the outcome of the <a>conformance checking</a>.
The value of <code>sh:conforms</code> is <code>true</code> if and only if the <a>validation</a> did not produce any <a>validation results</a>, and <code>false</code> otherwise.
</p>
</section>
<section id="result">
<h5>Result (sh:result)</h5>
<p>
For every validation result that is produced by a <a>validation</a> process
(except those mentioned in the context of <a href="#conformance-nested">conformance checking</a>),
the SHACL instance of <code>sh:ValidationReport</code> in the results graph has a value for the property <code>sh:result</code>.
Each value of <code>sh:result</code> is a <a>SHACL instance</a> of the class <code>sh:ValidationResult</code>.
</p>
</section>
<section id="shapesGraphWellFormed"><!-- ISSUE-233 -->
<h5>Syntax Checking of Shapes Graph (sh:shapesGraphWellFormed)</h5>
<p>
SHACL validation engines are not strictly required to check whether the <a>shapes graph</a> is <a>well-formed</a>.
Implementations that do perform such checks (e.g., when the shapes graph is installed in the system,
or before or during the validation) SHOULD use the property <code>sh:shapesGraphWellFormed</code> to inform the
consumer of the validation report about this fact.
If a SHACL instance of <code>sh:ValidationReport</code> in the results graph has <code>true</code> as the <a>value</a>
for <code>sh:shapesGraphWellFormed</code> then the <a>processor</a> was certain that the <a>shapes graph</a> that was used for the
<a>validation</a> process has passed all SHACL syntax rules (as summarized in <a href="#syntax-rules"></a>) during the validation process.
</p>
</section>
</section>
<section id="results-validation-result">
<h4>Validation Result (sh:ValidationResult)</h4>
<p>
SHACL defines <code>sh:ValidationResult</code> as a subclass of <code>sh:AbstractResult</code> to report individual SHACL <a>validation results</a>.
SHACL implementations may use other <a>SHACL subclasses</a> of <code>sh:AbstractResult</code>, for example,
to report successfully completed constraint checks or accumulated results.
</p>
<p>
All the properties described in the remaining sub-sections of this section can be specified in a <code>sh:ValidationResult</code>.
The properties <code>sh:focusNode</code>, <code>sh:resultSeverity</code> and <code>sh:sourceConstraintComponent</code>
are the only properties that are mandatory for all validation results.
</p>
<section id="results-focus-node">
<h5>Focus node (sh:focusNode)</h5>
<p>
Each validation result has exactly one value for the property <code>sh:focusNode</code>
that is equal to the <a>focus node</a> that has caused the result.
This is the <a>focus node</a> that was validated when the validation result was produced.
</p>
</section>
<section id="results-path">
<h4>Path (sh:resultPath)</h4>
<p>
Validation results may have a value for the property <code>sh:resultPath</code> pointing at a <a>well-formed</a> <a>SHACL property path</a>.
For results produced by a <a>property shape</a>, this <a>SHACL property path</a> is equivalent to the <a>value</a> of <code>sh:path</code> of the shape,
unless stated otherwise. <!-- sh:closed is an exception -->
</p>
</section>
<section id="results-value">
<h4>Value (sh:value)</h4>
<p>
Validation results may include, as a <a>value</a> of the property <code>sh:value</code>,
at most one RDF term that has caused the result.
The textual definitions of the validators of the SHACL Core components specify how this
value is constructed - often they are the <a>value nodes</a> that have violated a constraint.
</p>
</section>
<section id="results-source-shape">
<h4>Source (sh:sourceShape)</h4>
<p>
Validation results may include, as the only <a>value</a> of the property <code>sh:sourceShape</code>,
the <a>shape</a> that the given <code>sh:focusNode</code> was validated against.
</p>
</section>
<section id="results-source-constraint-component">
<h4>Constraint Component (sh:sourceConstraintComponent)</h4>
<p>
Validation results have exactly one value for the property <code>sh:sourceConstraintComponent</code>
and this value is the <a>IRI</a> of the <a>constraint component</a> that caused the result.
For example, results produced due to a violation of a constraint based on a value of <code>sh:minCount</code>
would have the source constraint component <code>sh:MinCountConstraintComponent</code>.
</p>
</section>
<section id="results-detail">
<h4>Details (sh:detail)</h4>
<p>
The property <code>sh:detail</code> may link a (parent) result with one or more SHACL instances of
<code>sh:AbstractResult</code> that can provide further details about the cause of the (parent) result.
Depending on the capabilities of the SHACL processor, this may for example include violations of
constraints that have been evaluated as part of conformance checking via <code>sh:node</code>.
</p>
</section>
<section id="results-message">
<h4>Message (sh:resultMessage)</h4>
<p>
Validation results may have values for the property <code>sh:resultMessage</code>,
for example to communicate additional textual details to humans.
While <code>sh:resultMessage</code> may have multiple values, there should not be two values with the same language tag.
These values are produced by a validation engine based on the values of <code>sh:message</code> of the constraints
in the shapes graph, see <a href="#message">Declaring Messages for a Shape</a>.
In cases where a constraint does not have any values for <code>sh:message</code> in the shapes graph the
SHACL processor MAY automatically generate other values for <code>sh:resultMessage</code>.
</p>
</section>
<section id="results-severity">
<h4>Severity (sh:resultSeverity)</h4>
<p>
Each validation result has exactly one <a>value</a> for the property <code>sh:resultSeverity</code>, and this value is an <a>IRI</a>.
The value is equal to the <a>value</a> of <a href="#severity"><code>sh:severity</code></a> of the <a>shape</a> in the <a>shapes graph</a> that caused the result,
defaulting to <code>sh:Violation</code> if no <code>sh:severity</code> has been specified for the shape.
</p>
</section>
</section>
</section>
<section id="value-nodes">
<h3>Value Nodes</h3>
<p>
The <a>validators</a> of most constraint components use the concept of <dfn data-lt="value node">value nodes</dfn>, which is defined as follows:
</p>
<ul>
<li>
For <a>node shapes</a> the <a>value nodes</a> are the individual <a>focus nodes</a>, forming a set with exactly one member.
</li>
<li>
For <a>property shapes</a> with a <a>value</a> for <code>sh:path</code> <code>p</code> the
<a>value nodes</a> are the set of <a>nodes</a> in the <a>data graph</a>
that can be reached from the <a>focus node</a> with the <a>path mapping</a> of <code>p</code>.
Unless stated otherwise, the value of <code>sh:resultPath</code> of each validation result is a
<a>SHACL property path</a> that <a href="#property-paths">represents</a> an <a>equivalent path</a> to the one provided in the shape.
</li>
</ul>
</section>
</section>
<section id="core-components">
<h2>Core Constraint Components</h2>
<p>
This section defines the built-in SHACL Core <a>constraint components</a> that MUST be supported by all SHACL Core processors.
The definition of each constraint component contains its IRI as well as a table of its <a>parameters</a>.
Unless stated otherwise, all these parameters are <a>mandatory parameters</a>.
Shapes that violate any of the syntax rules enumerated in those parameter tables are <a>ill-formed</a>.
</p>
<p>
Each constraint component also includes a textual definition, which describes the <a>validator</a> associated with the component.
These textual definitions refer to the values of the parameters in the constraint by variables of the form
<code>$paramName</code> where <code>paramName</code> is the part of the parameter's <a>IRI</a> after the <code>sh:</code> namespace.
For example, the textual definition of <code>sh:ClassConstraintComponent</code> refers to the value of
<code>sh:class</code> using the variable <code>$class</code>.
Note that these validators define the <em>only</em> validation results that are being produced by the component.
Furthermore, the validators always produce <em>new</em> result nodes, i.e. when the textual definition states that
"...there is a validation result..." then this refers to a distinct new node in a results graph.
</p>
<p><em>The remainder of this section is informative.</em></p>
<p>
The choice of constraint components that were included into the SHACL Core was made based on
the requirements collected by the [[shacl-ucr]] document.
Special attention was paid to the balance between trying to cover as many common use cases as possible
and keeping the size of the Core language manageable.
Not all use cases can be expressed by the Core language alone.
Instead, SHACL-SPARQL provides an extension mechanism, described in the second part of this specification.
It is expected that additional reusable libraries of <a>constraint components</a> will be maintained by third parties.
</p>
<p>
Unless stated otherwise, the Core constraint components can be used both in <a>property shapes</a> and <a>node shapes</a>.
Some constraint parameters have syntax rules attached to them that would make <a>node shapes</a> that use these parameters <a>ill-formed</a>.
Examples of this include <code>sh:minCount</code> which is only supported for <a>property shapes</a>.
</p>
<p class="def-sparql">
The SPARQL definitions in this section represent potential <a href="#constraint-components-validators">validators</a>.
They are included for illustration purposes only and have no formal status otherwise.
Many constraint components are written as SPARQL ASK queries.
These queries are interpreted against each <a>value node</a>, bound to the variable <code>value</code>.
If an ASK query does not evaluate to <code>true</code> for a <a>value node</a>, then there is a <a>validation result</a> based on the rules outlined in
the <a href="#SPARQLAskValidator">section on ASK-based validators</a>.
Constraint components that are described using a SELECT query are interpreted based on the rules outlined in
the <a href="#SPARQLSelectValidator">section on SELECT-based validators</a>.
In particular, for <a>property shapes</a>, the variable <code>PATH</code> is <a>substituted</a> with a path expression
based on the value of <code>sh:path</code> in the shape.
All SPARQL queries also require the variable bindings and result variable mapping rules detailed in the
<a href="#sparql-constraints">section on SPARQL-based Constraints</a>.
The variable <code>this</code> represents the currently validated <a>focus node</a>.
Based on the parameter IRIs on the tables, <a>pre-bound</a> variables are derived using the syntax rules for <a>parameter names</a>.
</p>
<section id="core-components-value-type">
<h3>Value Type Constraint Components</h3>
<p>
The constraint components in this section have in common that they can be used to restrict the type of value nodes.
Note that it is possible to represent multiple value type alternatives using <a href="#OrConstraintComponent">sh:or</a>.
</p>
<section id="ClassConstraintComponent">
<h4>sh:class</h4>
<p>
The condition specified by <code>sh:class</code> is that each <a>value node</a> is a <a>SHACL instance</a> of a given type.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:ClassConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:class</code></td>
<td>
The type of all value nodes.
<span data-syntax-rule="class-nodeKind">The values of <code>sh:class</code> in a shape are IRIs.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="Class">
For each <a>value node</a>
that is either a <a>literal</a>, or a non-literal that is not a <a>SHACL instance</a> of <code>$class</code> in the <a>data graph</a>,
there is a <a>validation result</a> with the <a>value node</a> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<p>
Note that multiple values for <code>sh:class</code> are interpreted as a conjunction,
i.e. the values need to be SHACL instances of all of them.
</p>
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must evaluate to true for each value node $value)</div>
<pre class="def-sparql-body">
ASK {
$value rdf:type/rdfs:subClassOf* $class .
}</pre>
</div>
<pre class="example-shapes">
ex:ClassExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:Bob, ex:Alice, ex:Carol ;</span>
sh:property [
sh:path ex:address ;
sh:class ex:PostalAddress ;
] .</pre>
<pre class="example-data">
ex:Alice a ex:Person .
ex:Bob ex:address [ a ex:PostalAddress ; ex:city ex:Berlin ] .
<span class="focus-node-error">ex:Carol</span> ex:address [ ex:city ex:Cairo ] .</pre>
</section>
<section id="DatatypeConstraintComponent">
<h4>sh:datatype</h4>
<p>
<code>sh:datatype</code> specifies a condition to be satisfied with regards to the datatype of each <a>value node</a>.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:DatatypeConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:datatype</code></td>
<td>
The datatype of all value nodes (e.g., <code>xsd:integer</code>).
<span data-syntax-rule="datatype-nodeKind">The values of <code>sh:datatype</code> in a shape are <a>IRIs</a>.</span>
<span data-syntax-rule="datatype-maxCount">A shape has at most one value for <code>sh:datatype</code>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="Datatype">
For each <a>value node</a>
that is not a <a>literal</a>, or is a <a>literal</a> with a datatype that does not match <code>$datatype</code>,
there is a <a>validation result</a> with the <a>value node</a> as <code>sh:value</code>.
The datatype of a literal is determined following the <a href="https://www.w3.org/TR/sparql11-query/#func-datatype">datatype</a> function of SPARQL 1.1.
A <a>literal</a> matches a datatype if the <a>literal</a>'s datatype has the same <a>IRI</a>
and, for the datatypes supported by SPARQL 1.1, is not an <a href="https://www.w3.org/TR/rdf11-concepts#section-Graph-Literal">ill-typed</a> literal.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<p>
The values of <code>sh:datatype</code> are typically <a>datatypes</a>, such as <code>xsd:string</code>.
Note that using <code>rdf:langString</code> as value of <code>sh:datatype</code> can be used to test if value nodes have a language tag.
</p>
<pre class="example-shapes" title="Shape with sh:datatype property constraint">
ex:DatatypeExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:Alice, ex:Bob, ex:Carol ;</span>
sh:property [
sh:path ex:age ;
sh:datatype xsd:integer ;
] .</pre>
<pre class="example-data">
ex:Alice ex:age "23"^^xsd:integer .
<span class="focus-node-error">ex:Bob</span> ex:age "twenty two" .
<span class="focus-node-error">ex:Carol</span> ex:age "23"^^xsd:int .</pre>
</section>
<section id="NodeKindConstraintComponent">
<h4>sh:nodeKind</h4>
<p>
<code>sh:nodeKind</code> specifies a condition to be satisfied by the RDF node kind of each <a>value node</a>.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:NodeKindConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:nodeKind</code></td>
<td>
The node kind (IRI, blank node, literal or combinations of these) of all value nodes.
<span data-syntax-rule="nodeKind-in">The values of <code>sh:nodeKind</code> in a shape are one of the following six instances of the class <code>sh:NodeKind</code>:
<code>sh:BlankNode</code>, <code>sh:IRI</code>, <code>sh:Literal</code>
<code>sh:BlankNodeOrIRI</code>, <code>sh:BlankNodeOrLiteral</code> and <code>sh:IRIOrLiteral</code>.</span>
<span data-syntax-rule="nodeKind-maxCount">A shape has at most one value for <code>sh:nodeKind</code>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="NodeKind">
For each <a>value node</a>
that does not match <code>$nodeKind</code>,
there is a <a>validation result</a> with the <a>value node</a> as <code>sh:value</code>.
Any <a>IRI</a> matches only <code>sh:IRI</code>, <code>sh:BlankNodeOrIRI</code> and <code>sh:IRIOrLiteral</code>.
Any <a>blank node</a> matches only <code>sh:BlankNode</code>, <code>sh:BlankNodeOrIRI</code> and <code>sh:BlankNodeOrLiteral</code>.
Any <a>literal</a> matches only <code>sh:Literal</code>, <code>sh:BlankNodeOrLiteral</code> and <code>sh:IRIOrLiteral</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must evaluate to true for each value node $value)</div>
<pre class="def-sparql-body">
ASK {
FILTER ((isIRI($value) && $nodeKind IN ( sh:IRI, sh:BlankNodeOrIRI, sh:IRIOrLiteral ) ) ||
(isLiteral($value) && $nodeKind IN ( sh:Literal, sh:BlankNodeOrLiteral, sh:IRIOrLiteral ) ) ||
(isBlank($value) && $nodeKind IN ( sh:BlankNode, sh:BlankNodeOrIRI, sh:BlankNodeOrLiteral ) )) .
}</pre>
</div>
<p>
The following example states that all values of <code>ex:knows</code> need to be IRIs, at any subject.
</p>
<pre class="example-shapes">
ex:NodeKindExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetObjectsOf ex:knows ;</span>
sh:nodeKind sh:IRI .</pre>
<pre class="example-data">
ex:Bob ex:knows ex:Alice .
ex:Alice ex:knows <span class="focus-node-error">"Bob"</span> .</pre>
</section>
</section>
<section id="core-components-count">
<h3>Cardinality Constraint Components</h3>
<p>
The following <a>constraint components</a> represent restrictions on the number of <a>value nodes</a> for the given <a>focus node</a>.
</p>
<section id="MinCountConstraintComponent">
<h4>sh:minCount</h4>
<p>
<code>sh:minCount</code> specifies the minimum number of <a>value nodes</a> that satisfy the condition.
If the minimum cardinality value is 0 then this constraint is always satisfied and so may be omitted.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:MinCountConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:minCount</code></td>
<td>
The minimum cardinality.
<span data-syntax-rule="minCount-scope"><a>Node shapes</a> cannot have any value for <code>sh:minCount</code>.</span>
<span data-syntax-rule="minCount-maxCount">A <a>property shape</a> has at most one value for <code>sh:minCount</code>.</span>
<span data-syntax-rule="minCount-datatype">The values of <code>sh:minCount</code> in a property shape are literals with datatype <code>xsd:integer</code>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="MinCount">
If the number of <a>value nodes</a> is less than <code>$minCount</code>,
there is a <a>validation result</a>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<!-- div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must return no results for the given $PATH)</div>
<pre class="def-sparql-body">
SELECT $this
WHERE {
OPTIONAL {
$this $PATH ?value .
}
}
GROUP BY $this
HAVING (COUNT(DISTINCT ?value) < $minCount)</pre>
</div-->
<pre class="example-shapes">
ex:MinCountExampleShape
a sh:PropertyShape ;
<span class="target-can-be-skipped">sh:targetNode ex:Alice, ex:Bob ;</span>
sh:path ex:name ;
sh:minCount 1 .</pre>
<pre class="example-data">
ex:Alice ex:name "Alice" .
<span class="focus-node-error">ex:Bob</span> ex:givenName "Bob"@en .</pre>
</section>
<section id="MaxCountConstraintComponent">
<h4>sh:maxCount</h4>
<p>
<code>sh:maxCount</code> specifies the maximum number of <a>value nodes</a> that satisfy the condition.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:MaxCountConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:maxCount</code></td>
<td>
The maximum cardinality.
<span data-syntax-rule="maxCount-scope"><a>Node shapes</a> cannot have any value for <code>sh:maxCount</code>.</span>
<span data-syntax-rule="maxCount-maxCount">A <a>property shape</a> has at most one value for <code>sh:maxCount</code>.</span>
<span data-syntax-rule="maxCount-datatype">The values of <code>sh:maxCount</code> in a property shape are literals with datatype <code>xsd:integer</code>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="MaxCount">
If the number of <a>value nodes</a> is greater than <code>$maxCount</code>,
there is a <a>validation result</a>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<!-- div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must return no results for the given $PATH)</div>
<pre class="def-sparql-body">
SELECT $this
WHERE {
$this $PATH ?value .
}
GROUP BY $this
HAVING (COUNT(DISTINCT ?value) > $maxCount)</pre>
</div-->
<pre class="example-shapes">
ex:MaxCountExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:Bob ;</span>
sh:property [
sh:path ex:birthDate ;
sh:maxCount 1 ;
] .</pre>
<pre class="example-data">
ex:Bob ex:birthDate "May 5th 1990" .</pre>
</section>
</section>
<section id="core-components-range">
<h3>Value Range Constraint Components</h3>
<p>
The following constraint components specify value range conditions to be satisfied by value nodes that are comparable
via operators such as <code><</code>, <code><=</code>, <code>></code> and <code>>=</code>.
The following example illustrates a typical use case of these constraint components.
</p>
<pre class="example-shapes">
ex:NumericRangeExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:Bob, ex:Alice, ex:Ted ;</span>
sh:property [
sh:path ex:age ;
sh:minInclusive 0 ;
sh:maxInclusive 150 ;
] .</pre>
<pre class="example-data">
ex:Bob ex:age 23 .
<span class="focus-node-error">ex:Alice</span> ex:age 220 .
<span class="focus-node-error">ex:Ted</span> ex:age "twenty one" .</pre>
<section id="MinExclusiveConstraintComponent">
<h4>sh:minExclusive</h4>
<p>
<span class="component-class">Constraint Component IRI:</span> <code>sh:MinExclusiveConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:minExclusive</code></td>
<td>
The minimum exclusive value.
<span data-syntax-rule="minExclusive-nodeKind">The values of <code>sh:minExclusive</code> in a shape are <a>literals</a>.</span>
<span data-syntax-rule="minExclusive-maxCount">A shape has at most one value for <code>sh:minExclusive</code>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="MinExclusive">
For each <a>value node</a> <code>v</code>
where the SPARQL expression <code>$minExclusive < v</code> does not return <code>true</code>,
there is a <a>validation result</a> with <code>v</code> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<p>
The SPARQL expression produces an error if the value node cannot be compared to the specified range,
for example when someone compares a string with an integer.
If the comparison cannot be performed, then there is a validation result.
This is different from, say, a plain SPARQL query, in which such errors would silently not lead to any results.
</p>
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must evaluate to true for each value node $value)</div>
<pre class="def-sparql-body">
ASK {
FILTER ($minExclusive < $value)
}</pre>
</div>
</section>
<section id="MinInclusiveConstraintComponent">
<h4>sh:minInclusive</h4>
<p>
<span class="component-class">Constraint Component IRI:</span> <code>sh:MinInclusiveConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:minInclusive</code></td>
<td>
The minimum inclusive value.
<span data-syntax-rule="minInclusive-nodeKind">The values of <code>sh:minInclusive</code> in a shape are <a>literals</a>.</span>
<span data-syntax-rule="minInclusive-maxCount">A shape has at most one value for <code>sh:minInclusive</code>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="MinInclusive">
For each <a>value node</a> <code>v</code>
where the SPARQL expression <code>$minInclusive <= v</code> does not return <code>true</code>,
there is a <a>validation result</a> with <code>v</code> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must evaluate to true for each value node $value)</div>
<pre class="def-sparql-body">
ASK {
FILTER ($minInclusive <= $value)
}</pre>
</div>
</section>
<section id="MaxExclusiveConstraintComponent">
<h4>sh:maxExclusive</h4>
<p>
<span class="component-class">Constraint Component IRI:</span> <code>sh:MaxExclusiveConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:maxExclusive</code></td>
<td>
The maximum exclusive value.
<span data-syntax-rule="maxExclusive-nodeKind">The values of <code>sh:maxExclusive</code> in a shape are <a>literals</a>.</span>
<span data-syntax-rule="maxExclusive-maxCount">A shape has at most one value for <code>sh:maxExclusive</code>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="MaxExclusive">
For each <a>value node</a> <code>v</code>
where the SPARQL expression <code>$maxExclusive > v</code> does not return <code>true</code>,
there is a <a>validation result</a> with <code>v</code> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must evaluate to true for each value node $value)</div>
<pre class="def-sparql-body">
ASK {
FILTER ($maxExclusive > $value)
}</pre>
</div>
</section>
<section id="MaxInclusiveConstraintComponent">
<h4>sh:maxInclusive</h4>
<p>
<span class="component-class">Constraint Component IRI:</span> <code>sh:MaxInclusiveConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:maxInclusive</code></td>
<td>
The maximum inclusive value.
<span data-syntax-rule="maxInclusive-nodeKind">The values of <code>sh:maxInclusive</code> in a shape are <a>literals</a>.</span>
<span data-syntax-rule="maxInclusive-maxCount">A shape has at most one value for <code>sh:maxInclusive</code>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="MaxInclusive">
For each <a>value node</a> <code>v</code>
where the SPARQL expression <code>$maxInclusive >= v</code> does not return <code>true</code>,
there is a <a>validation result</a> with <code>v</code> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must evaluate to true for each value node $value)</div>
<pre class="def-sparql-body">
ASK {
FILTER ($maxInclusive >= $value)
}</pre>
</div>
</section>
</section>
<section id="core-components-string">
<h3>String-based Constraint Components</h3>
<p>
The constraint components in this section have in common that they specify conditions
on the string representation of <a>value nodes</a>.
</p>
<section id="MinLengthConstraintComponent">
<h4>sh:minLength</h4>
<p>
<code>sh:minLength</code> specifies the minimum string length of each <a>value node</a> that satisfies the condition.
This can be applied to any <a>literals</a> and <a>IRIs</a>, but not to <a>blank nodes</a>.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:MinLengthConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:minLength</code></td>
<td>
The minimum length.
<span data-syntax-rule="minLength-datatype">The values of <code>sh:minLength</code> in a shape are literals with datatype <code>xsd:integer</code>.</span>
<span data-syntax-rule="minLength-maxCount">A shape has at most one value for <code>sh:minLength</code>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="MinLength">
For each <a>value node</a> <code>v</code>
where the length (as defined by the <a href="https://www.w3.org/TR/sparql11-query/#func-strlen">SPARQL STRLEN function</a>)
of the string representation of <code>v</code> (as defined by the <a href="http://www.w3.org/TR/sparql11-query/#func-str">SPARQL str function</a>)
is less than <code>$minLength</code>, or where <code>v</code> is a <a>blank node</a>,
there is a <a>validation result</a> with <code>v</code> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<p>
Note that if the value of <code>sh:minLength</code> is 0 then there is no restriction on the
string length but the constraint is still violated if the value node is a blank node.
</p>
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must evaluate to true for each value node $value)</div>
<pre class="def-sparql-body">
ASK {
FILTER (STRLEN(str($value)) >= $minLength) .
}</pre>
</div>
</section>
<section id="MaxLengthConstraintComponent">
<h4>sh:maxLength</h4>
<p>
<code>sh:maxLength</code> specifies the maximum string length of each <a>value node</a> that satisfies the condition.
This can be applied to any <a>literals</a> and <a>IRIs</a>, but not to <a>blank nodes</a>.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:MaxLengthConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:maxLength</code></td>
<td>
The maximum length.
<span data-syntax-rule="maxLength-datatype">The values of <code>sh:maxLength</code> in a shape are literals with datatype <code>xsd:integer</code>.</span>
<span data-syntax-rule="maxLength-maxCount">A shape has at most one value for <code>sh:maxLength</code>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="MaxLength">
For each <a>value node</a> <code>v</code>
where the length (as defined by the <a href="https://www.w3.org/TR/sparql11-query/#func-strlen">SPARQL STRLEN function</a>)
of the string representation of <code>v</code> (as defined by the <a href="http://www.w3.org/TR/sparql11-query/#func-str">SPARQL str function</a>)
is greater than <code>$maxLength</code>, or where <code>v</code> is a <a>blank node</a>,
there is a <a>validation result</a> with <code>v</code> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must evaluate to true for each value node $value)</div>
<pre class="def-sparql-body">
ASK {
FILTER (STRLEN(str($value)) <= $maxLength) .
}</pre>
</div>
<pre class="example-shapes">
ex:PasswordExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:Bob, ex:Alice ;</span>
sh:property [
sh:path ex:password ;
sh:minLength 8 ;
sh:maxLength 10 ;
] .</pre>
<pre class="example-data">
ex:Bob ex:password "123456789" .
<span class="focus-node-error">ex:Alice</span> ex:password "1234567890ABC" .</pre>
</section>
<section id="PatternConstraintComponent">
<h4>sh:pattern</h4>
<p>
<code>sh:pattern</code> specifies a regular expression that each <a>value node</a> matches to satisfy the condition.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:PatternConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:pattern</code></td>
<td>
A regular expression that all value nodes need to match.
<span data-syntax-rule="pattern-datatype">The values of <code>sh:pattern</code> in a shape are literals with datatype <code>xsd:string</code>.</span>
<span data-syntax-rule="pattern-regex">The values of <code>sh:pattern</code> in a shape are valid pattern arguments for the <a href="http://www.w3.org/TR/sparql11-query/#func-regex">SPARQL REGEX function</a>.</span>
</td>
</tr>
<tr>
<td><code>sh:flags</code></td>
<td>
An optional string of flags, interpreted as in <a href="http://www.w3.org/TR/sparql11-query/#func-regex">SPARQL 1.1 REGEX</a>.
<span data-syntax-rule="flags-datatype">The values of <code>sh:flags</code> in a shape are literals with datatype <code>xsd:string</code>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="Pattern">
For each <a>value node</a>
that is a blank node or
where the string representation (as defined by the <a href="http://www.w3.org/TR/sparql11-query/#func-str">SPARQL str function</a>)
does not match the regular expression <code>$pattern</code> (as defined by the <a href="http://www.w3.org/TR/sparql11-query/#func-regex">SPARQL REGEX function</a>),
there is a <a>validation result</a> with the <a>value node</a> as <code>sh:value</code>.
If <code>$flags</code> has a value then the matching MUST follow the definition of the 3-argument variant of the SPARQL REGEX function, using <code>$flags</code> as third argument.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must evaluate to true for each value node $value)</div>
<pre class="def-sparql-body">
ASK {
FILTER (!isBlank($value) && IF(bound($flags), regex(str($value), $pattern, $flags), regex(str($value), $pattern)))
}</pre>
</div>
<pre class="example-shapes">
ex:PatternExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:Bob, ex:Alice, ex:Carol ;</span>
sh:property [
sh:path ex:bCode ;
sh:pattern "^B" ; # starts with 'B'
sh:flags "i" ; # Ignore case
] .</pre>
<pre class="example-data">
ex:Bob ex:bCode "b101" .
ex:Alice ex:bCode "B102" .
<span class="focus-node-error">ex:Carol</span> ex:bCode "C103" .</pre>
</section>
<section id="LanguageInConstraintComponent">
<h4>sh:languageIn</h4>
<p>
The condition specified by <code>sh:languageIn</code> is that the allowed language tags for each <a>value node</a> are limited by a given list of language tags.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:LanguageInConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:languageIn</code></td>
<td>
A list of basic language ranges as per [[!BCP47]].
<span data-syntax-rule="languageIn-node">Each value of <code>sh:languageIn</code> in a shape is a <a>SHACL list</a>.</span>
<span data-syntax-rule="languageIn-members-datatype">Each <a>member</a> of such a list is a literal with datatype <code>xsd:string</code>.</span>
<span data-syntax-rule="languageIn-maxCount">A shape has at most one value for <code>sh:languageIn</code>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="LanguageIn">
For each <a>value node</a>
that is either not a <a>literal</a> or that does not have a language tag
matching any of the basic language ranges that are the <a>members</a> of <code>$languageIn</code>
following the filtering schema defined by the <a href="https://www.w3.org/TR/sparql11-query/#func-langMatches">SPARQL langMatches</a> function,
there is a <a>validation result</a> with the <a>value node</a> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<!-- Disabled due to the use of EXISTS
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must evaluate to true for each value node $value)</div>
<pre class="def-sparql-body">
ASK {
BIND (lang($value) AS ?valueLang) .
FILTER EXISTS {
GRAPH $shapesGraph {
$languageIn (rdf:rest*)/rdf:first ?lang .
FILTER (langMatches(?valueLang, ?lang))
}
}
}</pre>
</div-->
<p>
The following example shape states that all values of <code>ex:prefLabel</code>
can be either in English or Māori.
</p>
<pre class="example-shapes">
ex:NewZealandLanguagesShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:Mountain, ex:Berg ;</span>
sh:property [
sh:path ex:prefLabel ;
sh:languageIn ( "en" "mi" ) ;
] .</pre>
<p>
From the example instances, <code>ex:Berg</code> will lead to constraint violations for all
of its labels.
</p>
<pre class="example-data">
ex:Mountain
ex:prefLabel "Mountain"@en ;
ex:prefLabel "Hill"@en-NZ ;
ex:prefLabel "Maunga"@mi .
<span class="focus-node-error">ex:Berg</span>
ex:prefLabel "Berg" ;
ex:prefLabel "Berg"@de ;
ex:prefLabel ex:BergLabel .</pre>
</section>
<section id="UniqueLangConstraintComponent">
<h4>sh:uniqueLang</h4>
<p>
The property <code>sh:uniqueLang</code> can be set to <code>true</code> to specify that no pair of <a>value nodes</a> may use the same language tag.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:UniqueLangConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:uniqueLang</code></td>
<td>
<code>true</code> to activate this constraint.
<span data-syntax-rule="uniqueLang-datatype">The values of <code>sh:uniqueLang</code> in a shape are literals with datatype <code>xsd:boolean</code>.</span>
<span data-syntax-rule="uniqueLang-maxCount">A property shape has at most one value for <code>sh:uniqueLang</code>.</span>
<span data-syntax-rule="uniqueLang-scope"><a>Node shapes</a> cannot have any value for <code>sh:uniqueLang</code>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="UniqueLang">
If <code>$uniqueLang</code> is <code>true</code>
then for each non-empty language tag that is used by at least two <a>value nodes</a>,
there is a <a>validation result</a>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<!-- Deactivated due to the use of EXISTS
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must return no results for the given $PATH)</div>
<pre class="def-sparql-body">
SELECT DISTINCT $this ?lang
WHERE {
{
FILTER ($uniqueLang) .
}
$this $PATH ?value .
BIND (lang(?value) AS ?lang) .
FILTER (bound(?lang) && ?lang != "") .
FILTER EXISTS {
$this $PATH ?otherValue .
FILTER (?otherValue != ?value && ?lang = lang(?otherValue)) .
}
}</pre>
</div-->
<pre class="example-shapes">
ex:UniqueLangExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:Alice, ex:Bob ;</span>
sh:property [
sh:path ex:label ;
sh:uniqueLang true ;
] .</pre>
<pre class="example-data">
ex:Alice
ex:label "Alice" ;
ex:label "Alice"@en ;
ex:label "Alice"@fr .
<span class="focus-node-error">ex:Bob</span>
ex:label "Bob"@en ;
ex:label "Bobby"@en .</pre>
</section>
</section>
<section id="core-components-property-pairs">
<h3>Property Pair Constraint Components</h3>
<p>
The constraint components in this section specify conditions on the sets of <a>value nodes</a> in relation to other properties.
These constraint components can only be used by <a>property shapes</a>.
</p>
<section id="EqualsConstraintComponent">
<h4>sh:equals</h4>
<p>
<code>sh:equals</code> specifies the condition that the set of all <a>value nodes</a> is equal to the set of <a>objects</a> of the <a>triples</a> that have the <a>focus node</a> as <a>subject</a> and the <a>value</a> of <code>sh:equals</code> as <a>predicate</a>.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:EqualsConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:equals</code></td>
<td>
The property to compare with.
<span data-syntax-rule="equals-nodeKind">The values of <code>sh:equals</code> in a shape are <a>IRIs</a>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="Equals">
For each <a>value node</a>
that does not exist as a <a>value</a> of the property <code>$equals</code> at the <a>focus node</a>,
there is a <a>validation result</a> with the <a>value node</a> as <code>sh:value</code>.
For each <a>value</a> of the property <code>$equals</code> at the <a>focus node</a>
that is not one of the <a>value nodes</a>,
there is a <a>validation result</a> with the <a>value</a> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<p>
The following example illustrates the use of <code>sh:equals</code> in a shape to specify
that certain focus nodes need to have the same set of values for <code>ex:firstName</code> and <code>ex:givenName</code>.
</p>
<pre class="example-shapes">
ex:EqualExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:Bob ;</span>
sh:property [
sh:path ex:firstName ;
sh:equals ex:givenName ;
] .</pre>
<pre class="example-data">
ex:Bob
ex:firstName "Bob" ;
ex:givenName "Bob" .</pre>
</section>
<section id="DisjointConstraintComponent">
<h4>sh:disjoint</h4>
<p>
<code>sh:disjoint</code> specifies the condition that the set of <a>value nodes</a>
is disjoint with the set of <a>objects</a> of the <a>triples</a>
that have the <a>focus node</a> as <a>subject</a>
and the <a>value</a> of <code>sh:disjoint</code> as <a>predicate</a>.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:DisjointConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:disjoint</code></td>
<td>
The property to compare the values with.
<span data-syntax-rule="disjoint-nodeKind">The values of <code>sh:disjoint</code> in a shape are <a>IRIs</a>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="Disjoint">
For each <a>value node</a>
that also exists as a <a>value</a> of the property <code>$disjoint</code> at the <a>focus node</a>,
there is a <a>validation result</a> with the <a>value node</a> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must return no results for the given $PATH)</div>
<pre class="def-sparql-body">
SELECT DISTINCT $this ?value
WHERE {
$this $PATH ?value .
$this $disjoint ?value .
}</pre>
</div>
<p>
The following example illustrates the use of <code>sh:disjoint</code> in a shape to specify
that certain focus nodes cannot share any values for <code>ex:prefLabel</code> and <code>ex:altLabel</code>.
</p>
<pre class="example-shapes">
ex:DisjointExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:USA, ex:Germany ;</span>
sh:property [
sh:path ex:prefLabel ;
sh:disjoint ex:altLabel ;
] .</pre>
<pre class="example-data">
ex:USA
ex:prefLabel "USA" ;
ex:altLabel "United States" .
<span class="focus-node-error">ex:Germany</span>
ex:prefLabel "Germany" ;
ex:altLabel "Germany" .</pre>
</section>
<section id="LessThanConstraintComponent">
<h4>sh:lessThan</h4>
<p>
<code>sh:lessThan</code> specifies the condition that each <a>value node</a> is smaller than all the <a>objects</a> of the <a>triples</a> that have the <a>focus node</a> as <a>subject</a> and the <a>value</a> of <code>sh:lessThan</code> as <a>predicate</a>.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:LessThanConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:lessThan</code></td>
<td>
The property to compare the values with.
<span data-syntax-rule="lessThan-nodeKind">The values of <code>sh:lessThan</code> in a shape are <a>IRIs</a>.</span>
<span data-syntax-rule="lessThan-scope"><a>Node shapes</a> cannot have any value for <code>sh:lessThan</code>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="LessThan">
For each pair of <a>value nodes</a> and the values of the property <code>$lessThan</code> at the given <a>focus node</a>
where the first <a>value</a> is not less than the second <a>value</a> (based on SPARQL's <code><</code> operator)
or where the two values cannot be compared,
there is a <a>validation result</a> with the <a>value node</a> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must return no results for the given $PATH)</div>
<pre class="def-sparql-body">
SELECT $this ?value
WHERE {
$this $PATH ?value .
$this $lessThan ?otherValue .
BIND (?value < ?otherValue AS ?result) .
FILTER (!bound(?result) || !(?result)) .
}</pre>
</div>
<p>
The following example illustrates the use of <code>sh:lessThan</code> in a shape to specify
that all values of <code>ex:startDate</code> are "before" the values of <code>ex:endDate</code>.
</p>
<pre class="example-shapes">
ex:LessThanExampleShape
a sh:NodeShape ;
sh:property [
sh:path ex:startDate ;
sh:lessThan ex:endDate ;
] .</pre>
</section>
<section id="LessThanOrEqualsConstraintComponent">
<h4>sh:lessThanOrEquals</h4>
<p>
<code>sh:lessThanOrEquals</code> specifies the condition that each <a>value node</a> is smaller than or equal to all the <a>objects</a> of the <a>triples</a> that have the <a>focus node</a> as <a>subject</a> and the <a>value</a> of <code>sh:lessThanOrEquals</code> as <a>predicate</a>.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:LessThanOrEqualsConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:lessThanOrEquals</code></td>
<td>
The property to compare the values with.
<span data-syntax-rule="lessThanOrEquals-nodeKind">The values of <code>sh:lessThanOrEquals</code> in a shape are <a>IRIs</a>.</span>
<span data-syntax-rule="lessThanOrEquals-scope"><a>Node shapes</a> cannot have any value for <code>sh:lessThanOrEquals</code>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="LessThanOrEquals">
For each pair of <a>value nodes</a> and the values of the property <code>$lessThanOrEquals</code> at the given <a>focus node</a>
where the first <a>value</a> is not less than or equal to the second <a>value</a> (based on SPARQL's <code><=</code> operator)
or where the two values cannot be compared,
there is a <a>validation result</a> with the <a>value node</a> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must return no results for the given $PATH)</div>
<pre class="def-sparql-body">
SELECT $this ?value
WHERE {
$this $PATH ?value .
$this $lessThan ?otherValue .
BIND (?value <= ?otherValue AS ?result) .
FILTER (!bound(?result) || !(?result)) .
}</pre>
</div>
</section>
</section>
<section id="core-components-logical">
<h4>Logical Constraint Components</h4>
<p>
The constraint components in this section implement the common logical operators
<em>and</em>, <em>or</em> and <em>not</em>, as well as a variation of <em>exclusive or</em>.
</p>
<section id="NotConstraintComponent">
<h3>sh:not</h3>
<p>
<code>sh:not</code> specifies the condition that each <a>value node</a> cannot <a>conform</a> to a given <a>shape</a>.
This is comparable to negation and the logical "not" operator.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:NotConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:not</code></td>
<td>
The shape to negate.
<span data-syntax-rule="not-node">The values of <code>sh:not</code> in a shape must be <a>well-formed</a> <a>shapes</a>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="Not">
For each <a>value node</a> <code>v</code>:
A <a>failure</a> MUST be reported if the <a>conformance checking</a> of <code>v</code> against
the shape <code>$not</code> produces a <a>failure</a>.
Otherwise, if <code>v</code> <a>conforms</a> to the shape <code>$not</code>,
there is <a>validation result</a> with <code>v</code> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<p>
The following example illustrates the use of <code>sh:not</code> in a shape to specify the condition
that certain focus nodes cannot have any value of <code>ex:property</code>.
</p>
<pre class="example-shapes">
ex:NotExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:InvalidInstance1 ;</span>
sh:not [
a sh:PropertyShape ;
sh:path ex:property ;
sh:minCount 1 ;
] .</pre>
<pre class="example-data">
<span class="focus-node-error">ex:InvalidInstance1</span> ex:property "Some value" .</pre>
</section>
<section id="AndConstraintComponent">
<h4>sh:and</h4>
<p>
<code>sh:and</code> specifies the condition that each <a>value node</a> conforms to all provided shapes.
This is comparable to conjunction and the logical "and" operator.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:AndConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:and</code></td>
<td>
A <a>SHACL list</a> of shapes to validate the value nodes against.
<span data-syntax-rule="and-node">Each value of <code>sh:and</code> in a shape is a <a>SHACL list</a>.</span>
<span data-syntax-rule="and-members-node">Each <a>member</a> of such list must be a <a>well-formed</a> <a>shape</a>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="And">
For each <a>value node</a> <code>v</code>:
A <a>failure</a> MUST be produced if the <a>conformance checking</a> of <code>v</code> against any of the <a>members</a> of <code>$and</code> produces a <a>failure</a>.
Otherwise, if <code>v</code> does not <a>conform</a> to each <a>member</a> of <code>$and</code>,
there is a <a>validation result</a> with <code>v</code> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<p>
Note that although <code>sh:and</code> has a <a>SHACL list</a> of shapes as its value,
the order of those shapes does not impact the validation results.
</p>
<p>
The following example illustrates the use of <code>sh:and</code> in a shape to specify the condition
that certain focus nodes have exactly one value of <code>ex:property</code>.
This is achieved via the conjunction of a separate named shape (<code>ex:SuperShape</code>) which specifies
the minimum count, and a blank node shape that additionally specifies the maximum count.
As shown here, <code>sh:and</code> can be used to implement a specialization mechanism between shapes.
</p>
<pre class="example-shapes">
ex:SuperShape
a sh:NodeShape ;
sh:property [
sh:path ex:property ;
sh:minCount 1 ;
] .
ex:ExampleAndShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:ValidInstance, ex:InvalidInstance ;</span>
sh:and (
ex:SuperShape
[
sh:path ex:property ;
sh:maxCount 1 ;
]
) .</pre>
<pre class="example-data">
ex:ValidInstance
ex:property "One" .
# Invalid: more than one property
<span class="focus-node-error">ex:InvalidInstance</span>
ex:property "One" ;
ex:property "Two" .</pre>
</section>
<section id="OrConstraintComponent">
<h4>sh:or</h4>
<p>
<code>sh:or</code> specifies the condition that each <a>value node</a> conforms to at least one of the provided shapes.
This is comparable to disjunction and the logical "or" operator.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:OrConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:or</code></td>
<td>
A <a>SHACL list</a> of shapes to validate the value nodes against.
<span data-syntax-rule="or-node">Each value of <code>sh:or</code> in a shape is a <a>SHACL list</a>.</span>
<span data-syntax-rule="or-members-node">Each <a>member</a> of such list must be a <a>well-formed</a> <a>shape</a>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="Or">
For each <a>value node</a> <code>v</code>:
A <a>failure</a> MUST be produced if the <a>conformance checking</a> of <code>v</code> against any of the <a>members</a> produces a <a>failure</a>.
Otherwise, if <code>v</code> <a>conforms</a> to none of the <a>members</a> of <code>$or</code>
there is a <a>validation result</a> with <code>v</code> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<p>
Note that although <code>sh:or</code> has a <a>SHACL list</a> of shapes as its value,
the order of those shapes does not impact the validation results.
</p>
<p>
The following example illustrates the use of <code>sh:or</code> in a shape to specify the condition
that certain focus nodes have at least one value of <code>ex:firstName</code>
or at least one value of <code>ex:givenName</code>.
</p>
<pre class="example-shapes">
ex:OrConstraintExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:Bob ;</span>
sh:or (
[
sh:path ex:firstName ;
sh:minCount 1 ;
]
[
sh:path ex:givenName ;
sh:minCount 1 ;
]
) .</pre>
<pre class="example-data">
ex:Bob ex:firstName "Robert" .</pre>
<p>
The next example shows how <code>sh:or</code> can be used in a <a>property shape</a> to state that the values of
the given property <code>ex:address</code> may be either literals with datatype <code>xsd:string</code>
or <a>SHACL instances</a> of the class <code>ex:Address</code>.
</p>
<pre class="example-shapes">
ex:PersonAddressShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetClass ex:Person ;</span>
sh:property [
sh:path ex:address ;
sh:or (
[
sh:datatype xsd:string ;
]
[
sh:class ex:Address ;
]
)
] .</pre>
<pre class="example-data">
ex:Bob ex:address "123 Prinzengasse, Vaduz, Liechtenstein" .</pre>
</section>
<section id="XoneConstraintComponent">
<h4>sh:xone</h4>
<p>
<code>sh:xone</code> specifies the condition that each <a>value node</a> conforms to <em>exactly one</em> of the provided shapes.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:XoneConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:xone</code></td>
<td>
A <a>SHACL list</a> of shapes to validate the value nodes against.
<span data-syntax-rule="xone-node">Each value of <code>sh:xone</code> in a shape is a <a>SHACL list</a>.</span>
<span data-syntax-rule="xone-members-node">Each <a>member</a> of such list must be a <a>well-formed</a> <a>shape</a>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="Xone">
For each <a>value node</a> <code>v</code>
let <code>N</code> be the number of the <a>shapes</a> that are <a>members</a> of <code>$xone</code>
where <code>v</code> <a>conforms</a> to the shape.
A <a>failure</a> MUST be produced if the <a>conformance checking</a> of <code>v</code> against any of the <a>members</a> produces a <a>failure</a>.
Otherwise, if <code>N</code> is not exactly <code>1</code>,
there is a <a>validation result</a> with <code>v</code> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<p>
Note that although <code>sh:xone</code> has a <a>SHACL list</a> of shapes as its value,
the order of those shapes does not impact the validation results.
</p>
<p>
The following example illustrates the use of <code>sh:xone</code> in a shape to specify the condition
that certain focus nodes must either have a value for <code>ex:fullName</code> or values for
<code>ex:firstName</code> and <code>ex:lastName</code>, but not both.
</p>
<pre class="example-shapes">
ex:XoneConstraintExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetClass ex:Person ;</span>
sh:xone (
[
sh:property [
sh:path ex:fullName ;
sh:minCount 1 ;
]
]
[
sh:property [
sh:path ex:firstName ;
sh:minCount 1 ;
] ;
sh:property [
sh:path ex:lastName ;
sh:minCount 1 ;
]
]
) .</pre>
<pre class="example-data">
ex:Bob a ex:Person ;
ex:firstName "Robert" ;
ex:lastName "Coin" .
ex:Carla a ex:Person ;
ex:fullName "Carla Miller" .
<span class="focus-node-error">ex:Dory</span> a ex:Person ;
ex:firstName "Dory" ;
ex:lastName "Dunce" ;
ex:fullName "Dory Dunce" .</pre>
</section>
</section>
<section id="core-components-shape">
<h3>Shape-based Constraint Components</h3>
<p>
The constraint components in this section can be used to specify complex conditions
by validating the value nodes against certain shapes.
</p>
<section id="NodeConstraintComponent">
<h4>sh:node</h4>
<p>
<code>sh:node</code> specifies the condition that each <a>value node</a> conforms to the given <a>node shape</a>.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:NodeConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:node</code></td>
<td>
The <a>node shape</a> that all value nodes need to conform to.
<span data-syntax-rule="node-node">The values of <code>sh:node</code> in a shape must be <a>well-formed</a> <a>node shapes</a>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="Node">
For each <a>value node</a> <code>v</code>:
A <a>failure</a> MUST be produced if the <a>conformance checking</a> of <code>v</code> against <code>$node</code> produces a <a>failure</a>.
Otherwise, if <code>v</code> does not <a>conform</a> to <code>$node</code>,
there is a <a>validation result</a> with <code>v</code> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<p>
In the following example, all values of the property <code>ex:address</code> must fulfill the
constraints expressed by the <a>shape</a> <code>ex:AddressShape</code>.
</p>
<pre class="example-shapes">
ex:AddressShape
a sh:NodeShape ;
sh:property [
sh:path ex:postalCode ;
sh:datatype xsd:string ;
sh:maxCount 1 ;
] .
ex:PersonShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetClass ex:Person ;</span>
sh:property [ # _:b1
sh:path ex:address ;
sh:minCount 1 ;
sh:node ex:AddressShape ;
] .</pre>
<pre class="example-data">
ex:Bob a ex:Person ;
ex:address ex:BobsAddress .
ex:BobsAddress
ex:postalCode "1234" .
<span class="focus-node-error">ex:Reto</span> a ex:Person ;
ex:address ex:RetosAddress .
ex:RetosAddress
ex:postalCode 5678 .</pre>
<pre class="example-results">
[ a sh:ValidationReport ;
sh:conforms false ;
sh:result [
a sh:ValidationResult ;
sh:resultSeverity sh:Violation ;
sh:focusNode ex:Reto ;
sh:resultPath ex:address ;
sh:value ex:RetosAddress ;
sh:resultMessage "Value does not conform to shape ex:AddressShape." ;
sh:sourceConstraintComponent sh:NodeConstraintComponent ;
sh:sourceShape _:b1 ;
]
] .</pre>
</section>
<section id="PropertyConstraintComponent">
<h4>sh:property</h4>
<p>
<code>sh:property</code> can be used to specify that each <a>value node</a> has a given <a>property shape</a>.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:PropertyShapeComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:property</code></td>
<td>
A <a>property shape</a> that all value nodes need to have.
<span data-syntax-rule="property-node">Each value of <code>sh:property</code> in a shape must be a <a>well-formed</a> <a>property shape</a>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="Property">
For each <a>value node</a> <code>v</code>:
A <a>failure</a> MUST be produced if the validation of <code>v</code> as <a>focus node</a> against the property shape <code>$property</code> produces a <a>failure</a>.
Otherwise, the validation results are the results of <a>validating</a> <code>v</code> as <a>focus node</a> against the property shape <code>$property</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<p>
Note that there is an important difference between <code>sh:property</code> and <code>sh:node</code>:
If a value node is violating the constraint, then there is only a single validation result for <code>sh:node</code> for this value node,
with <code>sh:NodeConstraintComponent</code> as its <code>sh:sourceConstraintComponent</code>.
On the other hand side, there may be any number of validation results for <code>sh:property</code>, and these
will have the individual constraint components of the <a>constraints</a> in the <a>property shape</a> as their values of <code>sh:sourceConstraintComponent</code>.
</p>
<p>
Like with all other validation results, each time a <a>property shape</a> is reached via <code>sh:property</code>,
a validation engine MUST produce <em>fresh</em> validation result nodes.
This includes cases where the same <a>focus node</a> is validated against the same <a>property shape</a>
although it is reached via different paths in the <a>shapes graph</a>.
</p>
</section>
<section id="QualifiedValueShapeConstraintComponent">
<h4>sh:qualifiedValueShape, sh:qualifiedMinCount, sh:qualifiedMaxCount</h4>
<p>
<code>sh:qualifiedValueShape</code> specifies the condition that a specified number of <a>value nodes</a> conforms to the given shape.
Each <code>sh:qualifiedValueShape</code> can have: one value for <code>sh:qualifiedMinCount</code>, one value for <code>sh:qualifiedMaxCount</code> or, one value for each, at the same <a>subject</a>.
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:qualifiedValueShape</code></td>
<td>
The shape that the specified number of value nodes needs to conform to.
<span data-syntax-rule="qualifiedValueShape-node">The values of <code>sh:qualifiedValueShape</code> in a shape must be <a>well-formed</a> <a>shapes</a>.</span>
<span data-syntax-rule="qualifiedValueShape-scope"><a>Node shapes</a> cannot have any value for <code>sh:qualifiedValueShape</code>.</span>
This is a <a>mandatory parameter</a> of <code>sh:QualifiedMinCountConstraintComponent</code> and <code>sh:QualifiedMaxCountConstraintComponent</code>.
</td>
</tr>
<tr>
<td><code>sh:qualifiedValueShapesDisjoint</code></td>
<td>
This is an <a>optional parameter</a> of <code>sh:QualifiedMinCountConstraintComponent</code> and <code>sh:QualifiedMaxCountConstraintComponent</code>.
If set to <code>true</code> then (for the counting) the value nodes must not conform to any of the <a>sibling shapes</a>.
<span data-syntax-rule="qualifiedValueShapesDisjoint-datatype">The values of <code>sh:qualifiedValueShapesDisjoint</code> in a shape are literals with datatype <code>xsd:boolean</code>.</span>
</td>
</tr>
<tr>
<td><code>sh:qualifiedMinCount</code></td>
<td>
The minimum number of value nodes that conform to the shape.
<span data-syntax-rule="qualifiedMinCount-datatype">The values of <code>sh:qualifiedMinCount</code> in a shape are literals with datatype <code>xsd:integer</code>.</span>
This is a <a>mandatory parameter</a> of <code>sh:QualifiedMinCountConstraintComponent</code>.
</td>
</tr>
<tr>
<td><code>sh:qualifiedMaxCount</code></td>
<td>
The maximum number of value nodes that can conform to the shape.
<span data-syntax-rule="qualifiedMaxCount-datatype">The values of <code>sh:qualifiedMaxCount</code> in a shape are literals with datatype <code>xsd:integer</code>.</span>
This is a <a>mandatory parameter</a> of <code>sh:QualifiedMaxCountConstraintComponent</code>.
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION of Sibling Shapes</div>
<div class="def-text-body">
Let <code>Q</code> be a <a>shape</a> in <a>shapes graph</a> <code>G</code> that declares a qualified cardinality constraint
(by having values for <code>sh:qualifiedValueShape</code> and at least one of <code>sh:qualifiedMinCount</code> or <code>sh:qualifiedMaxCount</code>).
Let <code>ps</code> be the set of <a>shapes</a> in <code>G</code> that have <code>Q</code> as a <a>value</a> of <code>sh:property</code>.
If <code>Q</code> has <code>true</code> as a <a>value</a> for <code>sh:qualifiedValueShapesDisjoint</code> then
the set of <dfn>sibling shapes</dfn> for <code>Q</code> is defined as the set of all <a>values</a> of the
<a>SPARQL property path</a> <code>sh:property/sh:qualifiedValueShape</code> for any <a>shape</a> in <code>ps</code>
minus the <a>value</a> of <code>sh:qualifiedValueShape</code> of <code>Q</code> itself.
The set of sibling shapes is empty otherwise.
</div>
</div>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION of sh:qualifiedMinCount</div>
<div class="def-text-body" data-validator="QualifiedMinCount">
Let <code>C</code> be the number of <a>value nodes</a> <code>v</code> where
<code>v</code> <a>conforms</a> to <code>$qualifiedValueShape</code>
and where <code>v</code> does not <a>conform</a> to any of the <a>sibling shapes</a> for the <em>current</em> shape,
i.e. the shape that <code>v</code> is validated against and which has <code>$qualifiedValueShape</code> as its value for <code>sh:qualifiedValueShape</code>.
A <a>failure</a> MUST be produced if any of the said conformance checks produces a <a>failure</a>.
Otherwise, there is a <a>validation result</a> if <code>C</code> is less than <code>$qualifiedMinCount</code>.
The <a>constraint component</a> for <code>sh:qualifiedMinCount</code> is <code>sh:QualifiedMinCountConstraintComponent</code>.
</div>
</div>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION of sh:qualifiedMaxCount</div>
<div class="def-text-body" data-validator="QualifiedMaxCount">
Let <code>C</code> be as defined for <code>sh:qualifiedMinCount</code> above.
A <a>failure</a> MUST be produced if any of the said conformance checks produces a <a>failure</a>.
Otherwise, there is a <a>validation result</a> if <code>C</code> is greater than <code>$qualifiedMaxCount</code>.
The <a>constraint component</a> for <code>sh:qualifiedMaxCount</code> is <code>sh:QualifiedMaxCountConstraintComponent</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<p>
In the following example shape can be used to specify the condition that the property <code>ex:parent</code> has exactly two values,
and at least one of them is female.
</p>
<pre class="example-shapes">
ex:QualifiedValueShapeExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:QualifiedValueShapeExampleValidResource ;</span>
sh:property [
sh:path ex:parent ;
sh:minCount 2 ;
sh:maxCount 2 ;
sh:qualifiedValueShape [
sh:path ex:gender ;
sh:hasValue ex:female ;
] ;
sh:qualifiedMinCount 1 ;
] .</pre>
<pre class="example-data">
ex:QualifiedValueShapeExampleValidResource
ex:parent ex:John ;
ex:parent ex:Jane .
ex:John
ex:gender ex:male .
ex:Jane
ex:gender ex:female .</pre>
<p>
The following example illustrates the use of <code>sh:qualifiedValueShapesDisjoint</code>
to express that a hand must have at most 5 values of <code>ex:property</code> (expressed using <code>sh:maxCount</code>),
and exactly one of them must be an instance of <code>ex:Thumb</code> while exactly 4 of them must be an instance of <code>ex:Finger</code>
but thumbs and fingers must be disjoint.
In other words, on a hand, none of the fingers can also be counted as the thumb.
</p>
<pre class="example-shapes">
ex:HandShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetClass ex:Hand ;</span>
sh:property [
sh:path ex:digit ;
sh:maxCount 5 ;
] ;
sh:property [
sh:path ex:digit ;
sh:qualifiedValueShape [ sh:class ex:Thumb ] ;
sh:qualifiedValueShapesDisjoint true ;
sh:qualifiedMinCount 1 ;
sh:qualifiedMaxCount 1 ;
] ;
sh:property [
sh:path ex:digit ;
sh:qualifiedValueShape [ sh:class ex:Finger ] ;
sh:qualifiedValueShapesDisjoint true ;
sh:qualifiedMinCount 4 ;
sh:qualifiedMaxCount 4 ;
] .</pre>
</section>
</section>
<section id="core-components-others">
<h3>Other Constraint Components</h3>
<p>
This section enumerates Core constraint components that do not fit into the other categories.
</p>
<section id="ClosedConstraintComponent">
<h3>sh:closed, sh:ignoredProperties</h3>
<p>
The RDF data model offers a huge amount of flexibility.
Any node can in principle have values for any property.
However, in some cases it makes sense to specify conditions on which properties can be applied to nodes.
The SHACL Core language includes a property called <code>sh:closed</code> that can be used to
specify the condition that each value node has <a>values</a> only for those properties that have been explicitly enumerated via the
<a>property shapes</a> specified for the shape via <code>sh:property</code>.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:ClosedConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:closed</code></td>
<td>
Set to <code>true</code> to close the shape.
<span data-syntax-rule="closed-datatype">The values of <code>sh:closed</code> in a shape are literals with datatype <code>xsd:boolean</code>.</span>
</td>
</tr>
<tr>
<td><code>sh:ignoredProperties</code></td>
<td>
Optional <a>SHACL list</a> of properties that are also permitted in addition to those explicitly enumerated via <code>sh:property</code>.
<span data-syntax-rule="ignoredProperties-node">The values of <code>sh:ignoredProperties</code> in a shape must be <a>SHACL lists</a>.</span>
<span data-syntax-rule="ignoredProperties-members-nodeKind">Each <a>member</a> of such a list must be a <a>IRI</a>.</span>
</td>
</tr>
</table>
<div id="def-ClosedShape-text" class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="Closed">
If <code>$closed</code> is <code>true</code> then
there is a <a>validation result</a> for each <a>triple</a> that has a <a>value node</a> as its
<a>subject</a> and a <a>predicate</a> that is not explicitly enumerated as a <a>value</a> of <code>sh:path</code>
in any of the <a>property shapes</a> declared via <code>sh:property</code> at the current shape.
If <code>$ignoredProperties</code> has a value then the properties enumerated as <a>members</a> of this <a>SHACL list</a>
are also permitted for the <a>value node</a>.
The <a>validation result</a> MUST have the <a>predicate</a> of the triple as its <code>sh:resultPath</code>,
and the <a>object</a> of the triple as its <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<!-- Deactivated due to the use of EXISTS
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must return no results)</div>
<pre class="def-sparql-body">
SELECT $this (?predicate AS ?path) ?value
WHERE {
{
FILTER ($closed) .
}
$this ?predicate ?value .
FILTER (NOT EXISTS {
GRAPH $shapesGraph {
$currentShape sh:property/sh:path ?predicate .
}
} && (!bound($ignoredProperties) || NOT EXISTS {
GRAPH $shapesGraph {
$ignoredProperties rdf:rest*/rdf:first ?predicate .
}
}))
}</pre>
</div -->
<p>
The following example illustrates the use of <code>sh:closed</code> in a shape to specify the condition
that certain focus nodes only have values for <code>ex:firstName</code> and <code>ex:lastName</code>.
The "ignored" property <code>rdf:type</code> would also be allowed.
</p>
<pre class="example-shapes">
ex:ClosedShapeExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:Alice, ex:Bob ;</span>
sh:closed true ;
sh:ignoredProperties (rdf:type) ;
sh:property [
sh:path ex:firstName ;
] ;
sh:property [
sh:path ex:lastName ;
] .</pre>
<pre class="example-data">
ex:Alice
ex:firstName "Alice" .
<span class="focus-node-error">ex:Bob</span>
ex:firstName "Bob" ;
ex:middleInitial "J" .</pre>
</section>
<section id="HasValueConstraintComponent">
<h4>sh:hasValue</h4>
<p>
<code>sh:hasValue</code> specifies the condition that at least one <a>value node</a> is equal to the given RDF term.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:HasValueConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:hasValue</code></td>
<td>
A specific required value.
</td>
</tr>
</table>
<div id="def-hasValue-text" class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="HasValue">
If the RDF term <code>$hasValue</code> is not among the <a>value nodes</a>,
there is a <a>validation result</a>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<!-- Deactivated due to the use of EXISTS
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must return no results for the given $PATH)</div>
<pre class="def-sparql-body">
SELECT $this
WHERE {
FILTER NOT EXISTS { $this $PATH $hasValue }
}</pre>
</div-->
<pre class="example-shapes">
ex:StanfordGraduate
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:Alice ;</span>
sh:property [
sh:path ex:alumniOf ;
sh:hasValue ex:Stanford ;
] .</pre>
<pre class="example-data">
ex:Alice
ex:alumniOf ex:Harvard ;
ex:alumniOf ex:Stanford .</pre>
</section>
<section id="InConstraintComponent">
<h4>sh:in</h4>
<p>
<code>sh:in</code> specifies the condition that each <a>value node</a> is a <a>member</a> of a provided <a>SHACL list</a>.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:InConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary and Syntax Rules</th>
</tr>
<tr>
<td><code>sh:in</code></td>
<td>
A <a>SHACL list</a> that has the allowed values as <a>members</a>.
<span data-syntax-rule="in-node">Each value of <code>sh:in</code> in a shape is a <a>SHACL list</a>.</span>
<span data-syntax-rule="in-maxCount">A shape has at most one value for <code>sh:in</code>.</span>
</td>
</tr>
</table>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body" data-validator="In">
For each <a>value node</a>
that is not a <a>member</a> of <code>$in</code>,
there is a <a>validation result</a> with the <a>value node</a> as <code>sh:value</code>.
</div>
</div>
<p><em>The remainder of this section is informative.</em></p>
<p>
Note that matching of literals needs to be exact, e.g. <code>"04"^^xsd:byte</code> does not match <code>"4"^^xsd:integer</code>.
</p>
<div class="def def-sparql">
<div class="def-header">POTENTIAL DEFINITION IN SPARQL (Must evaluate to true for each value node $value)</div>
<pre class="def-sparql-body">
ASK {
GRAPH $shapesGraph {
$in (rdf:rest*)/rdf:first $value .
}
}</pre>
</div>
<pre class="example-shapes">
ex:InExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetNode ex:RainbowPony ;</span>
sh:property [
sh:path ex:color ;
sh:in ( ex:Pink ex:Purple ) ;
] .</pre>
<pre class="example-data">
ex:RainbowPony ex:color ex:Pink .</pre>
</section>
</section>
</section>
<div style="padding-top: 30px">
<h1 id="part2" style="font-size: 160%; font-weight: bold">Part 2: SHACL-SPARQL</h1>
<p>
Part 1 of this specification introduced features that are built into the Core of SHACL.
The goal of this Core is to provide a high-level vocabulary for common use cases to describe shapes.
However, SHACL also provides mechanisms to go beyond the Core vocabulary and represent constraints with greater flexibility.
These mechanisms, called <a>SHACL-SPARQL</a>, are described in the following sections.
</p>
</div>
<section id="sparql-constraints">
<h2>SPARQL-based Constraints</h2>
<p>
SHACL-SPARQL supports a <a>constraint component</a> that can be used to express restrictions based on a SPARQL SELECT query.
</p>
<p>
<span class="component-class">Constraint Component IRI</span>: <code>sh:SPARQLConstraintComponent</code>
</p>
<div class="parameters">Parameters:</div>
<table class="term-table">
<tr>
<th>Property</th>
<th>Summary</th>
</tr>
<tr>
<td><code>sh:sparql</code></td>
<td>A <a>SPARQL-based constraint</a> declaring the SPARQL query to evaluate.</td>
</tr>
</table>
<p>
The <a href="#sparql-constraints-syntax">syntax rules</a> and <a href="#sparql-constraints-validation">validation process</a> for SPARQL-based constraints are defined in the rest of this section.
</p>
<section id="sparql-constraints-example" class="informative">
<h3>An Example SPARQL-based Constraint</h3>
<p>
The following example illustrates the syntax of a <a>SPARQL-based constraint</a>.
</p>
<pre class="example-data">
ex:ValidCountry a ex:Country ;
ex:germanLabel "Spanien"@de .
<span class="focus-node-error">ex:InvalidCountry</span> a ex:Country ;
ex:germanLabel "Spain"@en .</pre>
<pre class="example-shapes" id="example-sparql-constraint">
ex:LanguageExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetClass ex:Country ;</span>
sh:sparql [
a sh:SPARQLConstraint ; # This triple is optional
sh:message "Values are literals with German language tag." ;
sh:prefixes ex: ;
sh:select """
SELECT $this (ex:germanLabel AS ?path) ?value
WHERE {
$this ex:germanLabel ?value .
FILTER (!isLiteral(?value) || !langMatches(lang(?value), "de"))
}
""" ;
] .</pre>
<p>
The target of the shape above includes all <a>SHACL instances</a> of <code>ex:Country</code>.
For those nodes (represented by the variable <code>this</code>), the SPARQL query walks through the values of <code>ex:germanLabel</code>
and verifies that they are literals with a German language code.
The validation results for the aforementioned data graph is shown below:
</p>
<pre class="example-results">
[ a sh:ValidationReport ;
sh:conforms false ;
sh:result [
a sh:ValidationResult ;
sh:resultSeverity sh:Violation ;
sh:focusNode ex:InvalidCountry ;
sh:resultPath ex:germanLabel ;
sh:value "Spain"@en ;
sh:sourceConstraintComponent sh:SPARQLConstraintComponent ;
sh:sourceShape ex:LanguageExampleShape ;
# ...
]
] .</pre>
<p>
The SPARQL query returns result set <a>solutions</a> for all bindings of the variable <code>value</code> that violate the constraint.
There is a validation result for each <a>solution</a> in that result set, applying the <a href="#sparql-constraints-validation">mapping rules</a> explained later.
In this example, each validation result will have the <a>binding</a> for the variable <code>this</code> as the <code>sh:focusNode</code>,
<code>ex:germanLabel</code> as <code>sh:resultPath</code> and the violating value as <code>sh:value</code>.
</p>
<p>
The following example illustrates a similar scenario as above, but with a <a>property shape</a>.
</p>
<pre class="example-shapes" id="example-sparql-constraint-in-property-shape">
ex:LanguageExamplePropertyShape
a sh:PropertyShape ;
<span class="target-can-be-skipped">sh:targetClass ex:Country ;</span>
sh:path ex:germanLabel ;
sh:sparql [
a sh:SPARQLConstraint ; # This triple is optional
sh:message "Values are literals with German language tag." ;
sh:prefixes ex: ;
sh:select """
SELECT $this ?value
WHERE {
$this $PATH ?value .
FILTER (!isLiteral(?value) || !langMatches(lang(?value), "de"))
}
""" ;
] .</pre>
</section>
<section id="sparql-constraints-syntax">
<h3>Syntax of SPARQL-based Constraints</h3>
<p class="syntax">
<span data-syntax-rule="sparql-nodeKind">Shapes may have values for the property <code>sh:sparql</code>, and these values are either <a>IRIs</a> or <a>blank nodes</a>.</span>
These values are called <dfn data-lt="SPARQL-based constraint">SPARQL-based constraints</dfn>.
</p>
<p class="syntax">
<span data-syntax-rule="SPARQLConstraint-select-count"><a>SPARQL-based constraints</a> have exactly one <a>value</a> for the property <code>sh:select</code></span>.
<span data-syntax-rule="SPARQLConstraint-select-datatype">The value of <code>sh:select</code> is a <a>literal</a> of datatype <code>xsd:string</code>.</span>
The class <code>sh:SPARQLConstraint</code> is defined in the SHACL vocabulary and may be used as the <a>type</a> of these constraints (although no type is required).
<span data-syntax-rule="select-query-valid">Using the <a href="#sparql-prefixes">prefix handling rules</a>, the value of <code>sh:select</code> is a valid SPARQL 1.1 SELECT query.</span>
<span data-syntax-rule="select-query-this">The SPARQL query derived from the value of <code>sh:select</code> <a href="https://www.w3.org/TR/sparql11-query/#selectproject">projects</a> the variable <code>this</code> in the SELECT clause.</span>
</p>
<p>
The following two properties are similar to their use in <a>shapes</a>:
</p>
<p class="syntax">
<span data-syntax-rule="SPARQLConstraint-message-datatype"><a>SPARQL-based constraints</a> may have values for the property <code>sh:message</code> and these are either <code>xsd:string</code> literals or literals with a language tag.</span>
<span data-syntax-rule="SPARQLConstraint-deactivated-maxCount"><a>SPARQL-based constraints</a> may have at most one value for the property <code>sh:deactivated</code></span>
and this value is either <code>true</code> or <code>false</code>.
</p>
<p>
SELECT queries used in the context of <a>property shapes</a> use a special variable named <code>PATH</code> as a placeholder for the path used by the shape.
</p>
<p class="syntax">
<span data-syntax-rule="PATH-position">The only legal use of the variable <code>PATH</code> in the SPARQL queries of <a>SPARQL-based constraints</a>
and <a>SELECT-based validators</a> is in the
<a>predicate</a> position of a <a href="https://www.w3.org/TR/sparql11-query/#QSynTriples">triple pattern</a>.</span>
A query that uses the variable <code>PATH</code> in any other position is <a>ill-formed</a>.
</p>
<section id="sparql-prefixes">
<h4>Prefix Declarations for SPARQL Queries</h4>
<p>
A <a>shapes graph</a> may include declarations of namespace prefixes so that these prefixes can be used to abbreviate the SPARQL queries derived from the same shapes graph.
The syntax of such prefix declarations is illustrated by the following example.
</p>
<pre class="example-shapes">
ex:
a owl:Ontology ;
owl:imports sh: ;
sh:declare [
sh:prefix "ex" ;
sh:namespace "http://example.com/ns#"^^xsd:anyURI ;
] ;
sh:declare [
sh:prefix "schema" ;
sh:namespace "http://schema.org/"^^xsd:anyURI ;
] .</pre>
<p class="syntax">
<span data-syntax-rule="declare-nodeKind">The <a>values</a> of the property <code>sh:declare</code> are <a>IRIs</a> or <a>blank nodes</a></span>,
and these values are called <dfn data-lt="prefix declaration">prefix declarations</dfn>.
The SHACL vocabulary includes the class <code>sh:PrefixDeclaration</code> as type for such <a>prefix declarations</a>
although no <code>rdf:type</code> triple is required for them.
<span data-syntax-rule="prefix-count"><a>Prefix declarations</a> have exactly one value for the property <code>sh:prefix</code></span>.
<span data-syntax-rule="prefix-datatype">The values of <code>sh:prefix</code> are <a>literals</a> of datatype <code>xsd:string</code>.</span>
<span data-syntax-rule="namespace-count"><a>Prefix declarations</a> have exactly one value for the property <code>sh:namespace</code>.</span>
<span data-syntax-rule="namespace-datatype">The values of <code>sh:namespace</code> are <a>literals</a> of datatype <code>xsd:anyURI</code>.</span>
Such a pair of values specifies a single mapping of a prefix to a namespace.
</p>
<p>
The recommended <a>subject</a> for values of <code>sh:declare</code> is the IRI of the named graph containing the shapes that use the prefixes.
These IRIs are often declared as an instance of <code>owl:Ontology</code>, but this is not required.
</p>
<p>
<a>Prefix declarations</a> can be used by <a>SPARQL-based constraints</a>,
the <a>validators</a> of <a href="#sparql-constraint-components">SPARQL-based constraint components</a>,
and by similar features defined by SHACL extensions.
These nodes can use the property <code>sh:prefixes</code> to specify a set of prefix mappings.
An example use of the <code>sh:prefixes</code> property can be found in the
<a href="#sparql-constraints-example">example</a> above.
</p>
<p class="syntax">
<span data-syntax-rule="prefixes-nodeKind">The values of <code>sh:prefixes</code> are either <a>IRIs</a> or <a>blank nodes</a>.</span>
<span data-syntax-rule="prefixes-duplicates">A SHACL processor collects a set of prefix mappings as the union of all
individual prefix mappings that are <a>values</a> of the <a>SPARQL property path</a> <code>sh:prefixes/owl:imports*/sh:declare</code>
of the <a>SPARQL-based constraint</a> or <a>validator</a>.
If such a collection of prefix declarations contains multiple namespaces for the same <a>value</a> of <code>sh:prefix</code>,
then the <a>shapes graph</a> is <a>ill-formed</a>.</span>
(Note that SHACL processors MAY ignore prefix declarations that are never reached).
</p>
<p>
A SHACL processor transforms the values of <code>sh:select</code> (and similar properties such as <code>sh:ask</code>)
into SPARQL by prepending <a href="https://www.w3.org/TR/sparql11-query/#rPrefixDecl"><code>PREFIX</code></a> declarations
for all prefix mappings.
Each value of <code>sh:prefix</code> is turned into the <code>PNAME_NS</code>, while each value of <code>sh:namespace</code> is turned
into the <code>IRIREF</code> in the <code>PREFIX</code> declaration.
For the example shapes graph above, a SHACL-SPARQL processor would produce lines such as <code>PREFIX ex: <http://example.com/ns#></code>.
The SHACL-SPARQL processor MUST produce a <a>failure</a> if the resulting query string cannot be parsed into a valid SPARQL 1.1 query.
</p>
<p>
In the rest of this document, the <code>sh:prefixes</code> statements may have been omitted for brevity.
</p>
</section>
</section>
<section id="sparql-constraints-validation">
<h3>Validation with SPARQL-based Constraints</h3>
<p>
This section explains the <a>validator</a> of <code>sh:SPARQLConstraintComponent</code>.
Note that this validator only explains one possible implementation strategy, and
SHACL processors may choose alternative approaches as long as the outcome is equivalent.
</p>
<div class="def def-text">
<div class="def-header">TEXTUAL DEFINITION</div>
<div class="def-text-body">
There are no validation results if the <a>SPARQL-based constraint</a> has <code>true</code>
as a <a>value</a> for the property <code>sh:deactivated</code>.
Otherwise, execute the SPARQL query specified by the <a>SPARQL-based constraint</a> <code>$sparql</code>
<a>pre-binding</a> the variables <code>this</code> and, if supported,
<code>shapesGraph</code> and <code>currentShape</code> as described in <a href="#sparql-constraints-prebound"></a>.
If the <a>shape</a> is a <a>property shape</a>, then prior to execution
<dfn data-lt="substituted">substitute</dfn> the variable <code>PATH</code> where it appears in the <a>predicate</a>
position of a <a href="https://www.w3.org/TR/sparql11-query/#QSynTriples">triple pattern</a>
with a valid SPARQL surface syntax string of the <a>SHACL property path</a>
specified via <code>sh:path</code> at the <a>property shape</a>.
<span id="sparql-constraints-validation-rule">There is one validation result for each <a>solution</a> that does not have <code>true</code> as the <a>binding</a> for the variable <code>failure</code>.
These validation results MUST have the property values explained in <a href="#sparql-constraints-variables"></a>.
A <a>failure</a> MUST be produced if and only if one of the <a>solutions</a> has <code>true</code> as the <a>binding</a> for <code>failure</code>.</span>
</div>
</div>
<section id="sparql-constraints-prebound">
<h4>Pre-bound Variables in SPARQL Constraints ($this, $shapesGraph, $currentShape)</h4>
<p>
When the SPARQL queries of <a>SPARQL-based constraints</a> and the <a>validators</a>
of <a>SPARQL-based constraint components</a> are <a href="#validation-definition">processed</a>,
the SHACL-SPARQL processor <a>pre-binds</a> values for the variables in the following table.
</p>
<table class="term-table">
<tr>
<th>Variable</th>
<th>Interpretation</th>
</tr>
<tr>
<td><code>this</code></td>
<td>
The <a>focus node</a>.
</td>
</tr>
<tr>
<td><code style="white-space: nowrap">shapesGraph</code> (Optional)</td>
<td>
Can be used to query the shapes graph as in <code>GRAPH $shapesGraph { ... }</code>.
If the shapes graph is a named graph in the same dataset as the data graph then it is the <a>IRI</a> of the shapes graph in the dataset.
Not all SHACL-SPARQL processors need to support this variable.
Processors that do not support the variable <code>shapesGraph</code> MUST report a <a>failure</a> if they encounter a query that references this variable.
Use of <code>GRAPH $shapesGraph { ... }</code> should be handled with extreme caution.
It may result in constraints that are not interoperable across different SHACL-SPARQL processors and that may not run on remote RDF datasets.
</td>
</tr>
<tr>
<td><code style="white-space: nowrap">currentShape</code> (Optional)</td>
<td>
The current <a>shape</a>. Typically used in conjunction with the variable <code>shapesGraph</code>.
The same support policies as for <code>shapesGraph</code> apply for this variable.
</td>
</tr>
</table>
</section>
<section id="sparql-constraints-variables">
<h4>Mapping of Solution Bindings to Result Properties</h4>
<p>
The property <a>values</a> of the validation result nodes are derived by the following rules, through a combination of result solutions and the values of the constraint itself.
The rules are meant to be executed from top to bottom, so that the first bound value will be used.
</p>
<table class="term-table">
<tr>
<th>Property</th>
<th>Production Rules</th>
</tr>
<tr>
<td><code>sh:focusNode</code></td>
<td>
<ol>
<li>The binding for the variable <code>this</code></li>
</ol>
</td>
</tr>
<tr>
<td><code>sh:resultPath</code></td>
<td>
<ol>
<li>The binding for the variable <code>path</code>, if that is a <a>IRI</a></li>
<li>For results produced by a <a>property shape</a>, a <a>SHACL property path</a> that is equivalent to the <a>value</a> of <code>sh:path</code> of the shape</li>
</ol>
</td>
</tr>
<tr>
<td><code>sh:value</code></td>
<td>
<ol>
<li>The binding for the variable <code>value</code></li>
<li>The <a>value node</a></li>
</ol>
</td>
</tr>
<tr>
<td><code>sh:resultMessage</code></td>
<td>
<ol>
<li>The binding for the variable <code>message</code></li>
<li>
For SPARQL-based constraints: The values of <code>sh:message</code> of the <a>SPARQL-based constraint</a>.
For SPARQL-based constraint components: The values of <code>sh:message</code> of the <a>validator</a> of the <a>SPARQL-based constraint component</a>.
</li>
<li>
For SPARQL-based constraint components: The values of <code>sh:message</code> of the <a>SPARQL-based constraint component</a>.
</li>
</ol>
<div>
These message literals may include the names of any SELECT result variables via <code>{?varName}</code> or <code>{$varName}</code>.
If the constraint is based on a <a href="#sparql-constraint-components">SPARQL-based constraint component</a>, then the component's <a>parameter names</a> can also be used.
These <code>{?varName}</code> and <code>{$varName}</code> blocks SHOULD be replaced with suitable string representations of the values of said variables.
</div>
</td>
</tr>
<tr>
<td><code>sh:sourceConstraint</code></td>
<td>
<ol>
<li>The <a>SPARQL-based constraint</a>, i.e. the value of <code>sh:sparql</code></li>
</ol>
</td>
</tr>
</table>
</section>
</section>
</section>
<section id="sparql-constraint-components">
<h2>SPARQL-based Constraint Components</h2>
<p>
<a>SPARQL-based constraints</a> provide a lot of flexibility
but may be hard to understand for some people or lead to repetition.
This section introduces <a>SPARQL-based constraint components</a> as a way to abstract the complexity of SPARQL
and to declare high-level reusable components similar to the <a href="#core-components">Core constraint components</a>.
Such constraint components can be declared using the SHACL RDF vocabulary and thus shared and reused.
</p>
<section class="informative">
<h3>An Example SPARQL-based Constraint Component</h3>
<p>
The following example demonstrates how SPARQL can be used to specify new constraint components using the SHACL-SPARQL language.
The example implements <a href="#PatternConstraintComponent"><code>sh:pattern</code> and <code>sh:flags</code></a> using a
<a href="#SPARQLAskValidator">SPARQL ASK</a> query to validate that each <a>value node</a> matches a given regular expression.
Note that this is only an example implementation and should not be considered normative.
</p>
<pre class="example-shapes" title="Constraint component based on SPARQL">
sh:PatternConstraintComponent
a sh:ConstraintComponent ;
sh:parameter [
sh:path sh:pattern ;
] ;
sh:parameter [
sh:path sh:flags ;
sh:optional true ;
] ;
sh:validator shimpl:hasPattern .
shimpl:hasPattern
a sh:SPARQLAskValidator ;
sh:message "Value does not match pattern {$pattern}" ;
sh:ask """
ASK {
FILTER (!isBlank($value) &&
IF(bound($flags), regex(str($value), $pattern, $flags), regex(str($value), $pattern)))
}""" .</pre>
<p>
Constraint components provide instructions to validation engines on how to identify and validate <a>constraints</a> within a <a>shape</a>.
In general, if a <a>shape</a> <code>S</code> has a <a>value</a> for a property <code>p</code>, and there is a <a>constraint component</a>
<code>C</code> that specifies <code>p</code> as a parameter, and <code>S</code> has values for all <a>mandatory parameters</a> of <code>C</code>,
then the set of these parameter values (including the <a>optional parameters</a>) declare a <a>constraint</a> and the validation engine uses a suitable <a>validator</a> from <code>C</code>
to perform the validation of this constraint.
In the example above, <code>sh:PatternConstraintComponent</code> declares the mandatory parameter <code>sh:pattern</code>,
the optional parameter <code>sh:flags</code>,
and a <a>validator</a> that can be used to perform validation against either <a>node shapes</a> or <a>property shapes</a>.
</p>
</section>
<section id="constraint-components-syntax">
<h3>Syntax of SPARQL-based Constraint Components</h3>
<p class="syntax">
<span data-syntax-rule="ConstraintComponent">A <dfn data-lt="SPARQL-based constraint components">SPARQL-based constraint component</dfn> is an <a>IRI</a> that has <a>SHACL type</a>
<code>sh:ConstraintComponent</code> in the <a>shapes graph</a>.</span>
</p>
<p>
The mechanism to declare new <a>constraint components</a> in this document is limited to those based on SPARQL.
However, then general syntax of declaring parameters and validators has been designed to also work for other extension languages such as JavaScript.
</p>
<section id="constraint-components-parameters">
<h4>Parameter Declarations (sh:parameter)</h4>
<p class="syntax">
The <a>parameters</a> of a <a>constraint component</a> are declared via the property <code>sh:parameter</code>.
The values of <code>sh:parameter</code> are called <dfn data-lt="parameter declaration">parameter declarations</dfn>.
The class <code>sh:Parameter</code> may be used as <a>type</a> of <a>parameter declarations</a> but no such triple is required.
<span data-syntax-rule="Parameter-predicate-count">Each <a>parameter declaration</a> has exactly one value for the property <code>sh:path</code></span>.
<span data-syntax-rule="Parameter">At <a>parameter declarations</a>, the <a>value</a> of <code>sh:path</code> is an <a>IRI</a>.</span>
</p>
<p>
The <dfn data-lt="local names">local name</dfn> of an <a>IRI</a> is defined as the longest <a href="http://www.w3.org/TR/REC-xml-names/#NT-NCName">NCNAME</a>
at the end of the <a>IRI</a>, not immediately preceded by the first colon in the <a>IRI</a>.
The <dfn data-lt="parameter names">parameter name</dfn> of a <a>parameter declaration</a> is defined as the <a>local name</a> of the <a>value</a> of <code>sh:path</code>.
To ensure that a correct mapping from parameters into SPARQL variables is possible, the following syntax rules apply:
</p>
<p class="syntax">
<span data-syntax-rule="parameter-name-VARNAME">Every <a>parameter name</a> is a valid <a href="http://www.w3.org/TR/sparql11-query/#rVARNAME">SPARQL VARNAME</a>.</span>
<span data-syntax-rule="parameter-name-not-in"><a>Parameter names</a> must not be one of the following: <code>this</code>, <code>shapesGraph</code>, <code>currentShape</code>, <code>path</code>, <code>PATH</code>, <code>value</code>.</span>
<span data-syntax-rule="parameter-name-unique">A constraint component where two or more <a>parameter declarations</a> use the same <a>parameter names</a> is <a>ill-formed</a>.</span>
</p>
<p class="syntax">
<span data-syntax-rule="optional-datatype">The values of <code>sh:optional</code> must be literals with datatype <code>xsd:boolean</code>.</span>
<span data-syntax-rule="optional-maxCount">A <a>parameter declaration</a> can have at most one value for the property <code>sh:optional</code>.</span>
If set to <code>true</code> then the parameter declaration declares an <a>optional parameter</a>.
<span data-syntax-rule="ConstraintComponent-parameter">Every <a>constraint component</a> has at least one non-optional parameter.</span>
</p>
<p class="syntax">
The class <code>sh:Parameter</code> is defined as a <a>SHACL subclass</a> of <code>sh:PropertyShape</code>,
and all properties that are applicable to property shapes may also be used for parameters.
This includes descriptive properties such as <code>sh:name</code> and <code>sh:description</code>
but also constraint parameters such as <code>sh:class</code>.
<span data-syntax-rule="Parameter-conformance">Shapes that do not <a>conform</a> with the constraints declared for the parameters are <a>ill-formed</a>.</span>
Some implementations MAY use these constraint parameters to prevent the execution of constraint components with invalid parameter values.
</p>
</section>
<section id="labelTemplate">
<h4>Label Templates (sh:labelTemplate)</h4>
<p class="syntax">
The property <code>sh:labelTemplate</code> can be used at any <a>constraint component</a> to suggest how <a>constraints</a> could be rendered to humans.
<span data-syntax-rule="labelTemplate-datatype">The values of <code>sh:labelTemplate</code> are strings (possibly with language tag)</span> and
are called <dfn data-lt="label template">label templates</dfn>.
</p>
<p><em>The remainder of this section is informative.</em></p>
<p>
<a>Label templates</a> can include the names of the parameters that are declared for the constraint component
using the syntaxes <code>{?varName}</code> or <code>{$varName}</code>,
where <code>varName</code> is the name of the <a>parameter name</a>.
At display time, these <code>{?varName}</code> and <code>{$varName}</code> blocks SHOULD be replaced with the actual parameter values.
There may be multiple label templates for the same subject, but they should not have the same language tags.
</p>
</section>
<section id="constraint-components-validators">
<h4>Validators</h4>
<p>
For every supported shape type (i.e., <a>property shape</a> or <a>node shape</a>)
the constraint component declares a suitable <a>validator</a>.
For a given constraint, a validator is selected from the constraint component using the following rules, in order:
</p>
<ol>
<li>For <a>node shapes</a>, use one of the values of <code>sh:nodeValidator</code>, if present.</li>
<li>For <a>property shapes</a>, use one of the values of <code>sh:propertyValidator</code>, if present.</li>
<li>Otherwise, use one of the values of <code>sh:validator</code>.
</ol>
<p>
If no suitable validator can be found, a SHACL-SPARQL processor ignores the constraint.
</p>
<p>
SHACL-SPARQL includes two types of validators, based on <a href="#SPARQLSelectValidator">SPARQL SELECT</a> (for <code>sh:nodeValidator</code> and <code>sh:propertyValidator</code>)
or <a href="#SPARQLAskValidator">SPARQL ASK</a> queries (for <code>sh:validator</code>).
</p>
<section id="SPARQLSelectValidator">
<h5>SELECT-based Validators</h5>
<p class="syntax">
<a>Validators</a> with <a>SHACL type</a> <code>sh:SPARQLSelectValidator</code> are called <dfn>SELECT-based validators</dfn>.
<span data-syntax-rule="nodeValidator-class">The values of <code>sh:nodeValidator</code> must be <a>SELECT-based validators</a>.</span>
<span data-syntax-rule="propertyValidator-class">The values of <code>sh:propertyValidator</code> must be <a>SELECT-based validators</a>.</span>
<span data-syntax-rule="SPARQLSelectValidator-select-count"><a>SELECT-based validators</a> have exactly one <a>value</a> for the property <code>sh:select</code>.</span>
The value of <code>sh:select</code> is a valid SPARQL SELECT query using the aforementioned <a href="#sparql-prefixes">prefix handling rules</a>.
The SPARQL query derived from the value of <code>sh:select</code> <a href="https://www.w3.org/TR/sparql11-query/#selectproject">projects</a> the variable <code>this</code> in its SELECT clause.
</p>
<p><em>The remainder of this section is informative.</em></p>
<p>
The following example illustrates the declaration of a constraint component based on a SPARQL SELECT query.
It is a generalized variation of the example from <a href="#sparql-constraints-example"></a>.
That SPARQL query included two constants: the specific property <code>ex:germanLabel</code> and the language tag <code>de</code>.
Constraint components make it possible to generalize such scenarios, so that constants get <a>pre-bound</a> with <a>parameters</a>.
This allows the query logic to be reused in multiple places, without having to write any new SPARQL.
</p>
<pre class="example-shapes" title="Constraint component based on SPARQL">
ex:LanguageConstraintComponentUsingSELECT
a sh:ConstraintComponent ;
rdfs:label "Language constraint component" ;
sh:parameter [
sh:path ex:lang ;
sh:datatype xsd:string ;
sh:minLength 2 ;
sh:name "language" ;
sh:description "The language tag, e.g. \"de\"." ;
] ;
sh:labelTemplate "Values are literals with language \"{$lang}\"" ;
sh:propertyValidator [
a sh:SPARQLSelectValidator ;
sh:message "Values are literals with language \"{?lang}\"" ;
sh:select """
SELECT DISTINCT $this ?value
WHERE {
$this $PATH ?value .
FILTER (!isLiteral(?value) || !langMatches(lang(?value), $lang))
}
"""
] .</pre>
<p>
Once a constraint component has been declared (in a <a>shapes graph</a>), its parameters can be used as illustrated in the following example.
</p>
<pre class="example-shapes" title="Shape declaration using ex:LanguageConstraintComponent">
ex:LanguageExampleShape
a sh:NodeShape ;
<span class="target-can-be-skipped">sh:targetClass ex:Country ;</span>
sh:property [
sh:path ex:germanLabel ;
ex:lang "de" ;
] ;
sh:property [
sh:path ex:englishLabel ;
ex:lang "en" ;
] .</pre>
<p>
The example shape above specifies the condition that all values of <code>ex:germanLabel</code> carry the language tag <code>de</code>
while all values of <code>ex:englishLabel</code> have <code>en</code> as their language.
These details are specified via two property shapes that have values for the <code>ex:lang</code> parameter required by the constraint component.
</p>
</section>
<section id="SPARQLAskValidator">
<h5>ASK-based Validators</h5>
<p>
Many constraint components are of the form in which all <a>value nodes</a> are tested individually against some boolean condition.
Writing SELECT queries for these becomes burdensome, especially if a constraint component can be
used for both <a>property shapes</a> and <a>node shapes</a>.
SHACL-SPARQL provides an alternative, more compact syntax for validators based on ASK queries.
</p>
<p class="syntax">
<a>Validators</a> with <a>SHACL type</a> <code>sh:SPARQLAskValidator</code> are called <dfn>ASK-based validators</dfn>.
<span data-syntax-rule="validator-class">The values of <code>sh:validator</code> must be <a>ASK-based validators</a>.</span>
<span data-syntax-rule="ask-count"><a>ASK-based validators</a> have exactly one value for the property <code>sh:ask</code></span>.
<span data-syntax-rule="ask-datatype">The value of <code>sh:ask</code> must be a literal with datatype <code>xsd:string</code>.</span>
<span data-syntax-rule="ask-sparql">The value of <code>sh:ask</code> must be a valid SPARQL ASK query using the aforementioned <a href="#sparql-prefixes">prefix handling rules</a>.</span>
</p>
<p><em>The remainder of this section is informative.</em></p>
<p>
The ASK queries return <code>true</code> if and only if a given <a>value node</a>
(represented by the pre-bound variable <code>value</code>) conforms to the constraint.
</p>
<p>
The following example declares a constraint component using an ASK query.
</p>
<pre class="example-shapes" title="Constraint component based on SPARQL">
ex:LanguageConstraintComponentUsingASK
a sh:ConstraintComponent ;
rdfs:label "Language constraint component" ;
sh:parameter [
sh:path ex:lang ;
sh:datatype xsd:string ;
sh:minLength 2 ;
sh:name "language" ;
sh:description "The language tag, e.g. \"de\"." ;
] ;
sh:labelTemplate "Values are literals with language \"{$lang}\"" ;
sh:validator ex:hasLang .
ex:hasLang
a sh:SPARQLAskValidator ;
sh:message "Values are literals with language \"{$lang}\"" ;
sh:ask """
ASK {
FILTER (isLiteral($value) && langMatches(lang($value), $lang))
}
""" .</pre>
<p>
Note that the validation condition implemented by an ASK query is "in the inverse direction" from its SELECT counterpart:
ASK queries return <code>true</code> for value nodes that conform to the constraint, while SELECT queries return those value nodes that do not conform.
</p>
</section>
</section>
</section>
<section id="constraint-components-validation">
<h3>Validation with SPARQL-based Constraint Components</h3>
<p>
This section defines the <a>validator</a> of <a>SPARQL-based constraint components</a>.
Note that this validator only explains one possible implementation strategy, and
SHACL processors may choose alternative approaches as long as the outcome is equivalent.
</p>
<p>
As the first step, a <a>validator</a> MUST be selected based on the rules outlined
in <a href="#constraint-components-validators"></a>.
Then the following rules apply, producing a set of <a>solutions</a> of SPARQL queries:
</p>
<ul>
<li>
For <a>ASK-based validators</a>:
For each <a>value node</a> <code>v</code> where the SPARQL ASK query returns <code>false</code>
with <code>v</code> <a>pre-bound</a> to the variable <code>value</code>,
create one <a>solution</a> consisting of the bindings
(<code>$this</code>, <a>focus node</a>) and (<code>$value</code>, <code>v</code>).
Let <code>QS</code> be a list of these <a>solutions</a>.
</li>
<li>
For <a>SELECT-based validators</a>:
If the <a>shape</a> is a <a>property shape</a>, then prior to execution
<a>substitute</a> the variable <code>PATH</code> where it appears in the <a>predicate</a>
position of a <a href="https://www.w3.org/TR/sparql11-query/#QSynTriples">triple pattern</a>
with a valid SPARQL surface syntax string of the <a>SHACL property path</a>
specified via <code>sh:path</code> at the <a>property shape</a>.
Let <code>QS</code> be the <a>solutions</a> produced by executing the SPARQL query.
</li>
</ul>
<p>
The SPARQL query executions above MUST <a>pre-bind</a> the variables
<code>this</code> and, if supported, <code>shapesGraph</code> and <code>currentShape</code>
as described in <a href="#sparql-constraints-prebound"></a>.
In addition, each <a>value</a> of a <a>parameter</a> of the <a>constraint component</a> in the <a>constraint</a>
MUST be <a>pre-bound</a> as a variable that has the <a>parameter name</a> as its name.
</p>
<p>
The production rules for the validation results are identical to those for <a href="#sparql-constraints-validation-rule">SPARQL-based constraints</a>,
using the <a>solutions</a> <code>QS</code> as produced above.
</p>
</section>
</section>
<div style="padding-top: 30px">
<h1 id="appendix" style="font-size: 160%; font-weight: bold">Appendix</h1>
</div>
<section id="pre-binding" class="appendix">
<h2>Pre-binding of Variables in SPARQL Queries</h2>
<p>
Some features of SHACL-SPARQL rely on the concept of <a>pre-binding of variables</a> as defined in this section.
</p>
<div class="syntax" data-syntax-rule="pre-binding-limitations">
<p>
The definition of pre-binding used by SHACL requires the following restrictions on SPARQL queries.
SHACL-SPARQL processors MUST report a <a>failure</a> when it is operating on a <a>shapes graph</a>
that contains SHACL-SPARQL queries (via <code>sh:select</code> and <code>sh:ask</code>) that violate any of these restrictions.
Note that the term <em>potentially pre-bound variables</em> includes the variables <code>this</code>,
<code>shapesGraph</code>, <code>currentShape</code>, <code>value</code> (for ASK queries),
and any variables that represent the <a>parameters</a> of the <a>constraint component</a> that uses the query.
<!-- This is so that the checking can be performed once, not required each time. -->
</p>
<ul>
<li>SPARQL queries must not contain a <code>MINUS</code> clause</li>
<li>SPARQL queries must not contain a federated query (<code>SERVICE</code>)</li>
<li>SPARQL queries must not contain a <code>VALUES</code> clause</li>
<li>SPARQL queries must not use the syntax form <code>AS ?var</code> for any potentially pre-bound variable</li>
<li><a href="https://www.w3.org/TR/sparql11-query/#subqueries">Subqueries</a> must return all potentially pre-bound variables, except <code>shapesGraph</code> and <code>currentShape</code> which are optional as already mentioned in <a href="#sparql-constraints-prebound"></a></li>
</ul>
</div>
<div class="def def-text">
<div class="def-header">DEFINITION: <dfn>Values Insertion</dfn></div>
<div class="def-text-body">
<p>
For solution mapping <code>μ</code>, define <code>Table(μ)</code> to be the multiset formed from <code>μ</code>.
</p>
<p>
<code>Table(μ) = { μ }</code><br/>
<code>Card[μ] = 1</code>
</p>
<p>
Define the <em>Values Insertion</em> function <code>Replace(X, μ)</code> to
replace each occurence <code>Y</code> of a
<a href="https://www.w3.org/TR/sparql11-query/#sparqlTranslateBasicGraphPatterns">Basic Graph Pattern</a>,
<a href="https://www.w3.org/TR/sparql11-query/#sparqlTranslatePathExpressions">Property Path Expression</a>,
<a href="https://www.w3.org/TR/sparql11-query/#sparqlTranslateGraphPatterns"><code>Graph(Var, pattern)</code></a>
in <code>X</code> with <code>join(Y, Table(μ))</code>.
</p>
</div>
</div>
<div class="def def-text">
<div class="def-header">DEFINITION: <dfn data-lt="pre-binding|pre-bind|pre-bound|pre-bound variables|pre-binds">Pre-binding of variables</dfn></div>
<div class="def-text-body">
<p>
The evaluation of the <a href="https://www.w3.org/TR/sparql11-query/#idp2427544">SPARQL Query</a>
<code>Q = (E, DS, QF)</code> with <em>pre-bound</em> variables <code>μ</code>
is defined as the evaluation of SPARQL query <code>Q' = (Replace(E, μ), DS, QF)</code>.
</p>
</div>
</div>
</section>
<section id="syntax-rules" class="appendix">
<h2>Summary of SHACL Syntax Rules</h2>
<p>
This section enumerates all normative syntax rules of SHACL.
This section is automatically generated from other parts of this spec and hyperlinks are provided back
into the prose if the context of the rule in unclear.
Nodes that violate these rules in a <a>shapes graph</a> are <a>ill-formed</a>.
</p>
<table class="term-table" id="syntax-rules-table">
<tr>
<th>Syntax Rule Id</th>
<th>Syntax Rule Text</th>
</tr>
</table>
</section>
<section id="shacl-shacl" class="appendix">
<h2>SHACL Shapes to Validate Shapes Graphs</h2>
<p>
The following shapes graph is intended to enforce many of the syntactic constraints related to SHACL Core in this specification.
As such, it can be understood as a machine-readable version of a subset of those constraints,
and should be understood as normative.
If differences are found between the constraints expressed here and elsewhere in this specification,
that indicates an error in the following shapes graph.
Please see the <a href="https://www.w3.org/2017/shacl/errata">Errata Page</a> for an enumeration and analysis of possible errors that have been reported.
This shapes graph is available at <a href="http://www.w3.org/ns/shacl-shacl">http://www.w3.org/ns/shacl-shacl</a>.
That version may be more up-to-date than this specification as errata are noted against this specification.
</p>
<pre id="shacl-shacl-pre" class="shapes">
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix shsh: <http://www.w3.org/ns/shacl-shacl#> .
shsh:
rdfs:label "SHACL for SHACL"@en ;
rdfs:comment "This shapes graph can be used to validate SHACL shapes graphs against a subset of the SHACL syntax rules."@en ;
sh:declare [
sh:prefix "shsh" ;
sh:namespace "http://www.w3.org/ns/shacl-shacl#" ;
] .
shsh:ListShape
a sh:NodeShape ;
rdfs:label "List shape"@en ;
rdfs:comment "A shape describing well-formed RDF lists. Currently does not check for non-recursion. This could be expressed using SHACL-SPARQL."@en ;
rdfs:seeAlso <https://www.w3.org/TR/shacl/#syntax-rule-SHACL-list> ;
sh:property [
sh:path [ sh:zeroOrMorePath rdf:rest ] ;
rdfs:comment "Each list member (including this node) must be have the shape shsh:ListNodeShape."@en ;
sh:hasValue rdf:nil ;
sh:node shsh:ListNodeShape ;
] .
shsh:ListNodeShape
a sh:NodeShape ;
rdfs:label "List node shape"@en ;
rdfs:comment "Defines constraints on what it means for a node to be a node within a well-formed RDF list. Note that this does not check whether the rdf:rest items are also well-formed lists as this would lead to unsupported recursion."@en ;
sh:or ( [
sh:hasValue rdf:nil ;
sh:property [
sh:path rdf:first ;
sh:maxCount 0 ;
] ;
sh:property [
sh:path rdf:rest ;
sh:maxCount 0 ;
] ;
]
[
sh:not [ sh:hasValue rdf:nil ] ;
sh:property [
sh:path rdf:first ;
sh:maxCount 1 ;
sh:minCount 1 ;
] ;
sh:property [
sh:path rdf:rest ;
sh:maxCount 1 ;
sh:minCount 1 ;
] ;
] ) .
shsh:ShapeShape
a sh:NodeShape ;
rdfs:label "Shape shape"@en ;
rdfs:comment "A shape that can be used to validate syntax rules for other shapes."@en ;
# See https://www.w3.org/TR/shacl/#shapes for what counts as a shape
sh:targetClass sh:NodeShape ;
sh:targetClass sh:PropertyShape ;
sh:targetSubjectsOf sh:targetClass, sh:targetNode, sh:targetObjectsOf, sh:targetSubjectsOf ;
sh:targetSubjectsOf sh:and, sh:class, sh:closed, sh:datatype, sh:disjoint, sh:equals, sh:flags, sh:hasValue,
sh:ignoredProperties, sh:in, sh:languageIn, sh:lessThan, sh:lessThanOrEquals, sh:maxCount, sh:maxExclusive,
sh:maxInclusive, sh:maxLength, sh:minCount, sh:minExclusive, sh:minInclusive, sh:minLength, sh:node, sh:nodeKind,
sh:not, sh:or, sh:pattern, sh:property, sh:qualifiedMaxCount, sh:qualifiedMinCount, sh:qualifiedValueShape,
sh:qualifiedValueShape, sh:qualifiedValueShapesDisjoint, sh:qualifiedValueShapesDisjoint, sh:uniqueLang, sh:xone ;
sh:targetObjectsOf sh:node ; # node-node
sh:targetObjectsOf sh:not ; # not-node
sh:targetObjectsOf sh:property ; # property-node
sh:targetObjectsOf sh:qualifiedValueShape ; # qualifiedValueShape-node
# Shapes are either node shapes or property shapes
sh:xone ( shsh:NodeShapeShape shsh:PropertyShapeShape ) ;
sh:property [
sh:path sh:targetNode ;
sh:nodeKind sh:IRIOrLiteral ; # targetNode-nodeKind
] ;
sh:property [
sh:path sh:targetClass ;
sh:nodeKind sh:IRI ; # targetClass-nodeKind
] ;
sh:property [
sh:path sh:targetSubjectsOf ;
sh:nodeKind sh:IRI ; # targetSubjectsOf-nodeKind
] ;
sh:property [
sh:path sh:targetObjectsOf ;
sh:nodeKind sh:IRI ; # targetObjectsOf-nodeKind
] ;
sh:or ( [ sh:not [
sh:class rdfs:Class ;
sh:or ( [ sh:class sh:NodeShape ] [ sh:class sh:PropertyShape ] )
] ]
[ sh:nodeKind sh:IRI ]
) ; # implicit-targetClass-nodeKind
sh:property [
sh:path sh:severity ;
sh:maxCount 1 ; # severity-maxCount
sh:nodeKind sh:IRI ; # severity-nodeKind
] ;
sh:property [
sh:path sh:message ;
sh:or ( [ sh:datatype xsd:string ] [ sh:datatype rdf:langString ] ) ; # message-datatype
] ;
sh:property [
sh:path sh:deactivated ;
sh:maxCount 1 ; # deactivated-maxCount
sh:in ( true false ) ; # deactivated-datatype
] ;
sh:property [
sh:path sh:and ;
sh:node shsh:ListShape ; # and-node
] ;
sh:property [
sh:path sh:class ;
sh:nodeKind sh:IRI ; # class-nodeKind
] ;
sh:property [
sh:path sh:closed ;
sh:datatype xsd:boolean ; # closed-datatype
sh:maxCount 1 ; # multiple-parameters
] ;
sh:property [
sh:path sh:ignoredProperties ;
sh:node shsh:ListShape ; # ignoredProperties-node
sh:maxCount 1 ; # multiple-parameters
] ;
sh:property [
sh:path ( sh:ignoredProperties [ sh:zeroOrMorePath rdf:rest ] rdf:first ) ;
sh:nodeKind sh:IRI ; # ignoredProperties-members-nodeKind
] ;
sh:property [
sh:path sh:datatype ;
sh:nodeKind sh:IRI ; # datatype-nodeKind
sh:maxCount 1 ; # datatype-maxCount
] ;
sh:property [
sh:path sh:disjoint ;
sh:nodeKind sh:IRI ; # disjoint-nodeKind
] ;
sh:property [
sh:path sh:equals ;
sh:nodeKind sh:IRI ; # equals-nodeKind
] ;
sh:property [
sh:path sh:in ;
sh:maxCount 1 ; # in-maxCount
sh:node shsh:ListShape ; # in-node
] ;
sh:property [
sh:path sh:languageIn ;
sh:maxCount 1 ; # languageIn-maxCount
sh:node shsh:ListShape ; # languageIn-node
] ;
sh:property [
sh:path ( sh:languageIn [ sh:zeroOrMorePath rdf:rest ] rdf:first ) ;
sh:datatype xsd:string ; # languageIn-members-datatype
] ;
sh:property [
sh:path sh:lessThan ;
sh:nodeKind sh:IRI ; # lessThan-nodeKind
] ;
sh:property [
sh:path sh:lessThanOrEquals ;
sh:nodeKind sh:IRI ; # lessThanOrEquals-nodeKind
] ;
sh:property [
sh:path sh:maxCount ;
sh:datatype xsd:integer ; # maxCount-datatype
sh:maxCount 1 ; # maxCount-maxCount
] ;
sh:property [
sh:path sh:maxExclusive ;
sh:maxCount 1 ; # maxExclusive-maxCount
sh:nodeKind sh:Literal ; # maxExclusive-nodeKind
] ;
sh:property [
sh:path sh:maxInclusive ;
sh:maxCount 1 ; # maxInclusive-maxCount
sh:nodeKind sh:Literal ; # maxInclusive-nodeKind
] ;
sh:property [
sh:path sh:maxLength ;
sh:datatype xsd:integer ; # maxLength-datatype
sh:maxCount 1 ; # maxLength-maxCount
] ;
sh:property [
sh:path sh:minCount ;
sh:datatype xsd:integer ; # minCount-datatype
sh:maxCount 1 ; # minCount-maxCount
] ;
sh:property [
sh:path sh:minExclusive ;
sh:maxCount 1 ; # minExclusive-maxCount
sh:nodeKind sh:Literal ; # minExclusive-nodeKind
] ;
sh:property [
sh:path sh:minInclusive ;
sh:maxCount 1 ; # minInclusive-maxCount
sh:nodeKind sh:Literal ; # minInclusive-nodeKind
] ;
sh:property [
sh:path sh:minLength ;
sh:datatype xsd:integer ; # minLength-datatype
sh:maxCount 1 ; # minLength-maxCount
] ;
sh:property [
sh:path sh:nodeKind ;
sh:in ( sh:BlankNode sh:IRI sh:Literal sh:BlankNodeOrIRI sh:BlankNodeOrLiteral sh:IRIOrLiteral ) ; # nodeKind-in
sh:maxCount 1 ; # nodeKind-maxCount
] ;
sh:property [
sh:path sh:or ;
sh:node shsh:ListShape ; # or-node
] ;
sh:property [
sh:path sh:pattern ;
sh:datatype xsd:string ; # pattern-datatype
sh:maxCount 1 ; # multiple-parameters
# Not implemented: syntax rule pattern-regex
] ;
sh:property [
sh:path sh:flags ;
sh:datatype xsd:string ; # flags-datatype
sh:maxCount 1 ; # multiple-parameters
] ;
sh:property [
sh:path sh:qualifiedMaxCount ;
sh:datatype xsd:integer ; # qualifiedMaxCount-datatype
sh:maxCount 1 ; # multiple-parameters
] ;
sh:property [
sh:path sh:qualifiedMinCount ;
sh:datatype xsd:integer ; # qualifiedMinCount-datatype
sh:maxCount 1 ; # multiple-parameters
] ;
sh:property [
sh:path sh:qualifiedValueShape ;
sh:maxCount 1 ; # multiple-parameters
] ;
sh:property [
sh:path sh:qualifiedValueShapesDisjoint ;
sh:datatype xsd:boolean ; # qualifiedValueShapesDisjoint-datatype
sh:maxCount 1 ; # multiple-parameters
] ;
sh:property [
sh:path sh:uniqueLang ;
sh:datatype xsd:boolean ; # uniqueLang-datatype
sh:maxCount 1 ; # uniqueLang-maxCount
] ;
sh:property [
sh:path sh:xone ;
sh:node shsh:ListShape ; # xone-node
] .
shsh:NodeShapeShape
a sh:NodeShape ;
sh:targetObjectsOf sh:node ; # node-node
sh:property [
sh:path sh:path ;
sh:maxCount 0 ; # NodeShape-path-maxCount
] ;
sh:property [
sh:path sh:lessThan ;
sh:maxCount 0 ; # lessThan-scope
] ;
sh:property [
sh:path sh:lessThanOrEquals ;
sh:maxCount 0 ; # lessThanOrEquals-scope
] ;
sh:property [
sh:path sh:maxCount ;
sh:maxCount 0 ; # maxCount-scope
] ;
sh:property [
sh:path sh:minCount ;
sh:maxCount 0 ; # minCount-scope
] ;
sh:property [
sh:path sh:qualifiedValueShape ;
sh:maxCount 0 ; # qualifiedValueShape-scope
] ;
sh:property [
sh:path sh:uniqueLang ;
sh:maxCount 0 ; # uniqueLang-scope
] .
shsh:PropertyShapeShape
a sh:NodeShape ;
sh:targetObjectsOf sh:property ; # property-node
sh:property [
sh:path sh:path ;
sh:maxCount 1 ; # path-maxCount
sh:minCount 1 ; # PropertyShape-path-minCount
sh:node shsh:PathShape ; # path-node
] .
# Values of sh:and, sh:or and sh:xone must be lists of shapes
shsh:ShapesListShape
a sh:NodeShape ;
sh:targetObjectsOf sh:and ; # and-members-node
sh:targetObjectsOf sh:or ; # or-members-node
sh:targetObjectsOf sh:xone ; # xone-members-node
sh:property [
sh:path ( [ sh:zeroOrMorePath rdf:rest ] rdf:first ) ;
sh:node shsh:ShapeShape ;
] .
# A path of blank node path syntax, used to simulate recursion
_:PathPath
sh:alternativePath (
( [ sh:zeroOrMorePath rdf:rest ] rdf:first )
( sh:alternativePath [ sh:zeroOrMorePath rdf:rest ] rdf:first )
sh:inversePath
sh:zeroOrMorePath
sh:oneOrMorePath
sh:zeroOrOnePath
) .
shsh:PathShape
a sh:NodeShape ;
rdfs:label "Path shape"@en ;
rdfs:comment "A shape that can be used to validate the syntax rules of well-formed SHACL paths."@en ;
rdfs:seeAlso <https://www.w3.org/TR/shacl/#property-paths> ;
sh:property [
sh:path [ sh:zeroOrMorePath _:PathPath ] ;
sh:node shsh:PathNodeShape ;
] .
shsh:PathNodeShape
sh:xone ( # path-metarule
[ sh:nodeKind sh:IRI ] # 2.3.1.1: Predicate path
[ sh:nodeKind sh:BlankNode ; # 2.3.1.2: Sequence path
sh:node shsh:PathListWithAtLeast2Members ;
]
[ sh:nodeKind sh:BlankNode ; # 2.3.1.3: Alternative path
sh:closed true ;
sh:property [
sh:path sh:alternativePath ;
sh:node shsh:PathListWithAtLeast2Members ;
sh:minCount 1 ;
sh:maxCount 1 ;
]
]
[ sh:nodeKind sh:BlankNode ; # 2.3.1.4: Inverse path
sh:closed true ;
sh:property [
sh:path sh:inversePath ;
sh:minCount 1 ;
sh:maxCount 1 ;
]
]
[ sh:nodeKind sh:BlankNode ; # 2.3.1.5: Zero-or-more path
sh:closed true ;
sh:property [
sh:path sh:zeroOrMorePath ;
sh:minCount 1 ;
sh:maxCount 1 ;
]
]
[ sh:nodeKind sh:BlankNode ; # 2.3.1.6: One-or-more path
sh:closed true ;
sh:property [
sh:path sh:oneOrMorePath ;
sh:minCount 1 ;
sh:maxCount 1 ;
]
]
[ sh:nodeKind sh:BlankNode ; # 2.3.1.7: Zero-or-one path
sh:closed true ;
sh:property [
sh:path sh:zeroOrOnePath ;
sh:minCount 1 ;
sh:maxCount 1 ;
]
]
) .
shsh:PathListWithAtLeast2Members
a sh:NodeShape ;
sh:node shsh:ListShape ;
sh:property [
sh:path [ sh:oneOrMorePath rdf:rest ] ;
sh:minCount 2 ; # 1 other list node plus rdf:nil
] .
shsh:ShapesGraphShape
a sh:NodeShape ;
sh:targetObjectsOf sh:shapesGraph ;
sh:nodeKind sh:IRI . # shapesGraph-nodeKind
shsh:EntailmentShape
a sh:NodeShape ;
sh:targetObjectsOf sh:entailment ;
sh:nodeKind sh:IRI . # entailment-nodeKind
</pre>
</section>
<section id="core-validators" class="appendix">
<h2>Summary of SHACL Core Validators</h2>
<p>
This section enumerates all normative <a>validators</a> of SHACL Core.
This section is automatically generated from other parts of this spec and hyperlinks are provided back
into the prose if the context of the validator in unclear.
</p>
<table class="term-table" id="validators-table">
<tr>
<th>Validators by Constraint Component</th>
</tr>
</table>
</section>
<section id="security" class="appendix informative">
<h2>Security and Privacy Considerations</h2>
<p>
Like most RDF-based technologies, SHACL processors may operate on graphs that are combined
from various sources. Some applications may have an open "linked data" architecture and dynamically
assemble RDF triples from sources that are outside of 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 lead to misleading results.
Protection against this (and the following) scenario can be achieved by only using trusted
and verified RDF sources and eliminating the possibility that graphs are dynamically added via
<code>owl:imports</code> and <code>sh:shapesGraph</code>.
</p>
<p>
SHACL-SPARQL includes all the <a href="https://www.w3.org/TR/sparql11-query/#security">security issues of SPARQL</a>.
</p>
</section>
<section id="ack" class="appendix informative">
<h2>Acknowledgements</h2>
<p>
Many people contributed to this specification, including members of the RDF Data Shapes Working Group.
We especially thank the following:
</p>
<p>
Arnaud Le Hors (chair until end of 2016),
Dean Allemang,
Jim Amsden,
Iovka Boneva,
Olivier Corby,
Karen Coyle,
Richard Cyganiak,
Michel Dumontier,
Sandro Hawke,
Holger Knublauch,
Dimitris Kontokostas,
Jose Labra,
Pano Maria,
Peter Patel-Schneider,
Irene Polikoff,
Eric Prud'hommeaux,
Arthur Ryman (who also served as a co-editor until Feb 2016),
Andy Seaborne,
Harold Solbrig,
Simon Steyskal,
Ted Thibodeau,
Bart van Leeuwen,
Nicky van Oorschot
</p>
</section>
<section class="appendix informative">
<h2>Revision History</h2>
<p>
The detailed list of changes and their diffs can be found in the <a href="https://github.com/w3c/data-shapes/commits/gh-pages/shacl/index.html">Git repository</a>.
</p>
<ul>
<li><b>2017-05-18</b>: Clarified that $shapesGraph and $currentShape are optional in pre-binding (see <a href="https://github.com/w3c/data-shapes/issues/84">Issue #84</a>).</li>
<li><b>2017-05-10</b>: Removed features at risk as <a href="https://www.w3.org/2017/05/10-shapes-minutes.html#item03">decided</a> in the meeting.</li>
<li><b>2017-05-10</b>: Further simplification of pre-binding, removing "dead code" that became redundant due to recently added restriction on Sub-SELECTs.</li>
<li><b>2017-05-04</b>: Stricter policy for exclusions on SPARQL queries handled by pre-binding, see <a href="https://www.w3.org/2017/05/03-shapes-minutes.html#item02">WG decision</a>.</li>
<li><b>2017-04-30</b>: Removed accidental use of sh:sparql in SHACL-for-SHACL graph, clarified that SHACL Core processors ignore SHACL-SPARQL constructs (see <a href="https://github.com/w3c/data-shapes/issues/63">Issue #63</a>).</li>
<li><b>2017-04-28</b>: Improvements to SHACL-SPARQL handling in the (informative) Security appendix (see <a href="https://github.com/w3c/data-shapes/issues/73">Issue #73</a>).</li>
<li><b>2017-04-23</b>: Clarified that values of sh:message are copied into sh:resultMessage (see <a href="https://github.com/w3c/data-shapes/issues/57">Issue #57</a>).</li>
<li><b>2017-04-23 and 2017-05-03</b>: Added some exclusions on SPARQL queries handled by pre-binding, see <a href="https://www.w3.org/2017/04/19-shapes-minutes.html#item02">WG decision</a>.</li>
<li><b>2017-04-20</b>: Clarified that sh:property always produces new validation result nodes, see <a href="https://www.w3.org/2017/04/19-shapes-minutes.html#item01">WG decision</a>.</li>
<li><b>2017-04-09</b>: Changed SHACL-for-SHACL to no longer be at-risk, per W3C staff.</li>
<li><b>2017-04-05</b>: Added Appendix C with SHACL-for-SHACL shapes graph, marked two syntax rules as <a href="#at-risk">feature-at-risk</a>, added non-normative comment to the section on recursion (3.4.3)</li>
<li><b>2017-03-24</b>: Updated pre-binding definition to align with <a href="https://w3c.github.io/sparql-exists/docs/sparql-exists.html">SPARQL EXISTS Errata</a></li>
<li><b>2017-03-22</b>: sh:minLength and sh:maxLength now use SPARQL STRLEN function explicitly, see <a href="https://github.com/w3c/data-shapes/issues/43">GitHub Issue #43</a></li>
<li><b>2017-03-22</b>: Tightened some syntax rules so that they only apply to shapes, and set maxCount=1 to some core parameters, see <a href="https://lists.w3.org/Archives/Public/public-rdf-shapes/2017Mar/0063.html">email thread</a></li>
<li><b>2017-03-22</b>: Clean up of path-related terminology</li>
<li><b>2017-03-17</b>: Updated example from 1.4 and other editorial work</li>
<li><b>2017-03-02</b>: Moved the sh:qualifiedValueShapesDisjoint flag from the parent into the property shapes (<a href="http://www.w3.org/2014/data-shapes/track/issues/92">ISSUE-92</a>)</li>
<li><b>2017-03-02</b>: Added informative security and privacy section to the appendix</li>
<li><b>2017-03-02</b>: Removed syntax restrictions that were disallowing sh:equals and sh:disjoint at node shapes (<a href="http://www.w3.org/2014/data-shapes/track/issues/139">ISSUE-139</a>)</li>
<li><b>2017-03-02</b>: Marked SHACL-SPARQL as feature at risk, for process reasons (<a href="http://www.w3.org/2014/data-shapes/track/issues/222">ISSUE-222</a>)</li>
<li><b>2017-03-01</b>: Clarified definition of sibling shapes (sh:qualifiedValueShapesDisjoint) (<a href="http://www.w3.org/2014/data-shapes/track/issues/92">ISSUE-92</a>)</li>
<li><b>2017-02-27</b>: Updated definitions of sh:not, sh:and, sh:or, sh:xone, sh:node to use "conforms" (<a href="http://www.w3.org/2014/data-shapes/track/issues/234">ISSUE-234</a>)</li>
<li><b>2017-02-23</b>: Added sh:shapesGraphWellFormed (<a href="http://www.w3.org/2014/data-shapes/track/issues/233">ISSUE-233</a>)</li>
<li><b>2017-02-20</b>: Clarifications on result graph (<a href="http://www.w3.org/2014/data-shapes/track/issues/225">ISSUE-225</a>, <a href="http://www.w3.org/2014/data-shapes/track/issues/228">ISSUE-228</a>, <a href="http://www.w3.org/2014/data-shapes/track/issues/229">ISSUE-229</a>)</li>
<li><b>2017-02-17</b>: Moved content on Appendix A (Entailment) into section 1.5</li>
<li><b>2017-02-16</b>: In section 5.3.2, allowed sh:message for constraint components; that may be over-ridden by a more specific sh:message attached to a specific validator within that constraint component (<a href="http://www.w3.org/2014/data-shapes/track/issues/231">ISSUE-231</a>)</li>
<li><b>2017-02-16</b>: Renamed sh:xor to sh:xone (<a href="http://www.w3.org/2014/data-shapes/track/issues/219">ISSUE-219</a>)</li>
<li><b>2017-02-10</b>: Changed execution of sh:sparql in property shapes so that $this is the focus node and $PATH can be used. Also dropped support for SPARQL result variable focusNode (<a href="http://www.w3.org/2014/data-shapes/track/issues/230">ISSUE-230</a>)</li>
<li><b>2017-02-09</b>: Added syntax rules that sh:NodeShapes cannot have sh:path and sh:PropertyShapes must have a sh:path (<a href="http://www.w3.org/2014/data-shapes/track/issues/223">ISSUE-223</a>) and related terminology clarifications (<a href="http://www.w3.org/2014/data-shapes/track/issues/224">ISSUE-224</a>)</li>
<li><b>2017-02-09</b>: Declared the use of sh:minCount, sh:maxCount, sh:uniqueLang, the 4 property pair parameters and sh:qualifiedValueShape at node shapes ill-formed (<a href="http://www.w3.org/2014/data-shapes/track/issues/139">ISSUE-139</a>)</li>
<li><b>2017-02-09</b>: Corrected the constraint component IRIs of sh:qualifiedMinCount and sh:qualifiedMaxCount</li>
<li><b>2017-02-08</b>: Clarified validation of ASK-based constraint components in 6.3</li>
<li><b>2017-02-07</b>: Slightly updated definition of pre-binding (now about query instead of graph pattern)</li>
<li><b>2017-02-07</b>: Added an example snippet in JSON-LD</li>
<li><b>2017-02-03</b>: "predicate" no longer an ill-formed parameter name in SPARQL constraint components (left-over from ISSUE-217)</li>
<li><b>2017-02-02</b>: Renamed sh:shape to sh:node, limited its range to node shapes (<a href="http://www.w3.org/2014/data-shapes/track/issues/221">ISSUE-221</a>)</li>
<li><b>2017-01-27</b>: Added conditions to distinguish shapes from other nodes (<a href="http://www.w3.org/2014/data-shapes/track/issues/220">ISSUE-220</a>)</li>
<li><b>2017-01-26</b>: Added sh:xor (<a href="http://www.w3.org/2014/data-shapes/track/issues/219">ISSUE-219</a>)</li>
<li><b>2017-01-24</b>: New definition of pre-binding (first draft based on <a href="https://w3c.github.io/sparql-exists/docs/sparql-exists.html">SPARQL EXISTS CG Draft Report</a>) (<a href="http://www.w3.org/2014/data-shapes/track/issues/68">ISSUE-68</a>)</li>
<li><b>2017-01-19</b>: Moved SPARQL annotation properties mechanism to advanced features WG Note in anticipation of the vote on (<a href="http://www.w3.org/2014/data-shapes/track/issues/218">ISSUE-218</a>)</li>
<li><b>2017-01-19</b>: Deleted sh:partition and added a boolean flag sh:qualifiedValueShapesDisjoint (<a href="http://www.w3.org/2014/data-shapes/track/issues/92">ISSUE-92</a>)</li>
<li><b>2017-01-19</b>: Removed sh:predicate in favor of using sh:path only (<a href="http://www.w3.org/2014/data-shapes/track/issues/217">ISSUE-217</a>)</li>
<li><b>2017-01-17</b>: Finished general restructuring, formalization and clean up of the whole document</li>
<li><b>2017-01-15</b>: Added appendixes that summarize syntax rules and validators</li>
<li><b>2017-01-12</b>: Removed dependency on SPARQL EXISTS (<a href="http://www.w3.org/2014/data-shapes/track/issues/170">ISSUE-170</a>)</li>
<li><b>2017-01-12</b>: Renamed sh:Shape to sh:NodeShape, sh:PropertyConstraint to sh:PropertyShape and sh:Constraint to sh:Shape. Targets can now be applied to every such shape. The term "constraint" now refers to parameter values at a shape. Limited sh:sourceConstraint to SPARQL-based constraints. Renamed sh:shapeValidator to sh:nodeValidator. Other related changes. (<a href="http://www.w3.org/2014/data-shapes/track/issues/211">ISSUE-211</a>)</li>
<li><b>2017-01-12</b>: Moved SPARQL-based targets, derived properties and functions into a separate document (not normative WG note) to reduce scope, switched to using SHACL-SPARQL for Core + SPARQL-based constraints and components</li>
<li><b>2017-01-10</b>: Added syntax highlighting to make syntax rules (ill-formed shapes) more explicit</li>
<li><b>2017-01-05</b>: Removed sh:stem (<a href="http://www.w3.org/2014/data-shapes/track/issues/194">ISSUE-194</a>)</li>
<li><b>2016-12-16</b>: Introduced concept of ill-formed nodes, stating that validation is undefined with ill-formed shapes graph</li>
<li><b>2016-12-16</b>: Turned sh:property and sh:sparql into constraint components, updated related definitions (<a href="http://www.w3.org/2014/data-shapes/track/issues/211">ISSUE-211</a>)</li>
<li><b>2016-12-16</b>: Completed the example used in Derived Values constraints with data and results</li>
<li><b>2016-12-15</b>: Replaced term 'focus node constraint' with 'shape' (<a href="http://www.w3.org/2014/data-shapes/track/issues/212">ISSUE-212</a>)</li>
<li><b>2016-12-14</b>: Clarified that the TTL file is the RDF namespace document only.</li>
<li><b>2016-12-12</b>: Removed the exclusion of blank nodes as values of sh:in.</li>
<li><b>2016-11-24</b>: Use SHACL list instead of RDF list, define ordering for list members and recursion</li>
<li><b>2016-11-22</b>: Added link to (normative) SHACL TTL file (<a href="http://www.w3.org/2014/data-shapes/track/issues/195">ISSUE-195</a>)</li>
<li><b>2016-11-21</b>: Clarifications for SHACL property paths (<a href="http://www.w3.org/2014/data-shapes/track/issues/180">ISSUE-180</a>)</li>
<li><b>2016-11-20</b>: Added sh:ValidationReport (<a href="http://www.w3.org/2014/data-shapes/track/issues/189">ISSUE-189</a>)</li>
<li><b>2016-11-17</b>: Added terms sh:resultPath, sh:resultSeverity and sh:resultMessage (<a href="http://www.w3.org/2014/data-shapes/track/issues/186">ISSUE-186</a>)</li>
<li><b>2016-11-17</b>: Introduced the term "conforms" on the outcome of validation (<a href="http://www.w3.org/2014/data-shapes/track/issues/188">ISSUE-188</a>)</li>
<li><b>2016-11-17</b>: Deleted filter shapes, added sh:deactivated (<a href="http://www.w3.org/2014/data-shapes/track/issues/196">ISSUE-196</a>)</li>
<li><b>2016-11-15</b>: Added statement that shapes can be identified by being the subject of a target triple</li>
<li><b>2016-10-20</b>: Removed the sh:hasShape SPARQL function (<a href="http://www.w3.org/2014/data-shapes/track/issues/131">ISSUE-131</a>)</li>
<li><b>2016-10-12</b>: Generalized sh:message so that it can also be used in constraint (instances) (<a href="http://www.w3.org/2014/data-shapes/track/issues/178">ISSUE-178</a>)</li>
<li><b>2016-09-27</b>: Change several constraint components such as sh:minCount / sh:maxCount and ASK-based validators to operate on value node sets because property paths may return duplicates</li>
<li><b>2016-09-27</b>: Removed shapesGraph argument from sh:hasShape</li>
<li><b>2016-09-15</b>: Added proposed SPARQL prefix handling section (<a href="http://www.w3.org/2014/data-shapes/track/issues/105">ISSUE-105</a>)</li>
<li><b>2016-09-15</b>: Added sh:languageIn (<a href="http://www.w3.org/2014/data-shapes/track/issues/137">ISSUE-137</a>)</li>
<li><b>2016-08-26</b>: Remove special treatment of sh:Violation (<a href="http://www.w3.org/2014/data-shapes/track/issues/150">ISSUE-150</a>)</li>
<li><b>2016-08-23</b>: Added Appendix enumerating the optional features of SHACL</li>
<li><b>2016-08-05</b>: Renamed scope to target, sh:scopeProperty -> sh:scopeSubjectsOf, etc <a href="http://www.w3.org/2014/data-shapes/track/issues/175">ISSUE-175</a>)</li>
<li><b>2016-08-01</b>: Deleted sh:classIn and sh:datatypeIn <a href="https://www.w3.org/2016/07/28-shapes-minutes.html#resolution07">resolution on ISSUE-141</a></li>
<li><b>2016-07-28</b>: Drop sh:defaultValueType according to <a href="https://www.w3.org/2016/06/16-shapes-minutes.html#resolution03">resolution</a></li>
<li><b>2016-07-23</b>: Changed abstract and adopt <a href="https://lists.w3.org/Archives/Public/public-rdf-shapes/2016May/0008.html">Peter's proposal</a>)</li>
<li><b>2016-07-23</b>: Changes to accommodate universal applicability <a href="http://www.w3.org/2014/data-shapes/track/issues/139">ISSUE-139</a>)</li>
<li><b>2016-07-05</b>: Generalized inverseProperty into property paths, added generalized sh:validator <a href="http://www.w3.org/2014/data-shapes/track/issues/41">ISSUE-41</a>)</li>
<li><b>2016-06-17</b>: Applied resolution that SHACL leaves recursion to implementations (<a href="http://www.w3.org/2014/data-shapes/track/issues/22">ISSUE-22</a>)</li>
<li><b>2016-06-12</b>: Added explanations of sh:shapesGraph for ontologies / vocabularies</li>
<li><b>2016-06-03</b>: Removed sh:AllObjectsScope and sh:AllSubjectsScope (<a href="http://www.w3.org/2014/data-shapes/track/issues/148">ISSUE-148</a>)</li>
<li><b>2016-05-27</b>: Renamed sh:sparql into sh:ask and sh:select. Spawned off sh:sparql from sh:constraint. sh:constraint is now for node constraints only (<a href="http://www.w3.org/2014/data-shapes/track/issues/133">ISSUE-133</a>)</li>
<li><b>2016-05-27</b>: Changed syntax of property scopes to sh:scopeProperty and sh:scopeInverseProperty (<a href="http://www.w3.org/2014/data-shapes/track/issues/148">ISSUE-148</a>)</li>
<li><b>2016-05-27</b>: Generalized sh:valueShape into sh:shape (<a href="http://www.w3.org/2014/data-shapes/track/issues/160">ISSUE-160</a>)</li>
<li><b>2016-05-17</b>: New example in section 1.3</li>
<li><b>2016-05-13</b>: Terminology changes, use SHACL instance, SHACL sub/superclass and SHACL type in the spec</li>
<li><b>2016-05-13</b>: Swapped sections 3 with section 4</li>
<li><b>2016-05-12</b>: sh:and,or,not now also apply to property/inverseProperty constraints (<a href="http://www.w3.org/2014/data-shapes/track/issues/135">ISSUE-135</a>)</li>
<li><b>2016-05-12</b>: Removed sh:abstract (<a href="http://www.w3.org/2014/data-shapes/track/issues/78">ISSUE-78</a>)</li>
<li><b>2016-05-09</b>: SPARQL query at sh:derivedValues must now be proper SELECT queries, to allow PREFIX declarations</li>
<li><b>2016-05-06</b>: Deleted sh:directType (<a href="http://www.w3.org/2014/data-shapes/track/issues/123">ISSUE-123</a>)</li>
<li><b>2016-04-22</b>: Switched from graph-based prefixes to sh:prefix (this is a proposal only!) (<a href="http://www.w3.org/2014/data-shapes/track/issues/105">ISSUE-105</a>)</li>
<li><b>2016-04-20</b>: Significant rework of the advanced sections, based on metamodel Proposal 3 (<a href="http://www.w3.org/2014/data-shapes/track/issues/95">ISSUE-95</a>)</li>
<li><b>2016-04-18</b>: Added sh:stem definition</li>
<li><b>2016-04-18</b>: Renamed sh:sourceTemplate to sh:sourceConstraintComponent</li>
<li><b>2016-04-18</b>: Updated the definition of pre-binding (<a href="http://www.w3.org/2014/data-shapes/track/issues/68">ISSUE-68</a>)</li>
<li><b>2016-04-15</b>: Allowing multi-occurrence of constraint parameters <a href="http://www.w3.org/2014/data-shapes/track/issues/133">ISSUE-133</a></li>
<li><b>2016-04-10/16/18</b>: Updated text for <a href="http://www.w3.org/2014/data-shapes/track/issues/144">ISSUE-144</a></li>
<li><b>2016-04-10</b>: Fixed SPARQL query of sh:minExclusive <a href="http://www.w3.org/2014/data-shapes/track/issues/145">ISSUE-145</a></li>
<li><b>2016-04-08</b>: Updated the definition and use of sh:hasShape <a href="http://www.w3.org/2014/data-shapes/track/issues/131">ISSUE-131</a></li>
<li><b>2016-04-08</b>: Renamed sh:notEquals to sh:disjoint <a href="http://www.w3.org/2014/data-shapes/track/issues/136">ISSUE-136</a></li>
<li><b>2016-04-07</b>: Added section on Invalid Shapes Graphs for <a href="http://www.w3.org/2014/data-shapes/track/issues/134">ISSUE-134</a></li>
<li><b>2016-03-25</b>: Rearrange, cleanup sections 2 and 4, better definition of shape validation</li>
<li><b>2016-03-25</b>: Entailment regime - fix the graph IRI issue</li>
<li><b>2016-03-25</b>: $shapesGraph warnings</li>
<li><b>2016-03-22</b>: Cleaned up generic mechanism to define constraint components applied to 3.1</li>
<li><b>2016-03-21</b>: SHACL does not assume that the data graph is an RDF dataset</li>
<li><b>2016-03-21</b>: updated some definitions for shapes, scopes and filters</li>
<li><b>2016-03-21</b>: Re-organized the sections on the various constraint properties, introducing the term constraint component</li>
<li><b>2016-03-21</b>: Updated the definition of pre-binding (<a href="http://www.w3.org/2014/data-shapes/track/issues/68">ISSUE-68</a>)</li>
<li><b>2016-03-14</b>: Added three new node kinds as resolved (<a href="http://www.w3.org/2014/data-shapes/track/issues/99">ISSUE-99</a>)</li>
<li><b>2016-03-12</b>: Added issue warning regarding recursion</li>
<li><b>2016-03-04</b>: Simplified the definition of sh:class (<a href="http://www.w3.org/2014/data-shapes/track/issues/99">ISSUE-99</a>)</li>
<li><b>2016-02-24</b>: Updated the definition of pre-binding (<a href="http://www.w3.org/2014/data-shapes/track/issues/68">ISSUE-68</a>)</li>
<li><b>2016-02-19</b>: Clarified that support for <code>$shapesGraph</code> is optional (<a href="http://www.w3.org/2014/data-shapes/track/issues/47">ISSUE-47</a>)</li>
<li><b>2016-02-19</b>: Clarified that the SHACL graph URI includes the # (<a href="http://www.w3.org/2014/data-shapes/track/issues/129">ISSUE-129</a>)</li>
<li><b>2016-02-18</b>: Removed reference to the proposed class <code>sh:QCC</code>(<a href="http://www.w3.org/2014/data-shapes/track/issues/92">ISSUE-92</a>)</li>
<li><b>2016-02-12</b>: Added a paragraph on the limits of the core vocabulary, highlighting how rdf:Lists can be handled by the extension mechanism (<a href="http://www.w3.org/2014/data-shapes/track/issues/119">ISSUE-119</a>)</li>
<li><b>2016-02-10</b>: Added <code>sh:partition</code>. (<a href="http://www.w3.org/2014/data-shapes/track/issues/92">ISSUE-92</a>)</li>
<li><b>2016-02-05</b>: Removed value type constraints on various constraint properties such as sh:class (<a href="http://www.w3.org/2014/data-shapes/track/issues/117">ISSUE-117</a>)</li>
<li><b>2016-01-29</b>: Clarified that validation results must be based on the data graph only. (<a href="http://www.w3.org/2014/data-shapes/track/issues/118">ISSUE-118</a>)</li>
<li><b>2016-01-25</b>: Clarified direction of property path. Remove comment about consistency. (<a href="http://www.w3.org/2014/data-shapes/track/issues/23">ISSUE-23</a>)</li>
<li><b>2016-01-22</b>: Switched closed shapes syntax to sh:closed (<a href="http://www.w3.org/2014/data-shapes/track/issues/115">ISSUE-115</a>)</li>
<li><b>2016-01-21</b>: Limit definition of shapes that are also classes to the shapes graph (<a href="http://www.w3.org/2014/data-shapes/track/issues/23">ISSUE-23</a>)</li>
<li><b>2016-01-19</b>: Describe scoping of shapes that are also classes (<a href="http://www.w3.org/2014/data-shapes/track/issues/23">ISSUE-23</a>)</li>
<li><b>2016-01-18</b>: Stated starting point for recursion (<a href="http://www.w3.org/2014/data-shapes/track/issues/22">ISSUE-22</a>)</li>
<li><b>2016-01-18</b>: Clarified the meaning of filter shapes (<a href="http://www.w3.org/2014/data-shapes/track/issues/49">ISSUE-49</a>)</li>
<li><b>2016-01-11</b>: Deleted operations section (<a href="http://www.w3.org/2014/data-shapes/track/issues/108">ISSUE-108</a>)</li>
<li><b>2016-01-11</b>: Added derived properties (<a href="http://www.w3.org/2014/data-shapes/track/issues/97">ISSUE-97</a>)</li>
<li><b>2016-01-11</b>: Dropped sh:ShapeClass (<a href="http://www.w3.org/2014/data-shapes/track/issues/23">ISSUE-23</a>), elaborated on possible sh:scopeClass rule</li>
<li><b>2016-01-10</b>: Added sh:order (<a href="http://www.w3.org/2014/data-shapes/track/issues/100">ISSUE-100</a>) and sh:group (<a href="http://www.w3.org/2014/data-shapes/track/issues/114">ISSUE-114</a>)</li>
<li><b>2016-01-10</b>: Introduced sh:datatypeIn and sh:classIn, deleted sh:text (<a href="http://www.w3.org/2014/data-shapes/track/issues/104">ISSUE-104</a>)</li>
<li><b>2016-01-09</b>: Syntax simplifications: Switched to sh:not, sh:and, sh:or, sh:equals, sh:notEquals, sh:lessThan, sh:lessThanOrEquals (<a href="http://www.w3.org/2014/data-shapes/track/issues/103">ISSUE-103</a>)</li>
<li><b>2015-12-02</b>: Fixed <a href="https://github.com/w3c/data-shapes/issues/9">minor mistake in spec - ex:unsinged</a>.</li>
<li><b>2015-11-20</b>: Switched from rdfs:label/rdfs:comment at property constraints to sh:name/sh:description (ISSUE-112)</li>
<li><b>2015-11-06</b>: Renamed sh:nodeShape to sh:scopeNode, clarified that its triples are expected in shapes graph (ISSUE-61)</li>
<li><b>2015-10-30</b>: Deleted sh:cachable, removed the option for sh:sparql to be a query fragment in sh:scope</li>
<li><b>2015-10-29</b>: Improved wording in the definition of sh:in.</li>
<li><b>2015-10-28</b>: Separated definitions of sh:qualifiedMinCount and sh:qualifiedMaxCount</li>
<li><b>2015-10-22</b>: Define sh:minLength, sh:maxLength, sh:qualifiedMinCount, and sh:qualifiedMaxCount without reference to default values</li>
<li><b>2015-10-22</b>: Replaced ex:bornIn with ex:residentIn in Section 2.2</li>
<li><b>2015-10-16</b>: Added sh:SPARQLConstraint and sh:SPARQLScope (part of ISSUE-98)</li>
<li><b>2015-10-16</b>: Renamed sh:valueClass to sh:class, sh:allowedValues to sh:in, sh:directValueType to sh:directType (part of ISSUE-98)</li>
<li><b>2015-10-15</b>: Define sh:minCount and sh:maxCount without reference to default values</li>
<li><b>2015-10-15</b>: Use real-world names in examples 3, 4 and 5</li>
<li><b>2015-10-15</b>: Changed SPARQL definition of sh:AllObjects, implementing resolution to ISSUE-90</li>
<li><b>2015-10-09</b>: Added sh:flags and sh:uniqueLang</li>
<li><b>2015-09-23</b>: Multiple minor stylistic edits and corrections</li>
<li><b>2015-09-21</b>: Added button to show or hide SPARQL definitions (thanks to Simon)</li>
<li><b>2015-09-18</b>: Deleted <code>sh:XorConstraint</code> as resolved, renamed <code>sh:Error</code> to <code>sh:Violation</code></li>
<li><b>2015-09-17</b>: Added missing definition of <code>sh:class</code>, editorial changes, renamed sh:ClosedShape to sh:Closed, added sh:sourceTemplate</li>
<li><b>2015-09-15</b>: Restructured Part 2, with new examples, integrated SPARQL binding and rewritten Operations section</li>
<li><b>2015-09-14</b>: Added SPARQL definitions for each constraint type, added description of sh:hasShape function</li>
<li><b>2015-09-11</b>: Restructured constraint section, cleaned up results vocabulary</li>
<li><b>2015-09-10</b>: Added sh:shapesGraph property (<a href="http://www.w3.org/2014/data-shapes/track/issues/44">ISSUE-44</a>)</li>
<li><b>2015-09-09</b>: Rewritten introduction, dropped Profile section, word-smithing on sh:class</li>
<li><b>2015-09-04</b>: Applied resolution to <a href="http://www.w3.org/2014/data-shapes/track/issues/70">ISSUE-70</a></li>
<li><b>2015-09-03</b>: Many editorial changes, restructured section 5 (scopes and filters) into section 2 (Shapes)</li>
<li><b>2015-09-01</b>: Minor changes and clarifications</li>
<li><b>2015-08-24</b>: Added section on sh:defaultValueType (<a href="http://www.w3.org/2014/data-shapes/track/issues/70">ISSUE-70</a>)</li>
<li><b>2015-08-21</b>: Added support for validation functions (<a href="http://www.w3.org/2014/data-shapes/track/issues/79">ISSUE-79</a>)</li>
<li><b>2015-08-14</b>:
Added qualified cardinality restrictions (<a href="http://www.w3.org/2014/data-shapes/track/issues/72">ISSUE-72</a>),
added sh:ignoredProperties to sh:ClosedShape (<a href="http://www.w3.org/2014/data-shapes/track/issues/58">ISSUE-58</a>),
editorial improvements to terminology, added Glossary to appendix
</li>
<li><b>2015-08-07</b>: Extended the use of sh:severity to template constraints, split sh:source into sh:sourceConstraint and sh:sourceShape, renamed sh:root to sh:focusNode</li>
<li><b>2015-07-31</b>: Added sh:text as the union of xsd:string and rdf:langString</li>
<li><b>2015-07-30</b>: Integrated sh:InversePropertyScope and sh:AllObjects</li>
<li><b>2015-07-24</b>: Added details of XSD-like facets (<a href="http://www.w3.org/2014/data-shapes/track/issues/64">ISSUE-64</a>)</li>
<li>
<b>2015-07-17</b>: Rewritten scope and filter mechanism (<a href="http://www.w3.org/2014/data-shapes/track/issues/62">ISSUE-62</a>),
suggestion for generalized execution language interface (<a href="http://www.w3.org/2014/data-shapes/track/issues/60">ISSUE-60</a>)
</li>
<li><b>2015-07-13</b>: Replaced Appendix with references to SHACL-REF document</li>
<li><b>2015-07-03</b>: Editorial fixes, started revision history</li>
</ul>
</section>
</body>
<script type="text/javascript">
tooltip = "Targets are not the only way to initiate validation, SHACL also allows specific nodes to be validated against specific shapes.";
var t = document.getElementsByClassName("target-can-be-skipped");
for (var i = 0; i < t.length; i++) {
t[i].title = tooltip;
}
</script>
</html>