What needs to be finished first
At least five must-have questions with identified concepts and relationships are available to validate pattern choice.
What needs to be ready before start
Pattern catalog (for example ODP wiki, NeOn pattern repository, or internal project catalog), modeling tool (Protégé, TopBraid), sketch surface, test query sandbox, sample data for pattern validation.
One ontology engineer; one to two domain experts per pattern session; optional pattern reviewer with experience from other projects.
Modeling problem in one sentence; relevant competency questions; existing model fragments; list of known patterns (Part-Whole, Time-Indexed Situation, Roles, Provenance).
1-3 h per pattern
Modeling problem and CQs visible. Pattern catalog at hand. Sandbox with mini sample data prepared so patterns can be tested immediately.
The one question this method answers
Which modeling pattern solves the current problem so that it fits competency questions, the existing model, and reuse strategy?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Isolate problem | 15-20 min | Define the modeling problem in one sentence (for example "how do I model time-valid employee roles?"). Identify affected CQs. Sketch a solution-free problem fragment. | If the problem splits into 2-3 sentences, multiple patterns are involved. Prefer one pattern session per pattern instead of mixing everything. |
2Phase 2: Search pattern catalog | 20-30 min | Search for suitable candidates in the pattern catalog (keyword search, tags, similar problems). For each candidate, read description, inspect examples, and roughly check coverage against CQs. | If three patterns seem equally strong, they are related. Choose the one with clearest documentation and strongest community, not the most exotic. |
3Phase 3: Adapt pattern | 30-60 min | Adapt pattern to the domain: rename classes, specialize properties, add constraints. Document reuse relationship (pattern IRI, adaptation delta). | If adaptation changes 80% of the pattern, it is no longer reuse. Document it clearly as a custom pattern or choose another pattern. |
4Phase 4: Validate | 20-30 min | Populate the pattern in a sandbox with sample data. Run test queries for affected CQs. Check edge cases (empty values, time boundaries, multi-roles). | If test query returns unexpected results, adaptation is too loose. Recheck pattern or tighten constraints, do not adapt test data. |
5Phase 5: Document and reference | 15-20 min | Document pattern selection, source, adaptation, affected CQs, and test results in the model repo. Reference selected patterns as annotations in the model (for example dct:source) on pattern IRI. | Without reference, the next modeler forgets why this pattern was selected. Reverse-engineering patterns is expensive. |
What comes out at the end
Pattern application document per pattern with problem, chosen pattern, source URI, adaptation (delta), sample data, test query results, and links to CQs. Plus annotation in the model itself.
Header with date, pattern version, and model version. Document delta for later pattern updates and keep previous version. Pin model annotation to exact pattern version, not a moving target.
Compact working template for Ontology Design Patterns with context, input, output artifacts, and next step.
Reusable modeling patterns for recurring problems in ontologies and knowledge graphs.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Short notes along the runsheet.
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Problem: How do I model that Anna Müller served as Team Lead for Team Discovery from 2023-01-15 to 2024-12-31, then moved to Engineering Manager?
Affected CQs: CQ 8 (Who was Team Lead of Team X at time T?), CQ 12 (History of roles of a person), CQ 15 (Who had role Y between T1 and T2?).
Pattern: Time-Indexed Person Role from odp.cs.ox.ac.uk/wiki/Submissions:TimeIndexedPersonRole.
Adaptation:
TimeIndexedRole renamed to RoleAssignment (project language).forPerson renamed to assignedTo.validFrom required, validTo optional (open intervals allowed).Test data (TTL excerpt):
:anna_ra_2023 a :RoleAssignment ; :assignedTo :anna ; :hasRole :TeamLead ;
:inTeam :discovery ; :validFrom "2023-01-15"^^xsd:date ; :validTo "2024-12-31"^^xsd:date .
Test query CQ 8 returns Anna for 2024-06-01. CQ 12 returns chronological list. CQ 15 correctly returns two people for overlapping period.
Source: ODP wiki, version 2024-03-01. Model annotation: dct:source <http://...TimeIndexedPersonRole>.
Recognize symptoms and steer against them
Patterns are used without a CQ requiring them, making model complexity unnecessary.
Justify each pattern application with affected CQs. If no CQ benefits, do not apply the pattern; a simple property may be enough.
Pattern is barely recognizable after adaptation; reuse benefit is lost.
Track delta. If over 50% changed, either document as custom pattern honestly or select another pattern.
Pattern is added to model before anyone tested whether CQs work with it.
Mandatory sandbox with minimal sample data. At least one test query per affected CQ. No merge to main without test.
Two applied patterns overlap or contradict each other (for example two time models), with no conflict check.
Whenever applying a new pattern, check which existing patterns interact with the same classes. Document and resolve conflicts before both patterns land.
Pattern was applied but no annotation in TTL/OWL; three months later nobody knows why it was modeled.
At minimum add `dct:source` or a comparable annotation per pattern-instantiated class. Doco generator (WIDOCO) will expose it later.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.