How the four semantic layers work together — and why real-world ontologies use SKOS annotations.
Every well-structured knowledge graph has four layers that build on each other. Understanding how they relate is the key to designing ontologies that are both rigorous and reusable.
VOCABULARIES (dcterms, foaf, rdfs, skos, schema.org) ↓ used by ONTOLOGY (northwind-ontology.ttl) ↓ describes structure of DATA (instances: customers, products, orders) ↓ classified by TAXONOMY (product-categories.ttl)
Let's walk through each one using the Northwind database as a concrete example.
What they are: Standard properties and classes defined by standards bodies (W3C, Dublin Core, FOAF project, Schema.org). They provide shared, well-defined terms that everyone agrees on.
Key principle: You don't invent your own vocabulary — you import and reuse existing ones. When you need "name", use foaf:name. When you need "license", use dcterms:license. When you need "formal definition", use skos:definition.
foaf:name
dcterms:license
skos:definition
rdfs:
rdfs:label
rdfs:comment
rdfs:subClassOf
owl:
owl:Class
owl:ObjectProperty
foaf:
foaf:firstName
foaf:lastName
dcterms:
dcterms:creator
skos:
skos:Concept
schema:
When you write foaf:firstName instead of nwo:firstName, any tool that understands FOAF automatically knows what that property means. Search engines, data integration tools, and other ontologies can interoperate with your data without custom mapping.
nwo:firstName
In RDF Studio: The vocabulary TTL files in vocabularies/ are local copies of these standards. They're loaded into the database so the UI can display their labels and SPARQL queries can reference them. Try it: Go to Query ▸ Editor and run: SELECT * WHERE { ?s a foaf:Person } LIMIT 10 — the foaf: prefix works because the FOAF vocabulary is loaded.
In RDF Studio: The vocabulary TTL files in vocabularies/ are local copies of these standards. They're loaded into the database so the UI can display their labels and SPARQL queries can reference them.
vocabularies/
Try it: Go to Query ▸ Editor and run: SELECT * WHERE { ?s a foaf:Person } LIMIT 10 — the foaf: prefix works because the FOAF vocabulary is loaded.
SELECT * WHERE { ?s a foaf:Person } LIMIT 10
What they are: OWL class and property definitions that describe the structure of your specific domain. The ontology says "there exists a thing called Customer, it has a companyName (string), and it places Orders."
Key distinction: An ontology defines what kinds of things exist and how they relate. It doesn't say which things exist (that's the data) or how to categorize them (that's the taxonomy).
nwo:Customer a owl:Class ; rdfs:label "Customer" ; rdfs:comment "A client who places orders through the system." ; skos:definition "An organization or individual that purchases products from Northwind Traders through the order management system." ; skos:example "ALFKI - Alfreds Futterkiste (Germany)" ; rdfs:subClassOf nwo:Organization .
This says:
Customer
Organization
skos:example
The annotations don't change the structure — they document it for humans. A reasoner ignores skos:definition completely. But for anyone reading or maintaining the ontology, they're essential.
In RDF Studio: Go to the Model ▸ Editor, click any class, and look for the SKOS Annotations section in the right panel. You'll see the definition, examples, and scope notes for classes like Customer, Product, and Order.
What they are: The concrete entities that populate your knowledge graph. While the ontology says "Customer exists and has a companyName", the data says "ALFKI is a Customer whose companyName is 'Alfreds Futterkiste'."
nwr:ALFKI a nwo:Customer ; nwo:companyName "Alfreds Futterkiste" ; nwo:city "Berlin" ; nwo:country "Germany" .
Data is where users spend most of their time in RDF Studio — browsing instances in Explore ▸ Browse, running SPARQL queries, and visualizing relationships.
nwo:companyName
xsd:string
What they are: SKOS concept schemes that organize things into hierarchical categories. While ontology classes define types (Customer, Product), taxonomies define classification values (Beverages > Coffee > Instant Coffee).
nwt:beverages a skos:Concept ; skos:prefLabel "Beverages" ; skos:definition "Soft drinks, coffees, teas, beers, and ales" ; skos:inScheme nwt:product-categories ; skos:narrower nwt:coffee, nwt:tea, nwt:juice . nwt:coffee a skos:Concept ; skos:prefLabel "Coffee" ; skos:broader nwt:beverages ; skos:inScheme nwt:product-categories .
skos:broader
skos:narrower
Northwind includes a taxonomy-ontology-mapping.ttl file that bridges the two:
taxonomy-ontology-mapping.ttl
# "The taxonomy concept 'beverages' corresponds to # instances of the ontology class Category" nwt:beverages skos:closeMatch nwo:Category .
This is the standard pattern: keep them separate, link them with skos:closeMatch, skos:exactMatch, or custom mapping properties.
skos:closeMatch
skos:exactMatch
Why separate? Because:
This is where it gets interesting. SKOS appears in both layers, but for different reasons:
SKOS was originally designed for this — building thesauri and classification schemes:
nwt:beverages a skos:Concept ; skos:prefLabel "Beverages" ; skos:broader nwt:food-beverages-tobacco ; skos:narrower nwt:coffee, nwt:tea .
Here, SKOS is the structural backbone. skos:Concept, skos:broader, skos:narrower, skos:inScheme — these define what the taxonomy is.
skos:inScheme
Production ontologies also use SKOS, but purely as annotations on OWL classes:
nwo:Customer a owl:Class ; rdfs:label "Customer" ; rdfs:comment "A client who places orders." ; skos:definition "An organization or individual that purchases products..." ; skos:example "ALFKI - Alfreds Futterkiste" ; skos:scopeNote "Customers are always organizations, not individuals." .
Here, SKOS is just documentation. It annotates the OWL class but doesn't change its meaning. A reasoner completely ignores these triples.
The rule of thumb: use rdfs:comment for a brief informal description, and skos:definition for the formal definition you'd put in a glossary.
Reactome defines over 2,000 biological pathway classes. In drug research, the precise definition of "phosphorylation" vs. "dephosphorylation" has life-or-death implications:
reactome:Phosphorylation a owl:Class ; skos:definition "A reaction that adds a phosphate group to a substrate" ; skos:altLabel "Phosphorylation reaction" ; skos:editorialNote "Curated by EMBL-EBI pathway team, 2024-Q3" .
Multiple names (skos:altLabel) matter because a protein may be known by its gene symbol, full name, and common abbreviation.
skos:altLabel
The Financial Industry Business Ontology defines classes for every financial instrument. Regulators need consistent, auditable definitions:
fibo:CorporateBond a owl:Class ; skos:definition "A debt security issued by a corporation to raise capital" ; skos:example "Apple Inc. 2.65% Notes due 2051" ; skos:scopeNote "Excludes government bonds and municipal bonds" .
These ontologies don't use SKOS because they're taxonomies — they use it because:
skos:editorialNote
Here's the complete picture for a single Northwind Product, showing how all four layers interact:
VOCABULARY LAYER ├── rdfs:label → "Product" (display name) ├── rdfs:comment → "A tangible item offered in the catalog" (informal) ├── dcterms:creator → "RDF Studio" (provenance on the ontology) ├── foaf:homepage → https://github.com/... (ontology homepage) ONTOLOGY LAYER ├── owl:Class → Product IS a class (structural) ├── rdfs:subClassOf → with restrictions on unitPrice, category (structural) ├── skos:definition → "A tangible specialty food item..." (formal definition) ├── skos:example → "Chai (Beverages, $18.00)" (concrete example) ├── skos:altLabel → "Catalog Item" (synonym) DATA LAYER ├── nwr:chai a nwo:Product → Chai IS an instance of Product ├── nwo:productName "Chai" → the actual data ├── nwo:unitPrice 18.00 → the actual data ├── nwo:hasCategory nwr:beverages → links to... TAXONOMY LAYER ├── nwt:beverages a skos:Concept → "Beverages" IS a category concept ├── skos:narrower nwt:tea, nwt:coffee → with subcategories ├── skos:broader nwt:food-beverages → in a hierarchy
Each layer has a clear responsibility. Vocabularies provide the language. The ontology defines the structure. Data populates it. Taxonomies classify it.
Key takeaway: Don't try to do everything in one layer. An ontology that also tries to be a taxonomy becomes unmaintainable. A taxonomy that also tries to define constraints becomes unreasonable (literally — reasoners won't process it correctly). Keep them separate, link them with mappings, and use SKOS annotations to document the ontology for humans.