shacl/index.html

<!DOCTYPE html>
<html>
	<head>
		<title>Shapes Constraint Language (SHACL)</title>
		<meta charset='utf-8'>
		<script src='//www.w3.org/Tools/respec/respec-w3c-common' async class='remove'></script>
		<script class='remove'>
			var respecConfig = {
				edDraftURI: "http://w3c.github.io/data-shapes/shacl/",
				specStatus: "ED",
				shortName:  "shacl",
				editors: [
					{
						name:       "Holger Knublauch",
						url:        "http://knublauch.com/",
						company:    "TopQuadrant, Inc.",
						companyURL: "http://topquadrant.com/"
					},
					{
						name:       "Eric Prud'hommeaux",
						url:        "http://www.w3.org/People/Eric/",
						company:    "W3C/MIT",
						companyURL: "http://www.w3.org/"
					}
				],
				wg:           "RDF Data Shapes Working Group",
				wgURI:        "https://www.w3.org/2014/data-shapes/wiki/Main_Page",
				wgPublicList: "public-data-shapes",
				wgPatentURI:  "http://www.w3.org/2004/01/pp-impl/73865/status",
			};
		</script>
		<style>

			pre {
				tab-size: 4;
			}

			th {
				text-align: left;
			}
			table.rule { background-color: #EBEBE0; }
			table.rule td { text-align: center; }
			td.up { border-bottom:1px solid black; }
			
			.arg {
				font-weight: bold;
				color: #000080;
			}

			.def {
				background: #fcfcfc;
				border-left-style: solid;
				border-left-width: .5em;
				border-color: #c0c0c0;
				margin-bottom: 16px;
				padding: 8px;
			}
			
			.def-sparql {
			}
			
			.def-text {
			}
			
			.def-text-body {
				margin-left: 2em;
			}
			
			.def-header {
				color: #a0a0a0;
				font-size: 16px;
				padding-bottom: 8px;
			}
		
			.term {
				font-style: italic;
			}
		
			.term-table {
				border-collapse: collapse;
				border-color: #000000;
				margin: 16px;
			}
		
			.todo {
				color: red;
			}

		</style>
	</head>
	<body>

		<section id="abstract">
			<p>
				SHACL (Shapes Constraint Language) is an RDF vocabulary for describing RDF graph structures.
				Some of these graph structures are captured as "shapes", which group together constraints about the same RDF nodes.
				Shapes provide a high-level vocabulary to identify predicates and their associated cardinalities, datatypes and other constraints.
				Additional constraints can either be stated globally or be associated with shapes using SPARQL and similar executable languages.
				These executable languages can also be used to define new high-level vocabulary terms.
				SHACL shapes can be used to communicate data structures associated with some process or interface, generate or validate data, or drive user interfaces.
				This document defines the SHACL RDF vocabulary together with its underlying semantics.
			</p>	
		</section>

		<section id="sotd">
			<p>
				Proposal to RDF Data Shapes WG.
			</p>
		</section>
	
		<section id="introduction">
			<h2>Introduction</h2>
			<p>
				SHACL (Shapes Constraint Language) is an RDF vocabulary to formulate structural constraints on <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-graph">RDF graphs</a>.
				The SHACL vocabulary includes high-level concepts to represent restrictions on predicates used in <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-triple">triples</a>.
				These restrictions can be grouped into "<span class="term">shapes</span>".
				Shapes can be used to restrict the number of property values and the permitted value types as well as other conditions.
				Some users and implementors will be content with using the high-level shapes language only, which is called the <span class="term">SHACL Core Profile</span>
				and is described in sections 2 to 6 of this document.
			</p>
			<p>
				For more complex use cases, SHACL also includes facilities to express other restrictions in an executable language such as SPARQL and, possibly, other languages such as JavaScript.
				SHACL includes macro facilities that encapsulate reusable building blocks based on these executable languages into <span class="term">templates</span> and <span class="term">functions</span>.
				These advanced topics are covered from section 7 onwards. 
			</p>
			<p>
				SHACL definitions are represented in RDF and can be serialized in multiple RDF formats.
				The example snippets in this document use Turtle [[turtle]] and <span class="todo">(not written yet:)</span> JSON-LD [[json-ld]] notation.
				The reader should be familiar with basic RDF concepts [[rdf11-concepts]] such as triples and (for the advanced concepts of SHACL) with SPARQL [[sparql11-overview]].
			</p>
			<section id="introduction-outline">
				<h3>Document Outline</h3>
				<p>
					Unless otherwise noted in the section heading, all sections and appendices in this document are normative.
					<span class="todo">TODO: We still need to mark non-normative sections.</span>
				</p>
				<p>
					The remaining sub-sections of the Introduction provide an overview of the complete language and introduces relevant terminology.
				</p>
				<p>
					The sections 2 - 6 cover the <span class="term">SHACL Core Profile</span> and may be read independently from the later sections.
					<span class="todo">We could add details on every section here, but I am not sure this is really needed.</span>
				</p>
				<p>
					The sections 7 onwards are about the full SHACL language and its formal definition.
					The appendix includes SPARQL-related implementation details.
				</p>
			</section>
			<section id="introduction-overview">
				<h3>Overview and Terminology of Core Features</h3>
				<p>
					The following example illustrates the use of SHACL to define constraints on issues in a hypothetical bug tracking system.
					In the example scenario, the RDFS class <code>ex:Issue</code> is used to represent issues, and the class <code>schema:Person</code> represents users.
					Each <code>ex:Issue</code> must point to exactly one user via the property <code>ex:submittedBy</code> and may have one value for <code>ex:assignedTo</code>.
					Users that have submitted an issue must also have a <code>schema:email</code> address, so that they can be notified when the issue has been updated. 
				</p>
				<pre class="example" title="Definition of ex:Issue and ex:SubmitterShape">
ex:Issue
	a rdfs:Class ;
	sh:property [
		sh:predicate ex:assignedTo ;
		rdfs:label "assigned to" ;
		rdfs:comment "The assignee of an issue must be a person." ;
		sh:maxCount 1 ;
		sh:valueType schema:Person ;
	] ;
	sh:property [
		sh:predicate ex:submittedBy ;
		rdfs:label "submitted by" ;
		rdfs:comment "The submitter of an issue must be a person who also has an email address." ;
		sh:minCount 1 ;
		sh:maxCount 1 ;
		sh:valueType schema:Person ;
		sh:valueShape ex:SubmitterShape ;
	] .

ex:SubmitterShape
	a sh:Shape ;
	rdfs:comment "A submitter must have at least one email address." ;
	sh:property [
		sh:predicate schema:email ;
		sh:minCount 1 ;
	] .</pre>
				<p>
					The basic building blocks of SHACL are <span class="term">constraints</span>.
					Each <span class="term">constraint</span> defines a condition that can be validated against a graph.
					A <a href="#shapes"><span class="term">shape</span></a> describes a group of <span class="term">local constraints</span> with the same <span class="term">focus node</span>.
					Many of these constraints are about a certain property only, and these are called <a href="#property-constraints"><span class="term">property constraints</span></a>.
					<span class="term">Local constraints</span> are evaluated against a given <span class="term">focus node</span>, which serves as starting point of property paths and other graph traversal algorithms.
					In the current draft, the IRIs of classes (such as <code>ex:Issue</code> above) may also be used as shapes.
					Shapes may be arranged in a <span class="term">specialization</span> hierarchy, allowing some shapes to further narrow down the constraints from other shapes.
				</p>
				<p>
					In the Issue example above, the shape <code>ex:Issue</code> includes two local constraints.
					These constraints are here represented as blank nodes via <code>sh:property</code>.
					Each of these constraints specifies the restricted property via <code>sh:predicate</code>, and one or more constraint facets such as <code>sh:minCount</code> and <code>sh:valueType</code>.
					The facet <code>sh:valueShape</code> points to another <code>sh:Shape</code> that defines additional constraints that the values of
					the <code>ex:submittedBy</code> property must fulfill, in addition to being instances of <code>schema:User</code>.
				</p>
				<p>
					One of the <a href="#operations"><span class="term">operations</span></a> that SHACL engines should support validates that a given RDF node matches a given shape.
					This operation can be invoked based on any control logic, i.e. applications can pick their own mapping between RDF nodes and their shapes.
					SHACL also provides two mapping mechanisms based on the RDF triples in the graph being validated.
					Current proposals for these mechanisms include selection based on <code>sh:nodeShape</code> and <code>rdf:type</code> triples.
					Based on such in-graph mappings, SHACL supports constraint validation over a complete graph.
					The output of constraint validation is a set of <a href="#violations"><span class="term">constraint violations</span></a>.
				</p>
				<p>
					The following example code defines two instances of the class <code>ex:Issue</code>.
					When constraint validation is started, a SHACL engine may follow the <code>rdf:type</code> link of these instances to determine which shapes need to be used.
					(If <code>ex:Issue</code> were not a class but a <code>sh:Shape</code>, then the property <code>sh:nodeShape</code> would have been used instead).
					The first instance passes validation without producing any violations.
					The second instance produces an <code>sh:Error</code>, because its value for <code>ex:submittedBy</code> does not have an <code>schema:email</code>. 
				</p>
				<pre class="example" title="Sample Issue instances with resulting constraint violations">
ex:ValidExampleIssue
	a ex:Issue ;
	ex:assignedTo ex:UserWithoutEmail ;
	ex:submittedBy ex:UserWithEmail .
	
ex:InvalidExampleIssue
	a ex:Issue ;
	ex:submittedBy ex:UserWithoutEmail .

ex:UserWithoutEmail
	a schema:Person .
	
ex:UserWithEmail
	a schema:Person ;
	schema:email "someone@example.org" .</pre>
				<p>
					When this instance data is validated, a SHACL engine will produce the following constraint violations:
				</p>
				<pre class="example" title="Constraint violations for the sample instances">
[
	a sh:Error ;
	sh:root ex:InvalidExampleIssue ;
	sh:path ex:submittedBy ;
	sh:value ex:UserWithoutEmail ;
	sh:message "Value does not have the shape ex:SubmitterShape." ;
]</pre>
			</section>
			<section id="introduction-overview-advanced">
				<h3>Overview and Terminology of Advanced Features</h3>
				<p>
					The following paragraphs give an overview of the advanced features of SHACL.
					Readers only interested in the Core Profile may skip this section.
				</p>
				<p>
					In addition to <span class="term">local constraints</span> (attached to shapes), SHACL also supports <a href="#global-constraints"><span class="term">global constraints</span></a>.
					<span class="term">Global constraints</span> are executed when constraint validation is invoked on the whole graph, and may verify arbitrary conditions.
				</p>
				<p>
					The validation of each <span class="term">constraint</span> is formalized with one or more <span class="term">execution languages</span>.
					This version of SHACL supports <a href="#sparql">SPARQL</a> as an <span class="term">execution language</span>, but other languages may be supported in future versions or by other communities.
					Each constraint needs to be backed by at least one <span class="term">executable body</span> in SPARQL, and any alternative bodies need to follow the same semantics as the SPARQL queries.
					Constraints may either directly define such an <span class="term">executable body</span> or point to a <a href="#templates"><span class="term">template</span></a>.
					Constraints that directly include an <span class="term">executable body</span> are called <span class="term">native constraints</span>.
					A <span class="term">template</span> serves as a parameterizable macro that wraps an <span class="term">executable body</span>.
					Constraints that rely on a <span class="term">template</span> are called <span class="term">template constraints</span>.
					The SHACL vocabulary includes a small library of such <span class="term">templates</span> for common constraint patterns, but anyone can add their own template libraries.
					Templates can be grouped into so-called <a href="#profiles"><span class="term">profiles</span></a>.
					Some SHACL engines may decide to only support certain <span class="term">profiles</span> and implement them differently than the provided (SPARQL) bodies.
				</p>
				<p>
					The following example illustrates the use of a <span class="term">global native SPARQL constraint</span> to specify that there cannot be two instances of <code>schema:Person</code> with the same <code>schema:email</code>.
					Note that each result set row produced by the SELECT clauses of the SPARQL query creates one constraint violation.
				</p>
				<pre class="example" title="A global SPARQL-based constraint">
ex:EmailsMustBeUnique
	a sh:GlobalConstraint ;
	sh:message "There cannot be two persons with the same email address." ;
	sh:path schema:email ;
	sh:sparql """
		SELECT (?person1 AS ?root) ?value
		WHERE {
			?person1 schema:email ?email .
			?person2 schema:email ?email .
			?person1 a schema:Person .
			?person2 a schema:Person .
			FILTER (?person1 != ?person2) .
		}
		""" .</pre>
			</section>
			
			<section id="namespaces">
				<h3>Namespaces</h3>
				<p>
					The SHACL system vocabulary is available as a <a href="shacl.shacl.ttl">SHACL Turtle File</a>.
					<span class="todo">Currently contains slight differences from this spec.</span> 
				</p>
				
				<p>
					Within this document, the following namespace prefix bindings are used:
				</p>
				<table class="term-table" border="1" cellpadding="5">
					<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>http://www.w3.org/ns/shacl#</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>
					<tr>
						<td><code>schema:</code></td>
						<td><code>http://schema.org/</code></td>
					</tr>
				</table>
			</section>
			
			<div class="issue" title="Alternative Specifications">
				This document defines the semantics of the high-level vocabulary in textual form and using SPARQL queries, consistent with the SHACL template mechanism.
				Several individual working group members have also proposed alternative language definitions:
				<ul>
					<li><a href="http://w3c.github.io/data-shapes/semantics/">Eric's proposal</a></li>
					<li><a href="http://w3c.github.io/data-shapes/semantics/Axiomatic">Jose's proposal</a></li>
					<li><a href="https://www.w3.org/2014/data-shapes/wiki/Shacl-sparql">Peter's proposal</a></li>
				</ul>
			</div>

		</section>

		<section id="shapes">
			<h2>Shapes</h2>
			<div class="issue" title="Classes and/or Shapes">
				There is no agreement in the WG on the relationship of sh:Shape with RDFS classes.
				Proposals include:
				<ul>
					<li>Keep them completely separate, users only instantiate sh:Shape and use sh:extends</li>
					<li>Have rdfs:Class rdfs:subClassOf sh:Shape, use rdfs:subClassOf</li>
					<li>Have sh:Shape rdfs:subClassOf rdfs:Class, use rdfs:subClassOf</li>
					<li>Allow both approaches in parallel: either rdfs:Class/subClassOf or sh:Shape/extends</li>
					<li>Allow both and have sh:classShape to point from a class to its shape(s)</li>
				</ul>
				In the absence of such an agreement, this document uses sh:Shape in most examples.
				Note that depending on the resolution, all examples could also use rdfs:Class instead of sh:Shape.
			</div>
			<p>
				A <span class="term">Constraint</span> defines restrictions on the structure of an RDF graph.
				Some constraints, called <span class="term">local constraints</span>, can be regarded as radiating out from a <span class="term">focus node</span>.  
				A <span class="term">Shape</span> is a group of constraints that have the same focus nodes.
				For example, a shape can be used to state that all instances of a class must have a certain number of values for a given property.
				In that example, the instances of the class are the focus nodes, and the restriction on property values is expressed via a constraint.
			</p>
			<p>
				In the SHACL RDF vocabulary, Shapes are instances of the class <code>sh:Shape</code>
				<span class="todo">(or, depending on the outcome of the ISSUE above, <code>rdfs:Class</code>)</span>.
			</p>
			<section id="shape-labels">
				<h3>Shape Labels and Comments</h3>
				<p>
					Like many other types of RDF resources, shapes SHOULD have human-readable labels via <code>rdfs:label</code>.
					The property <code>rdfs:comment</code> is recommended for documentation and definition purposes.
				</p>
			</section>
			<section id="shape-specialization">
				<h3>Shape Specialization Mechanism</h3>
				<p>
					Shape declarations can specialize other shapes.
					If a (sub) shape is declared to specialize another (super) shape then all constraints
					attached to the super-shape must also apply to the sub-shape.
					In other words, the set of nodes that match a sub-shape is a sub-set of those that
					match a super-shape.
				</p>
				<p class="todo">
					In the currently discussed proposals, the property <code>sh:extends</code> would be used
					for instances of <code>sh:Shape</code> assuming <code>sh:Shape</code> is not declared to be a
					subclass or superclass of <code>rdfs:Class</code>.
					In all other cases, the property <code>rdfs:subClassOf</code> would be used to link
					a sub-shape with its super-shape(s).
				</p>
				<p class="issue" title="RDFS Entailment">
					There is no agreement in the WG about the role of RDFS entailment.
					RDFS entailment would potentially serve as an alternative to rdfs:subClassOf.
					However, making RDFS entailment mandatory may exclude too many systems and have other drawbacks.
				</p>
			</section>
			<section id="shape-constraints">
				<h3>Shape Constraints</h3>
				<p>
					A shape can be regarded as a collection of local constraints on a <span class="term">focus node</span>.
					These constraints can be grouped into three categories that are covered by subsequent sections.
				</p>
				<ul>
					<li>
						<a href="#property-constraints">Property Constraints</a> specify characteristics of a given property in the context of the Shape.
						The properties <code>sh:property</code> and <code>sh:inverseProperty</code> are used to link a Shape with its property constraints.
					</li>
					<li>
						<a href="#or">Disjunctive Constraints</a> can be used to define two or more alternative restrictions.
					</li>
					<li>
						For complex use cases that cannot be handled by the SHACL Core Profile,
						<a href="#general-constraints">General Constraints</a> may define constraints that are not related to only a single property.
						The property <code>sh:constraint</code> is used to link a Shape with its general constraints.
					</li>
				</ul>
				<p>
					Orthogonal to these constraint types, SHACL has a notion of <a href="#scope">Scopes</a> that can be used to define pre-conditions
					that must hold before a constraint is applied to a given <span class="term">focus node</span>.
				</p>
			</section>
		</section>
		
		<section id="property-constraints">
			<h2>Property Constraints</h2>
			<p>
				In many cases, the constraints attached to a shape can be attributed to a given property of the focus nodes.
				Depending on the direction of triple traversal, SHACL defines two properties to associate a shape with such property-related constraints:
			</p>
			<ul>
				<li><a href="#property-constraints-property"><code>sh:property</code></a> is used to link a shape with property constraints (on the objects of triples)</li>
				<li><a href="#property-constraints-inverseProperty"><code>sh:inverseProperty</code></a> is used to link a shape with inverse property constraints (on the subjects of triples)</li>
			</ul>
			<p>
				The following sections describe the role of each of these properties in detail.
				Note that this section only includes textual definitions of the semantics of those properties.
				An alternative formal definition based on SPARQL is provided in an <a href="#sparql-template-defs">Appendix</a>.
				<span class="todo">Additional formal definitions of the upcoming core templates may be published in separate deliverables.</span> 
			</p>

			<section id="property-constraints-property">
				<h3>Property Constraints (sh:property)</h3>
				<p>
					A <span class="term">property constraint</span> is a constraint that defines restrictions on the values of a given property in the context of the focus node.
					Here, the focus node is the <span class="term">subject</span> and the property is the <span class="term">predicate</span> of relevant triples.
					The property <code>sh:property</code> can be used to link a shape with its property constraints.
				</p>
				<p>
					In the SHACL RDF vocabulary, property constraints are instances of the class <code>sh:PropertyConstraint</code>.
					When used as values of <code>sh:property</code>, property constraints represented as blank nodes do not require an <code>rdf:type</code> triple.
					Note that <code>sh:property</code> may also have values that are sub-classes of <code>sh:PropertyConstraint</code>,
					but in this case the <code>rdf:type</code> triple is required.
					It is not valid to use <code>sh:property</code> for constraints that are not instance of <code>sh:PropertyConstraint</code>.
				</p>
				<p> 
					The following examples illustrate two ways of using property constraints.
					The first example uses a blank node:
				</p>
				<pre class="example" title="Property constraint represented by a blank node">
ex:InlinePropertyConstraintExampleShape
	a sh:Shape ;
	sh:property [
		sh:predicate ex:someProperty ;
		sh:minCount 1 ;
		sh:valueType ex:SomeClass ;
		rdfs:label "some property" ;
		rdfs:comment "Description of the role of ex:someProperty (in the context of the constraint)" ;
	] .</pre>
				<p>
					The second example defines a constraint as an IRI node, allowing it to be more easily referenced and shared across multiple shapes:
				</p>
				<pre class="example" title="Property constraint represented by a IRI">
ex:StandAlonePropertyConstraintExampleShape
	a sh:Shape ;
	sh:property ex:StandAloneConstraint .

ex:StandAloneConstraint
	a sh:PropertyConstraint ;
	sh:predicate ex:someProperty ;
	sh:defaultValue ex:SomeInstance ;
	sh:minCount 1 ;
	sh:valueType ex:SomeClass .</pre>
				<p>
					Property constraints may have an <code>rdfs:label</code> to provide a human-readable label for the property	in the context where it appears.
					If present, tools SHOULD prefer those locally defined labels over globally defined labels at the <code>rdf:Property</code> itself.
					Similarly, property constraints may have an <code>rdfs:comment</code> to provide a description of the property in the given context.
					Both <code>rdfs:label</code> and <code>rdfs:comment</code> may have multiple values, but SHOULD only have one value per language tag.
				</p>
				<p id="defaultValue">
					Property constraints 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:valueType</code> of the same constraint.
				</p>
				<p>
					The following sections provide details on the facet properties that may be used with <code>sh:PropertyConstraint</code>.
					Note that the textual definitions of those facets refers to the <a href="#violations">Constraint Violations Vocabulary</a>
					introduced in a later section.
				</p>
				<table class="term-table" border="1" cellpadding="5">
					<tr>
						<th>Facet&nbsp;Properties</th>
						<th>Summary</th>
					</tr>
					<tr>
						<td><a href="#AbstractAllowedValuesPropertyConstraint"><code>sh:allowedValues</code></a></td>
						<td>Enumeration of allowed values</td>
					</tr>
					<tr>
						<td><a href="#AbstractHasValuePropertyConstraint"><code>sh:hasValue</code></a></td>
						<td>A specific required value</td>
					</tr>
					<tr>
						<td><a href="#AbstractCountPropertyConstraint"><code>sh:minCount</code>, <code>sh:maxCount</code></a></td>
						<td>Minimum and maximum cardinality</td>
					</tr>
					<tr>
						<td><a href="#AbstractNodeTypePropertyConstraint"><code>sh:nodeType</code></a></td>
						<td>Node type (IRI, blank node, or literal) of all values</td>
					</tr>
					<tr>
						<td><a href="#AbstractValueShapePropertyConstraint"><code>sh:valueShape</code></a></td>
						<td>Nested shape of all values</td>
					</tr>
					<tr>
						<td><a href="#AbstractValueTypePropertyConstraint"><code>sh:valueType</code></a></td>
						<td>Type and datatype of all values</td>
					</tr>
				</table>
				<p class="todo">
					There appears to be a good chance that SHACL will also include the following datatype property constraints similar to their XSD counterparts.
				</p>
				<table class="term-table" border="1" cellpadding="5">
					<tr>
						<th>Facet&nbsp;Properties</th>
						<th>Summary</th>
					</tr>
					<tr>
						<td><a href="#AbstractMaxExclusivePropertyConstraint"><code>sh:maxExclusive</code></a></td>
						<td>Maximum exclusive value (&lt;)</td>
					</tr>
					<tr>
						<td><a href="#AbstractMaxInclusivePropertyConstraint"><code>sh:maxInclusive</code></a></td>
						<td>Maximum inclusive value (&lt;=)</td>
					</tr>
					<tr>
						<td><a href="#AbstractMinExclusivePropertyConstraint"><code>sh:minExclusive</code></a></td>
						<td>Minimum exclusive value (&gt;)</td>
					</tr>
					<tr>
						<td><a href="#AbstractMinInclusivePropertyConstraint"><code>sh:minInclusive</code></a></td>
						<td>Minimum inclusive value (&gt;=)</td>
					</tr>
					<tr>
						<td><a href="#AbstractLengthPropertyConstraint"><code>sh:length</code></a></td>
						<td>Exact string length</td>
					</tr>
					<tr>
						<td><a href="#AbstractMaxLengthPropertyConstraint"><code>sh:maxLength</code></a></td>
						<td>Maximum string length</td>
					</tr>
					<tr>
						<td><a href="#AbstractMinLengthPropertyConstraint"><code>sh:minLength</code></a></td>
						<td>Minimum string length</td>
					</tr>
					<tr>
						<td><a href="#AbstractPatternPropertyConstraint"><code>sh:pattern</code></a></td>
						<td>Regular expression string matching</td>
					</tr>
				</table>
				<p class="todo">
					Potential other datatype facets to include are whiteSpace, fractionDigits and totalDigits (from XSD) or stepValue from schema.org.
				</p>
				<section id="AbstractAllowedValuesPropertyConstraint">
					<h4>sh:allowedValues</h4>
					<p>
						The property <code>sh:allowedValues</code> can be used to specify that all values of the given predicate
						at the <span class="term">focus node</span> must be members of a given set of allowed values.
						The set of allowed values is assumed to be an exhaustive enumeration of all possible values.
					</p>
					<table class="term-table" border="1" cellpadding="5">
						<tr>
							<th>Facet&nbsp;Property</th>
							<th>Value Type</th>
							<th>Summary</th>
						</tr>
						<tr>
							<td><code>sh:allowedValues</code></td>
							<td><code>sh:Set</code></td>
							<td>Enumeration of allowed values</td>
						</tr>
					</table>
					<div id="def-allowedValues-text" class="def def-text">
						<div class="def-header">TEXTUAL DEFINITION</div>
						<div class="def-text-body">
							The values of <code>sh:allowedValues</code> must be instances of <code>sh:Set</code>, with its values of
							<code>sh:member</code> pointing at the nodes in the <code>sh:Set</code>.
							An <code>sh:Error</code> must be reported for every triple that has the <span class="term">focus node</span> as its subject,
							the <code>sh:predicate</code> as its predicate and an object that is not a member of the given set.
							Matching of literals needs to be exact, e.g. <code>"04"^^xsd:byte</code> does not match <code>"4"^^xsd:integer</code>.
							Each produced <code>sh:Error</code> must have the <span class="term">focus node</span> as its <code>sh:root</code>, the <code>sh:predicate</code>
							as its <code>sh:path</code> and the respective invalid value as its <code>sh:value</code>.
						</div>
					</div>
					<p>See also: <a href="#sparql-AbstractAllowedValuesPropertyConstraint">Definition in SPARQL</a>.</p>
					<pre class="example" title="Shape with sh:allowedValues constraint">
ex:AllowedValuesExampleShape
	a sh:Shape ;
	sh:property [
		sh:predicate ex:someProperty ;
		sh:allowedValues ex:AllowedValuesExampleSet ;
	] .

ex:AllowedValuesExampleSet
	a sh:Set ;
	sh:member ex:Value1 ;
	sh:member ex:Value2 ;
	sh:member ex:Value3 .

ex:AllowedValuesExampleValidResource
	ex:property ex:Value2 .</pre>
					<p class="todo">
						TODO: Some examples should also include the validation results.
					</p>
					<p class="issue" title="sh:allowedValue">
						It is not yet decided whether the language should also support <code>sh:allowedValue</code>
						that would point directly to the enumerated values instead of having an intermediate sh:Set.
						The downsides of having both is that it adds extra complexity to algorithm for something that feels redundant,
						and that it is not yet clear how the execution of template arguments with multiple values should work.
						If we allowed rdf:List, then the Turtle/JSON-LD syntax may look good yet a sh:Set is more extensible. 
					</p>
				</section>
				<section id="AbstractHasValuePropertyConstraint">
					<h4>sh:hasValue</h4>
					<p>
						The property <code>sh:hasValue</code> can be used to verify
						that the <span class="term">focus node</span> has a given RDF node among the values of the given
						predicate.
					</p>
					<table class="term-table" border="1" cellpadding="5">
						<tr>
							<th>Facet&nbsp;Property</th>
							<th>Value Type</th>
							<th>Summary</th>
						</tr>
						<tr>
							<td><code>sh:hasValue</code></td>
							<td>any</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">
							An <code>sh:Error</code> must be reported if there is no triple that has
							the <span class="term">focus node</span> as its subject, the <code>sh:predicate</code>
							as its predicate and the <code>sh:hasValue</code> as its object.
						</div>
					</div>
					<p>See also: <a href="#sparql-AbstractHasValuePropertyConstraint">Definition in SPARQL</a>.</p>
					<pre class="example" title="Shape with sh:hasValue constraint">
ex:HasValueExampleShape
	a sh:Shape ;
	sh:property [
		sh:predicate ex:property ;
		sh:hasValue ex:Green ;
	] .

ex:HasValueExampleValidResource
	ex:property ex:Green .</pre>
				</section>
				<section id="AbstractCountPropertyConstraint">
					<h4>sh:minCount, sh:maxCount</h4>
					<p>
						The properties <code>sh:minCount</code> and <code>sh:maxCount</code>
						restrict the number of values of the given property at the <span class="term">focus node</span>.
					</p>
					<table class="term-table" border="1" cellpadding="5">
						<tr>
							<th>Facet&nbsp;Property</th>
							<th>Value Type</th>
							<th>Summary</th>
						</tr>
						<tr>
							<td><code>sh:minCount</code></td>
							<td><code>xsd:integer</code></td>
							<td>The minimum number of values. Optional. Default value is 0.</td>
						</tr>
						<tr>
							<td><code>sh:maxCount</code></td>
							<td><code>xsd:integer</code></td>
							<td>The maximum number of values. Optional. Default interpretation is unlimited.</td>
						</tr>
					</table>
					<div id="def-count-text" class="def def-text">
						<div class="def-header">TEXTUAL DEFINITION</div>
						<div class="def-text-body">
							Both <code>sh:minCount</code> and <code>sh:maxCount</code> are optional.
							The default value of <code>sh:minCount</code> is 0.
							Let <code>?count</code> be the number of triples that have the <span class="term">focus node</span> as
							subject and the <code>sh:predicate</code> as the predicate.
							An <code>sh:Error</code> must be reported in either of the following cases:
							If <code>?count</code> is less than the value of <code>sh:minCount</code>, or
							if <code>sh:maxCount</code> is present and <code>?count</code> is greater than the value of <code>sh:maxCount</code>.
							The resulting <code>sh:Error</code> must have the <span class="term">focus node</span> as <code>sh:root</code>
							and the predicate as its <code>sh:path</code>. 
						</div>
					</div>
					<p>See also: <a href="#sparql-AbstractCountPropertyConstraint">Definition in SPARQL</a>.</p>
					<pre class="example" title="Shape with sh:minCount and sh:maxCount constraints">
ex:CountExampleShape
	a sh:Shape ;
	sh:property [
		sh:predicate ex:someProperty ;
		sh:minCount 1 ;
		sh:maxCount 1 ;
	] .

ex:CountExampleValidResource
	ex:someProperty ex:OneValue .</pre>
				</section>
				<section id="AbstractNodeTypePropertyConstraint">
					<h4>sh:nodeType</h4>
					<p>
						The property <code>sh:nodeType</code> can be used to restrict the RDF node type of all values of the given property.
					</p>
					<table class="term-table" border="1" cellpadding="5">
						<tr>
							<th>Facet&nbsp;Property</th>
							<th>Value Type</th>
							<th>Summary</th>
						</tr>
						<tr>
							<td><code>sh:nodeType</code></td>
							<td><code>sh:NodeType</code></td>
							<td>Node type (IRI, blank node, or literal) of all values</td>
						</tr>
					</table>
					<p>
						The values of <code>sh:nodeType</code> must be instances of the class <code>sh:NodeType</code>.
						The SHACL system vocabulary defines that <code>sh:NodeType</code> has exactly 7 instances,
						as defined in the <a href="#function-hasNodeType">Appendix</a>.
					</p>
					<p class="todo">
						Dimitris suggests we only support sh:IRI, sh:Literal and sh:BlankNode and use some generic OR mechanism to combine them.
					</p>
					<div id="def-nodeType-text" class="def def-text">
						<div class="def-header">TEXTUAL DEFINITION</div>
						<div class="def-text-body">
							An <code>sh:Error</code> must be reported for each triple that has
							the <span class="term">focus node</span> as its subject, the <code>sh:predicate</code>
							as its predicate and where the object does not match the node type tests
							defined in the table above.
							Each produced <code>sh:Error</code> must have the <code>sh:predicate</code>
							as its <code>sh:path</code> and the respective violating value as its <code>sh:value</code>.
						</div>
					</div>
					<p>See also: <a href="#sparql-AbstractNodeTypePropertyConstraint">Definition in SPARQL</a>.</p>
					<pre class="example" title="Shape with sh:nodeType constraint">
ex:NodeTypeExampleShape
	a sh:Shape ;
	sh:property [
		sh:predicate ex:someProperty ;
		sh:nodeType ex:IRI ;
	] .

ex:NodeTypeShapeExampleValidResource
	ex:someProperty ex:SomeIRI .

ex:NodeTypeShapeExampleInvalidResource
	ex:someProperty ex:SomeIRI ;
	ex:someProperty "A literal" .</pre>
				</section>
				<section id="AbstractValueShapePropertyConstraint">
					<h4>sh:valueShape</h4>
					<p>
						The property <code>sh:valueShape</code> can be used verify that all values of the given property must match a given shape.
						The value type of <code>sh:valueShape</code> is <code>sh:Shape</code><span class="todo"> (and/or <code>rdfs:Class</code>)</span>.
						If the value shapes are blank nodes, then their <code>rdf:type</code> triple can be omitted.
					</p>
					<table class="term-table" border="1" cellpadding="5">
						<tr>
							<th>Facet&nbsp;Property</th>
							<th>Value Type</th>
							<th>Summary</th>
						</tr>
						<tr>
							<td><code>sh:valueShape</code></td>
							<td><code>sh:Shape</code></td>
							<td>The required shape of all values</td>
						</tr>
					</table>
					<div id="def-valueShape-text" class="def def-text">
						<div class="def-header">TEXTUAL DEFINITION</div>
						<div class="def-text-body">
							An <code>sh:Error</code> must be reported for each triple that has
							the <span class="term">focus node</span> as its subject, the <code>sh:predicate</code>
							as its predicate and where the object does not match the shape specified by <code>sh:valueShape</code>.
							Each produced <code>sh:Error</code> must have the <code>sh:predicate</code>
							as its <code>sh:path</code> and the respective violating value as its <code>sh:value</code>.
						</div>
					</div>
					<p>See also: <a href="#sparql-AbstractValueShapePropertyConstraint">Definition in SPARQL</a>.</p>
					<p class="issue" title="Recursion of sh:valueShape">
						It is not yet decided how to handle recursive shape definitions in sh:valueShape.
					</p>
					<p>
						In the following example, all values of the property <code>ex:someProperty</code> are supposed to match the	shape
						specified by a blank node that ensures that the property <code>ex:nestedProperty</code> has at least one value.
						Note that the values of <code>sh:valueShape</code> do not require an <code>rdf:type</code> triple - <code>sh:Shape</code> is implicit.
					</p>
					<pre class="example" title="Shape with sh:valueShape constraint">
ex:ValueShapeExampleShape
	a sh:Shape ;
	sh:property [
		sh:predicate ex:someProperty ;
		sh:valueShape [
			a sh:Shape ;   # Optional
			sh:predicate [
				sh:predicate ex:nestedProperty ;
				sh:minCount 1 ;
			]
		]
	] .

ex:ValueShapeExampleValidResource
	ex:someProperty [
		ex:nestedProperty 42 ;
	] .</pre>
				</section>
				<section id="AbstractValueTypePropertyConstraint">
					<h4>sh:valueType</h4>
					<p class="issue" title="sh:valueType">
						The details of valueType validation need to be fully worked out.
						In a nutshell, the goal is to have one or two properties to narrow down the type of values.
						The user experience may be best if there was just one property, sh:valueType.
						However, there are substantial differences between datatypes and class-based types.
						For datatypes, we should exclude reified values such as instances of xsd:integer.
						For resources, we need to make sure that (transitive) subclasses are accepted too.
						What about typeless resources - I believe these should be allowed if the valueType is rdfs:Resource or rdf:Property.
						Another question will be whether multiple valueTypes should be supported, and what their semantics should be.
						For now we only include an example of sh:valueType, to illustrate a possible design.
					</p>
				</section>
				<pre class="example" title="Shape with sh:valueType constraint">
ex:ValueTypeExampleShape
	a sh:Shape ;
	sh:property [
		sh:predicate ex:someProperty ;
		sh:valueType xsd:string ;
	] .

ex:ValueTypeExampleValidResource
	ex:someProperty "A string" .</pre>
			</section>
			
			<section id="property-constraints-inverseProperty">
				<h3>Inverse Property Constraints (sh:inverseProperty)</h3>
				<p class="todo">
					TODO: This section is quite similar to the one about sh:property, only in the inverse direction.
					Before writing all this down, we'd rather wait until the forward direction has stabilized.
					A quick example should suffice for now:
				</p>
				<pre class="example" title="Shape with an inverse property constraint">
ex:InversePropertyConstraintExampleShape
	a sh:Shape ;
	sh:inverseProperty [
		sh:predicate ex:someProperty ;  # e.g. "child"
		sh:minCount 1 ;
		rdfs:label "is someProperty of" ;  # e.g. "parent"
	] .</pre>
				<p class="todo">
					TODO: Possibly use <code>sh:inversePredicate</code> instead of <code>sh:predicate</code>.
				</p>
			</section>
		</section>
		
		<section id="or">
			<h2>Disjunctive Constraints (sh:OrConstraint)</h2>
			<p class="issue">
				The WG has not decided whether Or (and similar operands such as Not) will be part of the high-level vocabulary, or whether they will be limited to executable languages such as SPARQL.
			</p>
			<p class="todo">
				TODO: The proposal here is just one possible syntax, based on a template.
				Other alternatives include to hard-code it into a new kind of Shape with its own syntax
				as outlined in Eric's version of the primer.
			</p>
			<p>
				SHACL supports a high-level syntax for disjunctive local constraints that can be used to test whether the <span class="term">focus node</span> matches at least one out of several shapes.
				This is comparable to a logical "or" operator.
			</p>
			<div id="def-orConstraint-text" class="def def-text">
				<div class="def-header">TEXTUAL DEFINITION</div>
				<div class="def-text-body">
					An <code>sh:Error</code> must be reported if the <span class="term">focus node</span> produces error-level
					constraint violations against both shapes <code>sh:shape1</code> and <code>sh:shape2</code>. 
				</div>
			</div>
			<p>See also: <a href="#sparql-or">Definition in SPARQL</a>.</p>
			<p>
				The following example illustrates the use of <code>sh:OrConstraint</code> in a shape to verify
				that matching nodes have at least one value of <code>ex:exampleProperty1</code>
				or at least one value of <code>ex:exampleProperty2</code>.
			</p>
			<pre class="example" title="Shape with a disjunction">
ex:OrConstraintExampleShape
	a sh:Shape ;
	sh:constraint [
		a sh:OrConstraint ;
		sh:shape1 [
			sh:property [
				sh:predicate ex:exampleProperty1 ;
				sh:minCount 1 ;
			] ;
		] ;
		sh:shape2 [
			sh:property [
				sh:predicate ex:exampleProperty2 ;
				sh:minCount 1 ;
			]
		]
	] .
	
ex:OrConstraintExampleValidResource
	sh:exampleProperty1 ex:someValue .</pre>
		</section>
			
		<section id="scope">
			<h2>Scope of Constraints (sh:scope)</h2>
			<p class="todo">
				This feature has been proposed but is not an accepted requirement and is fully not worked out yet.
				Here is just one possible design, as a placeholder, for now.
			</p>
			<p>
				Local constraints may have a property <code>sh:scope</code> to declare a <span class="term">scope</span> that serves as a <span class="term">pre-condition</span>
				to narrow down when the constraint applies.	The values of <code>sh:scope</code> must be shape definitions.
				These shapes must be evaluated before the constraint is evaluated.
				If the scope shape returns an error-level constraint violation, then the constraint will be ignored.
				Values of <code>sh:scope</code> that are blank nodes do not require an <code>rdf:type</code> triple - the default type is <code>sh:Shape</code>.
			</p>
			<p>
				The following example states that the <code>sh:minCount</code> constraint only applies to resources that have a certain value for <code>ex:requiredProperty</code>. 
			</p>
			<pre class="example" title="Scoped constraint">
ex:ScopedExampleShape
	a sh:Shape ;
	sh:property [
		sh:predicate ex:someProperty ;
		sh:minCount 1 ;
		sh:scope [
			a sh:Shape ; # Optional triple
			sh:property [
				sh:predicate ex:requiredProperty ;
				sh:hasValue ex:requiredValue ;
			]
		] ;
	] .

ex:ScopedShapeValidExampleInstance
	ex:someProperty ex:someValue ;
	ex:requiredProperty ex:requiredValue .</pre>
		</section>
		
		<section id="violations">
			<h2>Constraint Violations Vocabulary</h2>
			<p>
				The output of a SHACL constraint validation operation is a set of <span class="term">constraint violations</span>.
				SHACL includes an RDF vocabulary to represent such constraint violations together with
				structural information that may provide guidance on how to fix the violation, as well as
				human-readable messages.
			</p>
			<p>
				The following code snippet represents a valid constraint violation that may have been produced
				by a constraint validation engine:
			</p>
			<pre class="example" title="A constructed constraint violation">
ex:ExampleConstraintViolation
	a sh:Error ;
	sh:root ex:MyCurrentNode ;
	sh:path ex:someProperty ;
	sh:value ex:someInvalidValue ;
	sh:message "Incorrect value: expected something else here." .</pre>
			<section id="violations-types">
				<h3>Types of Constraint Violations</h3>
				<p>
					A constraint violation is represented by a IRI or blank node that has exactly one
					asserted <code>rdf:type</code>.
					The <code>rdf:type</code> arc of a constraint violation must point to one of the subclasses
					of the ("abstract") base class <code>sh:ConstraintViolation</code>.
					The SHACL system vocabulary includes the following constraint violation types: 
				</p>
				<table class="term-table" border="1" cellpadding="5">
					<tr>
						<th>Constraint&nbsp;Violation&nbsp;Class</th>
						<th>Superclass</th>
						<th>Description</th>
					</tr>
					<tr>
						<td><code>sh:Warning</code></td>
						<td><code>sh:ConstraintViolation</code></td>
						<td>A non-critical constraint violation indicating a warning.</td>
					</tr>
					<tr>
						<td><code>sh:Error</code></td>
						<td><code>sh:ConstraintViolation</code></td>
						<td>A constraint violation indicating an error.</td>
					</tr>
					<tr>
						<td><code>sh:FatalError</code></td>
						<td><code>sh:Error</code></td>
						<td>
							An error that cannot be recovered and further evaluation may terminate immediately.
							Engines may decide to validate potentially fatal constraints first.
						</td>
					</tr>
				</table>
				<p class="todo">
					<code>sh:Info</code> has also been suggested, but this would work best if there was a deterministic mechanism to identify
					constraints that need to be validated, so that Info constraints can be bypassed.
					Related to this, Dimitris also suggested we introduce <code>sh:ValidationResult</code> as a superclass of <code>sh:ConstraintViolation</code>.
				</p>
				<p>
					SHACL extensions may define additional violation types, as long as they are rooted in
					<code>sh:ConstraintViolation</code>.
					The <code>rdfs:subClassOf</code> relationship between these types indicates specialization,
					e.g. <code>sh:FatalError</code> is a subclass of <code>sh:Error</code> meaning that every
					fatal error should also be regarded as an error.
				</p>
				<p class="todo">
					TODO: There is an ongoing <a href="https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Mar/0011.html">proposal</a> to use these severity levels at engine control time.
				</p>
			</section>
			<section id="violations-structure">
				<h3>Structural Violation Metadata</h3>
				<p>
					SHACL constraint violations may include machine-readable metadata that points at
					the cause of the violation.
				</p>
				<section id="violations-structure-root">
					<h4>sh:root</h4>
					<p>
						Constraint violations may have a single value for the property <code>sh:root</code> to point to an
						IRI or blank node that has caused the violation.
					</p>
				</section>
				<section id="violations-structure-path">
					<h4>sh:path</h4>
					<p>
						Constraint violations may have one or more values for the property <code>sh:path</code>
						that describes a <em>path expression</em> that can be walked starting at the <code>sh:root</code>.
						If the value of this property is a IRI, then the path produces all triples that have the root node as
						subject and the value as its predicate.
						If the value of <code>sh:path</code> is a blank node, then it must have properties that
						match either one of the following options: 
					</p>
					<ul>
						<li>
							<code>sh:inverse</code> describes an inverse path consisting of all paths that start
							at the current root node and walk the given predicate backwards, i.e. from object to subject.
							The values of <code>sh:inverse</code> must be the IRIs of properties.
							Blank nodes with <code>sh:inverse</code> may have the optional type <code>sh:InversePath</code>.
						</li>
						<li>
							<code>sh:path1</code> and <code>sh:path2</code> describe a sequence path consisting of
							two other paths.  The values of these properties must be property IRIs or blank nodes
							of the same recursive path structure.  The path produces the concatenation of the two sub-paths.
							The values of <code>sh:path1</code> must either be IRIs or blank nodes with a value for <code>sh:inverse</code>,
							which means that only the second path segment may be another sequence path. 
							Blank nodes with <code>sh:path1</code> and <code>sh:path2</code> may have the optional type <code>sh:SequencePath</code>.
						</li>
					</ul>
					<p>
						The following example describes a path equivalent to the SPARQL 1.1 Property Path [[sparql11-query]]
						<code>ex:firstProperty/((^ex:inverseProperty)/ex:lastProperty)</code>
					</p>
					<pre class="example" title="Constraint violation with path expression">
ex:ExampleConstraintViolationWithPath
	a sh:Error ;
	sh:root ex:MyCurrentNode ;
	sh:path [
		sh:path1 ex:firstProperty ;
		sh:path2 [
			ex:path1 [ sh:inverse ex:inverseProperty ] ;
			ex:path2 ex:lastProperty
		]
	] .</pre>
					<p class="todo">
						Open discussion: Dimitris suggested that we may want to allow path expressions as xsd:strings too,
						and rdf:Lists for sequence paths.
					</p>
				</section>
				<section id="violations-structure-value">
					<h4>sh:value</h4>
					<p>
						Constraint violations may have one or more values of the property <code>sh:value</code> to
						point at specific nodes that caused the violation.
						These nodes SHOULD be accessible via at least one <code>sh:path</code> starting at the
						specific <code>sh:root</code> node.
					</p>
				</section>
				<section id="violations-structure-source">
					<h4>sh:source</h4>
					<p>
						Constraint violations may point at one <code>sh:Constraint</code> that has caused
						the violation, specified via the property <code>sh:source</code>.
						SHACL constraint validation engines SHOULD automatically insert the <code>sh:source</code>
						based on the currently evaluated constraint, unless the constraint violation already has
						such a value.
					</p>
				</section>
				<section id="violations-structure-detail">
					<h4>sh:detail</h4>
					<p>
						The property <code>sh:detail</code> may link a (parent) constraint violation with one or more other
						(child) constraint violations that provide further details about the cause of the (parent) violation.
						Depending on the capabilities of the constraint validation engine, this may include failures of
						nested constraints that have been evaluated via <code>sh:valueShape</code>.
					</p>
				</section>
			</section>
			<section id="violations-message">
				<h3>Human-readable Violation Messages (sh:message)</h3>
				<p>
					Constraint violations may have values for the property <code>sh:message</code> to communicate
					additional textual details to humans.
					While <code>sh:message</code> may have multiple values, there SHOULD not be two values
					with the same language tag.
				</p>
				<p class="todo">
					TODO: The standard will likely make it possible to derive the values of <code>sh:message</code> from string templates,
					as discussed in this thread: <a href="https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Mar/0249.html"></a>. 
				</p>
			</section>
		</section>
		
		<section id="general-constraints">
			<h2>General Shape Constraints (sh:constraint)</h2>
			<p>
				Note that the subsequent sections cover features of SHACL that go beyond the <span class="term">SHACL Core Profile</span>.
			</p>
			<p>
				The property <code>sh:constraint</code> provides the most general mechanism to associate a constraint with a shape.
				The values of this property must be <span class="term">local constraints</span>, i.e. they MUST reference a
				<span class="term">focus node</span>.
				Note that the property <code>sh:property</code> SHOULD be used instead of <code>sh:constraint</code> if the constraint is a <code>sh:PropertyConstraint</code>.
				The property <code>sh:inverseProperty</code> SHOULD be used instead of <code>sh:constraint</code> if the constraint is a <code>sh:InversePropertyConstraint</code>.
			</p>
			<p>
				SHACL supports two types of general shape constraints:
			</p>
			<ul>
				<li>General shape constraints based on a high-level vocabulary (template)</li>
				<li>General shape constraints based on a native executable (such as a SPARQL query)</li>
			</ul>
			<p>
				The following example assumes that there is a high-level template called <code>myt:DisjointPropertiesConstraint</code> that takes two arguments
				<code>myt:property1</code> and <code>myt:property2</code>.
				The intent of that example is to state that the values of the properties <code>ex:father</code> and <code>ex:mother</code> must be disjoint.
			</p>
			<pre class="example">
@prefix myt: &lt;http://example.org/myTemplates#&gt; .

ex:GeneralTemplateConstraintExampleShape
	a sh:Shape ;
	sh:constraint [
		a myt:DisjointPropertiesConstraint ;
		myt:property1 ex:father ;
		myt:property2 ex:mother ;
	] .</pre>
			<p>
				The following example illustrates the definition of a <span class="term">local constraint</span> based on a SPARQL query.
				The property <code>sh:sparql</code> is used to point at a SELECT query as explained in a later <a href="#sparql-constraints">section</a>.
				Note that the variable <code>?this</code> is used to reference the <span class="term">focus node</span>.
			</p>
			<pre class="example">
ex:GeneralSPARQLConstraintExampleShape
	a sh:Shape ;
	sh:constraint [
		sh:message "The value of property2 cannot be smaller than the value of property1." ;
		sh:sparql """
			SELECT (?this AS ?root)
			WHERE {
				?this ex:property1 ?value1 .
				?this ex:property2 ?value2 .
				FILTER (?value2 &lt; ?value1) .
			}
			""" ;
	] .</pre>
			<p>
				In the example above, SPARQL is provided as the only native executable.
				However, additional executables such as JavaScript may be provided based on other sets of properties like <code>ex:javaScript</code>.
			</p>
		</section>
		
		<section id="templates">
			<h2>Templates</h2>
			<p>
				Templates can be used to encapsulate and parameterize <span class="term">executable bodies</span> based on arguments.
				Templates can be instantiated anywhere where a native constraint may appear (for example, at <code>sh:constraint</code>).
				SHACL includes several templates that were deemed to be of general use, including the <a href="#shapeconstraints-property">property constraint templates</a>.
				Such templates form a high-level vocabulary that may be directly interpreted ("hard-coded") without reliance on their executable bodies.
			</p>
			<p>
				Constraint templates are represented as IRI nodes that are instances of the class <code>sh:ConstraintTemplate</code>.
				SHACL also includes a more general superclass <code>sh:Template</code> that may be used for other kinds of templates (rules, stored queries etc).
				Well-defined, non-abstract templates MUST provide at least one executable body property using <a href="#sparql-templates"><code>sh:sparql</code></a>.
				The following example illustrates the definition of a local constraint template based on a SPARQL query.
			</p>
			<pre class="example" title="Constraint template based on SPARQL">
ex:ExampleTemplate
	a sh:ConstraintTemplate ;
	rdfs:label "Example Template" ;
	rdfs:comment "Verifies that the given focus node (?this) has at least one value for the argument property (?argProperty)." ;
	sh:argument [
		sh:predicate ex:argProperty ;
		sh:valueType rdf:Property ;
	] ;
	sh:labelTemplate "The property {?argProperty} must have at least one value" ;
	sh:sparql """
		SELECT (?this AS ?root) (?argProperty AS ?path) 
		WHERE {
			FILTER NOT EXISTS { ?this ?argProperty ?anyValue }
		}
		""" .</pre>
			<p>
				The following sections introduce details of the properties that such templates may have.
			</p>
			<section id="template-arguments">
				<h3>Template Arguments</h3>
				<p>
					The arguments of a template are attached via the property <code>sh:argument</code>.
					Each argument must be an instance of <code>sh:Argument</code>.
					The <code>rdf:type</code> triple of the argument can be omitted if it is a blank node with an incoming <code>sh:argument</code> triple.
				</p>
				<p>
					Each <code>sh:Argument</code> MUST have exactly one value for the property <code>sh:predicate</code>.
					The values of <code>sh:predicate</code> must be IRIs.
					<span id="def-local-name">The <span class="term">local name</span> of a IRI is defined as the longest <a href="http://www.w3.org/TR/REC-xml-names/#NT-NCName">NCNAME</a>
					at the end of the IRI, not immediately preceeded by the first colon in the IRI.</span>
					The local names of the values of <code>sh:predicate</code> must match the following conditions (to ensure a correct mapping from arguments into SPARQL variables is possible):
				</p>
				<ul>
					<li>The <span class="term">local name</span> must be a valid <a href="http://www.w3.org/TR/sparql11-query/#rVARNAME">SPARQL VARNAME</a></li>
					<li>There must not be any other declared <code>sh:Argument</code> for the same template (and its transitive superclasses) that has a <code>sh:predicate</code> with the same <span class="term">local name</span></li>
				</ul>
				<p>
					An <code>sh:Argument</code> may have its property <code>sh:optional</code> set to <code>true</code>
					to indicate that the argument is not mandatory.
				</p>
				<p>
					An <code>sh:Argument</code> may declare a default value via <code>sh:defaultValue</code>.
					For non-optional arguments, the engine must use the declared default value for template instances that do not define a value for this argument.
				</p>
				<p>
					An <code>sh:Argument</code> may declare one value for the property <code>sh:valueType</code>.
					This can be used to communicate the expected value type of the argument in template instances.
					Some implementations MAY use this information to prevent the execution of a template with invalid arguments, and to signal errors.
				</p>
			</section>
			<section id="template-labelTemplate">
				<h3>sh:labelTemplate</h3>
				<p>
					The property <code>sh:labelTemplate</code> can be used to suggest how instances of the template shall be rendered to humans.
					The <code>sh:labelTemplate</code> must be a string that can reference the arguments using the syntax <code>{?varName}</code>,
					where <code>?varName</code> is the name of the SPARQL variable that corresponds to the argument.
					In SPARQL-based systems, the function <a href="#function-label"><code>sh:label</code></a> may be used to expand those label templates into consumable strings.
				</p>
			</section>
		</section>

		<section id="profiles">
			<h2>Profiles</h2>
			<p>
				A Profile is a set of shape templates.
				Profiles can be used to define controlled sub-dialects of SHACL, e.g. with desirable complexity.
				Tools may decide to only support certain profiles, for example so that they can hard-code and optimize certain algorithms.
				Since Profiles are entirely based on templates, <span class="term">native constraints</span> such as those in SPARQL are outside of their expressivity.
			</p>
			<p>
				The class <code>sh:Profile</code> is used to represent SHACL profiles.
				The property <code>sh:member</code> links a <code>sh:Profile</code> with the templates that are in the profile.
				The following example defines a profile consisting of the two SHACL templates for min/max cardinality and value shape,
				as well as their shared superclass (which defines the <code>sh:predicate</code> property) and their shared subclass
				<code>sh:PropertyConstraint</code> that is directly instantiated.
			</p>
			<pre class="example" title="Simple SHACL Profile">
ex:MyProfile
	a sh:Profile ;
	sh:member sh:AbstractPropertyConstraint ;
	sh:member sh:AbstractCountPropertyConstraint ;
	sh:member sh:AbstractValueShapePropertyConstraint ;
	sh:member sh:PropertyConstraint .</pre>
			<p>
				In the example above, the profile includes only the properties from the enumerated template classes.
				Sibling template classes such as <code>sh:AbstractAllowedValuesPropertyConstraint</code> are outside of the profile,
				which means that <code>sh:allowedValues</code> would be out of scope for this profile.
			</p>
			<p>
				SHACL includes a profile called <code>sh:CoreProfile</code> that includes all <a href="#property-constraints">property constraint templates</a>
				as well as <a href="#or">disjunctive constraints</a>. 
			</p>
		</section>
		
		<section id="global-constraints">
			<h2>Global Constraints</h2>
			<p>
				While Shapes define constraints centered around <span class="term">focus nodes</span>, global constraints may define arbitrary graph-level restrictions.
				SHACL can represent two kinds of global constraints:
			</p>
			<ul>
				<li><a href="#global-constraints-native">Global native constraints</a></li>
				<li><a href="#global-constraints-template">Global template constraints</a></li>
			</ul>
			<section id="global-constraints-native">
				<h3>Global Native Constraints</h3>
				<p>
					Similar to <a href="#general-constraints">native general shape constraints</a>, native global constraints must have at least
					one <span class="term">executable body</span> that instructs execution engines how to compute constraint violations.
					The current version of SHACL only includes one such language, SPARQL, identified by the property <code>sh:sparql</code>.
					Details of the evaluation rules for SPARQL are defined in its corresponding <a href="#sparql-constraints">section</a>. 
				</p>
				<p>
					The following example illustrates the syntax for a global native constraint based on SPARQL.
				</p>
				<pre class="example" title="Global native constraint">
ex:ExampleGlobalSPARQLConstraint
	a sh:GlobalConstraint ;
	sh:message "There needs to be at least one instance of ex:SomeClass." ;
	sh:sparql """
		SELECT (ex:SomeClass AS ?root)
		WHERE {
			FILTER NOT EXISTS { ?any rdf:type ex:SomeClass } .
		}
		""" .</pre>
			</section>
			<section id="global-constraints-template">
				<h3>Global Template Constraints</h3>
				<p>
					Global constraints can be expressed as instances of the class <code>sh:ConstraintTemplate</code> that are also subclass of <code>sh:GlobalConstraint</code>.
					While this version of the SHACL vocabulary does not include any pre-defined global constraint templates, anyone can define and publish such templates with a given IRI.
				</p>
				<p>
					The following example illustrates the syntax for a global template constraint and the template that it instantiates.
					Note that the constraint does not need to have the explicit type <code>sh:GlobalConstraint</code>
					because it is an instance of the template <code>ex:ExampleGlobalConstraintTemplate</code> which
					is declared as a subclass of <code>sh:GlobalConstraint</code>.
				</p>
				<pre class="example" title="Global template constraint">
ex:ExampleGlobalTemplateConstraint
	a ex:ExampleGlobalConstraintTemplate ;
	ex:exampleArgument ex:SomeClass .
	
ex:ExampleGlobalConstraintTemplate
	a sh:ConstraintTemplate ;
	rdfs:subClassOf sh:GlobalConstraint ;
	sh:argument [
		sh:predicate ex:exampleArgument ;
		sh:valueType rdfs:Class ;
		rdfs:label "The class that needs to have at least one instance." ;
	] ;
	sh:message "There needs to be at least one instance of the given class" ;
	...</pre>
			</section>
		</section>

		<section id="operations">
			<h2>Supported Operations</h2>
			<p>
				This section enumerates the basic operations that complete SHACL engines SHOULD support.
				The specification does not prescribe how these operations are exposed to the user of a SHACL system.
				The following table provides an overview of the operations and how they depend on each other.
			</p>
			<table class="term-table" border="1" cellpadding="5">
				<tr>
					<th>Operation</th>
					<th>Depends&nbsp;On</th>
					<th>Description</th>
				</tr>
				<tr>
					<td><a href="#operation-validateConstraint"><code>validateConstraint</code></a></td>
					<td></td>
					<td>Validates a single constraint</td>
				</tr>
				<tr>
					<td><a href="#operation-validateNodeAgainstShape"><code>validateNodeAgainstShape</code></a></td>
					<td><code>validateConstraint</code></td>
					<td>Validates a given node against a given shape</td>
				</tr>
				<tr>
					<td><a href="#operation-validateNode"><code>validateNode</code></a></td>
					<td><code>validateNodeAgainstShape</code></td>
					<td>Validates a given node against the shapes derived from the graph</td>
				</tr>
				<tr>
					<td><a href="#operation-validateGraph"><code>validateGraph</code></a></td>
					<td><code>validateNode</code>, <code>validateConstraint</code></td>
					<td>Validates all nodes in a graph, including global constraints</td>
				</tr>
			</table>
			<p>
				All operations produce <span class="term">constraint violations</span>.
				For the sake of this specification, we assume that the constraint violations are represented as instances of
				<code>sh:ConstraintViolation</code>	that are added to a <span class="term">result graph</span> that is known
				to each operation for the duration of its execution.
				Actual implementations may use different data structures and result formats and input and output to these operations.
			</p>
			<p class="todo">
				All operations have an implicit argument, which is a data set with a default named graph.
				Details of this need to be fleshed out, pending design decisions on general graph management.
			</p>
		
			<section id="shape-selection">
				<h3>Shape Selection</h3>
				<p>
					Some operations on SHACL graphs, such as <a href="#operation-validateNode"><code>validateNode</code></a> and
					<a href="#operation-validateGraph"><code>validateGraph</code></a> rely on in-graph information to determine
					which nodes need to be evaluated against which shapes.
					This section describes the two currently supported <span class="term">shape selection</span> properties.
				</p>
				<div class="issue" title="Shape selection">
					There are multiple proposals on how to associate resources with their shapes, in particular
					based on rdf:type or sh:nodeShape.
					The WG may chose to:
					<ul>
						<li>Only support one of these patterns</li>
						<li>Always support both of these patterns</li>
						<li>Support both of these patterns, allowing them to be switched on or off individually</li>
						<li>Support a more general mechanism that allows arbitrary selectors</li>
					</ul>
					Also we need to agree on terminology, e.g. Shape Selection vs Shape Mapping
				</div>
				<section>
					<h4>Shape Selection based on rdf:type</h4>
					<p>
						RDF Schema and OWL provide a well-established framework to model domains in terms of classes and instances.
						A lot of existing data is already represented using these languages.
						In this <span class="term">shape selector</span>, the IRIs of classes double as shape definitions, i.e.
						it is possible to directly attach constraints at the IRI of a class.
						The property <code>rdf:type</code> is used to determine which shapes a given node needs to fulfill.
						Specialization between shapes is expressed via <code>rdfs:subClassOf</code>.
						This pattern is illustrated in the following example.
					</p>
					<pre class="example" title="Shape selection based on rdf:type">
ex:ExampleClass
	a rdfs:Class ;
	sh:constraint [
		...
	] .

ex:ExampleInstance
	rdf:type ex:ExampleClass .</pre>
				</section>
				<section>
					<h4>Shape Selection based on sh:nodeShape</h4>
					<p>
						In some application scenarios, there may be unwanted interactions between existing RDFS models and shapes.
						For example, an application may want to ensure that there is no interaction between shapes and RDFS/OWL inferencing.
						In those cases, users can declare shapes as instances of <code>sh:Shape</code> and use <code>sh:nodeShape</code>
						to point from a node to its shape(s).
						This pattern is illustrated in the following example. 				
					</p>
					<pre class="example" title="Shape selection based on sh:nodeShape">
ex:ExampleShape
	a sh:Shape ;
	sh:constraint [
		...
	] .

ex:ExampleInstance
	sh:nodeShape ex:ExampleShape .</pre>
				</section>
			</section>
			<section id="operation-validateConstraint">
				<h3>validateConstraint</h3>
				<p>
					This operation evaluates a single <span class="term">constraint</span> and produces <span class="term">constraint violations</span>. 
				</p>
				<table class="term-table" border="1" cellpadding="5">
					<tr>
						<th>Argument</th>
						<th>Type</th>
						<th>Description</th>
					</tr>
					<tr>
						<td><code>?constraint</code></td>
						<td><code>sh:Constraint</code></td>
						<td>The <span class="term">constraint</span> to evalate</td>
					</tr>
					<tr>
						<td><code>?focusNode</code></td>
						<td><code>rdfs:Resource</code> (Optional)</td>
						<td>The <span class="term">focus node</span>, if present.</td>
					</tr>
				</table>
				<p>
					This operation assumes that the <code>?constraint</code> is either a <span class="term">native constraint</span>
					or a <span class="term">template constraint</span>.
				</p>
				<ul>
					<li>
						For <span class="term">native constraints</span>, the operation selects one of the provided <span class="term">executable bodies</span>.
						For example if the constraint has a <code>sh:sparql</code> query and the engine is capable of executing SPARQL,
						it should follow the execution rules specified in the <a href="#sparql-constraints">SPARQL-based Constraints</a> section,
						using the provided <code>?focusNode</code> if present.
						A <code>sh:Warning</code> should be produced if no suitable <span class="term">executable body</span> was found.
					</li>
					<li>
						For <span class="term">template constraints</span>, the operation traverses the associated template as well as all its superclasses.
						For each of those templates, it selects the best suitable <span class="term">executable body</span>.
						For example, if the engine is capable of executing SPARQL,
						it should follow the execution rules specified in the <a href="#sparql-templates">SPARQL-based Templates</a> section,
						using the provided <code>?focusNode</code> if present.
						A <code>sh:Warning</code> should be produced if no suitable <span class="term">executable body</span> was found.
					</li>
				</ul>
			</section>
			<section id="operation-validateNodeAgainstShape">
				<h3>validateNodeAgainstShape</h3>
				<p>
					This operation validates a single <span class="term">node</span> against all constraints associated with a given shape.
				</p>
				<table class="term-table" border="1" cellpadding="5">
					<tr>
						<th>Argument</th>
						<th>Type</th>
						<th>Description</th>
					</tr>
					<tr>
						<td><code>?focusNode</code></td>
						<td><code>rdfs:Resource</code></td>
						<td>The <span class="term">focus node</span> to validate</td>
					</tr>
					<tr>
						<td><code>?shape</code></td>
						<td><code>sh:Shape</code></td>
						<td>The <span class="term">shape</span> that has the constraints.</td>
					</tr>
					<!-- tr>
						<td><code>?contextFilter</code></td>
						<td><code class="todo">TBD</code></td>
						<td>The <span class="term">context filter</span> specifying which constraints to exclude/include.</td>
					</tr-->
				</table>
				<p>
					Algorithm in pseudo-code:
				</p>
				<pre>
forEach ?s := ?shape and its transitive super-shapes
	forEach ?constraint := (?s sh:constraint|sh:property|sh:inverseProperty|sh:argument ?constraint) 
		validateConstraint(?constraint, ?focusNode)</pre>
			</section>
			<section id="operation-validateNode">
				<h3>validateNode</h3>
				<p>
					This operation validates a single <span class="term">node</span> against all shapes associated with it, based on in-graph mappings.
				</p>
				<table class="term-table" border="1" cellpadding="5">
					<tr>
						<th>Argument</th>
						<th>Type</th>
						<th>Description</th>
					</tr>
					<tr>
						<td><code>?focusNode</code></td>
						<td><code>rdfs:Resource</code></td>
						<td>The <span class="term">focus node</span> to validate</td>
					</tr>
					<!-- tr>
						<td><code>?contextFilter</code></td>
						<td><code class="todo">TBD</code></td>
						<td>The <span class="term">context filter</span> specifying which shapes and constraints to exclude/include.</td>
					</tr-->
				</table>
				<p>
					Algorithm in pseudo-code:
				</p>
				<pre>
forEach ?shape := (?focusNode sh:nodeShape|rdf:type ?shape)
	validateNodeAgainstShape(?focusNode, ?shape)</pre>
				<p class="todo">
					Note that the selection properties sh:nodeShape|rdf:type are not decided yet.
					Possibly we need a mechanism to switch one or the other off (could become a parameter).
				</p>
			</section>
			<section id="operation-validateGraph">
				<h3>validateGraph</h3>
				<p>
					This operation validates a whole graph against global constraints and all shapes associated with it, based on in-graph mappings.
				</p>
				<!-- table class="term-table" border="1" cellpadding="5">
					<tr>
						<th>Argument</th>
						<th>Type</th>
						<th>Description</th>
					</tr>
					<tr>
						<td><code>?contextFilter</code></td>
						<td><code class="todo">TBD</code></td>
						<td>The <span class="term">context filter</span> specifying which shapes and constraints to exclude/include.</td>
					</tr>
				</table-->
				<p>
					Algorithm in pseudo-code:
				</p>
				<pre>
forEach ?focusNode := (?focusNode sh:nodeShape|rdf:type ?anyShape)
	validateNode(?focusNode)

forEach ?constraint := instance of sh:GlobalConstraint
	validateConstraint(?constraint)</pre>
   			</section>
		</section>
		
		<section id="functions">
			<h2>Functions</h2>
			<p class="todo">
				This section is backed by a requirement that has not yet been officially approved by the WG.
			</p>
			<p>
				SHACL <span class="term">functions</span> define operations that produce an RDF node based on arguments.
				Functions can be called within SPARQL queries to encapsulate complex logic of other SPARQL queries, or executable logic in other languages such as JavaScript.
				However, the general declaration mechanism for SHACL functions is independent from SPARQL.
			</p>
			<p>
				Functions must be declared as instances of the class <code>sh:Function</code>.
				Well-defined, non-abstract functions MUST provide at least one executable body property using <a href="#sparql-functions"><code>sh:sparql</code></a>.
				The following example illustrates the definition of a <span class="term">function</span> based on a SPARQL query.
			</p>
			<pre class="example" title="SHACL function with a SPARQL body">
# Example call: ex:exampleFunction(4, 3) returns 7
ex:exampleFunction
	a sh:Function ;
	rdfs:comment "Computes the sum of its two arguments ?arg1 and ?arg2." ;
	sh:returnType xsd:integer ;
	sh:argument [
		sh:predicate sh:arg1 ;
		sh:valueType xsd:integer ;
		rdfs:comment "The first operand" ;
	] ;
	sh:argument [
		sh:predicate sh:arg2 ;
		sh:valueType xsd:integer ;
		rdfs:comment "The second operand" ;
	] ;
	sh:sparql """
		SELECT (?arg1 + ?arg2 AS ?result)
		WHERE {
		}
		""" .</pre>
			<p>
				The following sections introduce details of the properties that such functions may have.
			</p>
			<section id="function-arguments">
				<h3>Function Arguments</h3>
				<p>
					The arguments of a function are attached to its <code>sh:Function</code> via the property <code>sh:argument</code>.
					Each argument must be an instance of <code>sh:Argument</code>.
					The <code>rdf:type</code> triple of the argument can be omitted if it is a blank node with an incoming <code>sh:argument</code> triple.
					Arguments are ordered, corresponding to the notation of function calls in SPARQL such as
					<code>ex:exampleFunction(?arg1, ?arg2)</code>.
				</p>
				<p>
					Each <code>sh:Argument</code> MUST have exactly one value for the property <code>sh:predicate</code>.
					The values of <code>sh:predicate</code> must be <code>sh:arg1</code> for the first argument,
					<code>sh:arg2</code> for the second argument, etc.
					Arguments are "inherited" from the superclasses of the function.
					For example if a superclass already declares <code>sh:arg1</code> then subclasses may only define <code>sh:arg2</code> etc.
				</p>
				<p>
					Each <code>sh:Argument</code> may have its property <code>sh:optional</code> set to <code>true</code>
					to indicate that the argument is not mandatory.
					If an argument has been declared optional, then all succeeding arguments must also be declared optional.
				</p>
				<p>
					Each <code>sh:Argument</code> may declare one value for the property <code>sh:valueType</code>.
					This can be used to communicate the expected value type of the argument in function calls.
					Some implementations MAY use this information to prevent the execution of a function with invalid arguments, and to signal errors.
				</p>
			</section>
			<section id="function-returnType">
				<h3>sh:returnType</h3>
				<p>
					A function may declare a single return type via <code>sh:returnType</code>.
					This information may serve for documentation purposes, only.
					However, in some execution languages such as JavaScript, the declared <code>sh:returnType</code> may inform
					the engine how to cast a native value into an RDF value type.
				</p>
			</section>
			<section id="function-cachable">
				<h3>sh:cachable</h3>
				<p>
					A <code>sh:Function</code> may have a property <code>sh:cachable</code> set to <code>true</code>.
					Functions that are marked as cachable MUST always return the same value for the same combination of arguments, regardless of the query graphs.
					Engines can use this information to cache and reuse previous function calls without repeatedly evaluating their executable body.
				</p>
			</section>
		</section>

		<section id="sparql">
			<h2>SPARQL-based Execution (sh:sparql)</h2>
			<p>
				The property <code>sh:sparql</code> is used to link constraints, templates and functions with an executable body in SPARQL.
				The values of <code>sh:sparql</code> must be string literals that can be parsed into syntactically valid SPARQL queries.
				Prior to parsing, a SHACL engine MUST add all prefix declarations from the defining graph into the beginning of the string.
				This means that the values of <code>sh:sparql</code> do not have to explicitly state any <code>@prefix</code> declarations for the prefixes used in the SPARQL query.
			</p>
			<p>
				The following sections provide details on how <code>sh:sparql</code> is interpreted for
				<a href="#sparql-constraints">constraints</a>, <a href="#sparql-templates">templates</a> and <a href="#sparql-functions">functions</a>.
			</p>
			<section id="sparql-constraints">
				<h3>SPARQL-based Constraints</h3>
				<p>
					The SPARQL queries attached to a <span class="term">constraint</span> via <code>sh:sparql</code> must be of the query form <code>SELECT</code>.
				</p>
				<section id="sparql-constraints-this">
					<h4>Binding the Focus Node in Local SPARQL Constraints (?this)</h4>
					<p>
						The SPARQL variable <code>?this</code> has a special meaning in local constraints.
						When SPARQL constraints are executed then the variable <code>?this</code> needs to be pre-bound to the <span class="term">focus node</span>.
						<span class="todo">(Need a pointer to what "pre-binding" means in this context)</span>
					</p>
				</section>
				<section id="sparql-constraints-variables">
					<h4>Mapping of Result Variables to Constraint Violations</h4>
					<p>
						Each row of the result set produced by a SELECT query must be converted into one constraint violation blank node.
						The properties of those blank nodes are derived by the following rules, through a combination of result variables and by looking at properties attached to the constraint itself.
						In the following table, the <span class="term">host resource</span> is assumed to be the constraint or template that has the executed <code>sh:sparql</code> query as one of its properties.
						The production rules are meant to be executed from top to bottom, so that the first bound value will be used.
					</p>
					<table class="term-table" border="1" cellpadding="5">
						<tr>
							<th>Property</th>
							<th>Production Rules</th>
						</tr>
						<tr>
							<td><code>rdf:type</code></td>
							<td>
								<ol>
									<li>The value of <code>sh:severity</code> of the <span class="term">host resource</span></li>
									<li><code>sh:Error</code> as default</li>
								</ol>
							</td>
						</tr>
						<tr>
							<td><code>sh:root</code></td>
							<td>
								<ol>
									<li>The value of the variable <code>?root</code></li>
									<li>The value of the variable <code>?this</code></li>
									<li>The current <span class="term">focus node</span></li>
									<li>The value of <code>sh:root</code> of the <span class="term">host resource</span></li>
								</ol>
							</td>
						</tr>
						<tr>
							<td><code>sh:path</code></td>
							<td>
								<ol>
									<li>The value of the variable <code>?path</code></li>
									<li>The value of the variable <code>?predicate</code></li>
									<li>If the variable <code>?inversePredicate</code> is bound, then create a new blank node as <code>[ sh:inverse ?inversePredicate ]</code>.</li>
									<li>
										Starting with <code>N=1</code>, if the variables <code>?predicateN|?inversePredicateN</code> are bound,
										build a new blank node <code>[ sh:path1 ?first ; sh:path2 ?rest ]</code> where
										<code>?first</code> is a the value of <code>?predicateN</code> if it exists,
										or a new blank node <code>[ sh:inverse ?inversePredicateN ]</code>,
										and <code>?rest</code> is recursively built using this same rule for <code>?predicate(N+1)|?inversePredicate(N+1)</code>
										until it reaches an <code>N</code> where both <code>?predicateN</code> and <code>?inversePredicateN</code> are unbound.
									</li>
									<li>The value of <code>sh:path</code> of the <span class="term">host resource</span></li>
								</ol>
							</td>
						</tr>
						<tr>
							<td><code>sh:value</code></td>
							<td>
								<ol>
									<li>The value of the variable <code>?value</code></li>
									<li>The value of <code>sh:value</code> of the <span class="term">host resource</span></li>
								</ol>
							</td>
						</tr>
						<tr>
							<td><code>sh:message</code></td>
							<td>
								<ol>
									<li>The value of the variable <code>?message</code></li>
									<li>The values of <code>sh:message</code> of the <span class="term">host resource</span></li>
								</ol>
							</td>
						</tr>
						<tr>
							<td><code>sh:source</code></td>
							<td>
								<ol>
									<li>The <span class="term">host resource</span></li>
								</ol>
							</td>
						</tr>
					</table>
					<p>
						The following example illustrates a constraint that flags warnings for all subjects that have a <code>rdfs:label</code> with the language tag <code>"de"</code>.
					</p>
					<pre class="example" title="Global constraint based on SPARQL SELECT">
ex:ExampleGlobalSelectConstraint
	a sh:GlobalConstraint ;
	sh:message "Deutsch is verboten" ;
	sh:path rdfs:label ;
	sh:severity sh:Warning ;
	sh:sparql """
		SELECT (?subject AS ?root) ?value
		WHERE {
			?subject rdfs:label ?value .
			FILTER (lang(?value) = "de") .
		}
		""" .

ex:Resource1
	rdfs:label "Eins"@de ;
	rdfs:label "Zwei"@de ;
	rdfs:label "Trois"@fr .</pre>
					<p>
						Output created by the example above would be:
					</p>
					<pre class="example" title="Global constraint example violation output">
[
	a sh:Warning ;
	sh:root ex:Resource1 ;
	sh:path rdfs:label ;
	sh:value "Eins"@de ;
	sh:message "Deutsch is verboten" ;
	sh:source ex:ExampleGlobalSelectConstraint ;
] .
[
	a sh:Warning ;
	sh:root ex:Resource1 ;
	sh:path rdfs:label ;
	sh:value "Zwei"@de ;
	sh:message "Deutsch is verboten" ;
	sh:source ex:ExampleGlobalSelectConstraint ;
] .</pre>
					<p>
						Here is a more complex example, producing a path expression <code>ex:property1/^ex:property2</code>.
					</p>
					<pre class="example" title="Local constraint with path expression in the violation">
ex:LocalShapeWithPathViolationExample
	a sh:Shape ;
	sh:constraint [
		sh:sparql """
				SELECT ?value (ex:property1 AS ?predicate1) (ex:property2 AS ?inversePredicate2) ?message
				WHERE {
					?this ex:property1 ?first .
					?value ex:property2 ?first .
					FILTER isBlank(?value) .
					BIND (CONCAT("The ", "message.") AS ?message) .
				}
			""" ;
	] .
	
ex:ExampleRootResource
	sh:nodeShape ex:LocalShapeWithPathViolationExample ;
	ex:property1 ex:ExampleIntermediateResource .

ex:ExampleValueResource
	ex:property2 ex:ExampleIntermediateResource .
</pre>
					<p>
						Which produces the following error:
					</p>
					<pre class="example" title="Local constraint example violation output">
[
	a sh:Error ;
	sh:root ex:ExampleRootResource ;
	sh:path [
		sh:path1 ex:property1 ;
		sh:path2 [
			sh:inverse ex:property2
		]
	] ;
	sh:value ex:ExampleValueResource ;
	sh:message "The message." ;
	sh:source [ the blank node of the sh:constraint above ] ;
] .</pre>
				</section>
			</section>
			<section id="sparql-templates">
				<h3>SPARQL-based Templates</h3>
				<p>
					If a <code>sh:Template</code> has a value for <code>sh:sparql</code>, then the corresponding instances need to follow the same execution rules as outlined for <a href="#sparql-constraints">SPARQL-based Constraints</a>.
					The only difference is that the SPARQL queries need to be executed with additional <span class="term">pre-bound</span> variables, derived from the arguments of the template.
					The names of those variables must match the <a href="#def-local-name"><span class="term">local name</span></a> of the argument predicates, including the arguments defined by any (transitive) superclasses of the template.
					For example, if an argument is represented with the predicate <code>ex:myArgument</code> then the variable <code>?myArgument</code> must be <span class="term">pre-bound</span> with the value of the argument in the template instance.
				</p>
			</section>
			<section id="sparql-functions">
				<h3>SPARQL-based Functions</h3>
				<p>
					If a <code>sh:Function</code> has a value for <code>sh:sparql</code>, then a SPARQL-based execution engine SHOULD
					execute the provided SPARQL query on the current data set.
					In this SPARQL query, the engine needs to <span class="term">pre-bind</span> the variables <code>?arg1</code>, <code>?arg2</code> etc
					based on the provided arguments of the function call.
					The SPARQL query must be of type ASK or SELECT.
					For ASK queries, the function's return value is the result of the ASK query execution.
					For SELECT queries, the function's return value is the first binding of the first result variable in the result set.
				</p>
				<p>
					Some execution engines may ignore the specified <code>sh:sparql</code> query and rely on an alternative (possibly native) implementation instead,
					as long as the functions return the same values as the specified <code>sh:sparql</code> query.
					This can be used to optimize frequently needed functions.
					Some processors may even use the <code>sh:sparql</code> query to rewrite other SPARQL queries via inlining techniques.
				</p>
			</section>
		</section>
		
		<section class="appendix">
			<h2>SPARQL Functions in the SHACL Namespace</h2>
			<p>
				SPARQL-based SHACL engines MUST implement the following SPARQL functions.
			</p>
			<section id="function-hasShape">
				<h3>sh:hasShape</h3>
				<p>
					The function <code>sh:hasShape</code> returns <code>true</code> if	a given node (<code>?arg1</code>) matches a given shape (<code>?arg2</code>).
					The return type of this function is <code>xsd:boolean</code>.
				</p>
				<table class="term-table" border="1" cellpadding="5">
					<tr>
						<th>Argument</th>
						<th>Value type</th>
						<th>Description</th>
					</tr>
					<tr>
						<td><code>?arg1</code></td>
						<td>Any IRI or blank node</td>
						<td>The node to validate</td>
					</tr>
					<tr>
						<td><code>?arg2</code></td>
						<td><code>sh:Shape</code> or <code>rdfs:Class</code></td>
						<td>The shape to match against</td>
					</tr>
				</table>
				<p>
					This function MUST perform constraint validation equivalent to the <a href="#operation-validateNodeAgainstShape"><code>validateNodeAgainstShape</code></a> operation.
					The function MUST return <code>true</code> if the operation returns no error-level constraint violations, <code>false</code> if any error-level constraint violations exist. 
				</p>
			</section>
			<section id="function-hasNodeType">
				<h3>sh:hasNodeType</h3>
				<p>
					The function <code>sh:hasNodeType</code> can be used to verify whether a given
					node (<code>?arg1</code>) has the provided <code>sh:NodeType</code> (<code>?arg2</code>).
					The return type of this function is <code>xsd:boolean</code>.
				</p>
				<table class="term-table" border="1" cellpadding="5">
					<tr>
						<th>Argument</th>
						<th>Value type</th>
						<th>Description</th>
					</tr>
					<tr>
						<td><code>?arg1</code></td>
						<td>Any</td>
						<td>The node to test</td>
					</tr>
					<tr>
						<td><code>?arg2</code></td>
						<td><code>sh:NodeType</code></td>
						<td>The node type that <code>?arg1</code> is expected to have</td>
					</tr>
				</table>
				<p>
					The following table summarizes the values of the class <code>sh:NodeType</code> together with their SPARQL definition.
				</p>
					<table class="term-table" border="1" cellpadding="5">
						<tr>
							<th>NodeType</th>
							<th>Super-NodeTypes</th>
							<th>SPARQL Expression</th>
						</tr>
						<tr>
							<td><code>sh:Node</code></td>
							<td></td>
							<td><code>true</code></td>
						</tr>
						<tr>
							<td><code>sh:BlankNodeOrIRI</code></td>
							<td><code>sh:Node</code></td>
							<td><code>isBlank(?node) || isIRI(?node)</code></td>
						</tr>
						<tr>
							<td><code>sh:BlankNodeOrLiteral</code></td>
							<td><code>sh:Node</code></td>
							<td><code>isBlank(?node) || isLiteral(?node)</code></td>
						</tr>
						<tr>
							<td><code>sh:LiteralOrIRI</code></td>
							<td><code>sh:Node</code></td>
							<td><code>isLiteral(?node) || isIRI(?node)</code></td>
						</tr>
						<tr>
							<td><code>sh:BlankNode</code></td>
							<td><code>sh:BlankNodeOrIRI</code>, <code>sh:BlankNodeOrLiteral</code></td>
							<td><code>isBlank(?node)</code></td>
						</tr>
						<tr>
							<td><code>sh:IRI</code></td>
							<td><code>sh:BlankNodeOrIRI</code>, <code>sh:LiteralOrIRI</code></td>
							<td><code>isIRI(?node)</code></td>
						</tr>
						<tr>
							<td><code>sh:Literal</code></td>
							<td><code>sh:LiteralOrIRI</code>, <code>sh:BlankNodeOrLiteral</code></td>
							<td><code>isLiteral(?node)</code></td>
						</tr>
					</table>
				<div id="def-hasNodeType-sparql" class="def def-sparql">
					<div class="def-header">SPARQL DEFINITION</div>
<pre class="def-sparql-body">
ASK {
	FILTER (isIRI(?arg1) &amp;&amp; (?arg2 IN (sh:IRI, sh:BlankNodeOrIRI, sh:LiteralOrIRI, sh:Node)) ||
		(isLiteral(?arg1) &amp;&amp; (?arg2 IN (sh:Literal, sh:BlankNodeOrLiteral, sh:LiteralOrIRI, sh:Node))) ||
 		(isBlank(?arg1) &amp;&amp; (?arg2 IN (sh:BlankNode, sh:BlankNodeOrLiteral, sh:BlankNodeOrIRI, sh:Node))))
}</pre>
				</div>
				<pre class="example">
sh:hasNodeType(42, sh:IRI)   # false
sh:hasNodeType(42, sh:Literal)   # true
sh:hasNodeType(ex:MyInstance, sh:BlankNodeOrIRI)   # true</pre>
			</section>
			<section id="function-inverseValueCount">
				<h3>sh:inverseValueCount</h3>
				<p>
					The function <code>sh:inverseValueCount</code> returns the number of triples that have
					a given object (<code>?arg1</code>) and a given predicate (<code>?arg2</code>).
					The return type of this function is <code>xsd:integer</code>.
				</p>
				<table class="term-table" border="1" cellpadding="5">
					<tr>
						<th>Argument</th>
						<th>Value type</th>
						<th>Description</th>
					</tr>
					<tr>
						<td><code>?arg1</code></td>
						<td>Any node</td>
						<td>The object node</td>
					</tr>
					<tr>
						<td><code>?arg2</code></td>
						<td><code>rdf:Property</code></td>
						<td>The predicate node</td>
					</tr>
				</table>
				<div id="def-inverseValueCount-sparql" class="def def-sparql">
					<div class="def-header">SPARQL DEFINITION</div>
<pre class="def-sparql-body">
SELECT (COUNT(?subject) AS ?result)
WHERE {
	?subject ?arg2 ?arg1 .
}</pre>
				</div>
			</section>
			<section id="function-label">
				<h3>sh:label</h3>
				<p>
					The function <code>sh:label</code> returns a string representation of a given node <code>?arg1</code>.
					This function is the recommended entry point whenever a node shall be displayed to end users, e.g. as part of a constructed <code>sh:message</code>.
					The output of this function must be an <code>xsd:string</code> literal.
					Unbound is not a valid result.
				</p>
				<table class="term-table" border="1" cellpadding="5">
					<tr>
						<th>Argument</th>
						<th>Value type</th>
						<th>Description</th>
					</tr>
					<tr>
						<td><code>?arg1</code></td>
						<td>Any node</td>
						<td>The node to render</td>
					</tr>
				</table>
				<p>
					The implementation details of this function are left unspecified.
					As a guideline, the function MAY use the values of <code>rdfs:label</code> and similar properties for resources.
					As a fall-back, it may return the qname or full IRI of a resource.
					For literal values, the function may use the lexical form, but may also render date and time literals in locale-specific strings.
				</p>
			</section>
			<section id="function-valueCount">
				<h3>sh:valueCount</h3>
				<p>
					The function <code>sh:valueCount</code> returns the number of triples that have
					a given subject (<code>?arg1</code>) and a given predicate (<code>?arg2</code>).
					The return type of this function is <code>xsd:integer</code>.
				</p>
				<table class="term-table" border="1" cellpadding="5">
					<tr>
						<th>Argument</th>
						<th>Value type</th>
						<th>Description</th>
					</tr>
					<tr>
						<td><code>?arg1</code></td>
						<td>Any IRI or blank node</td>
						<td>The subject node</td>
					</tr>
					<tr>
						<td><code>?arg2</code></td>
						<td><code>rdf:Property</code></td>
						<td>The predicate node</td>
					</tr>
				</table>
				<div id="def-valueCount-sparql" class="def def-sparql">
					<div class="def-header">SPARQL DEFINITION</div>
<pre class="def-sparql-body">
SELECT (COUNT(?object) AS ?result)
WHERE {
	?arg1 ?arg2 ?object .
}</pre>
				</div>
			</section>
		</section>
		
		<section id="sparql-template-defs" class="appendix">
			<h2>SPARQL Definitions of the SHACL Templates</h2>
			<p>
				The following subsections define the semantics of the high-level constraint vocabulary built into SHACL using SPARQL.
				The SPARQL Definitions use the variable <code>?this</code> to refer to the <span class="term">focus node</span>.
				Pre-bound variables such are printed such as <code class="arg">?this</code>.
				SPARQL-based implementations of SHACL may use variations of the provided SPARQL queries, as long as they expose compatible behavior.
			</p>
			<section>
				<h3>Property Constraints</h3>
				<section id="sparql-AbstractAllowedValuesPropertyConstraint">
					<h4>sh:allowedValues</h4>
					<p>
						The property facet <code>sh:allowedValues</code> is defined in the SHACL template <code>sh:AbstractAllowedValuesPropertyConstraint</code>.
					</p>
					<div id="def-allowedValues-sparql" class="def def-sparql">
						<div class="def-header">SPARQL DEFINITION</div>
<pre class="def-sparql-body">
SELECT (<span class="arg">?this</span> AS ?root) (<span class="arg">?predicate</span> AS ?path) ?value
WHERE {
	<span class="arg">?this</span> ?predicate ?value ;
	FILTER NOT EXISTS {
		<span class="arg">?allowedValues</span> sh:member ?value
	}
}</pre>
					</div>
				</section>
				<section id="sparql-AbstractHasValuePropertyConstraint">
					<h4>sh:hasValue</h4>
					<p>
						The property facet <code>sh:hasValue</code> is defined in the SHACL template <code>sh:AbstractHasValuePropertyConstraint</code>.
					</p>
					<div id="def-hasValue-sparql" class="def def-sparql">
						<div class="def-header">SPARQL DEFINITION</div>
<pre class="def-sparql-body">
SELECT (<span class="arg">?this</span> AS ?root) (<span class="arg">?predicate</span> AS ?path)
WHERE {
	FILTER NOT EXISTS {
		<span class="arg">?this</span> <span class="arg">?predicate</span> <span class="arg">?hasValue</span>
	}
}</pre>
					</div>
				</section>
				<section id="sparql-AbstractCountPropertyConstraint">
					<h4>sh:minCount, sh:maxCount</h4>
					<p>
						The property facets <code>sh:minCount</code> and <code>sh:maxCount</code> are defined in the SHACL template <code>sh:AbstractCountPropertyConstraint</code>.
					</p>
					<div id="def-count-sparql" class="def def-sparql">
						<div class="def-header">SPARQL DEFINITION</div>
<pre class="def-sparql-body">
SELECT (<span class="arg">?this</span> AS ?root) (<span class="arg">?predicate</span> AS ?path)
WHERE {
	BIND (sh:valueCount(<span class="arg">?this</span>, <span class="arg">?predicate</span>) AS ?count) .
	FILTER ((?count &lt; <span class="arg">?minCount</span>) || (bound(<span class="arg">?maxCount</span>) &amp;&amp; (?count &gt; <span class="arg">?maxCount</span>))) .
}</pre>
					</div>
				</section>
				<section id="sparql-AbstractNodeTypePropertyConstraint">
					<h4>sh:nodeType</h4>
					<p>
						The property facet <code>sh:nodeType</code> is defined in the SHACL template <code>sh:AbstractNodeTypePropertyConstraint</code>.
					</p>
					<div id="def-nodeType-sparql" class="def def-sparql">
						<div class="def-header">SPARQL DEFINITION</div>
<pre class="def-sparql-body">
SELECT (<span class="arg">?this</span> AS ?root) (<span class="arg">?predicate</span> AS ?path) ?value
WHERE {
	<span class="arg">?this</span> <span class="arg">?predicate</span> ?value ;
	FILTER (!sh:hasNodeType(?value, <span class="arg">?nodeType</span>)) .
}</pre>
					</div>
				</section>
				<section id="sparql-AbstractValueShapePropertyConstraint">
					<h4>sh:valueShape</h4>
					<p>
						The property facet <code>sh:valueShape</code> is defined in the SHACL template <code>sh:AbstractValueShapePropertyConstraint</code>.
					</p>
					<div id="def-valueShape-sparql" class="def def-sparql">
						<div class="def-header">SPARQL DEFINITION</div>
<pre class="def-sparql-body">
SELECT (<span class="arg">?this</span> AS ?root) (<span class="arg">?predicate</span> AS ?path) ?value 
WHERE {
	<span class="arg">?this</span> <span class="arg">?predicate</span> ?value .
	FILTER (!sh:hasShape(?value, <span class="arg">?valueShape</span>)) .
}</pre>
					</div>
					<p class="todo">
						Some WG members have voiced concerns that the definition above requires the sh:hasShape function that may
						be expensive to implement for SPARQL vendors.
						An alternative design would be to hard-code the <code>sh:valueShape</code> property into the engine,
						and do the recursion in the outer layer, outside of SPARQL.
					</p>
				</section>
			</section>
			<section>
				<h3>Inverse Property Constraints</h3>
				<p class="todo">
					TODO
				</p>
			</section>
			<section id="sparql-or">
				<h3>sh:OrConstraint</h3>
				<div id="def-orConstraint-sparql" class="def def-sparql">
					<div class="def-header">SPARQL DEFINITION</div>
					<pre class="def-sparql-body">
SELECT (<span class="arg">?this</span> AS ?root)
WHERE {
	FILTER (!sh:hasShape(<span class="arg">?this</span>, <span class="arg">?shape1</span>) &amp;&amp; !sh:hasShape(<span class="arg">?this</span>, <span class="arg">?shape2</span>)) .
}</pre>
				</div>
			</section>
		</section>

	</body>
</html>