1---2name: odp-pattern-selector3description: Browse and select Ontology Design Patterns (ODPs) from the ODP catalogue for ontology modeling. Use whenever the user needs to choose a modeling pattern, asks "how should I model X?", wants to represent parts, roles, events, time, collections, situations, n-ary relations, or any recurring ontology structure. Also use proactively during Step 3 (Knowledge Organization) and Step 4 (Draft Proposal) of the ontology-builder workflow when identifying candidate axiom patterns. Covers 55+ patterns from ontologydesignpatterns.org and the ODPA repository.4---56# Ontology Design Pattern Selector78Use this skill to **find and apply established Ontology Design Patterns (ODPs)** when modeling an ontology. ODPs are reusable, community-vetted solutions to common ontology engineering problems. Each pattern comes with a formal OWL building block, competency questions, and usage guidance.910## When to Use1112- **Step 3 (Knowledge Organization)**: When identifying candidate axiom patterns and checking whether an existing ODP fits the domain.13- **Step 4 (Draft Proposal)**: When structuring the class hierarchy and choosing how to model relations, roles, events, temporal aspects, or part-whole structures.14- **Ad-hoc modeling questions**: When the user asks "how should I model roles?", "what pattern handles n-ary relations?", "how do I represent part-whole with time?", etc.15- **Import-over-reinvention**: When a pattern's OWL building block can be imported or adapted rather than recreating equivalent structures.1617## How to Use18191. **Run the modeling checklist** (`references/ModelingChecklist.md`): Before finalizing any draft, check for over-classification, anti-patterns, and structural issues. This is mandatory during Step 4.202. **Scan the catalogue below** to find patterns matching the user's modeling problem (match by intent, CQs, or domain).213. **Read the full reference file** for candidate patterns: each pattern has a detailed file at `references/<pattern-name>.md` with full documentation, OWL elements, consequences, related patterns, and the OWL building block URL.224. **Present candidates** to the user with rationale for why each pattern fits.235. **Apply the pattern** by adapting its classes and properties to the user's domain, referencing the OWL building block as a template.2425## Source2627All patterns originate from [ontologydesignpatterns.org](http://ontologydesignpatterns.org) and the [ODPA patterns repository](https://github.com/odpa/patterns-repository). Most are based on DOLCE-UltraLite (DUL).2829---3031## Pattern Catalogue3233### Parts and Wholes3435| Pattern | Intent | When to Use | Reference |36|---------|--------|-------------|-----------|37| **PartOf** | Represent entities and their parts with transitive parthood. | You need a general transitive part-whole relation (e.g. brain is part of body). | `references/PartOf.md` |38| **Componency** | Represent proper parts (intransitive) of objects. | You need non-transitive composition where components form a designed system (e.g. engine has turbine as component). | `references/Componency.md` |39| **Constituency** | Represent constituents of an entity (material composition). | The parts are a different kind from the whole — matter-form relation (e.g. a vase is constituted by clay). | `references/Constituency.md` |40| **WinstonPartWhole** | Distinguish multiple part-whole relation types (component, member, portion, stuff, feature, place). | You need fine-grained distinctions between different kinds of parthood following Winston's taxonomy. | `references/WinstonPartWhole.md` |41| **TimeIndexedPartOf** | Represent part-whole relations that change over time. | Parts can be added or removed from a whole over time (e.g. a department was part of a university from 2000 to 2010). | `references/TimeIndexedPartOf.md` |4243### Collections and Membership4445| Pattern | Intent | When to Use | Reference |46|---------|--------|-------------|-----------|47| **CollectionEntity** | Represent collections and their members. | You need to model groups, sets, or named collections with membership (e.g. the Louvre Egyptian collection). | `references/CollectionEntity.md` |48| **Bag** | Model bags — collections allowing duplicate items. | The collection can have multiple copies of the same element, and you need to track each item individually. | `references/Bag.md` |49| **List** | Model ordered sequences of items. | Order matters — you need first, last, next, previous navigation through a collection. | `references/List.md` |50| **Set** | Model sets — collections without duplicates. | You need a mathematical set with no repeated elements and set operations. | `references/Set.md` |5152### Agents, Roles, and Participation5354| Pattern | Intent | When to Use | Reference |55|---------|--------|-------------|-----------|56| **AgentRole** | Represent agents and the roles they play. | An agent (person, organization) plays one or more roles; roles are not permanent types but assignable positions. | `references/AgentRole.md` |57| **Objectrole** | Represent objects and the roles they play (generalization of AgentRole). | Any object (not just agents) can play a role — a more general version of AgentRole. | `references/Objectrole.md` |58| **ActingFor** | Represent agents acting on behalf of other agents. | One agent delegates to or acts as proxy for another (e.g. a lawyer acts for a client). | `references/ActingFor.md` |59| **Participation** | Represent objects participating in events. | You need a basic binary relation between objects and events (e.g. a person participated in a meeting). | `references/Participation.md` |60| **ParticipantRole** | Represent participation with an explicit role. | The kind of participation matters — the same object can participate in different roles (e.g. speaker vs. attendee). | `references/ParticipantRole.md` |61| **Co-participation** | Represent multiple objects participating in the same event. | You need to query which objects co-participated in an event without n-ary reification. | `references/Co-participation.md` |62| **TimeIndexedPersonRole** | Represent time-bounded roles played by persons. | Roles are temporary and you need to record when a person held a specific role. | `references/TimeIndexedPersonRole.md` |6364### Events, Actions, and Processes6566| Pattern | Intent | When to Use | Reference |67|---------|--------|-------------|-----------|68| **Action** | Represent intentional actions by agents. | You need to model deliberate actions that agents perform (with a plan or goal behind them). | `references/Action.md` |69| **EventCore** | Represent events with participants, time, and place. | You need a rich event model connecting who, what, when, and where. | `references/EventCore.md` |70| **BasicPlan** | Represent plans as descriptions that define goals and tasks. | You need to model plans, strategies, or workflows as first-class objects that can be described and compared. | `references/BasicPlan.md` |71| **BasicPlanExecution** | Represent the execution of a plan (linking plan to actual performance). | You need to track how a plan was actually carried out — which actions satisfied which plan steps. | `references/BasicPlanExecution.md` |72| **TaskExecution** | Represent tasks and their execution by agents. | You need to model task assignment and completion — who did what task and when. | `references/TaskExecution.md` |73| **Controlflow** | Represent control flow ordering between tasks or actions. | You need to model if-then, sequence, parallel, or conditional branching between process steps. | `references/Controlflow.md` |74| **Move** | Represent the movement of entities from one place to another. | Something physically moves — you need origin, destination, and the moving object. | `references/Move.md` |75| **Transition** | Represent state transitions of entities. | An object moves from one state to another as the result of a process or event. | `references/Transition.md` |76| **MaterialTransformation** | Represent transformations of materials or substances. | Raw materials are transformed into products through a process (e.g. manufacturing, cooking). | `references/MaterialTransformation.md` |7778### Time, Sequence, and Recurrence7980| Pattern | Intent | When to Use | Reference |81|---------|--------|-------------|-----------|82| **Sequence** | Represent ordering/precedence relations (transitive and intransitive). | You need to express "before/after" between tasks, events, time intervals, or spatial objects. | `references/Sequence.md` |83| **TimeInterval** | Represent time intervals with start and end. | You need to model durations, periods, or spans of time with boundary points. | `references/TimeInterval.md` |84| **TimePeriod** | Represent named time periods. | You need named, possibly recurring time units (e.g. "Monday", "January", "Q3 2025"). | `references/TimePeriod.md` |85| **PeriodicInterval** | Represent regularly recurring intervals. | Something happens on a regular schedule (e.g. every Tuesday, every 6 months). | `references/PeriodicInterval.md` |86| **RecurrentEventSeries** | Represent series of recurring events. | A named event recurs multiple times (e.g. annual conference, weekly meeting). | `references/RecurrentEventSeries.md` |87| **RecurrentSituationSeries** | Represent series of recurring situations. | A situation (context with multiple entities) recurs regularly. | `references/RecurrentSituationSeries.md` |8889### Temporal Indexing9091| Pattern | Intent | When to Use | Reference |92|---------|--------|-------------|-----------|93| **TimeIndexedClassification** | Represent classification/categorization that changes over time. | An entity's category or type is not permanent — it changes over time and you need to record when. | `references/TimeIndexedClassification.md` |94| **TimeIndexedSituation** | Represent situations (contexts) anchored to specific time intervals. | You need to record when a particular situation held (e.g. during 2020, the team had these members). | `references/TimeIndexedSituation.md` |95| **TimeIndexedParticipation** | Represent participation that is bounded in time. | An object's participation in an event has a specific time range (e.g. an employee joined a project in March 2024). | `references/TimeIndexedParticipation.md` |9697### Description, Situation, and Context9899| Pattern | Intent | When to Use | Reference |100|---------|--------|-------------|-----------|101| **Description** | Represent descriptions as social objects that define concepts, roles, parameters. | You need to model plans, norms, regulations, diagnoses — any conceptual framework that can be applied to reality. | `references/Description.md` |102| **Situation** | Represent contexts or reified n-ary relations. | You need to group multiple related entities into a single context, or reify an n-ary relation as a first-class object. | `references/Situation.md` |103| **DescriptionAndSituation** | Link descriptions (conceptual) to situations (actual). | You need to express that a real-world situation satisfies (or violates) a description/plan/norm. | `references/DescriptionAndSituation.md` |104| **Classification** | Represent concept/category assignment to entities. | Entities are classified under concepts that are first-order objects (not just OWL classes) — e.g. tagging, folksonomies, thesauri. | `references/Classification.md` |105| **Parameter** | Represent parameters that constrain or qualify descriptions. | A description has configurable parameters with regions of allowed values (e.g. a medical guideline with dosage ranges). | `references/Parameter.md` |106107### N-ary Relations and Reification108109| Pattern | Intent | When to Use | Reference |110|---------|--------|-------------|-----------|111| **NaryParticipation** | Reify participation as an n-ary relation. | Participation has attributes beyond just "who" and "in what" — you need to attach role, time, or other qualifiers to the participation itself. | `references/NaryParticipation.md` |112| **NaryRelationOWL2** | Represent n-ary relations in OWL 2. | A relation connects 3+ entities simultaneously and cannot be reduced to binary properties. | `references/NaryRelationOWL2.md` |113114### Space and Place115116| Pattern | Intent | When to Use | Reference |117|---------|--------|-------------|-----------|118| **Place** | Represent places as first-class entities. | You need to model locations, geographic regions, or spatial entities with their own identity. | `references/Place.md` |119| **SpatioTemporalExtent** | Represent entities with both spatial and temporal extent. | Things occupy space and time together — you need to model spatiotemporal regions or events with location and duration. | `references/SpatioTemporalExtent.md` |120| **Trajectory** | Represent trajectories — paths through space over time. | An entity follows a path from point to point across time (e.g. GPS tracks, migration routes). | `references/Trajectory.md` |121122### Information and Knowledge123124| Pattern | Intent | When to Use | Reference |125|---------|--------|-------------|-----------|126| **InformationRealization** | Represent information objects and their physical realizations. | You need to distinguish between abstract information (e.g. a novel) and its physical forms (e.g. a hardcover copy, an ebook). | `references/InformationRealization.md` |127| **InformationObjectsAndRepresentationLanguages** | Represent information objects along with their representation languages. | Information is encoded in a specific language or format (e.g. an ontology in OWL, a document in HTML). | `references/InformationObjectsAndRepresentationLanguages.md` |128| **IntensionExtension** | Represent the distinction between intension (meaning) and extension (instances). | You need to separate a concept's definition from its actual instances (e.g. "mammal" as concept vs. all actual mammals). | `references/IntensionExtension.md` |129| **Observation** | Represent observations or measurements. | You need to model who observed what, when, where, with which method, and what result was obtained. | `references/Observation.md` |130| **Topic** | Represent topics or subjects. | Entities are about or related to topics/themes (e.g. documents have subjects). | `references/Topic.md` |131| **Tagging** | Represent tagging — associating tags with entities. | Users or systems assign free-form or structured tags to entities (e.g. social tagging, annotation). | `references/Tagging.md` |132| **Provenance** | Track the provenance/lineage of entities. | You need to record where something came from, who created it, and how (e.g. data provenance, artifact history). | `references/Provenance.md` |133134### State, Disposition, and Change135136| Pattern | Intent | When to Use | Reference |137|---------|--------|-------------|-----------|138| **ObjectWithStates** | Represent objects that can be in different states. | An object transitions between named states over its lifecycle (e.g. an order: pending → shipped → delivered). | `references/ObjectWithStates.md` |139| **Disposition** | Represent dispositions or capabilities of entities. | An entity has a latent capability that may or may not be realized (e.g. fragility, solubility, a skill). | `references/Disposition.md` |140141### Miscellaneous142143| Pattern | Intent | When to Use | Reference |144|---------|--------|-------------|-----------|145| **Region** | Represent abstract or concrete regions (value spaces). | You need to model value spaces, quality regions, or continuous/discrete ranges (e.g. color space, temperature range). | `references/Region.md` |146| **Partition** | Partition a class into exhaustive, disjoint subclasses. | A class is divided into non-overlapping categories that together cover the whole class. | `references/Partition.md` |147| **ActivitySpecification** | Represent specifications of activities. | You need to describe what an activity should do (its specification) separately from actual activity instances. | `references/ActivitySpecification.md` |148| **EEP** | Executor-Execution-Procedure: link who does it, the doing, and the specification. | You need the triad of an executor (who), an execution (the act), and a procedure (the plan/spec). | `references/EEP.md` |149| **CommunicationEvent** | Represent communication events between agents. | You need to model messages, conversations, or information exchange between parties. | `references/CommunicationEvent.md` |150151---152153## Pattern Selection Guide154155When uncertain which pattern to use, consider these common modeling problems:156157| Modeling Problem | Recommended Pattern(s) |158|-----------------|----------------------|159| "X is part of Y" (transitive) | **PartOf** |160| "X is a component of Y" (designed system) | **Componency** |161| "X is made of Y" (material constitution) | **Constituency** |162| Parts change over time | **TimeIndexedPartOf** |163| Groups, teams, collections | **CollectionEntity**, **Bag**, **List**, **Set** |164| People/agents play roles | **AgentRole**, **TimeIndexedPersonRole** |165| Objects play roles | **Objectrole** |166| Delegation or proxy | **ActingFor** |167| Something participates in an event | **Participation**, **ParticipantRole** |168| Multiple participants in one event | **Co-participation** |169| Ordering, before/after | **Sequence** |170| Events with who/what/when/where | **EventCore** |171| Events composed of sub-events | **EventCore** (subEventOf) |172| Plans and their execution | **BasicPlan**, **BasicPlanExecution** |173| Task assignment and tracking | **TaskExecution** |174| Workflow branching/ordering | **Controlflow** |175| Entity changes state | **ObjectWithStates**, **Transition** |176| Entity moves location | **Move** |177| Raw material → product | **MaterialTransformation** |178| Relation involving 3+ entities | **Situation**, **NaryParticipation**, **NaryRelationOWL2** |179| Classification changes over time | **TimeIndexedClassification** |180| Concept vs. its instances | **IntensionExtension**, **Classification** |181| Abstract info vs. physical copy | **InformationRealization** |182| Recurring events/schedules | **RecurrentEventSeries**, **PeriodicInterval** |183| Paths/tracks through space-time | **Trajectory** |184| Capability/potential | **Disposition** |185| Tagging or annotation | **Tagging** |186| Data lineage/history | **Provenance** |