From 763d7f3c2548a72e0156a2b1a2c6700d0b661684 Mon Sep 17 00:00:00 2001 From: YoucTagh Date: Thu, 14 Aug 2025 10:26:38 +0200 Subject: [PATCH 1/6] add getting started section --- shacl12-core/index.html | 412 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 412 insertions(+) diff --git a/shacl12-core/index.html b/shacl12-core/index.html index d0aa6e18..757d2f3b 100644 --- a/shacl12-core/index.html +++ b/shacl12-core/index.html @@ -1107,6 +1107,418 @@

Relationship between SHACL and RDFS inferencing

+
+

Getting Started with SHACL Core

+

+ In this section, we'll walk you through a simple example that introduces the basics of SHACL Core. You'll see how to describe what your data should look like, and how SHACL checks if your data meets that description. +

+
+

+ Simple Example: +

+

+ Imagine you have a set of people—Alice, Bob, Calvin—and you want to make sure: +

+ +
    +
  1. + Every Person has at most one Social Security Number (SSN), and that SSN needs to be a properly formatted text (like 123-45-6789). +
    2. +
  2. + A Person can work for one or more companies—but those companies must be typed as a ex:Company in your data. +
    3. +
  3. + No other properties are allowed for a Person, other than the SSN (ex:ssn), the work affiliation (ex:worksFor), and the mandatory typing (rdf:type). +
    4. +
+

+ That's what our shape (think "rulebook") will enforce on the data. +

+
+
+

+ Our Sample Data (Data Graph) +

+ + Here's the data we want to check: + +
+
+ex:Alice a ex:Person ; + ex:ssn "987-65-432A" . # SSN has a typo or bad format + +ex:Bob a ex:Person ; + ex:ssn "123-45-6789", "124-35-6789" . # Two SSNs (too many) + +ex:Calvin a ex:Person ; + ex:birthDate "1971-07-07"^^xsd:date ; # Extra birthDate + ex:worksFor ex:UntypedCompany . # Untyped company +
+
+ 
{
+	"@graph": [
+		{
+			"@id": "ex:Alice",
+			"@type": "ex:Person",
+			"ex:ssn": "987-65-432A"
+		},
+		{
+			"@id": "ex:Bob",
+			"@type": "ex:Person",
+			"ex:ssn": [
+				"123-45-6789",
+				"124-35-6789"
+			]
+		},
+		{
+			"@id": "ex:Calvin",
+			"@type": "ex:Person",
+			"ex:birthDate": {
+				"@type": "xsd:date",
+				"@value": "1971-07-07"
+			},
+			"ex:worksFor": {
+				"@id": "ex:UntypedCompany"
+			}
+		}
+	]
+}
+
+
+

+ What's wrong here? +

    +
  • + Alice has an SSN—but it doesn't match the correct pattern. +
    • +
  • + Bob has two SSNs, but we only allow one. +
    • +
  • + Calvin works for something called ex:UntypedCompany, but that item isn't labeled as a ex:Company; plus, Calvin has a ex:birthDate, which we don't allow. +
    • +
+

+
+
+

+ Writing the Shape (Shapes Graph) +

+

+ Here's how we say it clearly using SHACL's Turtle syntax, as well as JSON-LD and SHACL-C: +

+ +
+
+ex:PersonShape a sh:NodeShape ; + sh:targetClass ex:Person ; # This shape applies to all Persons + + sh:property [ + sh:path ex:ssn ; + sh:maxCount 1 ; # At most one SSN + sh:datatype xsd:string ; # Must be a string + sh:pattern "^\\d{3}-\\d{2}-\\d{4}$" ; # and look like 123-45-6789 + ] ; + + sh:property [ + sh:path ex:worksFor ; + sh:nodeKind sh:IRI ; # Must be an IRI + sh:class ex:Company ; # and point to a typed Company + ] ; + + sh:closed true ; # No other properties are allowed + sh:ignoredProperties ( rdf:type ) . # except for rdf:type +
+
+ 
{
+	"@id": "ex:PersonShape",
+	"@type": "sh:NodeShape",
+	"sh:closed": {
+		"@type": "xsd:boolean",
+		"@value": "true"
+	},
+	"sh:ignoredProperties": {
+		"@list": [
+			{
+				"@id": "rdf:type"
+			}
+		]
+	},
+	"sh:property": [
+		{
+			"sh:datatype": {
+				"@id": "xsd:string"
+			},
+			"sh:maxCount": {
+				"@type": "xsd:integer",
+				"@value": "1"
+			},
+			"sh:path": {
+				"@id": "ex:ssn"
+			},
+			"sh:pattern": "^\\d{3}-\\d{2}-\\d{4}$"
+		},
+		{
+			"sh:class": {
+				"@id": "ex:Company"
+			},
+			"sh:nodeKind": {
+				"@id": "sh:IRI"
+			},
+			"sh:path": {
+				"@id": "ex:worksFor"
+			}
+		}
+	],
+	"sh:targetClass": {
+		"@id": "ex:Person"
+	}
+}
+
+ 
shape ex:PersonShape -> ex:Person {
+	closed=true ignoredProperties=[rdf:type] .
+	ex:ssn xsd:string [0..1] pattern="^\\d{3}-\\d{2}-\\d{4}$" .
+	ex:worksFor IRI ex:Company .
+}
+

+ Let's break that down: +

+
    +
  • + sh:targetClass ex:Person means "apply this rule to all people". +
    • +
  • + The first sh:property block ensures: +
  • + SSNs are strings (sh:datatype xsd:string), +
    • +
  • + Only one is allowed (sh:maxCount 1), +
    • +
  • + And it must follow the typical U.S. SSN format (sh:pattern "^\d{3}-\d{2}-\d{4}$"). +
    • + +
  • + The second `sh:property` block says: +
  • + If someone has a ex:worksFor property, its value must be an IRI and point to something that's a ex:Company. +
    • + +
  • + sh:closed true means no properties beyond those listed are allowed (except ones explicitly ignored). +
    • +
  • + sh:ignoredProperties ( rdf:type ) lets rdf:type slip through even though it's not in the allowed property list. +
    • +
+
+
+

+ Running the Validation (Validation Report) +

+

+ When we run SHACL validation on our data graph using our shapes graph, the validator checks each Person against the rules we wrote. +

+

+ In plain English, here’s what it finds: +

+
    +
  • + Alice: SSN doesn’t match the expected pattern (987-65-432A has a letter where a digit should be). +
    • +
  • + Bob: Has more than one SSN (two values found, but sh:maxCount says only one is allowed). +
    • +
  • + Calvin: +
      +
    • + Works for something (ex:UntypedCompany) that isn’t declared as a ex:Company. +
      • +
    • + Has an extra property ex:birthDate that isn’t allowed by the shape. +
      • +
    +
    • +
+

+ Here’s what a SHACL validation report for this example might look like (simplified for readability): +

+ +
+
+[ a sh:ValidationReport ; + sh:conforms false ; + sh:result + [ a sh:ValidationResult ; + sh:resultSeverity sh:Violation ; + sh:focusNode ex:Alice ; + sh:resultPath ex:ssn ; + sh:value "987-65-432A" ; + sh:sourceConstraintComponent sh:PatternConstraintComponent ; + sh:sourceShape _:b1 ; # ... blank node _:b1 on ex:ssn above ... + sh:resultMessage "Value does not match pattern "^\d{3}-\d{2}-\d{4}$"" ; + ] , + [ a sh:ValidationResult ; + sh:resultSeverity sh:Violation ; + sh:focusNode ex:Bob ; + sh:resultPath ex:ssn ; + sh:sourceConstraintComponent sh:MaxCountConstraintComponent ; + sh:sourceShape _:b1 ; # ... blank node _:b1 on ex:ssn above ... + sh:resultMessage "More than 1 values" ; + ] , + [ a sh:ValidationResult ; + sh:resultSeverity sh:Violation ; + sh:focusNode ex:Calvin ; + sh:resultPath ex:worksFor ; + sh:value ex:UntypedCompany ; + sh:sourceConstraintComponent sh:ClassConstraintComponent ; + sh:sourceShape _:b2 ; # ... blank node _:b2 on ex:worksFor above ... + sh:resultMessage "Value does not have class ex:Company" ; + ] , + [ a sh:ValidationResult ; + sh:resultSeverity sh:Violation ; + sh:focusNode ex:Calvin ; + sh:resultPath ex:birthDate ; + sh:value "1971-07-07"^^xsd:date ; + sh:sourceConstraintComponent sh:ClosedConstraintComponent ; + sh:sourceShape sh:PersonShape ; + sh:resultMessage "Predicate is not allowed (closed shape)" ; + ] +] . +
+
+ 
{
+	"@type": "sh:ValidationReport",
+	"sh:conforms": {
+		"@type": "xsd:boolean",
+		"@value": "false"
+	},
+	"sh:result": [
+		{
+			"@type": "sh:ValidationResult",
+			"sh:focusNode": {
+				"@id": "ex:Alice"
+			},
+			"sh:resultPath": {
+				"@id": "ex:ssn"
+			},
+			"sh:resultSeverity": {
+				"@id": "sh:Violation"
+			},
+			"sh:sourceConstraintComponent": {
+				"@id": "sh:PatternConstraintComponent"
+			},
+			"sh:sourceShape": {
+				"@id": "_:b1"
+			},
+			"sh:value": "987-65-432A",
+			"sh:resultMessage": "Value does not match pattern '^\d{3}-\d{2}-\d{4}$'"
+		},
+		{
+			"@type": "sh:ValidationResult",
+			"sh:focusNode": {
+				"@id": "ex:Bob"
+			},
+			"sh:resultPath": {
+				"@id": "ex:ssn"
+			},
+			"sh:resultSeverity": {
+				"@id": "sh:Violation"
+			},
+			"sh:sourceConstraintComponent": {
+				"@id": "sh:MaxCountConstraintComponent"
+			},
+			"sh:sourceShape": {
+				"@id": "_:b1"
+			},
+			"sh:resultMessage": "More than 1 values"
+		},
+		{
+			"@type": "sh:ValidationResult",
+			"sh:focusNode": {
+				"@id": "ex:Calvin"
+			},
+			"sh:resultPath": {
+				"@id": "ex:worksFor"
+			},
+			"sh:resultSeverity": {
+				"@id": "sh:Violation"
+			},
+			"sh:sourceConstraintComponent": {
+				"@id": "sh:ClassConstraintComponent"
+			},
+			"sh:sourceShape": {
+				"@id": "_:b2"
+			},
+			"sh:value": {
+				"@id": "ex:UntypedCompany"
+			},
+			"sh:resultMessage": "Value does not have class ex:Company"
+		},
+		{
+			"@type": "sh:ValidationResult",
+			"sh:focusNode": {
+				"@id": "ex:Calvin"
+			},
+			"sh:resultPath": {
+				"@id": "ex:birthDate"
+			},
+			"sh:resultSeverity": {
+				"@id": "sh:Violation"
+			},
+			"sh:sourceConstraintComponent": {
+				"@id": "sh:ClosedConstraintComponent"
+			},
+			"sh:sourceShape": {
+				"@id": "sh:PersonShape"
+			},
+			"sh:value": {
+				"@type": "xsd:date",
+				"@value": "1971-07-07"
+			},
+			"sh:resultMessage": "Predicate is not allowed (closed shape)"
+		}
+	]
+}
+
+
+

How to read the report:

+
    +
  • + sh:ValidationReport is the overall report, with sh:conforms false meaning at least one rule failed. +
    • +
  • + Each sh:ValidationResult is one problem found: +
      +
    • + sh:resultSeverity — tells you how serious the problem is. In this example, all issues are sh:Violation (the highest and default severity). +
      • +
    • + sh:focusNode — the data node that failed. +
      • +
    • + sh:resultPath — the property involved. +
      • +
    • + sh:value — the actual value that triggered the failure. +
      • +
    • + sh:sourceConstraintComponent — which kind of rule was broken (max count, pattern, class, etc.). +
      • +
    • + sh:sourceShape — the shape that defined the rule. +
      • +
    • + sh:resultMessage — a human-readable explanation. +
      • +
    +
    • +
+
+
+

Shapes and Constraints

From 07506884e69d2f41ef23973ddef9eb4238be6ac6 Mon Sep 17 00:00:00 2001 From: Holger Knublauch Date: Thu, 14 Aug 2025 13:24:30 +0300 Subject: [PATCH 2/6] Suggested edits - Removed use of abbreviations such as "isn't" - written English usually should prefer the longer form "is not" - Extended example to include class definition to clarify SHACL isn't limited to shapes - Deleted the old example section but moved the terminology introduction down - Avoid the term "rule" which is overloaded. Instead always use "constraint" to not clash with the use of rule in inference rules - Use property shapes with URI and type instead of blank nodes, yet added a section to explain the syntactic variations --- shacl12-core/index.html | 847 ++++++++++++++++------------------------ 1 file changed, 329 insertions(+), 518 deletions(-) diff --git a/shacl12-core/index.html b/shacl12-core/index.html index 757d2f3b..8470ba7b 100644 --- a/shacl12-core/index.html +++ b/shacl12-core/index.html @@ -765,319 +765,6 @@

Document Conventions

A shapes graph is ill-formed if it contains at least one ill-formed node.

- -
-

SHACL Example

-

- The following example data graph contains three SHACL instances of the class ex:Person. -

- -

- We can use the shape declaration above to illustrate some of the key terminology used by SHACL. - The target for the shape ex:PersonShape is the set of all SHACL instances of the class ex:Person. - This is specified using the property sh:targetClass. - During the validation, these target nodes become focus nodes for the shape. - The shape ex:PersonShape is a node shape, which means that it applies to the focus nodes. - It declares constraints on the focus nodes, for example using the parameters sh:closed and sh:ignoredProperties. - The node shape also declares two other constraints with the property sh:property, - and each of these is backed by a property shape. - These property shapes declare additional constraints using parameters such as sh:datatype and sh:maxCount. -

-

- Some of the property shapes specify parameters from multiple constraint components in order to - restrict multiple aspects of the property values. - For example, in the property shape for ex:ssn, parameters from three constraint components are used. - The parameters of these constraint components are sh:datatype, sh:pattern and sh:maxCount. - For each focus node the property values of ex:ssn will be validated against all three components. -

-

- SHACL validation based on the provided data graph and shapes graph would produce the following validation report. - See the section Validation Report for details on the format. -

- -

- The validation results are enclosed in a validation report. - The first validation result is produced because ex:Alice has a value for ex:ssn - that does not match the regular expression specified by the property sh:pattern. - The second validation result is produced because ex:Bob has more than the permitted number of values - for the property ex:ssn as specified by the sh:maxCount of 1. - The third validation result is produced because ex:Calvin has a value for ex:worksFor - that does not have an rdf:type triple that makes it a SHACL instance of ex:Company. - The forth validation result is produced because the shape ex:PersonShape has the property sh:closed set to true - but ex:Calvin uses the property ex:birthDate which is neither one of the predicates from any of the - property shapes of the shape, nor one of the properties listed using sh:ignoredProperties. -

-

Relationship between SHACL and RDFS inferencing

@@ -1107,52 +794,49 @@

Relationship between SHACL and RDFS inferencing

-
+

Getting Started with SHACL Core

- In this section, we'll walk you through a simple example that introduces the basics of SHACL Core. You'll see how to describe what your data should look like, and how SHACL checks if your data meets that description. + In this section, we will walk you through a simple example that introduces the basics of SHACL Core. + You will learn how to describe what your data should look like, and how a SHACL processor checks if your data meets that description.

-

- Simple Example: -

+

Use Case

- Imagine you have a set of people—Alice, Bob, Calvin—and you want to make sure: + Imagine you have a set of entities (Alice, Bob, Calvin) and you want explain to a computer or another human that

-
  1. - Every Person has at most one Social Security Number (SSN), and that SSN needs to be a properly formatted text (like 123-45-6789). + there is a class called ex:Person that is the type of these entities
  2. - A Person can work for one or more companies—but those companies must be typed as a ex:Company in your data. + every instance of ex:Person has at most one Social Security Number (SSN), and that SSN needs to be a properly formatted text (like 123-45-6789)
  3. - No other properties are allowed for a Person, other than the SSN (ex:ssn), the work affiliation (ex:worksFor), and the mandatory typing (rdf:type). + every instance of ex:Person can work for one or more companies, but those companies must be typed as a ex:Company in your data +
    4. +
  4. + no other properties are allowed for a ex:Person, other than the SSN (ex:ssn), the work affiliation (ex:worksFor), and the mandatory typing (rdf:type)
-

- That's what our shape (think "rulebook") will enforce on the data. -

-

- Our Sample Data (Data Graph) -

- - Here's the data we want to check: - -
-
+

Our Sample Data (Data Graph)

+

+ Here is the data we want to describe and validate: +

+
+

+ What is wrong here? +

    +
  • + Alice has an SSN — but it does not match the correct pattern. +
    • +
  • + Bob has two SSNs, but we only allow one. +
    • +
  • + Calvin works for something called ex:UntypedCompany, + but that entity is not labeled as a ex:Company. + Furthermore, Calvin has a ex:birthDate, which we do not allow in our data. +
    • +
+

+
-

- Writing the Shape (Shapes Graph) -

+

Writing the Shapes and Classes (Shapes Graph)

- Here's how we say it clearly using SHACL's Turtle syntax, as well as JSON-LD and SHACL-C: + Here is a self-contained example of how to represent our domain of interest. + In SHACL terminology, this is called a shapes graph, but you can also think + of this as a domain model or an ontology.

-
-
-ex:PersonShape a sh:NodeShape ; - sh:targetClass ex:Person ; # This shape applies to all Persons - - sh:property [ - sh:path ex:ssn ; - sh:maxCount 1 ; # At most one SSN - sh:datatype xsd:string ; # Must be a string - sh:pattern "^\\d{3}-\\d{2}-\\d{4}$" ; # and look like 123-45-6789 - ] ; - - sh:property [ - sh:path ex:worksFor ; - sh:nodeKind sh:IRI ; # Must be an IRI - sh:class ex:Company ; # and point to a typed Company - ] ; - - sh:closed true ; # No other properties are allowed - sh:ignoredProperties ( rdf:type ) . # except for rdf:type +
-
-

- Running the Validation (Validation Report) -

-

- When we run SHACL validation on our data graph using our shapes graph, the validator checks each Person against the rules we wrote. -

-

- In plain English, here’s what it finds: -

-
    -
  • - Alice: SSN doesn’t match the expected pattern (987-65-432A has a letter where a digit should be). -
    • -
  • - Bob: Has more than one SSN (two values found, but sh:maxCount says only one is allowed). -
    • -
  • - Calvin: + ex:worksFor IRI ex:Company . # TODO: This needs to be updated +} + + +

    + Let us break that down: +

    • - Works for something (ex:UntypedCompany) that isn’t declared as a ex:Company. + sh:targetClass ex:Person means "apply this constraint to all people".
    • - Has an extra property ex:birthDate that isn’t allowed by the shape. + The first sh:property definition declares that: +
        +
      • + SSNs are strings (sh:datatype xsd:string), +
        • +
      • + Only one is allowed (sh:maxCount 1), +
        • +
      • + And it must follow the typical U.S. SSN format (sh:pattern "^\d{3}-\d{2}-\d{4}$"). +
        • +
      +
      • +
    • + The second sh:property definition declares that: +
        +
      • + If someone has a ex:worksFor property, its value must be an IRI and point to something that's a ex:Company. +
        • +
      +
      • +
    • + sh:closed true means no properties beyond those listed are allowed (except ones explicitly ignored). +
      • +
    • + sh:ignoredProperties ( rdf:type ) lets rdf:type slip through even though it's not in the allowed property list.
    -
    • -
+ +
+
+

Running the Validation (Validation Report)

+

+ When we run SHACL validation on our data graph using our shapes graph, the validator checks each Person against the constraints that we wrote. +

+

+ In plain English, here is what it finds: +

+
    +
  • + Alice: SSN does not match the expected pattern (987-65-432A has a letter where a digit should be). +
    • +
  • + Bob: Has more than one SSN (two values found, but sh:maxCount says only one is allowed). +
    • +
  • + Calvin: +
      +
    • + Works for something (ex:UntypedCompany) that is not declared as a ex:Company. +
      • +
    • + Has an extra property ex:birthDate that is not allowed by the shape. +
      • +
    +
    • +

- Here’s what a SHACL validation report for this example might look like (simplified for readability): + Here is what a SHACL validation report for this example might look like (simplified for readability):

-
+ +

How to read the report:

+
    +
  • + sh:ValidationReport is the overall report, with sh:conforms false meaning at least one rule failed. +
    • +
  • + Each sh:ValidationResult is one problem found: +
      +
    • + sh:resultSeverity — tells you how serious the problem is. In this example, all issues are sh:Violation (the highest and default severity). +
      • +
    • + sh:focusNode — the data node that failed. +
      • +
    • + sh:resultPath — the property involved. +
      • +
    • + sh:value — the actual value that triggered the failure. +
      • +
    • + sh:sourceConstraintComponent — which kind of constraint was broken (max count, pattern, class, etc.). +
      • +
    • + sh:sourceShape — the shape that defined the constraint. +
      • +
    • + sh:resultMessage — a human-readable explanation. +
      • +
    +
    • +
+
+

Syntactic Variations of Shapes and Classes

+

+ While SHACL is primarily designed to represent shapes, it also borrows terms and concepts such as + rdfs:Class and rdfs:subClassOf from the RDF Schema namespace. + Some people prefer to keep those concepts separate, as shown in the original example above + which had separate entities for ex:Person and ex:PersonShape. + However, it is also possible to couple them more closely together, and use sh:ShapeClass + to declare both a class and a shape at the same time. +

+

+ Furthermore, sometimes you will see property shapes declared as blank nodes instead of IRIs. + This is a more compact notation, yet it means that the property shape cannot easily be referenced from + the outside, for example if some other graph wants to reuse a node shape but deactivate a property shape. +

+

+ The following Turtle example shows these two syntactic variations in action. +

+ +
+
+

Introducing some SHACL Terminology

+

+ We can use the shape declarations above to introduce some of the formal terminology used by SHACL. + This may help you read the remainder of this specification. +

+

+ The target for the shape ex:PersonShape is the set of all SHACL instances of the class ex:Person. + This is specified using the property sh:targetClass. + During the validation, these target nodes become focus nodes for the shape. + The shape ex:PersonShape is a node shape, which means that it applies to the focus nodes. + It declares constraints on the focus nodes, for example using the parameters sh:closed and sh:ignoredProperties. + The node shape also declares two other constraints with the property sh:property, + and each of these is backed by a property shape. + These property shapes declare additional constraints using parameters such as sh:datatype and sh:maxCount. +

+

+ Some of the property shapes specify parameters from multiple constraint components in order to + restrict multiple aspects of the property values. + For example, in the property shape for ex:ssn, parameters from three constraint components are used. + The parameters of these constraint components are sh:datatype, sh:pattern and sh:maxCount. + For each focus node the property values of ex:ssn will be validated against all three components. +

+
From d24a89feee69de63937fe603e887454dcb0cf464 Mon Sep 17 00:00:00 2001 From: Holger Knublauch Date: Sat, 16 Aug 2025 11:38:05 +0300 Subject: [PATCH 3/6] Apply suggestions from code review Co-authored-by: Ted Thibodeau Jr --- shacl12-core/index.html | 106 ++++++++++++++++++++-------------------- 1 file changed, 53 insertions(+), 53 deletions(-) diff --git a/shacl12-core/index.html b/shacl12-core/index.html index 8470ba7b..2d1928c6 100644 --- a/shacl12-core/index.html +++ b/shacl12-core/index.html @@ -772,11 +772,11 @@

Relationship between SHACL and RDFS inferencing

SHACL uses the RDF and RDFS vocabularies, but full RDFS inferencing is not required.

- However, SHACL processors MAY operate on RDF graphs that include entailments [[!sparql12-entailment]] - - either pre-computed before being submitted to a SHACL processor or performed on the fly as + However, SHACL processors MAY operate on RDF graphs that include entailments [[!sparql12-entailment]], + whether pre-computed before being submitted to a SHACL processor or performed on the fly as part of SHACL processing (without modifying either data graph or shapes graph). To support processing of entailments, SHACL includes the property - sh:entailment to indicate what inferencing is required + sh:entailment to indicate the inferencing that is required by a given shapes graph.

@@ -786,7 +786,7 @@

Relationship between SHACL and RDFS inferencing

SHACL implementations MAY, but are not required to, support entailment regimes. If a shapes graph contains any triple with the predicate sh:entailment and object E - and the SHACL processor does not support E as an entailment regime for the given data graph + and the SHACL processor does not support E as an entailment regime for the given data graph, then the processor MUST signal a failure. Otherwise, the SHACL processor MUST provide the entailments for all of the values of sh:entailment in the shapes graph, and any inferred triples MUST be returned by all queries against the data graph during the validation process. @@ -798,7 +798,7 @@

Relationship between SHACL and RDFS inferencing

Getting Started with SHACL Core

In this section, we will walk you through a simple example that introduces the basics of SHACL Core. - You will learn how to describe what your data should look like, and how a SHACL processor checks if your data meets that description. + You will learn how to describe what your data should look like, and how a SHACL processor checks whether your data meets that description.

Use Case

@@ -816,7 +816,7 @@

Use Case

every instance of ex:Person can work for one or more companies, but those companies must be typed as a ex:Company in your data
  • - no other properties are allowed for a ex:Person, other than the SSN (ex:ssn), the work affiliation (ex:worksFor), and the mandatory typing (rdf:type) + no other properties are allowed for an ex:Person, other than the SSN (ex:ssn), the work affiliation (ex:worksFor), and the mandatory typing (rdf:type)
    • @@ -880,8 +880,8 @@

    Our Sample Data (Data Graph)

  • Calvin works for something called ex:UntypedCompany, - but that entity is not labeled as a ex:Company. - Furthermore, Calvin has a ex:birthDate, which we do not allow in our data. + but that entity is not labeled as an ex:Company. + Furthermore, Calvin has an ex:birthDate, which we do not allow in our data.

    • @@ -899,37 +899,37 @@

    Writing the Shapes and Classes (Shapes Graph)

    ex:Person - a rdfs:Class ; # or owl:Class - rdfs:subClassOf rdfs:Resource ; # or owl:Thing - rdfs:label "Person" ; - rdfs:comment "A human being." ; + a rdfs:Class ; # or owl:Class + rdfs:subClassOf rdfs:Resource ; # or owl:Thing + rdfs:label "Person" ; + rdfs:comment "A human being." ; . ex:PersonShape - a sh:NodeShape ; - rdfs:label "Person shape" ; - rdfs:comment "A shape that applies to all instances of Person." ; - sh:targetClass ex:Person ; - sh:property ex:PersonShape-ssn ; - sh:property ex:PersonShape-worksFor ; - sh:closed true ; # No other properties are allowed - sh:ignoredProperties ( rdf:type ) ; # except for rdf:type + a sh:NodeShape ; + rdfs:label "Person shape" ; + rdfs:comment "A shape that applies to all instances of Person." ; + sh:targetClass ex:Person ; + sh:property ex:PersonShape-ssn ; + sh:property ex:PersonShape-worksFor ; + sh:closed true ; # No other properties are allowed + sh:ignoredProperties ( rdf:type ) ; # except for rdf:type . ex:PersonShape-ssn - a sh:PropertyShape ; - sh:path ex:ssn ; # The values of ex:ssn are valid if: - sh:maxCount 1 ; # there is at most one SSN - sh:datatype xsd:string ; # the value must be a string - sh:pattern "^\\d{3}-\\d{2}-\\d{4}$" ; # the value must look like "123-45-6789" - sh:name "social security number" ; - sh:description "A person's unique identifier in the US." ; + a sh:PropertyShape ; + sh:path ex:ssn ; # The values of ex:ssn are valid if: + sh:maxCount 1 ; # there is at most one SSN + sh:datatype xsd:string ; # the value must be a string + sh:pattern "^\\d{3}-\\d{2}-\\d{4}$" ; # the value must look like "123-45-6789" + sh:name "social security number" ; + sh:description "A person's unique identifier in the US." ; . ex:PersonShape-worksFor - a sh:PropertyShape ; - sh:path ex:worksFor ; # The values of ex:worksFor are valid if: - sh:nodeKind sh:IRI ; # they are IRIs (and, e.g., not literals) - sh:class ex:Company ; # they are instances of Company - sh:name "works for" ; - sh:description "The companies that a person works for." ; + a sh:PropertyShape ; + sh:path ex:worksFor ; # The values of ex:worksFor are valid if: + sh:nodeKind sh:IRI ; # they are IRIs (and, e.g., not literals) + sh:class ex:Company ; # they are instances of Company + sh:name "works for" ; + sh:description "The companies that a person works for." ; .
    @@ -1044,7 +1044,7 @@

    Writing the Shapes and Classes (Shapes Graph)

  • - sh:closed true means no properties beyond those listed are allowed (except ones explicitly ignored). + sh:closed true means no properties beyond those listed are allowed (except any that are explicitly ignored).
  • sh:ignoredProperties ( rdf:type ) lets rdf:type slip through even though it's not in the allowed property list. @@ -1268,8 +1268,8 @@

    Syntactic Variations of Shapes and Classes

    Furthermore, sometimes you will see property shapes declared as blank nodes instead of IRIs. - This is a more compact notation, yet it means that the property shape cannot easily be referenced from - the outside, for example if some other graph wants to reuse a node shape but deactivate a property shape. + This is a more compact notation, but it means that the property shape cannot easily be referenced from + the outside; for example, if some other graph wants to reuse a node shape but deactivate a property shape.

    The following Turtle example shows these two syntactic variations in action. @@ -1278,27 +1278,27 @@

    Syntactic Variations of Shapes and Classes

    ex:Person - a sh:ShapeClass ; # or rdfs:Class, sh:NodeShape - rdfs:subClassOf rdfs:Resource ; # or owl:Thing - rdfs:label "Person" ; - rdfs:comment "A human being." ; + a sh:ShapeClass ; # or rdfs:Class, sh:NodeShape + rdfs:subClassOf rdfs:Resource ; # or owl:Thing + rdfs:label "Person" ; + rdfs:comment "A human being." ; sh:property [ - sh:path ex:ssn ; # The values of ex:ssn are valid if: - sh:maxCount 1 ; # there is at most one SSN - sh:datatype xsd:string ; # the value must be a string - sh:pattern "^\\d{3}-\\d{2}-\\d{4}$" ; # the value must look like "123-45-6789" - sh:name "social security number" ; - sh:description "A person's unique identifier in the US." ; + sh:path ex:ssn ; # The values of ex:ssn are valid if: + sh:maxCount 1 ; # there is at most one SSN + sh:datatype xsd:string ; # the value must be a string + sh:pattern "^\\d{3}-\\d{2}-\\d{4}$" ; # the value must look like "123-45-6789" + sh:name "social security number" ; + sh:description "A person's unique identifier in the US." ; ] ; sh:property [ - sh:path ex:worksFor ; # The values of ex:worksFor are valid if: - sh:nodeKind sh:IRI ; # they are IRIs (and, e.g., not literals) - sh:class ex:Company ; # they are instances of Company - sh:name "works for" ; - sh:description "The companies that a person works for." ; + sh:path ex:worksFor ; # The values of ex:worksFor are valid if: + sh:nodeKind sh:IRI ; # they are IRIs (so, e.g., not literals) + sh:class ex:Company ; # they are instances of Company + sh:name "works for" ; + sh:description "The companies that a person works for." ; ] ; - sh:closed true ; # No other properties are allowed - sh:ignoredProperties ( rdf:type ) ; # except for rdf:type + sh:closed true ; # No other properties are allowed + sh:ignoredProperties ( rdf:type ) ; # except for rdf:type .
    From f6d017a5c6b31ba72ed5f3210c6fa932510db12d Mon Sep 17 00:00:00 2001 From: Yousouf Taghzouti <48333491+YoucTagh@users.noreply.github.com> Date: Mon, 18 Aug 2025 10:12:53 +0200 Subject: [PATCH 4/6] Update shacl12-core/index.html Co-authored-by: Thomas Bergwinkl --- shacl12-core/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/shacl12-core/index.html b/shacl12-core/index.html index 2d1928c6..8323242b 100644 --- a/shacl12-core/index.html +++ b/shacl12-core/index.html @@ -1226,7 +1226,7 @@

    Running the Validation (Validation Report)

    How to read the report:

    • - sh:ValidationReport is the overall report, with sh:conforms false meaning at least one rule failed. + sh:ValidationReport is the overall report, with sh:conforms false meaning that there was at least one violation.
    • Each sh:ValidationResult is one problem found: From 5a85d56b4945372a12a97723ca8d8354f0f06f8f Mon Sep 17 00:00:00 2001 From: Holger Knublauch Date: Mon, 18 Aug 2025 20:13:53 +0300 Subject: [PATCH 5/6] Update shacl12-core/index.html Co-authored-by: Ted Thibodeau Jr --- shacl12-core/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/shacl12-core/index.html b/shacl12-core/index.html index 8323242b..c64fe003 100644 --- a/shacl12-core/index.html +++ b/shacl12-core/index.html @@ -798,7 +798,7 @@

      Relationship between SHACL and RDFS inferencing

      Getting Started with SHACL Core

      In this section, we will walk you through a simple example that introduces the basics of SHACL Core. - You will learn how to describe what your data should look like, and how a SHACL processor checks whether your data meets that description. + You will learn how to describe how your data should look, and how a SHACL processor checks whether your data meets that description.

      Use Case

      From 3f1f20651b896748e569d5c170dd739df1d10bf2 Mon Sep 17 00:00:00 2001 From: Holger Knublauch Date: Tue, 16 Sep 2025 08:41:18 +0200 Subject: [PATCH 6/6] Update shacl12-core/index.html Co-authored-by: Ted Thibodeau Jr --- shacl12-core/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/shacl12-core/index.html b/shacl12-core/index.html index c64fe003..24a3cf22 100644 --- a/shacl12-core/index.html +++ b/shacl12-core/index.html @@ -798,7 +798,7 @@

      Relationship between SHACL and RDFS inferencing

      Getting Started with SHACL Core

      In this section, we will walk you through a simple example that introduces the basics of SHACL Core. - You will learn how to describe how your data should look, and how a SHACL processor checks whether your data meets that description. + You will learn to describe how your data should look, and how a SHACL processor checks whether your data meets that description.

      Use Case