2.1.1Constraints, Parameters and Constraint Components

Shapes can declareconstraints using theparameters ofconstraint components.

Aconstraint component is anIRI. Each constraint component has one or moremandatory parameters, each of which is a property. Each constraint component has zero or moreoptional parameters, each of which is a property. Theparameters of a constraint component are its mandatory parameters plus its optional parameters.

For example, thecomponentsh:MinCountConstraintComponent declares theparametersh:minCount to represent the restriction that anode has at least a minimum number ofvalues for a particular property.

For aconstraint componentC withmandatory parametersp1, ...pn, ashapes in ashapes graphSGdeclares aconstraint that haskindC withmandatory parametervalues<p1,v1>, ...<pn,vn> inSG whens hasvi as avalue forpi inSG. For constraint components withoptional parameters, the constraint declaration consists of thevalues that the shape has for all mandatory and optional parameters of that component.

Some constraint components declare only a single parameter. For examplesh:ClassConstraintComponent has the single parametersh:class. These parameters may be used multiple times in the same shape, and eachvalue of such a parameter declares an individualconstraint. The interpretation of such declarations is conjunction, i.e. all constraints apply. The following example specifies that the values ofex:customer have to beSHACL instances of bothex:Customer andex:Person.

ex:InvoiceShapea sh:NodeShape ;sh:property [sh:path ex:customer ;sh:class ex:Customer ;sh:class ex:Person ;] .

Some constraint components such assh:PatternConstraintComponent declare more than one parameter. Shapes that have more than one value for any of the parameters of such components areill-formed.

One way to bypass this syntax rule is to spread the constraints across multiple (property) shapes, as illustrated in the following example.

ex:MultiplePatternsShapea sh:NodeShape ;sh:property [sh:path ex:name ;sh:pattern "^Start" ;sh:flags "i" ;] ;sh:property [sh:path ex:name ;sh:pattern "End$" ;] .

Constraint components are associated withvalidators, which provide instructions (for example expressed via SPARQL queries) on how the parameters are used to validate data. Validating anRDF term against ashape involves validating the term against eachconstraint where the shape hasvalues for allmandatory parameters of thecomponent of theconstraint, using the validators associated with the respective component.

The list of constraint components included in SHACL Core is described insection 4. SHACL-SPARQL can be used to declare additionalconstraint components based on SPARQL.

2.1.2Focus Nodes

AnRDF term that isvalidated against ashape using the triples from adata graph is called afocus node.

The remainder of this section is informative.

The set offocus nodes for ashape may be identified as follows:

• specified in ashape usingtarget declarations
• specified in anyconstraint that references ashape in parameters ofshape-expecting constraint parameters (e.g.sh:node)
• specified as explicit input to the SHACL processor for validating a specific RDF term against a shape

2.1.3Targets

Target declarations of ashape in ashapes graph aretriples with theshape as thesubject and certain properties described in this document (e.g.,sh:targetClass) aspredicates. Target declarations can be used to producefocus nodes for ashape. Thetarget of atarget declaration is the set of RDF terms produced by applying the rules described in the remainder of this section to thedata graph. Thetarget of a shape is the union of all RDF terms produced by the individualtargets that are declared by theshape in theshapes graph.

SHACL Core includes the following kinds of targets:node targets,class-based targets (includingimplicit class-based targets),subjects-of targets, andobjects-of targets.

The remainder of this introduction is informative.

RDF terms produced by targets are not required to exist as nodes in thedata graph. Targets of a shape are ignored whenever a focus node is provided directly as input to the validation process for that shape. This includes the cases where the shape is a value of one of theshape-expecting constraint parameters (such assh:node) and a focus node is determined during the validation of the corresponding constraint component (such assh:NodeConstraintComponent). In such cases, the provided focus node does not need to be in thetarget of the shape.

ex:PersonShapea sh:NodeShape ;sh:targetNode ex:Alice .

ex:Alice a ex:Person .ex:Bob a ex:Person .

SELECT DISTINCT ?this# ?this is the focus nodeWHERE {BIND ($targetNode AS ?this)# $targetNode ispre-bound to ex:Alice}

ex:PersonShapea sh:NodeShape ;sh:targetClass ex:Person .

ex:Alice a ex:Person .ex:Bob a ex:Person .ex:NewYork a ex:Place .

ex:Doctor rdfs:subClassOf ex:Person .ex:Who a ex:Doctor .ex:House a ex:Nephrologist .

SELECT DISTINCT ?this# ?this is the focus nodeWHERE {?this rdf:type/rdfs:subClassOf* $targetClass .# $targetClass ispre-bound to ex:Person}

ex:Persona rdfs:Class, sh:NodeShape .

ex:Alice a ex:Person .ex:NewYork a ex:Place .

ex:TargetSubjectsOfExampleShapea sh:NodeShape ;sh:targetSubjectsOf ex:knows .

ex:Alice ex:knows ex:Bob .ex:Bob ex:livesIn ex:NewYork .

SELECT DISTINCT ?this# ?this is the focus nodeWHERE {?this $targetSubjectsOf ?any .# $targetSubjectsOf ispre-bound to ex:knows}

ex:TargetObjectsOfExampleShapea sh:NodeShape ;sh:targetObjectsOf ex:knows .

ex:Alice ex:knowsex:Bob .ex:Bob ex:livesIn ex:NewYork .

SELECT DISTINCT ?this# ?this is the focus nodeWHERE {?any $targetObjectsOf ?this .# $targetObjectsOf ispre-bound to ex:knows}

2.1.4Declaring the Severity of a Shape

Shapes can specify onevalue for the propertysh:severity in theshapes graph.Each value ofsh:severity in a shape is anIRI.

The values ofsh:severity are calledseverities. SHACL includes the three IRIs listed in the table below to representseverities. These are declared in the SHACL vocabulary as SHACL instances ofsh:Severity.

The remainder of this section is informative.

The specific values ofsh:severity have no impact on the validation, butMAY be used by user interface tools to categorize validation results. The values ofsh:severity are used by SHACL processors to populate thesh:resultSeverity field of validation results, seesection on severity in validation results. Any IRI can be used as a severity.

For every shape,sh:Violation is the default ifsh:severity is unspecified. The following example illustrates this.

ex:MyShapea sh:NodeShape ;sh:targetNode ex:MyInstance ;sh:property [    # _:b1# Violations of sh:minCount and sh:datatype are produced as warningssh:path ex:myProperty ;sh:minCount 1 ;sh:datatype xsd:string ;sh:severity sh:Warning ;] ;sh:property [    # _:b2# The default severity here is sh:Violationsh:path ex:myProperty ;sh:maxLength 10 ;sh:message "Too many characters"@en ;sh:message "Zu viele Zeichen"@de ;] .

ex:MyInstanceex:myProperty "http://toomanycharacters"^^xsd:anyURI .

[a sh:ValidationReport ;sh:conforms false ;sh:result[a sh:ValidationResult ;sh:resultSeverity sh:Warning ;sh:focusNode ex:MyInstance ;sh:resultPath ex:myProperty ;sh:value "http://toomanycharacters"^^xsd:anyURI ;sh:sourceConstraintComponent sh:DatatypeConstraintComponent ;sh:sourceShape _:b1 ;] ,[a sh:ValidationResult ;sh:resultSeverity sh:Violation ;sh:focusNode ex:MyInstance ;sh:resultPath ex:myProperty ;sh:value "http://toomanycharacters"^^xsd:anyURI ;sh:resultMessage "Too many characters"@en ;sh:resultMessage "Zu viele Zeichen"@de ;sh:sourceConstraintComponent sh:MaxLengthConstraintComponent ;sh:sourceShape _:b2 ;]] .

2.1.5Declaring Messages for a Shape

Shapes can have values for the propertysh:message.The values ofsh:message in a shape are eitherxsd:string literals or literals with a language tag. A shape should not have more than one value forsh:message with the same language tag.

If a shape has at least one value forsh:message in the shapes graph, then allvalidation results produced as a result of the shape will have exactly these messages as their value ofsh:resultMessage, i.e. the values will be copied from the shapes graph into the results graph. (Note that in SHACL-SPARQL,SPARQL-based constraints andSPARQL-based constraint components provide additional means to declare such messages.)

The remainder of this section is informative.

The example from the previous section uses this mechanism to supply the second validation result with two messages. See thesection onsh:resultMessage in the validation results on further details on how the values ofsh:resultMessage are populated.

2.1.6Deactivating a Shape

Shapes can have at most one value for the propertysh:deactivated.The value ofsh:deactivated in a shape must be eithertrue orfalse.

A shape that has thevaluetrue for the propertysh:deactivated is calleddeactivated. All RDF termsconform to a deactivated shape.

The remainder of this section is informative.

Use cases of this feature include shape reuse and debugging. In scenarios where shapes from other graphs or files are imported into a givenshapes graph,sh:deactivated can be set totrue in the local shapes graph for imported shapes to exclude shapes that do not apply in the current application context. This makes it possible to reuse SHACL graphs developed by others even if you disagree with certain assumptions made by the original authors. If a shape author anticipates that a shape may need to be disabled or modified by others, it is a good practice to useIRIs instead ofblank nodes for the actual shapes. For example, aproperty shape for the propertyex:name at the shapeex:PersonShape may have the IRIex:PersonShape-name. Another typical use case ofsh:deactivated is during the development and testing of shapes, to (temporarily) disable certain shapes.

The following example illustrates the use ofsh:deactivated to deactivate a shape. In cases where shapes are imported from other graphs, thesh:deactivated true triple would be in the importing graph.

ex:PersonShapea sh:NodeShape ;sh:targetClass ex:Person ;sh:property ex:PersonShape-name .ex:PersonShape-namea sh:PropertyShape ;sh:path ex:name ;sh:minCount 1 ;sh:deactivated true .

With the following data, no constraint violation will be reported even though the instance does not have any value forex:name.

ex:JohnDoe a ex:Person .

2.3.1SHACL Property Paths

SHACL includes RDF terms to represent the following subset ofSPARQL property paths:PredicatePath,InversePath,SequencePath,AlternativePath,ZeroOrMorePath,OneOrMorePath andZeroOrOnePath.

The following sub-sections provide syntax rules ofwell-formedSHACL property paths together with mapping rules toSPARQL 1.1 property paths. These rules define thepath mappingpath(p,G) in an RDF graphG of an RDF termp that is a SHACL property path inG. Two SHACL property paths are consideredequivalent paths when they map to the exact same SPARQL property paths.

A node in an RDF graph is awell-formedSHACL property pathp if it satisfies exactly one of the syntax rules in the following sub-sections.A nodep is not awell-formed SHACL property path ifp is a blank node and any path mappings ofp directly or transitively referencep.

The following example illustrates some valid SHACL property paths, together with their SPARQL 1.1 equivalents.

SPARQL Property path: ex:parentSHACL Property path: ex:parentSPARQL Property path: ^ex:parentSHACL Property path: [ sh:inversePath ex:parent ]SPARQL Property path: ex:parent/ex:firstNameSHACL Property path: ( ex:parent ex:firstName )SPARQL Property path: rdf:type/rdfs:subClassOf*SHACL Property path: ( rdf:type [ sh:zeroOrMorePath rdfs:subClassOf ] )SPARQL Property path: ex:father|ex:motherSHACL Property path: [ sh:alternativePath ( ex:father ex:mother  ) ]

2.3.2Non-Validating Property Shape Characteristics

This section is non-normative.

While the previous sections introduced properties that represent validation conditions, this section covers properties that are ignored by SHACL processors. The use of these so-callednon-validating properties is entirely optional and not subject to formal interpretation contracts. TheyMAY be used for purposes such as form building or predictable printing of RDF files.

ex:PersonFormShapea sh:NodeShape ;sh:property [sh:path ex:firstName ;sh:name "first name" ;sh:description "The person's given name(s)" ;sh:order 0 ;sh:group ex:NameGroup ;] ;sh:property [sh:path ex:lastName ;sh:name "last name" ;sh:description "The person's last name" ;sh:order 1 ;sh:group ex:NameGroup ;] ;sh:property [sh:path ex:streetAddress ;sh:name "street address" ;sh:description "The street address including number" ;sh:order 11 ;sh:group ex:AddressGroup ;] ;sh:property [sh:path ex:locality ;sh:name "locality" ;sh:description "The suburb, city or town of the address" ;sh:order 12 ;sh:group ex:AddressGroup ;] ;sh:property [sh:path ex:postalCode ;sh:name "postal code" ;sh:name "zip code"@en-US ;sh:description "The postal code of the locality" ;sh:order 13 ;sh:group ex:AddressGroup ;] .ex:NameGroupa sh:PropertyGroup ;sh:order 0 ;rdfs:label "Name" .ex:AddressGroupa sh:PropertyGroup ;sh:order 1 ;rdfs:label "Address" .

3.4.1Failures

Validation andconformance checking can result in afailure. For example, a particular SHACL processor might allow recursive shapes but report a failure if it detects a loop within the data. Failures can also be reported due to resource exhaustion. Failures are signalled through implementation-specific channels.

3.4.2Handling of Ill-formed Shapes Graphs

If theshapes graph containsill-formed nodes, then the result of the validation process isundefined. A SHACL processorSHOULD produce afailure in this case. See also3.6.1.3Syntax Checking of Shapes Graph (sh:shapesGraphWellFormed).

3.4.3Handling of Recursive Shapes

The following properties are the so-calledshape-expecting constraint parameters in SHACL Core:

• sh:and
• sh:not
• sh:or
• sh:property
• sh:qualifiedValueShape
• sh:node
• sh:xone

The following properties are the so-calledlist-taking constraint parameters in SHACL Core:

• sh:and
• sh:in
• sh:languageIn
• sh:or
• sh:xone

A shapes1 in an RDF graphGrefers to shapes2 inG if it hass2 asvalue for some non-list-taking, shape-expecting parameter of some constraint component ors2 as amember of thevalue for some list-taking, shape-expecting parameter of some constraint component. A shape in an RDF graphG is arecursive shape inG if it is related to itself by the transitive closure of therefers relationship inG.

Thevalidation withrecursive shapes is not defined in SHACL and is left to SHACL processor implementations. For example, SHACL processors may support recursion scenarios or produce a failure when they detect recursion.

The remainder of this section is informative.

The recursion policy above has been selected to support a large variety of implementation strategies. By leaving recursion undefined, implementations may chose to not support recursion so that they can issue a static set of SPARQL queries (against SPARQL end points) without having to support cycles. The Working Group is aware that other implementations may support recursion and that some shapes graphs may rely on these specific characteristics. The expectation is that future work, for example inW3C Community Groups, will lead to the definition of specific dialects of SHACL where recursion is well-defined.

3.6.1Validation Report (sh:ValidationReport)

The result of avalidation process is an RDF graph with exactly oneSHACL instance ofsh:ValidationReport. The RDF graphMAY contain additional information such as provenance metadata.

3.6.2Validation Result (sh:ValidationResult)

SHACL definessh:ValidationResult as a subclass ofsh:AbstractResult to report individual SHACLvalidation results. SHACL implementations may use otherSHACL subclasses ofsh:AbstractResult, for example, to report successfully completed constraint checks or accumulated results.

All the properties described in the remaining sub-sections of this section can be specified in ash:ValidationResult. The propertiessh:focusNode,sh:resultSeverity andsh:sourceConstraintComponent are the only properties that are mandatory for all validation results.

4.1.1sh:class

The condition specified bysh:class is that eachvalue node is aSHACL instance of a given type.

Constraint Component IRI:sh:ClassConstraintComponent

The remainder of this section is informative.

Note that multiple values forsh:class are interpreted as a conjunction, i.e. the values need to be SHACL instances of all of them.

ASK {$value rdf:type/rdfs:subClassOf* $class .}

ex:ClassExampleShapea sh:NodeShape ;sh:targetNode ex:Bob, ex:Alice, ex:Carol ;sh:property [sh:path ex:address ;sh:class ex:PostalAddress ;] .

ex:Alice a ex:Person .ex:Bob ex:address [ a ex:PostalAddress ; ex:city ex:Berlin ] .ex:Carol ex:address [ ex:city ex:Cairo ] .

4.1.2sh:datatype

sh:datatype specifies a condition to be satisfied with regards to the datatype of eachvalue node.

Constraint Component IRI:sh:DatatypeConstraintComponent

The remainder of this section is informative.

The values ofsh:datatype are typicallydatatypes, such asxsd:string. Note that usingrdf:langString as value ofsh:datatype can be used to test if value nodes have a language tag.

ex:DatatypeExampleShapea sh:NodeShape ;sh:targetNode ex:Alice, ex:Bob, ex:Carol ;sh:property [sh:path ex:age ;sh:datatype xsd:integer ;] .

ex:Alice ex:age "23"^^xsd:integer .ex:Bob ex:age "twenty two" .ex:Carol ex:age "23"^^xsd:int .

4.1.3sh:nodeKind

sh:nodeKind specifies a condition to be satisfied by the RDF node kind of eachvalue node.

Constraint Component IRI:sh:NodeKindConstraintComponent

The remainder of this section is informative.

ASK {FILTER ((isIRI($value) && $nodeKind IN ( sh:IRI, sh:BlankNodeOrIRI, sh:IRIOrLiteral ) ) ||(isLiteral($value) && $nodeKind IN ( sh:Literal, sh:BlankNodeOrLiteral, sh:IRIOrLiteral ) ) ||(isBlank($value)   && $nodeKind IN ( sh:BlankNode, sh:BlankNodeOrIRI, sh:BlankNodeOrLiteral ) )) .}

The following example states that all values ofex:knows need to be IRIs, at any subject.

ex:NodeKindExampleShapea sh:NodeShape ;sh:targetObjectsOf ex:knows ;sh:nodeKind sh:IRI .

ex:Bob ex:knows ex:Alice .ex:Alice ex:knows"Bob" .

4.2.1sh:minCount

sh:minCount specifies the minimum number ofvalue nodes that satisfy the condition. If the minimum cardinality value is 0 then this constraint is always satisfied and so may be omitted.

Constraint Component IRI:sh:MinCountConstraintComponent

The remainder of this section is informative.

ex:MinCountExampleShapea sh:PropertyShape ;sh:targetNode ex:Alice, ex:Bob ;sh:path ex:name ;sh:minCount 1 .

ex:Alice ex:name "Alice" .ex:Bob ex:givenName "Bob"@en .

4.2.2sh:maxCount

sh:maxCount specifies the maximum number ofvalue nodes that satisfy the condition.

Constraint Component IRI:sh:MaxCountConstraintComponent

The remainder of this section is informative.

ex:MaxCountExampleShapea sh:NodeShape ;sh:targetNode ex:Bob ;sh:property [sh:path ex:birthDate ;sh:maxCount 1 ;] .

ex:Bob ex:birthDate "May 5th 1990" .

4.3.1sh:minExclusive

Constraint Component IRI:sh:MinExclusiveConstraintComponent

The remainder of this section is informative.

The SPARQL expression produces an error if the value node cannot be compared to the specified range, for example when someone compares a string with an integer. If the comparison cannot be performed, then there is a validation result. This is different from, say, a plain SPARQL query, in which such errors would silently not lead to any results.

ASK {FILTER ($minExclusive < $value)}

4.3.2sh:minInclusive

Constraint Component IRI:sh:MinInclusiveConstraintComponent

The remainder of this section is informative.

ASK {FILTER ($minInclusive <= $value)}

4.3.3sh:maxExclusive

Constraint Component IRI:sh:MaxExclusiveConstraintComponent

The remainder of this section is informative.

ASK {FILTER ($maxExclusive > $value)}

4.3.4sh:maxInclusive

Constraint Component IRI:sh:MaxInclusiveConstraintComponent

The remainder of this section is informative.

ASK {FILTER ($maxInclusive >= $value)}

4.4.1sh:minLength

sh:minLength specifies the minimum string length of eachvalue node that satisfies the condition. This can be applied to anyliterals andIRIs, but not toblank nodes.

Constraint Component IRI:sh:MinLengthConstraintComponent

The remainder of this section is informative.

Note that if the value ofsh:minLength is 0 then there is no restriction on the string length but the constraint is still violated if the value node is a blank node.

ASK {FILTER (STRLEN(str($value)) >= $minLength) .}

4.4.2sh:maxLength

sh:maxLength specifies the maximum string length of eachvalue node that satisfies the condition. This can be applied to anyliterals andIRIs, but not toblank nodes.

Constraint Component IRI:sh:MaxLengthConstraintComponent

The remainder of this section is informative.

ASK {FILTER (STRLEN(str($value)) <= $maxLength) .}

ex:PasswordExampleShapea sh:NodeShape ;sh:targetNode ex:Bob, ex:Alice ;sh:property [sh:path ex:password ;sh:minLength 8 ;sh:maxLength 10 ;] .

ex:Bob ex:password "123456789" .ex:Alice ex:password "1234567890ABC" .

4.4.3sh:pattern

sh:pattern specifies a regular expression that eachvalue node matches to satisfy the condition.

Constraint Component IRI:sh:PatternConstraintComponent

The remainder of this section is informative.

ASK {FILTER (!isBlank($value) && IF(bound($flags), regex(str($value), $pattern, $flags), regex(str($value), $pattern)))}

ex:PatternExampleShapea sh:NodeShape ;sh:targetNode ex:Bob, ex:Alice, ex:Carol ;sh:property [sh:path ex:bCode ;sh:pattern "^B" ;    # starts with 'B'sh:flags "i" ;       # Ignore case] .

ex:Bob ex:bCode "b101" .ex:Alice ex:bCode "B102" .ex:Carol ex:bCode "C103" .

4.4.4sh:languageIn

The condition specified bysh:languageIn is that the allowed language tags for eachvalue node are limited by a given list of language tags.

Constraint Component IRI:sh:LanguageInConstraintComponent

The remainder of this section is informative.

The following example shape states that all values ofex:prefLabel can be either in English or Māori.

ex:NewZealandLanguagesShapea sh:NodeShape ;sh:targetNode ex:Mountain, ex:Berg ;sh:property [sh:path ex:prefLabel ;sh:languageIn ( "en" "mi" ) ;] .

From the example instances,ex:Berg will lead to constraint violations for all of its labels.

ex:Mountainex:prefLabel "Mountain"@en ;ex:prefLabel "Hill"@en-NZ ;ex:prefLabel "Maunga"@mi .ex:Bergex:prefLabel "Berg" ;ex:prefLabel "Berg"@de ;ex:prefLabel ex:BergLabel .

4.4.5sh:uniqueLang

The propertysh:uniqueLang can be set totrue to specify that no pair ofvalue nodes may use the same language tag.

Constraint Component IRI:sh:UniqueLangConstraintComponent

The remainder of this section is informative.

ex:UniqueLangExampleShapea sh:NodeShape ;sh:targetNode ex:Alice, ex:Bob ;sh:property [sh:path ex:label ;sh:uniqueLang true ;] .

ex:Aliceex:label "Alice" ;ex:label "Alice"@en ;ex:label "Alice"@fr .ex:Bobex:label "Bob"@en ;ex:label "Bobby"@en .

4.5.1sh:equals

sh:equals specifies the condition that the set of allvalue nodes is equal to the set ofobjects of thetriples that have thefocus node assubject and thevalue ofsh:equals aspredicate.

Constraint Component IRI:sh:EqualsConstraintComponent

The remainder of this section is informative.

The following example illustrates the use ofsh:equals in a shape to specify that certain focus nodes need to have the same set of values forex:firstName andex:givenName.

ex:EqualExampleShapea sh:NodeShape ;sh:targetNode ex:Bob ;sh:property [sh:path ex:firstName ;sh:equals ex:givenName ;] .

ex:Bobex:firstName "Bob" ;ex:givenName "Bob" .

4.5.2sh:disjoint

sh:disjoint specifies the condition that the set ofvalue nodes is disjoint with the set ofobjects of thetriples that have thefocus node assubject and thevalue ofsh:disjoint aspredicate.

Constraint Component IRI:sh:DisjointConstraintComponent

The remainder of this section is informative.

SELECT DISTINCT $this ?valueWHERE {$this $PATH ?value .$this $disjoint ?value .}

The following example illustrates the use ofsh:disjoint in a shape to specify that certain focus nodes cannot share any values forex:prefLabel andex:altLabel.

ex:DisjointExampleShapea sh:NodeShape ;sh:targetNode ex:USA, ex:Germany ;sh:property [sh:path ex:prefLabel ;sh:disjoint ex:altLabel ;] .

ex:USAex:prefLabel "USA" ;ex:altLabel "United States" .ex:Germanyex:prefLabel "Germany" ;ex:altLabel "Germany" .

4.5.3sh:lessThan

sh:lessThan specifies the condition that eachvalue node is smaller than all theobjects of thetriples that have thefocus node assubject and thevalue ofsh:lessThan aspredicate.

Constraint Component IRI:sh:LessThanConstraintComponent

The remainder of this section is informative.

SELECT $this ?valueWHERE {$this $PATH ?value .$this $lessThan ?otherValue .BIND (?value < ?otherValue AS ?result) .FILTER (!bound(?result) || !(?result)) .}

The following example illustrates the use ofsh:lessThan in a shape to specify that all values ofex:startDate are "before" the values ofex:endDate.

ex:LessThanExampleShapea sh:NodeShape ;sh:property [sh:path ex:startDate ;sh:lessThan ex:endDate ;] .

4.5.4sh:lessThanOrEquals

sh:lessThanOrEquals specifies the condition that eachvalue node is smaller than or equal to all theobjects of thetriples that have thefocus node assubject and thevalue ofsh:lessThanOrEquals aspredicate.

Constraint Component IRI:sh:LessThanOrEqualsConstraintComponent

The remainder of this section is informative.

SELECT $this ?valueWHERE {$this $PATH ?value .$this $lessThan ?otherValue .BIND (?value <= ?otherValue AS ?result) .FILTER (!bound(?result) || !(?result)) .}

4.6.1sh:not

sh:not specifies the condition that eachvalue node cannotconform to a givenshape. This is comparable to negation and the logical "not" operator.

Constraint Component IRI:sh:NotConstraintComponent

The remainder of this section is informative.

The following example illustrates the use ofsh:not in a shape to specify the condition that certain focus nodes cannot have any value ofex:property.

ex:NotExampleShapea sh:NodeShape ;sh:targetNode ex:InvalidInstance1 ;sh:not [a sh:PropertyShape ;sh:path ex:property ;sh:minCount 1 ;] .

ex:InvalidInstance1 ex:property "Some value" .

4.6.2sh:and

sh:and specifies the condition that eachvalue node conforms to all provided shapes. This is comparable to conjunction and the logical "and" operator.

Constraint Component IRI:sh:AndConstraintComponent

The remainder of this section is informative.

Note that althoughsh:and has aSHACL list of shapes as its value, the order of those shapes does not impact the validation results.

The following example illustrates the use ofsh:and in a shape to specify the condition that certain focus nodes have exactly one value ofex:property. This is achieved via the conjunction of a separate named shape (ex:SuperShape) which specifies the minimum count, and a blank node shape that additionally specifies the maximum count. As shown here,sh:and can be used to implement a specialization mechanism between shapes.

ex:SuperShapea sh:NodeShape ;sh:property [sh:path ex:property ;sh:minCount 1 ;] .ex:ExampleAndShapea sh:NodeShape ;sh:targetNode ex:ValidInstance, ex:InvalidInstance ;sh:and (ex:SuperShape[sh:path ex:property ;sh:maxCount 1 ;]) .

ex:ValidInstanceex:property "One" .# Invalid: more than one propertyex:InvalidInstanceex:property "One" ;ex:property "Two" .

4.6.3sh:or

sh:or specifies the condition that eachvalue node conforms to at least one of the provided shapes. This is comparable to disjunction and the logical "or" operator.

Constraint Component IRI:sh:OrConstraintComponent

The remainder of this section is informative.

Note that althoughsh:or has aSHACL list of shapes as its value, the order of those shapes does not impact the validation results.

The following example illustrates the use ofsh:or in a shape to specify the condition that certain focus nodes have at least one value ofex:firstName or at least one value ofex:givenName.

ex:OrConstraintExampleShapea sh:NodeShape ;sh:targetNode ex:Bob ;sh:or ([sh:path ex:firstName ;sh:minCount 1 ;][sh:path ex:givenName ;sh:minCount 1 ;]) .

ex:Bob ex:firstName "Robert" .

The next example shows howsh:or can be used in aproperty shape to state that the values of the given propertyex:address may be either literals with datatypexsd:string orSHACL instances of the classex:Address.

ex:PersonAddressShapea sh:NodeShape ;sh:targetClass ex:Person ;sh:property [sh:path ex:address ;sh:or ([sh:datatype xsd:string ;][sh:class ex:Address ;])] .

ex:Bob ex:address "123 Prinzengasse, Vaduz, Liechtenstein" .

4.6.4sh:xone

sh:xone specifies the condition that eachvalue node conforms toexactly one of the provided shapes.

Constraint Component IRI:sh:XoneConstraintComponent

The remainder of this section is informative.

Note that althoughsh:xone has aSHACL list of shapes as its value, the order of those shapes does not impact the validation results.

The following example illustrates the use ofsh:xone in a shape to specify the condition that certain focus nodes must either have a value forex:fullName or values forex:firstName andex:lastName, but not both.

ex:XoneConstraintExampleShapea sh:NodeShape ;sh:targetClass ex:Person ;sh:xone ([sh:property [sh:path ex:fullName ;sh:minCount 1 ;]][sh:property [sh:path ex:firstName ;sh:minCount 1 ;] ;sh:property [sh:path ex:lastName ;sh:minCount 1 ;]]) .

ex:Bob a ex:Person ;ex:firstName "Robert" ; ex:lastName "Coin" .ex:Carla a ex:Person ;ex:fullName "Carla Miller" .ex:Dory a ex:Person ;ex:firstName "Dory" ;ex:lastName "Dunce" ;ex:fullName "Dory Dunce" .

4.7.1sh:node

sh:node specifies the condition that eachvalue node conforms to the givennode shape.

Constraint Component IRI:sh:NodeConstraintComponent

The remainder of this section is informative.

In the following example, all values of the propertyex:address must fulfill the constraints expressed by theshapeex:AddressShape.

ex:AddressShapea sh:NodeShape ;sh:property [sh:path ex:postalCode ;sh:datatype xsd:string ;sh:maxCount 1 ;] .ex:PersonShapea sh:NodeShape ;sh:targetClass ex:Person ;sh:property [   # _:b1sh:path ex:address ;sh:minCount 1 ;sh:node ex:AddressShape ;] .

ex:Bob a ex:Person ;ex:address ex:BobsAddress .ex:BobsAddressex:postalCode "1234" .ex:Reto a ex:Person ;ex:address ex:RetosAddress .ex:RetosAddressex:postalCode 5678 .

[a sh:ValidationReport ;sh:conforms false ;sh:result [a sh:ValidationResult ;sh:resultSeverity sh:Violation ;sh:focusNode ex:Reto ;sh:resultPath ex:address ;sh:value ex:RetosAddress ;sh:resultMessage "Value does not conform to shape ex:AddressShape." ;sh:sourceConstraintComponent sh:NodeConstraintComponent ;sh:sourceShape _:b1 ;]] .

4.7.2sh:property

sh:property can be used to specify that eachvalue node has a givenproperty shape.

Constraint Component IRI:sh:PropertyShapeComponent

The remainder of this section is informative.

Note that there is an important difference betweensh:property andsh:node: If a value node is violating the constraint, then there is only a single validation result forsh:node for this value node, withsh:NodeConstraintComponent as itssh:sourceConstraintComponent. On the other hand side, there may be any number of validation results forsh:property, and these will have the individual constraint components of theconstraints in theproperty shape as their values ofsh:sourceConstraintComponent.

Like with all other validation results, each time aproperty shape is reached viash:property, a validation engineMUST producefresh validation result nodes. This includes cases where the samefocus node is validated against the sameproperty shape although it is reached via different paths in theshapes graph.

4.7.3sh:qualifiedValueShape, sh:qualifiedMinCount, sh:qualifiedMaxCount

sh:qualifiedValueShape specifies the condition that a specified number ofvalue nodes conforms to the given shape. Eachsh:qualifiedValueShape can have: one value forsh:qualifiedMinCount, one value forsh:qualifiedMaxCount or, one value for each, at the samesubject.

The remainder of this section is informative.

In the following example shape can be used to specify the condition that the propertyex:parent has exactly two values, and at least one of them is female.

ex:QualifiedValueShapeExampleShapea sh:NodeShape ;sh:targetNode ex:QualifiedValueShapeExampleValidResource ;sh:property [sh:path ex:parent ;sh:minCount 2 ;sh:maxCount 2 ;sh:qualifiedValueShape [sh:path ex:gender ;sh:hasValue ex:female ;] ;sh:qualifiedMinCount 1 ;] .

ex:QualifiedValueShapeExampleValidResourceex:parent ex:John ;ex:parent ex:Jane .ex:Johnex:gender ex:male .ex:Janeex:gender ex:female .

The following example illustrates the use ofsh:qualifiedValueShapesDisjoint to express that a hand must have at most 5 values ofex:property (expressed usingsh:maxCount), and exactly one of them must be an instance ofex:Thumb while exactly 4 of them must be an instance ofex:Finger but thumbs and fingers must be disjoint. In other words, on a hand, none of the fingers can also be counted as the thumb.

ex:HandShapea sh:NodeShape ;sh:targetClass ex:Hand ;sh:property [sh:path ex:digit ;sh:maxCount 5 ;] ;sh:property [sh:path ex:digit ;sh:qualifiedValueShape [ sh:class ex:Thumb ] ;sh:qualifiedValueShapesDisjoint true ;sh:qualifiedMinCount 1 ;sh:qualifiedMaxCount 1 ;] ;sh:property [sh:path ex:digit ;sh:qualifiedValueShape [ sh:class ex:Finger ] ;sh:qualifiedValueShapesDisjoint true ;sh:qualifiedMinCount 4 ;sh:qualifiedMaxCount 4 ;] .

4.8.1sh:closed, sh:ignoredProperties

The RDF data model offers a huge amount of flexibility. Any node can in principle have values for any property. However, in some cases it makes sense to specify conditions on which properties can be applied to nodes. The SHACL Core language includes a property calledsh:closed that can be used to specify the condition that each value node hasvalues only for those properties that have been explicitly enumerated via theproperty shapes specified for the shape viash:property.

Constraint Component IRI:sh:ClosedConstraintComponent

The remainder of this section is informative.

The following example illustrates the use ofsh:closed in a shape to specify the condition that certain focus nodes only have values forex:firstName andex:lastName. The "ignored" propertyrdf:type would also be allowed.

ex:ClosedShapeExampleShapea sh:NodeShape ;sh:targetNode ex:Alice, ex:Bob ;sh:closed true ;sh:ignoredProperties (rdf:type) ;sh:property [sh:path ex:firstName ;] ;sh:property [sh:path ex:lastName ;] .

ex:Aliceex:firstName "Alice" .ex:Bobex:firstName "Bob" ;ex:middleInitial "J" .

4.8.2sh:hasValue

sh:hasValue specifies the condition that at least onevalue node is equal to the given RDF term.

Constraint Component IRI:sh:HasValueConstraintComponent

The remainder of this section is informative.

ex:StanfordGraduatea sh:NodeShape ;sh:targetNode ex:Alice ;sh:property [sh:path ex:alumniOf ;sh:hasValue ex:Stanford ;] .

ex:Aliceex:alumniOf ex:Harvard ;ex:alumniOf ex:Stanford .

4.8.3sh:in

sh:in specifies the condition that eachvalue node is amember of a providedSHACL list.

Constraint Component IRI:sh:InConstraintComponent

The remainder of this section is informative.

Note that matching of literals needs to be exact, e.g."04"^^xsd:byte does not match"4"^^xsd:integer.

ASK {GRAPH $shapesGraph {$in (rdf:rest*)/rdf:first $value .}}

ex:InExampleShapea sh:NodeShape ;sh:targetNode ex:RainbowPony ;sh:property [sh:path ex:color ;sh:in ( ex:Pink ex:Purple ) ;] .

ex:RainbowPony ex:color ex:Pink .

5.2.1Prefix Declarations for SPARQL Queries

Ashapes graph may include declarations of namespace prefixes so that these prefixes can be used to abbreviate the SPARQL queries derived from the same shapes graph. The syntax of such prefix declarations is illustrated by the following example.

ex:a owl:Ontology ;owl:imports sh: ;sh:declare [sh:prefix "ex" ;sh:namespace "http://example.com/ns#"^^xsd:anyURI ;] ;sh:declare [sh:prefix "schema" ;sh:namespace "http://schema.org/"^^xsd:anyURI ;] .

Thevalues of the propertysh:declare areIRIs orblank nodes, and these values are calledprefix declarations. The SHACL vocabulary includes the classsh:PrefixDeclaration as type for suchprefix declarations although nordf:type triple is required for them.Prefix declarations have exactly one value for the propertysh:prefix.The values ofsh:prefix areliterals of datatypexsd:string.Prefix declarations have exactly one value for the propertysh:namespace.The values ofsh:namespace areliterals of datatypexsd:anyURI. Such a pair of values specifies a single mapping of a prefix to a namespace.

The recommendedsubject for values ofsh:declare is the IRI of the named graph containing the shapes that use the prefixes. These IRIs are often declared as an instance ofowl:Ontology, but this is not required.

Prefix declarations can be used bySPARQL-based constraints, thevalidators ofSPARQL-based constraint components, and by similar features defined by SHACL extensions. These nodes can use the propertysh:prefixes to specify a set of prefix mappings. An example use of thesh:prefixes property can be found in theexample above.

The values ofsh:prefixes are eitherIRIs orblank nodes.A SHACL processor collects a set of prefix mappings as the union of allindividual prefix mappings that arevalues of theSPARQL property pathsh:prefixes/owl:imports*/sh:declareof theSPARQL-based constraint orvalidator.If such a collection of prefix declarations contains multiple namespaces for the samevalue ofsh:prefix,then theshapes graph isill-formed. (Note that SHACL processorsMAY ignore prefix declarations that are never reached).

A SHACL processor transforms the values ofsh:select (and similar properties such assh:ask) into SPARQL by prependingPREFIX declarations for all prefix mappings. Each value ofsh:prefix is turned into thePNAME_NS, while each value ofsh:namespace is turned into theIRIREF in thePREFIX declaration. For the example shapes graph above, a SHACL-SPARQL processor would produce lines such asPREFIX ex: <http://example.com/ns#>. The SHACL-SPARQL processorMUST produce afailure if the resulting query string cannot be parsed into a valid SPARQL 1.1 query.

In the rest of this document, thesh:prefixes statements may have been omitted for brevity.

5.3.1Pre-bound Variables in SPARQL Constraints ($this, $shapesGraph, $currentShape)

When the SPARQL queries ofSPARQL-based constraints and thevalidators ofSPARQL-based constraint components areprocessed, the SHACL-SPARQL processorpre-binds values for the variables in the following table.

5.3.2Mapping of Solution Bindings to Result Properties

The propertyvalues of the validation result nodes are derived by the following rules, through a combination of result solutions and the values of the constraint itself. The rules are meant to be executed from top to bottom, so that the first bound value will be used.

6.2.1Parameter Declarations (sh:parameter)

Theparameters of aconstraint component are declared via the propertysh:parameter. The values ofsh:parameter are calledparameter declarations. The classsh:Parameter may be used astype ofparameter declarations but no such triple is required.Eachparameter declaration has exactly one value for the propertysh:path.Atparameter declarations, thevalue ofsh:path is anIRI.

Thelocal name of anIRI is defined as the longestNCNAME at the end of theIRI, not immediately preceded by the first colon in theIRI. Theparameter name of aparameter declaration is defined as thelocal name of thevalue ofsh:path. To ensure that a correct mapping from parameters into SPARQL variables is possible, the following syntax rules apply:

Everyparameter name is a validSPARQL VARNAME.Parameter names must not be one of the following:this,shapesGraph,currentShape,path,PATH,value.A constraint component where two or moreparameter declarations use the sameparameter names isill-formed.

The values ofsh:optional must be literals with datatypexsd:boolean.Aparameter declaration can have at most one value for the propertysh:optional. If set totrue then the parameter declaration declares anoptional parameter.Everyconstraint component has at least one non-optional parameter.

The classsh:Parameter is defined as aSHACL subclass ofsh:PropertyShape, and all properties that are applicable to property shapes may also be used for parameters. This includes descriptive properties such assh:name andsh:description but also constraint parameters such assh:class.Shapes that do notconform with the constraints declared for the parameters areill-formed. Some implementationsMAY use these constraint parameters to prevent the execution of constraint components with invalid parameter values.

6.2.2Label Templates (sh:labelTemplate)

The propertysh:labelTemplate can be used at anyconstraint component to suggest howconstraints could be rendered to humans.The values ofsh:labelTemplate are strings (possibly with language tag) and are calledlabel templates.

The remainder of this section is informative.

Label templates can include the names of the parameters that are declared for the constraint component using the syntaxes{?varName} or{$varName}, wherevarName is the name of theparameter name. At display time, these{?varName} and{$varName} blocksSHOULD be replaced with the actual parameter values. There may be multiple label templates for the same subject, but they should not have the same language tags.

6.2.3Validators

For every supported shape type (i.e.,property shape ornode shape) the constraint component declares a suitablevalidator. For a given constraint, a validator is selected from the constraint component using the following rules, in order:

1. Fornode shapes, use one of the values ofsh:nodeValidator, if present.
2. Forproperty shapes, use one of the values ofsh:propertyValidator, if present.
3. Otherwise, use one of the values ofsh:validator.

If no suitable validator can be found, a SHACL-SPARQL processor ignores the constraint.

SHACL-SPARQL includes two types of validators, based onSPARQL SELECT (forsh:nodeValidator andsh:propertyValidator) orSPARQL ASK queries (forsh:validator).

ex:LanguageConstraintComponentUsingSELECTa sh:ConstraintComponent ;rdfs:label "Language constraint component" ;sh:parameter [sh:path ex:lang ;sh:datatype xsd:string ;sh:minLength 2 ;sh:name "language" ;sh:description "The language tag, e.g. \"de\"." ;] ;sh:labelTemplate "Values are literals with language \"{$lang}\"" ;sh:propertyValidator [a sh:SPARQLSelectValidator ;sh:message "Values are literals with language \"{?lang}\"" ;sh:select """SELECT DISTINCT $this ?valueWHERE {$this $PATH ?value .FILTER (!isLiteral(?value) || !langMatches(lang(?value), $lang))}"""] .

ex:LanguageExampleShapea sh:NodeShape ;sh:targetClass ex:Country ;sh:property [sh:path ex:germanLabel ;ex:lang "de" ;] ;sh:property [sh:path ex:englishLabel ;ex:lang "en" ;] .

ex:LanguageConstraintComponentUsingASKa sh:ConstraintComponent ;rdfs:label "Language constraint component" ;sh:parameter [sh:path ex:lang ;sh:datatype xsd:string ;sh:minLength 2 ;sh:name "language" ;sh:description "The language tag, e.g. \"de\"." ;] ;sh:labelTemplate "Values are literals with language \"{$lang}\"" ;sh:validator ex:hasLang .ex:hasLanga sh:SPARQLAskValidator ;sh:message "Values are literals with language \"{$lang}\"" ;sh:ask """ASK {FILTER (isLiteral($value) && langMatches(lang($value), $lang))}""" .