When SHACL shapes are closed (sh:closed true), every property on a resource that isn't explicitly listed in the shape triggers a validation violation. This is great for catching typos and unexpected data — but it also catches common annotation properties like rdf:type, rdfs:label, and rdfs:comment that are perfectly legitimate on every resource.
sh:closed true
rdf:type
rdfs:label
rdfs:comment
The traditional fix is sh:ignoredProperties:
sh:ignoredProperties
nws:CustomerShape a sh:NodeShape ; sh:targetClass nwo:Customer ; sh:closed true ; sh:ignoredProperties ( rdf:type rdfs:label rdfs:comment ) ; sh:property [ sh:path nwo:companyName ; sh:datatype xsd:string ] .
But this has a critical limitation: ignored properties aren't validated at all. You can't require every Customer to have an rdfs:label if you're ignoring it.
RDF Studio replaces the binary "enforce or ignore" model with per-property severity rules. Instead of ignoring rdfs:label, you can enforce it — but at a severity level that matches how critical it is for your use case.
sh:Violation
sh:Warning
sh:Info
owl:deprecated
rdfs:isDefinedBy
dcterms:created
For each annotation property, the SHACL generator creates a sh:property constraint with the specified severity:
sh:property
# Violation level — rdf:type is mandatory sh:property [ sh:path rdf:type ; sh:minCount 1 ; sh:severity sh:Violation ; ] ; # Warning level — rdfs:label is recommended sh:property [ sh:path rdfs:label ; sh:minCount 1 ; sh:severity sh:Warning ; ] ; # Info level — dcterms:created is nice to have sh:property [ sh:path dcterms:created ; sh:minCount 1 ; sh:severity sh:Info ; ] ;
Properties set to Ignore go into sh:ignoredProperties (the traditional approach). Properties set to Off are omitted entirely — they will trigger the undeclared property constraint if encountered.
RDF Studio ships with a curated catalog of ~30 well-known annotation properties from standard vocabularies, organized by category:
skos:notation
dcterms:identifier
schema:identifier
skos:prefLabel
dcterms:title
schema:name
foaf:name
skos:altLabel
skos:hiddenLabel
dcterms:description
skos:definition
schema:description
dcterms:creator
dcterms:modified
dcterms:source
prov:wasGeneratedBy
prov:wasDerivedFrom
skos:inScheme
dcterms:subject
rdfs:seeAlso
owl:versionInfo
In addition to per-property rules, you can control what happens when a resource has a property that isn't in the shape AND isn't in the annotation rules:
This is controlled by sh:severity on the NodeShape itself:
sh:severity
nws:CustomerShape a sh:NodeShape ; sh:closed true ; sh:severity sh:Warning ; # Undeclared props are warnings, not violations sh:targetClass nwo:Customer ; sh:property [ sh:path nwo:companyName ; sh:datatype xsd:string ] ; sh:property [ sh:path rdf:type ; sh:minCount 1 ] ; # Required (violation) sh:property [ sh:path rdfs:label ; sh:minCount 1 ; sh:severity sh:Warning ] . # Recommended (warning)
Here's a practical example using the Northwind database. A Customer has domain-specific properties (company name, contact, city) plus common annotations:
Customer
nwr:customer-ALFKI a nwo:Customer ; # rdf:type ✓ rdfs:label "Alfreds Futterkiste" ; # rdfs:label ✓ nwo:companyName "Alfreds Futterkiste" ; nwo:contactName "Maria Anders" ; nwo:city "Berlin" ; nwo:country "Germany" .
With closed shapes and default annotation rules:
nwo:Customer
nwo:companyName
nwo:contactName
nwo:city
nwo:country
Now consider a Customer without rdfs:label:
nwr:customer-TEST a nwo:Customer ; nwo:companyName "Test Corp" ; nwo:contactName "Test User" .
The validator tells you exactly what's missing and how important it is, rather than silently ignoring the absence.
Not every database uses SKOS, Dublin Core, or Schema.org. RDF Studio's wizard is smart about this — it reads the @prefix declarations from the selected ontology file to determine which vocabularies are actually in use.
@prefix
How it works: When you select an ontology in the Generate dialog, RDF Studio fetches the namespace prefixes declared in that specific ontology file (e.g. @prefix foaf:, @prefix skos:, etc.) and uses them to set defaults:
@prefix foaf:
@prefix skos:
Example — Northwind Ontology declares rdf, rdfs, owl, dcterms, foaf, skos, and xsd:
rdf
rdfs
owl
dcterms
foaf
skos
xsd
schema:
prov:
Example — A Schema.org-based ontology declaring rdf, rdfs, owl, schema:
schema
This prevents noise: each ontology gets only the annotation property rules relevant to its vocabulary imports. The user can still manually toggle any property after the defaults are set.
Fallback: If the ontology prefixes can't be fetched (e.g. network error), the wizard falls back to enabling only universal prefixes (rdf, rdfs, owl) and setting everything else to Ignore.
With closed shapes, both Off and Ignore exclude a property from enforcement, but they behave very differently when data contains the property:
When to use each:
⚠️ Gotcha: If you set a property to Off but your data has it, closed shapes will report an "undeclared property" violation. Use Ignore instead if you're unsure whether your data uses the property.
When creating or editing shapes through the Visual Editor, each shape has a Closed dropdown:
Why the defaults differ: The Generate from OWL dialog defaults to Closed because auto-generated shapes cover the full ontology and benefit from strict validation to catch typo properties. The Visual Editor defaults to Open because you're building shapes from scratch and may not have declared all properties yet.
Minimal (default — good for most datasets):
SKOS taxonomy:
Enterprise data quality (DC metadata):
Permissive (early development, exploration):
sh:ignoredProperties (rdf:type rdfs:label)
The key advantage: you can catch missing annotations AND catch typos at the same time, with different severity levels for each.
RDF Studio uses a 5-level label extraction hierarchy to display human-readable names for every resource:
foaf:firstName
foaf:lastName
If your data lacks rdfs:label, the graph explorer, tables, and sidebars still work — but they fall back to less readable alternatives. By enforcing labeling properties through SHACL annotation rules, you ensure that your data is both valid and displayable.
Similarly, rdfs:comment feeds tooltips and description panels. dcterms:created / dcterms:modified support audit trails. skos:inScheme keeps taxonomies organized. Each annotation property has a concrete impact on how RDF Studio presents your data.
Here is what RDF Studio's SHACL generator produces for the Northwind CategoryShape with full catalog defaults (undeclared severity = Warning):
CategoryShape
shapes:CategoryShape a sh:NodeShape ; sh:closed true ; sh:severity sh:Warning ; # undeclared properties → warning sh:name "Category" ; sh:targetClass nwo:Category ; # ── Domain properties (from OWL ontology) ── sh:property [ sh:path nwo:categoryID ; sh:datatype xsd:integer ; sh:maxCount 1 ; sh:name "category ID" ; sh:nodeKind sh:Literal ] , sh:property [ sh:path nwo:categoryName ; sh:datatype xsd:string ; sh:name "category name" ; sh:nodeKind sh:Literal ] , # ── Annotation rules (from catalog) ── sh:property [ sh:path rdf:type ; # Violation (default) — no sh:severity needed sh:minCount 1 ] , sh:property [ sh:path rdfs:label ; # Violation (default) sh:minCount 1 ] , sh:property [ sh:path rdfs:comment ; # Warning — recommended sh:minCount 1 ; sh:severity sh:Warning ] , sh:property [ sh:path skos:prefLabel ; # Warning — recommended sh:minCount 1 ; sh:severity sh:Warning ] , sh:property [ sh:path dcterms:created ; # Info — nice to have sh:severity sh:Info ] , sh:property [ sh:path owl:deprecated ; # Info — nice to have sh:severity sh:Info ] .
Key observations:
sh:severity sh:Warning
required: true
sh:minCount 1
When you validate Northwind data with the full catalog defaults, the report groups results by severity:
These block data from being considered valid:
These indicate incomplete metadata:
These are improvement opportunities:
This three-tier approach lets you prioritize: fix violations first, then warnings, then info-level notes. Your data can pass strict validation (zero violations) while still showing areas for improvement.