Introduction
When working with data in RDF (Resource Description Framework), two mechanisms come up: “RDFS (RDF Schema)” and “SHACL (Shapes Constraint Language)”. Both can define constraints on properties and classes, but their purposes and behavior are completely different.
This article answers the following questions that are particularly prone to confusion:
- What is the difference between
rdfs:domain/rdfs:rangeand SHACL’ssh:class/sh:datatype? - Is it acceptable to set SHACL constraints that differ from the RDFS range?
- Is it problematic if the range is a class (
foaf:Person) but SHACL specifies a datatype (xsd:string)?
1. The Fundamental Difference Between RDFS and SHACL
RDFS: For Inference
RDFS is a declaration that states “if this property is used, the following knowledge can be derived”.
Meaning:
- When
ex:authoris used, the subject is automatically inferred to be a member ofex:Book - The object is automatically inferred to be a member of
ex:Person
Characteristics:
- Generates new knowledge (executed by the inference engine)
- Open World Assumption (the world is open)
- There is no concept of errors
- A declaration that “if used, this is also true”
SHACL: For Validation
SHACL is a constraint that “checks whether existing data conforms to these rules”.
Meaning: “Data should conform to these rules”
Characteristics:
- Detects rule violations (executed by the validation engine)
- Closed World Assumption-like (validates what is explicitly stated in the rules)
- Generates error reports
- A constraint that “data should be like this”
2. Comparison Table
| Aspect | RDFS domain/range | SHACL property shape |
|---|---|---|
| Purpose | Semantic definition / inference | Data validation |
| Behavior | Generates new knowledge | Detects rule violations |
| Philosophy | Open World | Closed World-like |
| Timing | Schema design time | Data registration / validation time |
| Executor | Inference engine | Validation engine |
| Result | Inferred triples | Validation report |
| Flexibility | More lenient | More strict |
3. Practical Differentiation
Pattern 1: Define Semantics with RDFS, Ensure Quality with SHACL
This is the most recommended combination.
Pattern 2: Different Constraints per Profile
The same vocabulary can be used with different constraints depending on the use case.
4. Frequently Asked Questions
Q1: Can SHACL constraints differ from the RDFS range?
A: Yes, you can, and it is often recommended.
However, SHACL constraints should be the same as or stricter than the range.
Recommended Pattern: Narrowing Down with Subclasses
Recommended Pattern: Making Literal Types More Specific
Pattern to Avoid: Making It Broader Than range
There is no logical contradiction, but it causes confusion.
Q2: Is it problematic to specify a datatype in SHACL when the range is a class?
A: Yes, this is a semantic contradiction. Absolutely avoid this.
Problematic Example
Why it is problematic:
rdfs:range foaf:Person: Value is an instance offoaf:Person(URI reference)sh:datatype xsd:string: Value is a string literal
These two are incompatible as types:
Correct Pattern 1: Use URI References
Correct Pattern 2: Use Literals
Recommended Pattern: Provide Both
Q3: What is type category consistency?
A: RDFS range and SHACL constraints must be in the same “type category”.
| rdfs:range | SHACL Constraint | Type Category | Evaluation |
|---|---|---|---|
foaf:Person | sh:class foaf:Person | Class <-> Class | Consistent |
foaf:Person | sh:class foaf:Agent | Class <-> Class | More lenient |
foaf:Agent | sh:class foaf:Person | Class <-> Class | Stricter (recommended) |
foaf:Person | sh:datatype xsd:string | Class <-> Datatype | Contradiction |
xsd:string | sh:datatype xsd:integer | Datatype <-> Datatype | Contradiction |
rdfs:Literal | sh:datatype xsd:string | Datatype <-> Datatype | Made more specific (recommended) |
5. Practical Application Example
Case: Metadata Management System
6. Summary: Design Guidelines
Key Points for Vocabulary Design (RDFS)
- Define as generically as possible (increase reusability)
- Keep domain/range flexible (consider future extensions)
- Make semantic relationships explicit (provide information usable for inference)
Key Points for Profile Design (SHACL)
- Set specific constraints according to use case (ensure data quality)
- Make constraints the same as or stricter than RDFS range (do not make them more lenient)
- Maintain type category consistency (class <-> class, datatype <-> datatype)
- Clearly specify required/optional, count limits, etc. (reflect operational rules)
Prohibited
- Specifying a datatype (
xsd:string) in SHACL when RDFS is a class (foaf:Person) - Specifying a different datatype (
xsd:integer) in SHACL when RDFS is a datatype (xsd:string) - Making SHACL constraints more lenient than RDFS range
Recommended
- RDFS should be generic, SHACL should be specific
- Narrow down with subclasses and subproperties
- Set different constraints per profile
- Manage URI references and literals with separate properties
7. Further Learning
- RDF 1.1 Primer
- RDF Schema 1.1
- SHACL - Shapes Constraint Language
- SHACL Playground - An online tool for trying SHACL constraints