Abstract

This document defines an abstract syntax for the core SHACL (SHApes Constraint Language). It is derived from the SHACL specification[shacl] and is a non-normative version of the content of that specification.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This is currently a Working Draft. It is not decided whether this will be a Working Group Note, a Working Group Recommendation, or an appendix to the SHACL specification.

This document was published by the RDF Data Shapes Working Group as a First Public Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-rdf-shapes@w3.org (subscribe, archives). All comments are welcome.

Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 September 2015 W3C Process Document.

1. Introduction

This section is non-normative.

SHACL (Shapes Constraint Language) is a language for describing and constraining the contents of RDF graphs[rdf11-concepts]. SHACL constraints are grouped into "shapes", which may also be referenced by constraints in other shapes. These constraints describe the triples[rdf11-concepts] connecting certain nodes in the graph.

2. Notation

The abstract syntax consists of statements defining data structures and named members of those data structures. Each member has either a single type or two or more types that are a union (choice) of types. Each type is either a reference to another statement, an RDF type, or a SPARQL literal term (e.g. numeric)[sparql11-query], or the template type Set, which signifies a logical set of a type. Sets are unordered and duplicate members have no significance; the set (1, 1, 2, 3, 5) is the same as the set (5, 1, 3, 2).

In this notation:

Shape := label:IRI|BNode, targets:Set[Target], filters:Set[Shape], constraints:Set[Constraint]

This signifies that a Shape has four components called label, targets, filters, constraints. The label is either a IRI or BNode, the targets are a set of Targets, the filters are a set of Shapes, and the constraints is a set of Constraints. IRI and BNode are defined in RDF 1.1 Semantics[rdf11-mt]. Target, Shape and Constraint are defined terms within this document.

The term definitions given in this document rely on matching triple patterns in the form (subject, predicate, object) where each position may be supplied by a constant, a previously defined term, or the underscore "_", which represents a previously undefined element or wildcard. This corresponds to a SPARQL Triple Pattern where each "_" is replaced by a unique blank node. Matching such a triple pattern against a graph is defined by SPARQL Basic Graph Pattern Matching (BFP) with a BGP containing only that triple pattern.

Sections defining the RDF representation of SHACL with have a .rdf class.

Results of validation are represented in a table associating node/shape pairs with a pass or fail and a reason for failure:

shape node result reason
<Shape1> <node1> pass
<Shape1> <node2> fail no ex:state supplied.

3. Schemas and Shapes

The SHACL environment uses two inputs: a SHACL instance graph, and a data graph. A SHACL instance consists of schemas and shapes. A Schema is a set of one or more Shapes. A Shape is a set of Targets, Filters, and Constraints. Each shape has a label that is an IRI or BNode. Targets define the nodes in the data graph that are selected as targets for comparison. Filters provide further refinement of the targets if needed. The targeted nodes in the data graph are called "focus nodes."

Schema := shapes:Set[Shape]
Shape := label:IRI|BNode, targets:Set[Target], filters:Set[Shape], constraints:Set[Test]
Test := Constraint|Algebraic

Shapes are represented in RDF as a subject node that is the shape's label with a set of properties identifying the types of any targets, filters and constraints. For a first example, a specific form of Constraint, a PathConstraint , which requires that conforming nodes have a foaf:name property with a value that is an RDF literal would look like this:

[ sh:predicate foaf:name; sh:nodeKind sh:Literal ] .

A Shape with the label IRI <http://a.example/Person> and only that constraint would have a sh:property arc connecting the shape label to the above constraint:

<Person> sh:property [ sh:predicate foaf:name; sh:nodeKind sh:Literal ] .

Here, sh:property identifies a PathConstraint constraint; other properties identify other forms of targets, filters and constraints. These properties will be enumerated in the definitions below.

The SHACL instance graph identifies the nodes in the data graph selected through targets and filters and that will be compared against the defined constraints. The data graph nodes that are identified by the targets and filters are call "focus nodes". Focus nodes are all nodes in the graph that:

  1. match any of the targets, and
  2. pass all of the filter Shapes. [deal with this somewhere (Targets in filter Shapes have no effect.)]

While SHACL can be used for documenting data structures or the input and output of processes, driving user interface generation or navigation, these processes all require testing some nodes in a graph against shapes. This process is called "validation" and the result is called a "validation result". The validation result is fail if validating any Test against each "focus node" returned fail, otherwise pass.

4. Constraints

Constraint := NodeConstraint|PathConstraint

Both PathConstraints and NodeConstraints include a set of Parameters. Constraints select a set of "value nodes" and then test the conformance of the value nodes against each Parameter.

Issue 1

It's possible that renaming Constraints to Selectors and Parameters to Constraints would clarify this specification. Please send feedback to public-rdf-shapes.

Parameters are either unary or n-ary. Validation of a unary Parameter can be performed on each value node individually. The result of validating a set of value nodes against a set of unary parameters is fail if any individual value node failed any Parameter, otherwise pass. The result of validating a set of value nodes against a set of n-ary parameters is fail if the set of value nodes failed any Parameter, otherwise pass.

Note that the Paramenter arguments include "numeric" which is the set of SPARQL numeric types enumerated in SPARQL Operand Data Types SPARQL Operand Data Types.

NodeConstraint := parms:Set[Parameter]

Testing a NodeConstraint against a focus node returns all of the errors from testing each Parameter (Node Constraint Parameter) against the value node where the value node is the focus node.

PathConstraint := path:SPARQLPropertyPath, parms:Set[Parameter]

A SPARQLPropertyPath is a property path as defined in [sparql11-query]. Testing a PathConstraint against a focus node returns all of the errors from testing each Parameter against each value node in the SPARQL1.1 Property Path Pattern (focus node, path, value node). The path is an expression in the SPARQL1.1 Property Path language excluding the forms of negation: NegatedPropertySet. Note that this includes InversePath.

5. Parameters

Parameter := NodeKind | In | Class | Datatype | MinLength | MaxLength | Pattern | Stem | MinInclusive | MinExclusive | MaxInclusive | MaxExclusive | LessThanEquals | LessThan | Equals | Disjoint | HasShape | UniqueLang | HasValue | MinCount | MaxCount | QualifiedMinCount | QualifiedMaxCount | QualifiedValueShape | Algebraic | Target

The specific ways a value or value set can be constrained are called Parameters. They are grouped below into unary and n-ary parameters depending on whether they evaluate a value node or a set of value nodes. Parameters take one or more arguments.

Note that RDF graphs do not include triples with a literal subject so tests of literal values can only succeed if applied to PathConstraint with a final path component with is not inverse. Other Parameters are only defined for PathConstraint. The symbol PC indicates Parameters which should only be used in a PathConstraint.

5.1 Unary Parameters

Unary Parameters evaluate each node in the set of value nodes which were selected by the Constraints.

5.1.1 RDF term type of value node

NodeKind := kind:"IRI"|"blank node"|"literal"

Testing a NodeKind parameter against a value node returns fail if

  • kind = "IRI" and value node is not an IRI
  • kind = "blank node" and value node is not an blank node
  • kind = "literal" and value node is not an RDFLiteral

A NodeKind parameter is connected to a constraint by the sh:nodeKind predicate; the node kinds are represented by the constants sh:IRI, sh:BlankNode and sh:literal respectively. The following combinations represent disjunctions of the above node kinds: sh:BlankNodeOrIRI, sh:IRIOrLiteral, sh:BlankNodeOrLiteral, sh:IRIOrLiteral, sh:BlankNodeOrIRI, sh:BlankNodeOrLiteral.

Parameters example 1
<IssueShape> sh:property [ sh:predicate ex:state; sh:nodeKind sh:IRI ] .
<issue1> ex:state ex:HunkyDory .
<issue2> ex:taste ex:GoodEnough .
<issue3> ex:state "just fine" .
shape node result reason
<IssueShape> <issue1> pass
<IssueShape> <issue2> pass
<IssueShape> <issue3> fail ex:state expected to be an IRI, literal found.

Note that <issue2> passes even though it has no sh:state property. To require a property, one must use cardinality parameters as described below in Cardinality.

5.1.2 RDF term equivalence

In := vals:Set[RDF term]

Testing a In parameter against a value node returns fail if the value node is not in the set vals.

An In parameter in RDF is represented as an RDF collection connected to a constraint by the sh:in predicate.

Parameters example 3
<NoActionIssueShape> sh:property [ sh:predicate ex:state; sh:in (ex:Resolved, ex:Rejected) ] .
<issue1> ex:state ex:Resolved .
<issue2> ex:state ex:Unresolved .
shape node result reason
<IssueShape> <issue1> pass
<IssueShape> <issue2> fail ex:state expected to be ex:Resolved, ex:Unresolved found.
Note

The n-ary variant HasValue passes if any value matches the supplied argument.

Class := t:IRI

Testing a Class parameter against a value node returns fail if there is no triple (focus node, rdf:type, X) where X is the subject of any triple matched by the SPARQL1.1 path expression (X, rdf:subClassOf*, t) matches 0 triples.

5.1.3 Datatype

Datatype := dt:IRI

Testing a Datatype parameter against a value node returns fail if the value node is not an RDFLiteral or of the datatype of the value node is not the same RDF term as dt.

A Datatype parameter is connected to a constraint by the sh:datatype predicate.

Parameters example 4
<IssueShape> sh:property [ sh:predicate ex:submittedOn; sh:datatype xsd:dateTime ] .
<issue1> ex:submittedOn "2016-07-08"^^xsd:date .
<issue2> ex:submittedOn "2016-07-08T01:23:45Z"^^xsd:dateTime .
shape node result reason
<IssueShape> <issue1> pass
<IssueShape> <issue2> fail ex:submittedOn expected to be an xsd:date, xsd:dateTime found.

5.1.4 XML Schema string facets

MinLength := ref:numeric

Testing a MinLength paramenter against a value node returns fail if the lexical form of the value node is longer than ref.

A MinLength parameter is connected to a constraint by the sh:minLength predicate.

Parameters example 5
<IssueShape> sh:property [ sh:predicate ex:submittedBy; sh:minLength 20 ] .
<issue1> ex:submittedBy <http://a.example/bob> . # 20 characters
<issue2> ex:submittedBy "Bob" . # 3 characters
shape node result reason
<IssueShape> <issue1> pass
<IssueShape> <issue2> fail ex:submittedOn expected to be >= 20 characters,
3 characters found.
MaxLength := ref:numeric

Testing a MaxLength paramenter against a value node returns fail if the lexical form of the value node is shorter than ref.

A MaxLength parameter is connected to a constraint by the sh:maxLength predicate.

Pattern := pat:RDFLiteral, flagstr:RDFLiteral

A Pattern parameter is evaluated against the SPARQL regex function with the lexical form of value node as the text parameter, pat as the pattern parameter and flagstr as the flags parameter. The test returns fail is the result is false or produces an XPath type error.

A Pattern parameter is connected to a constraint by the sh:pattern predicate. An optional sh:flags property can supply the flags parameter. It is an error for a constraint to have more than one sh:flags property or a single sh:flags property and more than one sh:pattern property.

Parameters example 6
<IssueShape1> sh:property [ sh:predicate ex:submittedBy; sh:pattern "^HtTp://" ; sh:flags "i" ] .
<IssueShape2> sh:property [ sh:predicate ex:submittedBy; sh:pattern " +" ; sh:flags "@" ] .
<issue1> ex:submittedBy <http://a.example/bob> . # matches <IssueShape1>'s case-insensitive pattern
<issue2> ex:submittedBy "http://hahaha!" . # also matches <IssueShape1>'s pattern
<issue3> ex:submittedBy <mailto:bob@example.com> .
shape node result reason
<IssueShape1> <issue1> pass
<IssueShape1> <issue2> pass
<IssueShape1> <issue3> fail mailto:bob@example.com does not match the pattern /^HtTp:\/\//i
<IssueShape2> <issue1> fail @ is not a valid flag string.
<IssueShape2> <issue2> fail @ is not a valid flag string.
Stem := str:RDFLiteral

Testing a Stem parameter against a value node returns fail if the value node is not an IRI or the lexical form of the value node does not start with str.

5.1.5 XML Schema numeric facets

MinInclusive := ref:RDFLiteral PC

Testing a MinInclusive parameter against a value node returns fail if the evaluation of (value node >= ref) in SPARQL1.1 Operator Mapping returns false or results in a type error.

A MinInclusive parameter is connected to a constraint by the sh:minInclusive predicate.

Parameters example 7
<IssueShape> sh:property [ sh:predicate ex:confirmations; sh:minInclusive 1 ] .
<issue1> ex:confirmations 1 .
<issue2> ex:confirmations 0 .
<issue3> ex:confirmations "ii"^^ex:romanNumeral .
shape node result reason
<IssueShape> <issue1> pass
<IssueShape> <issue2> fail 0 is less than 1.
<IssueShape> <issue3> fail ex:romanNumeral is not a numeric datatype.
MinExclusive := ref:RDFLiteral PC

Testing a MinExclusive parameter against a value node returns fail if the evaluation of (value node > ref) in SPARQL1.1 Operator Mapping returns false or results in a type error.

A MinExclusive parameter is connected to a constraint by the sh:minExclusive predicate.

MaxInclusive := ref:RDFLiteral PC

Testing a MaxInclusive parameter against a value node returns fail if the evaluation of (value node <= ref) in SPARQL1.1 Operator Mapping returns false or results in a type error.

A MaxInclusive parameter is connected to a constraint by the sh:maxInclusive predicate.

MaxExclusive := ref:RDFLiteral PC

Testing a MaxExclusive parameter against a value node returns fail if the evaluation of (value node < ref) in SPARQL1.1 Operator Mapping returns false or results in a type error.

A MaxExclusive parameter is connected to a constraint by the sh:maxExclusive predicate.

5.1.6 Comparison with specified property

Comparison parameters compare the value node against each value reachable by a specified property siblingProp. Note that these are (currently) limited to "arcs out" of the focus node, i.e. triples matching (focus node, siblingProp, _).

LessThanEquals := siblingProp:RDFLiteral PC

Let siblingVals be the set of objects in triples matching (focus node, siblingProp, siblingVal). Testing a LessThanOrEquals parameter against a value node returns fail if evaluating the SPARQL1.1 Operator (value node = siblingVal) for any siblingVal in siblingVals returns false or results in a type error.

A LessThanOrEqual's siblingProp parameter is connected to a constraint by the sh:lessThanOrEquals predicate.

Parameters example 8

Supposed different departments can assign different criticalities (how important is it) and priorities (how soon should it get fixed) to issues and that no priority may be lower than a criticality:

# Lower number means higher priority or criticality.
<IssueShape> sh:property [ sh:predicate ex:priority; sh:lessThanEquals ex:criticality ] .
<issue1> ex:criticality 3; ex:priority 2 .
<issue2> ex:priority 1, 4 . # No criticality against which to compare
<issue3> ex:criticality 2, 5; ex:priority 1, 4 .
<issue4> ex:criticality ex:Low; ex:priority ex:Medium .
<issue5> ex:criticality ex:Low; ex:priority 1 .
shape node result reason
<IssueShape> <issue1> pass
<IssueShape> <issue2> pass
<IssueShape> <issue3> fail 4 greater than 2.
<IssueShape> <issue4> fail "Medium" greater than "Low".
<IssueShape> <issue5> fail 1 not comparable with ex:Low.
LessThan := siblingProp:RDFLiteral PC

Let siblingVals be the set of objects in triples matching (focus node, siblingProp, siblingVal). Testing a LessThan parameter against a value node returns fail if evaluating the SPARQL1.1 Operator (value node < siblingVal) for any siblingVal in siblingVals returns false or results in a type error.

A LessThan's siblingProp parameter is connected to a constraint by the sh:lessThan predicate.

Equals := siblingProp:RDFLiteral PC

Let siblingVals be the set of objects in triples matching (focus node, siblingProp, siblingVal). Testing an Equals parameter against a value node returns fail if evaluating the SPARQL1.1 Operator (value node = siblingVal) for any siblingVal in siblingVals returns false or results in a type error.

A Equal's siblingProp parameter is connected to a constraint by the sh:equals predicate.

Disjoint := siblingProp:RDFLiteral

Let siblingVals be the set of objects in triples matching (focus node, siblingProp, siblingVal). Testing a Disjoint parameter against a value node returns fail if evaluating the SPARQL1.1 Operator (value node != siblingVal) for any siblingVal in siblingVals returns false or results in a type error.

A Disjoint's siblingProp parameter is connected to a constraint by the sh:disjoint predicate.

5.1.7 Nested shape constraints

HasShape := nested:Shape

Testing a HasShape parameter against a value node returns any errors returned when validating the value node as nested (c.f. definition of Shape above).

A Disjoint's nested parameter is connected to a constraint by the sh:shape predicate.

Parameters example 9
<IssueShape> sh:property [
    sh:predicate ex:submittedBy; sh:shape <UserShape> ] .
<UserShape> sh:property [
    sh:predicate dc:creator; sh:nodeKind sh:IRI ] . 
<issue1> ex:submittedBy [ dc:creator <mailto:alice@example.com> ] .
<issue2> ex:submittedBy [ dc:creator "amy" ] .
<issue1> ex:submittedBy <mailto:andrea@example.com> .
shape node result reason
<IssueShape> <issue1> pass
<IssueShape> <issue2> fail expected dc:creator to be an IRI.
<IssueShape> <issue3> fail expected ex:submittedBy to match <UserShape>.

5.2 N-ary Parameters

N-ary Parameters evaluate the set of value nodes which were selected by the Constraints.

5.2.1 Uniqueness

UniqueLang := b:boolean PC

Testing a UniqueLang parameter against a set of value nodes returns fail if b is true and two or more of the value nodes are RDFLiterals with the same language tag.

Parameters example 10
<IssueShape> sh:property [ sh:predicate ex:label; sh:uniqueLang true ] ;
             sh:property [ sh:predicate ex:description; sh:uniqueLang false ] ;
             sh:property [ sh:predicate ex:notes; sh:nodeKind sh:literal ] .
<issue2> ex:description "no Save As support"@en", "pas de Sauvegarder Sous""@fr ;
         ex:description "there's no way to save a document under another filename"@en" ;
         ex:notes "Shouldn't ADB take care of this?"@en .
<issue2> ex:label "grammar conflict"@en, "conflit analyse"@en ;
         ex:description "shift/reduce confict"@en", "reduce/reuse/recycle conflict"@en ;
         ex:notes "tried left factor"@en, "tried substitution"@en .
<issue3>
         ex:description "vague reports of random crashes"@en .
shape node result reason
<IssueShape> <issue1> pass
<IssueShape> <issue2> fail multiple ex:label values with same language tag.
<IssueShape> <issue3> pass

5.2.2 RDF term equivalence

HasValue := val:RDF term

Testing a HasValue parameter against a value node returns fail if the set of value nodes is non-empty and no element of value nodes is the same term as val.

A HasValue parameter is connected to a constraint by the sh:hasValue predicate.

Parameters example 2
<ResolvedIssueShape> sh:property [ sh:predicate ex:state; sh:hasValue ex:Resolved ] .
<issue1> ex:state ex:Resolved .
<issue2> ex:state ex:Resolved, ex:Referred .
<issue3> ex:state ex:Unresolved, ex:Referred .
shape node result reason
<ResolvedIssueShape> <issue1> pass
<ResolvedIssueShape> <issue2> pass
<ResolvedIssueShape> <issue3> fail ex:state expected to be ex:Resolved, ex:Unresolved found.

5.2.3 Cardinality

The MinCount and MaxCount Parameters on a Constraint with property P identify the minimum and maximum number of triples (value node, P, _) may exist in the instance data. Unless provided, the MinCount is 0 and the MaxCount in infinite.

MinCount := ref:numeric PC

Testing a MinCount parameter against a set of value nodes returns fail if the number of value nodes is less than ref.

MaxCount := ref:numeric PC

Testing a MaxCount parameter against a set of value nodes returns fail if the number of value nodes is greater than ref.

Parameters example 11
<IssueShape> sh:property [ sh:predicate ex:status; sh:minCount 1; sh:maxCount 1 ] ;
             sh:property [ sh:predicate ex:notes; sh:nodeKind sh:literal ] .
<issue1> ex:status ex:Confirmed .
<issue2> ex:status ex:Confirmed, ex:Assigned .
<issue3> ex:notes "shouldn't QC have caught this?" .
shape node result reason
<IssueShape> <issue1> pass
<IssueShape> <issue2> fail expected at most 1 ex:status.
<IssueShape> <issue3> fail expected at least 1 ex:status.

5.2.4 QualifiedCardinality

QualifiedMinCount := ref:numeric PC
QualifiedMaxCount := ref:numeric PC
QualifiedValueShape := nested:Shape PC

QualifiedMinCount and QualifiedMaxCount restrict the set of value nodes to those that pass the Shape QualifiedValueShape. Once the value set is restricted, their evaluation is the same as the evaluation of MinCount and MaxCount respecctively.

Parameters example 12

Every approved issue must be signed by one person from
engineering and at least one from quality assurance:

<ApprovedIssueShape>
  sh:sh:property [
    sh:predicate ex:approvedBy; sh:qualifiedShape [
        sh:pattern "^mailto:.*?@engineering.example" ] ;
    sh:qualifiedMinCount 1; sh:qualifiedMaxCount 1 ] ,
  sh:sh:property [
    sh:predicate ex:approvedBy; sh:qualifiedShape [
        sh:pattern "^mailto:.*?@qa.example" ] ;
    sh:qualifiedMinCount 1 ] .
<issue1> ex:approvedBy <mailto:alice@engineering.example>, <mailto:pat@admin.example>,
    <mailto:bob@qa.example>, <mailto:eve@qa.example> .
<issue2> ex:approvedBy <mailto:amy@engineering.example>,
    <mailto:brett@engeering.example>, <mailto:cynthia@qa.example> .
<issue3> ex:approvedBy <mailto:angel@engineering.example> .
shape node result reason
<IssueShape> <issue1> pass
<IssueShape> <issue2> fail expected at most 1 ex:approvedBy matching
"^mailto:.*?@engineering.example".
<IssueShape> <issue3> fail expected at least 1 ex:approvedBy matching
"^mailto:.*?@qa.example".

Additional ex:approvedBy matching neither "^mailto:.*?@engineering.example" nor "^mailto:.*?@qa.example" are not constrainted, c.f. <mailto:amy@engineering.example> on <Issue1>.

6. Logical operators

Algebraic := And|Or|Not

Algebraic operators provide logical combinations of shapes.

And := shapes:Set[Shape]

Testing an And parameter against a value node returns pass if validating each member of the set shapes against the value node returned pass, otherwise fail.

An And parameter is an RDF Collection of shapes connected to a constraint by the sh:and predicate.

Algebraics example 1
<Person> sh:property [ sh:predicate foaf:name; sh:nodeKind sh:Literal ] .
<Customer> sh:property [ sh:predicate corp:custId; sh:datatype xsd:integer ] .
<User> sh:constraint [ sh:and (<Person> <Customer>) ] .
<user1> foaf:name "Alice"; corp:custId 1234 .
<user2> foaf:name "Bob"; corp:custId 1234.0 .
shape node result reason
<User> <user1> pass
<User> <user2> fail "1234.0" is an xsd:double.
Or := shapes:Set[Shape]

Testing an Or parameter against a value node returns fail if validating each member of the set shapes against the value node returned fail, otherwise pass.

An Or parameter is an RDF Collection of shapes connected to a constraint by the sh:or predicate.

Algebraics example 2
<Person> sh:property [ sh:predicate foaf:name; sh:nodeKind sh:Literal; sh:minCount 1 ] .
<Customer> sh:property [ sh:predicate corp:custId; sh:datatype xsd:integer ] .
<User> sh:constraint [ sh:or (<Person> <Customer>) ] .
<user1> foaf:name "Alice"; corp:custId 12 .
<user2> foaf:givenName "Bob"; corp:custId 34 .
<user2> foaf:name "Eve"; corp:custId 56.0 .
<user2> foaf:name [ rdfs:value "Bob" ]; corp:customerId 78.0 .
shape node result reason
<User> <user1> pass
<User> <user2> pass
<User> <user3> pass
<User> <user4> fail no foaf:name supplied and
"78.0" is an xsd:double.
Not := shape:Shape

Testing a Not parameter against a value node returns pass if validating shape against the value node returned fail, otherwise fail.

A Not parameter is a single shape connected to a constraint by the sh:not predicate.

In this example, the not inverts the truth values of the or example above.

Algebraics example 3
<Person> sh:property [ sh:predicate foaf:name; sh:nodeKind sh:Literal ] .
<Customer> sh:property [ sh:predicate corp:custId; sh:datatype xsd:integer ] .
<User> sh:constraint [ sh:not [ sh:or (<Person> <Customer>) ] ] .
<user1> foaf:name "Alice"; corp:custId 12 .
<user2> foaf:givenName "Bob"; corp:custId 34 .
<user2> foaf:name "Eve"; corp:custId 56.0 .
<user2> foaf:name [ rdfs:value "Bob" ]; corp:customerId 78.0 .
shape node result reason
<User> <user1> pass foaf:name is an RDFLiteral and
"12" is an xsd:integer.
<User> <user2> pass "34" is an xsd:integer.
<User> <user3> pass foaf:name is an RDFLiteral
<User> <user4> fail

7. Targets

A SHACL target designates which nodes in the data graph will be validated against the defined constraints. A Target is defined either by matching a node label (TargetNode) in the data graph, a type statement using rdf:type (TargetClass) or a subject IRI (TargetSubjectsOf) or an object IRI (TargetObjectsOf.

Target := TargetNode|TargetClass|TargetSubjectsOf|TargetObjectsOf

The simplest form of Target directly identifies nodes the data graph:

TargetNode := node:IRI|literal|BNode
Issue 2

BNodes as TargetNodes depends on being able to name a blank node in an RDF graph. SPARQL1.1 had this as a proposed feature but did not implement it (see some of the SPARQL discussion).

A TargetNode matches node if node appears as a node (any subject or object in a triple) in the data graph.

A TargetNode is connected to a shape by the sh:targetNode property.

Targets example 1

In a graph with multiple nodes:

<http://a.example/Alice> foaf:name "Alice" ; foaf:knows <http://a.example/Bob> .
<http://a.example/Bob> foaf:name "Bob" .
<http://a.example/Sue> foaf:name "Sue" .

sh:targetNode could select a subset of them to be tested against the <Person> and <Name> shapes:

<PersonShape> sh:targetNode <http://a.example/Bob>, <http://a.example/Sue> .
<NameShape> sh:targetNode "Alice", "Bob" .
TargetClass := type:IRI

A TargetClass matches any node in the data graph with the triple (node, rdf:type, type) or any node which is of a type which is a transitive rdfs:subClassOf type.

A TargetClass is connected to a shape by the sh:targetClass property.

Targets example 2

In a graph with nodes of types ex:student, ex:teacher and ex:class:

<http://a.example/Alice> a ex:student .
<http://a.example/Bob> a ex:professor . ex:professor rdfs:subClassOf ex:teacher .
<http://a.example/Art> a ex:class .

sh:targetClass selects the subset of them to be tested against the <IssueShape> shape:

<TeacherShape> sh:targetClass ex:teacher .

This selects <http://a.example/Bob> for validation.

TargetSubjectsOf := predicate:IRI

A TargetSubjectsOf matches any subject node in the data graph with a triple (node, predicate, _) where "_" is any node.

A TargetSubjectsOf is connected to a shape by the sh:targetSubjectsOf property.

Targets example 3

In a graph with some triples with ex:ex:submittedOn predicates:

<http://a.example/Issue1> ex:submittedOn "2015-07-08" .
<http://a.example/Issue2> ex:submittedOn "2015-07-09"; ex:status ex:assigned .
<http://a.example/Issue3> ex:submittedOn "2015-07-10"; ex:status ex:resolved .

sh:targetSubjectOf selects the nodes that appear as subjects in triples with predicate as a predicate:

<IssueShape> sh:targetSubjectsOf ex:status .

This selects <http://a.example/Issue2> and <http://a.example/Issue3> for valdiation.

TargetObjectsOf := predicate:IRI

A TargetObjectsOf matches any object node in the data graph with a triple (_, predicate, node) where "_" is any node.

A TargetObjectsOf is connected to a shape by the sh:targetObjectsOf property.

Targets example 4

In a graph with some triples with ex:submittedOn predicates:

<http://a.example/Workflow1> ex:relatedTo <http://a.example/Issue1> .
<http://a.example/Workflow2> ex:waitingOn <http://a.example/Issue2> .
<http://a.example/Workflow3> ex:waitingOn <http://a.example/Issue3> .

sh:targetObjectsOf selects the nodes that appear as subjects in triples with predicate as a predicate:

<IssueShape> sh:targetObjectsOf ex:waitingOn .

This selects <http://a.example/Workflow2> and <http://a.example/Workflow3> for valdiation.

A. References

A.1 Normative references

[rdf11-concepts]
Richard Cyganiak; David Wood; Markus Lanthaler. W3C. RDF 1.1 Concepts and Abstract Syntax. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
[rdf11-mt]
Patrick Hayes; Peter Patel-Schneider. W3C. RDF 1.1 Semantics. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-mt/
[shacl]
Holger Knublauch; Dimitris Kontokostas. W3C. Shapes Constraint Language (SHACL). 14 August 2016. W3C Working Draft. URL: https://www.w3.org/TR/shacl/
[sparql11-query]
Steven Harris; Andy Seaborne. W3C. SPARQL 1.1 Query Language. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-query/