Introduction
- Distinctive and repetitive invariants across data, objects, processes etc.
- Patterns emerge from data, ontologies, queries etc.
- Majority of ontologies share a small set of modelling or publishing challenges that can be solved using a common strategy or an established best practice
- An ODP should have a motivating requirements, applicability limits, benefits, and shortcomings associated with it
- ODPs are analogous to software design patterns
Examples
- Trajectory Pattern
- Can be used in transportation domain, wildlife monitoring, scientific cruises
- Information Realization Pattern
- Describes relation between an information object (book) and its physical realization (paper copy of the book)
ODP Types
- Several types of ODPs
- Structural ODPs
- Correspondence ODPs
- Content ODPs
- Reasoning ODPs
- Presentation ODPs
- Lexico-Syntactic ODPs
- Available at ODP Repository
Structural ODPs
- Logical ODPs and Architectural ODPs make up the Structural ODPs
- Logical ODPs
- Composition of logical constructs that solve a problem of expressivity
- Eg: Expressing n-ary relation between concepts
- They are further divided into Logical Macros and Transformation patterns
- Logical Macros are shortcuts to recurrent intuitive logical expressions
- Transformation patterns translate a logical expression from one language to the other
Structural ODPs
- Architectural ODPs
- They have an affect on the overall shape of the ontology
- They aim to constrain how the ontology should look like
- They are chosen if there are specific needs such as any computational complexity constraints
Reasoning ODPs
- They are applications of Logical ODPs to obtain certain reasoning results
- Eg: Classification (all superclasses for each class in the ontology)
- They provide hints to the reasoner as to what kind of reasoning has to be performed in order to answer queries
Correspondence ODPs
- Correspondence ODPs are divided into Reengineering ODPs and Mapping (or Alignment) ODPs
- Reengineering ODPs
- They are design solutions that transform a conceptual model into an ontological model
- The source model can be a non-ontological model such as a thesaurus, UML model etc.
- Schema reengineering patterns and Refactoring patterns are sub categories of Reengineering ODPs
- Schema reengineering patterns are rules to transform a non-OWL ontology to an OWL ontology
Correspondence ODPs
- Refactoring patterns transform (refactor) models in the same form. For example, from one OWL 2 DL ontology to another
- Eg: An ontology defines an object property to represent preparing coffee between agent and coffee
- Time of coffee preparation and the tool used should also be added
- An n-ary Logical ODP needs to be used because the property preparing coffee needs to be associated with agent, coffee, time, tool
- The n-ary Logical ODP and the mechanism to replace the existing object property together form the Refactoring ODP
Correspondence ODPs
- Mapping patterns provide design solutions to relate two ontologies without changing the logical types of the ontology entities
- They provide semantic relations between mappable elements in the ontologies
- There are 3 basic semantic relations used for mapping: equivalence, containment, and overlap
- The negative counterparts are also included such as not equivalent, not contained, and no overlap or disjoint
Presentation ODPs
- They deal with usability and readability of ontologies from a user perspective
- They are meant to be good practices that support reuse of ontologies
- Naming ODPs and Annotation ODPs are types of Presentation ODPs
- Naming ODPs are naming conventions for files, namespaces, and ontological entities (class, property, instace)
- Annotation ODPs provide annotation properties such as label (description of an entity, synonyms etc.), seeAlso, versionInfo etc.
Lexico-Syntactic ODPs
- They are linguistic structures or schemas that consist of words following specific order
- They can be used to associate natural language sentences with other ODPs such as Logical and Content ODPs
Content ODPs (CPs)
- Small ontologies that mediate between use cases (problem types) and design solutions
- They are the building blocks to create ontologies
- An ontology can be built by composing different CPs with appropriate dependencies between them and by expanding the CPs as needed
ODP Description
- An ODP can be described using the following fields
- Name
- Intent
- Competency questions
- Alternate names
- Scenarios: Examples of requirements in natural language that can be modelled using this pattern
- Diagram: UML diagram representing the pattern
- Elements: list classes and relations in the pattern
- Consequences: description of benefits and trade-offs
- Known uses: examples of realistic ontologies where the pattern can be used
- Extracted/Reengineered from: reference ontology or conceptual schema from which the pattern has been extracted
- Related patterns: other patterns that are either a specialization, generalization, composition, or component of this pattern. Also lists patterns that are generally used along with the described pattern
- Building block: a reference implementation (URI or owl file)
AgentRole ODP
- Name: Agent Role
- Intent: To represent agents and the role they play
- Competency questions
- what is the role that is played by an agent?
- which agent plays this role?
- Consequences: allows designers to make assertions on roles played by agents without involving the agents that play those roles, and vice versa. It does not allow to express temporariness of roles
- Scenarios: She greeted us all in her various roles of mother, friend, and daughter
Information Realization ODP
- Name: Information Realization
- Description: It represents the relations between information objects like
poems, songs, formulas, etc., and their physical realizations like printed books, registered tracks, physical files, etc
- Intent: To represent information objects and their physical realization.
- Competency questions
- what are the physical realizations of this information object?
- what information objects are realized by this physical object?
- Consequences: This pattern allows to distinguish information objects from their concrete realizations
- Scenarios: The book of the "Divina Commedia"