What Are Ontology Design Patterns? A Practical Guide

If you’ve ever worked with ontologies, you’ve probably experienced the “blank page problem” — staring at Protege, wondering how to model a process, a measurement, or a material composition. Ontology Design Patterns (ODPs) solve this by providing reusable, tested modeling templates.

Think of them as design patterns for knowledge representation — the same idea as the Gang of Four patterns in software engineering, but for ontologies.

The Problem

Imagine you need to model a tensile test in your materials science ontology. You need to capture:

• The material being tested
• The testing machine and its parameters
• The person performing the test
• The resulting stress-strain curve
• The date, location, and standard used

You could model this from scratch. But then your colleague modeling a hardness test faces the same decisions. And someone else modeling a chemical synthesis. Each reinvents the wheel, and their models are incompatible.

The Solution: Patterns

An Ontology Design Pattern is a small, self-contained ontology fragment that solves a recurring modeling problem. For the testing scenario above, you’d use a Process Pattern:

┌─────────────┐    has_input     ┌──────────┐
│   Process    │ ───────────────→│ Material  │
│ (TensileTest)│                 └──────────┘
└──────┬───────┘
       │ has_output
       ▼
┌──────────────┐    has_parameter  ┌───────────┐
│   Result     │ ←────────────────│ Parameter │
│(StressCurve) │                  │(LoadRate) │
└──────────────┘                  └───────────┘

This pattern works for any process — synthesis, characterization, simulation — because it captures the universal structure of “something transforms inputs into outputs using parameters.”

Types of ODPs

There are several categories:

1. Content Patterns

The most common type. They provide domain-independent modeling solutions:

2. Structural Patterns

These address ontology architecture:

• Modularity — how to split a large ontology into manageable modules
• Alignment — how to connect your ontology to upper-level ontologies (BFO, DOLCE)
• Naming conventions — IRI patterns, label standards

3. Reasoning Patterns

These leverage OWL reasoning:

• Closure axioms — ensuring completeness
• Value partitions — modeling categorical properties
• N-ary relations — representing complex relationships that aren’t simply binary

How We Use ODPs in Materials Science

In our work on the MSE Knowledge Graph, we surveyed 15+ materials science ontologies and found that most contain implicit patterns — recurring structures that were never formally documented as reusable patterns.

We developed a method to automatically extract these implicit patterns and published them as an open catalog: ODPs4MSE.

Key patterns we identified:

The Process-Flow Pattern

Process → has_input → MaterialEntity
Process → has_output → MaterialEntity
Process → has_participant → Agent
Process → occurs_in → SpatiotemporalRegion

Used by: PMDco, MatOnto, EMMO, BWMD

The Measurement Pattern

Measurement → measures_property → Quality
Measurement → has_value → ValueSpecification
ValueSpecification → has_numeric_value → xsd:float
ValueSpecification → has_unit → Unit

Used by: QUDT alignment, OM, EMMO

The Material Composition Pattern

Material → has_part → Constituent
Constituent → has_proportion → Proportion
Proportion → has_value → xsd:float

How to Use ODPs in Practice

Step 1: Identify Your Modeling Problem

Before reaching for Protege, write down competency questions — what should your ontology be able to answer?

Example: “What materials were tested using nanoindentation at temperatures above 500°C?”

Step 2: Search for Existing Patterns

Check these resources:

• Ontology Design Patterns portal
• ODPs4MSE catalog
• Existing domain ontologies (they often contain implicit patterns)

Step 3: Adapt and Compose

Patterns are building blocks. Combine the Process Pattern with the Measurement Pattern to model “a tensile test that produces a stress-strain measurement.”

Step 4: Validate with SHACL

Write SHACL shapes that enforce your patterns. This catches data that doesn’t conform:

ex:ProcessShape a sh:NodeShape ;
    sh:targetClass mwo:Process ;
    sh:property [
        sh:path mwo:has_input ;
        sh:minCount 1 ;
        sh:class mwo:MaterialEntity ;
    ] .

Why ODPs Matter

1. Consistency — Multiple teams model the same things the same way
2. Reusability — Don’t reinvent the wheel for every new project
3. Interoperability — Shared patterns make ontology alignment easier
4. Learnability — Newcomers have concrete examples to follow
5. Quality — Patterns encode best practices and avoid common pitfalls

Further Reading

• Gangemi, A. (2005). Ontology Design Patterns for Semantic Web Content
• Blomqvist, E. et al. (2016). Ontology Engineering with Ontology Design Patterns
• Our paper: Semantic Representation of Processes with Ontology Design Patterns

Working on an ontology and not sure how to model something? Check if there’s a pattern for it first. And if you create a new pattern, please share it — the community benefits from every documented solution.