RDF Schema Classes and Properties

RDF Schema entailment showing subclass and domain declarations producing inferred type statements — FIG 07 / RDFS declarations add entailed triples; they do not validate a closed record shape.

The vocabulary layer

RDF Schema provides terms for describing classes, properties and relationships among them. It does not define a closed record schema comparable to XSD or JSON Schema. An RDFS description can entail additional types and property relationships, but it does not normally reject a resource because a property is missing or repeated.

Classes and instances

A resource is related to a class with rdf:type. Classes can themselves be resources described by other triples. Multiple types are normal, and class membership may be inferred through subclass relationships or property domains and ranges. Model categories for their meaning rather than forcing every implementation table into the public class hierarchy.

Subclass relationships

If one class is an rdfs:subClassOf another, every instance of the narrower class is also an instance of the broader class. The relationship is transitive. Cycles make classes mutually subsuming under RDFS entailment, which may be intentional equivalence or an accidental modeling error. Test the closure produced by the complete imported hierarchy.

Subproperties

A subproperty statement entails a corresponding triple using the broader property. This can support queries across specialized relationships, but it does not impose the argument constraints familiar from programming-language method overrides. Domain and range consequences from the superproperty can apply to data introduced through the subproperty.

Domain and range are inference rules

An rdfs:domain statement means that any subject using the property is inferred to belong to the declared class. Range similarly types the object. These are not validation gates and do not say that only members of those classes may use the property. Misusing domain and range as documentation can therefore classify large portions of a graph unexpectedly.

Labels, comments and language

rdfs:label and rdfs:comment provide human-readable annotations. Use language tags and allow more than one value for multilingual vocabularies. Labels are not identifiers and may change without changing the resource. Interfaces should select labels using an explicit language fallback rather than assuming one literal exists.

RDFS versus SHACL and OWL

Choose RDFS for lightweight vocabulary relationships and basic entailment. Choose OWL when the domain needs richer logical definitions, disjointness or property characteristics. Choose SHACL when the goal is validating graph shape and producing actionable reports. These layers can work together as long as processing order and expected entailment are documented.

Publication review

Dereference vocabulary IRIs when practical, publish stable machine-readable representations and retain old term identifiers. Run an RDFS reasoner over representative data, inspect newly inferred types and query for hierarchy cycles. Version changes that affect domains, ranges or subclass relationships as semantic changes, not merely documentation edits.

Questions for a design review

Use this reference to make a review decision, not merely to recognize terminology. Record the concrete document, schema, processor or consumer being discussed; the language and processor versions; and the behavior that must remain compatible. A useful review produces fixtures and an owner for every unresolved assumption.

What executable example or test demonstrates the intended behavior for the vocabulary layer?
What executable example or test demonstrates the intended behavior for classes and instances?
What executable example or test demonstrates the intended behavior for subclass relationships?
What executable example or test demonstrates the intended behavior for subproperties?
What executable example or test demonstrates the intended behavior for domain and range are inference rules?
What executable example or test demonstrates the intended behavior for labels, comments and language?

Include at least one ordinary case, one boundary case and one deliberately invalid or unsupported case. Check the result in the actual production toolchain, because parsers, validators, code generators and reasoners do not all implement the same optional features. Store the selected contract version with the test result, then repeat the review when a dependency, namespace, profile or public declaration changes.

RDF graph fundamentals · OWL ontology engineering

Query set / FAQ

Frequently asked questions

01What does the RDF Schema Classes and Properties reference cover?

Use RDF Schema to publish class and property vocabularies, and understand entailments from subclass, subproperty, domain and range statements.

02When should I use this Technical reference guidance?

Use it when designing, reviewing or updating a system that depends on RDF Schema Classes and Properties. Apply the guidance to a concrete example and record any project-specific policy that goes beyond the standard.

03How can I verify a RDF Schema Classes and Properties design decision?

Create a minimal positive example, a negative or boundary example, and run both through the same processors and consumer versions used in production. Keep the expected outcome with the fixture so the decision remains reproducible.

04What are the limitations of this Technical reference reference?

The page explains a focused technical decision; it does not replace the complete specification, processor documentation or integration testing. Version-specific behavior and external dependencies must still be verified in the target environment.