Ontology Design Patterns

Summary

Computational ontologies in the context of information systems are artifacts that encode a description of some world, for some purpose. Under the assumption that there exist classes of problems that can be solved by applying common solutions (as it has been experienced in software engineering), we envision small, task-oriented ontologies with explicit documentation of design rationales. In this chapter, we describe components called Ontology Design Patterns (OP), and methods that support pattern-based ontology design.

We present a typology of OPs, and then focus on Content Ontology Design Patterns in terms of their background, definition, communication means, related work beyond ontology engineering, exemplification, creation, and usage principles. At the time of chapter’s final version, recently performed experiments of patternbased ontology design show remarkable quality improvement within some sample ontology design projects, specially in terms of compliance to tasks expressed as competency questions or scenarios.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Computational ontologies in thecontext of information systems are artifacts that encode a description ofsome world (actual, possible, counterfactual, impossible, desired, etc.),for some purpose. They have a (primarily logical) structure, and mustmatch both domain and task: they allow the description of entities whoseattributes and relations are of concern because of their relevance in a domainfor some purpose, e.g. query, search, integration, matching, explanation,etc.

Like any artifact, ontologies have a lifecycle: they are designed, implemented, evaluated, fixed, exploited, reused, etc. (cf. chapter “Ontology Engineering Methodology” for an in-depth examination of ontology engineering methodologies).

In this chapter, we focus on patterns for ontology design [14, 18].

Despite the original ontology engineering approach, when ontologies were seen as “portable” components [22], and its enormous impact on Semantic Web and interoperability, today one of the most challenging and neglected areas of ontology design is reusability. The possible reasons include at least: size and complexity of the major reusable ontologies, opacity of design rationales in most ontologies, lack of criteria in the way existing knowledge resources (e.g. thesauri, database schemata, lexica) can be reengineered, and brittleness of tools that should assist ontology designers.

Nowadays, an average user that is trying to build or reuse an ontology, or an existing knowledge resource, is typically left with just some limited assistance in using unfriendly logical structures, some large, hardly comprehensible ontologies, and a bunch of good practices that must be discovered from the literature. A typical usage scenario includes, e.g. a large set of web ontologies that are evaluated (usually in an implicit way) against the intended domain and tasks. The selected ontology (if any) is reused, and then an adaptation process is started in order to cope with the implicit requirements from an ontology project. This scenario is costly in many cases, and automatic selection mechanisms do not help with the adaptation process. Another typical scenario includes so-called “reference” or “core” ontologies that are supposed to be directly reused and specialized. Unfortunately, even if well designed, they are usually large and cover more knowledge than what a designer might need. In this case, it is hard to reuse only the “useful pieces” of the ontology, and consequently the cost of reuse is higher than developing a new ontology from scratch.

On the other hand, the success of very simple and small ontologies like FOAF [6] and SKOS [31] shows the potential of really portable, or “sustainable” ontologies. The lesson learnt supports the new approach to ontology design, which is sketched here.

Under the assumption that there exist classes of problems that can be solved by applying common solutions (as it has been experienced in software engineering), we propose to support reusability on the design side specifically. We envision small (or cleverly modularized) ontologies with explicit documentation of design rationales, and best reengineering practices. These components need specific functionalities in order to be implemented in repositories, registries, catalogues, open discussion and evaluation forums, and ultimately in new-generation ontology design tools. In this chapter, we describe small, motivated ontologies that can be used as building blocks in ontology design. A formal framework for (collaborative) ontology design that justifies the use of building blocks with explicit rationales is presented in [18].

We call the basic building blocks to be used in ontology design Content Ontology Design Patterns (CP) [14]. CPs are small ontologies that mediate between use cases (problem types) and design solutions. They are used as modelling components: ideally, an ontology results from a composition of CPs, with appropriate dependencies between them, plus the necessary design expansion based on specific needs.

Throughout experiences in ontology engineering projects¹ as well as in other ongoing international projects that have experimented with these ideas, typical conceptual patterns have emerged out of different domains, for different tasks, and while working with experts having heterogeneous backgrounds. For example, a simple CP called participation (including objects taking part in events) emerges in domain ontologies as different as enterprise models [23], legal norms [19], sofware management [34], biochemical pathways [16], and fishery techniques [17]. Other, more complex CPs have also emerged in the same disparate domains.

Moreover, since CPs are strictly related to small use cases, they are transparent with respect to the rationales applied to the design of a certain ontology. CPs are therefore an additional tool to achieve tasks such as ontology evaluation, matching, modularization, etc. For example, an ontology can be evaluated against the presence of certain patterns (which act as unit tests for ontologies, cf. [50] and chapter “Ontology Engineering Environments”) that are typical of the tasks addressed by a designer. Furthermore, mapping and composition of CPs can facilitate ontology mapping and alignment/merging. Two ontologies drafted according to CPs can be mapped in an easier way: CP hierarchies will be more stable and well-maintained than local, partial, scattered ontologies. Finally, CPs can be also used in training and educational contexts for ontology engineers.

CPs are a very beneficial kind of patterns for ontology design, because they provide solutions to domain-oriented problems, and are directly reusable. On one hand, CPs are comparable to software engineering (SE) design patterns for what concerns the way they are documented and communicated. On the other hand, the intuition behind their usage is analogous to that of software engineering (object oriented) reusable libraries, e.g. Java libraries. A similar intuition is at the base of approaches to modularization of ontologies, e.g. [8], where the typical distinction between interface and implementation is used in order to distinguish between the module interface and the ontologies that a module encapsulates. CPs are compliant with this approach, and can be encapsulated in modules. However, this aspect is not key to the purpose of this chapter, and does not impact on their expected usage.

There are other types of ontology design patterns (OPs) that are beneficial for different purposes and targeted at different types of users. A typology of OPs will be also introduced in this chapter.

In principle, OPs do not depend on any specific representation language.² In this context, we focus mainly on CPs; in order to provide the readers with concrete examples and a closer view on their exploitation on the Semantic Web, we have decided to refer to OWL CPs (cf. chapter “Web Ontology Language: OWL” for details on OWL). In fact, CPs fit well with Semantic Web requirements for reuse and interoperability of ontologies and data, and as part of our work we have set up the ontologydesignpatterns.org web portal, which collects and makes them available on the Web [36].

Chapter’s content is organized as follows: Sect. 1.1 gives some background notions; Sect. 2 introduces the types of OPs, defines them, and provides the reader with some examples; Sect. 3 presents a sample catalogue of CPs; Sect. 4 describes ways to create and work with CPs, and Sect. 5 presents an example of their application. Finally, Sect. 6 provides some conclusions and remarks.

1.1 Background

In the seventies, the architect and mathematician Christopher Alexander introduced the term “design pattern” for shared guidelines that help solve design problems. In [1] he argues that a good (architectural) design can be achieved by means of a set of rules that are “packaged” in the form of patterns, such as “courtyards which live”, “windows place”, or “entrance room”. Design patterns are then assumed as archetypal solutions to design problems in a certain context.

Taking seriously the architectural metaphor, the notion has been eagerly endorsed by software engineering [21, 12, 29], and DBMS applications with so-called data model patterns [27]. In these areas, pattern is used as a general term for formatted guidelines in software reuse, and, more recently, has also appeared in requirements analysis, conceptual modelling, and ontology engineering [7, 24, 39, 11, 48, 44].³ Traditionally, design patterns appear more like a collection of shortcuts and suggestions related to a class of context-bound problems and success stories. Software engineering patterns are largely used for documenting software [26], and there is software support for automatic code generation based on them (see, e.g the Eclipse functionality for generating factory methods,⁴ and the Whole platform.⁵) Furthermore, there is recent work going towards a more formal encoding of design patterns (notably [3, 24, 30]), and even towards using ontology patterns to encode software engineering patterns [34].

Ontology engineering literature has tackled the notion of design pattern at least since [7, 39], while in the context of Semantic Web research and application, where OPs are now a hot topic, the notion has been introduced by [45, 16, 38, 48] and has been approached also by the W3C Semantic Web Best Practices and Deployment Group.⁶ In particular, [16, 48] take a foundational approach that anticipates that presented in [14, 37] (which are closely related to this chapter). Some work [4] has also attempted a learning approach (by using case-based reasoning) to derive and rank patterns with respect to user requirements. The research has also addressed domain-oriented best practices and patterns, e.g. to express sequences in OWL [10], for content objects and multimedia [2] (cf. chapter “Ontologies for Cultural Heritage”), software components (cf. chapter “COMM: A Core Ontology for Multimedia Annotation”), business modelling and interaction [20], medical [46, 43] (cf. chapter “An Ontology for Software”).

2 Types of Ontology Design Patterns

An ontology design pattern (OP) is a modelling solution to solve a recurrent ontology design problem. We have identified several types of OPs, and have grouped them into six families (cf. Fig. 1): Structural OPs, Correspondence OPs, Content OPs (CPs), Reasoning OPs, Presentation OPs, and Lexico-Syntactic OPs.

Fig. 1

Ontology design pattern types

Although this chapter mainly focuses on CPs, in this section we give an overview of the OP families, with some examples. For more details, the reader can refer to [37].

2.1 Structural OPs

Structural OPs include Logical OPs and Architectural OPs. Logical OPs are compositions of logical constructs that solve a problem of expressivity, while Architectural OPs affect the overall shape of the ontology either internally or externally.

Logical OPs are only expressed in terms of a logical vocabulary, because their signature (the set of predicate names, e.g. the set of classes and properties in an OWL ontology) is empty (with minor exceptions, e.g. the default inclusion of owl:Thing in OWL). On one hand, Logical OPs are independent from a specific domain of interest (i.e. they are content-independent), on the other hand, they depend on the expressivity of the logical formalism that is used for representation. In other words, Logical OPs help to solve design problems where the primitives of the representation language do not directly support certain logical constructs. For example, if the representation language is OWL, and a designer needs to represent a relation between more than two elements, a Logical OP is needed in order to express an n-ary relation semantics by only using class and binary relation primitives. The root of Logical OPs can be found in [5], where so-called description logics were conceived as a way of representing knowledge in a structural manner by singling out the most relevant and tractable patterns from first-order logic (and beyond). The first proposal for a library of Semantic Web logical patterns is [45]. We can informally divide Logical OPs into two types:

Logical macros provide a shortcut to model a recurrent intuitive logical expression, e.g. the combination of owl:allValuesFrom restriction with owl:someValuesFrom restriction.

Transformation patterns translate a logical expression from a logical language into another, which approximates the semantics of the first, in order to find a trade-off between requirements and expressivity. For example, the so called n-ary relation pattern, documented in [33] with respect to OWL, is a transformation pattern from first-order logic to OWL DL. Other Logical OPs are documented in [37, 47, 33].

The application of Logical OPs has consequences on the results and efficiency of reasoning procedures. They can be used in order to document design choices and are particularly suitable for teaching good practices of ontology design as they provide designers with solutions to represent complex logical expressions.

Architectural OPs affect the overall shape of the ontology: their aim is to constrain “how the ontology should look like”. They can be of two types: (i) internal, defined in terms of collections of Logical OPs that have to be exclusively employed when designing an ontology, e.g. an OWL species (cf. chapter “Web Ontology Language: OWL”), or the varieties of description logics (cf. chapter “Description Logics”); (ii) external, defined in terms of meta-level constructs, e.g. the modular architecture consists of an ontology network, where the involved ontologies play the role of modules (according to definitions given in [25]). The modules are connected by the import operation.

Architectural OPs emerged as design choices motivated by specific needs, e.g. computational complexity constraints. Such OPs are also useful as reference documentation for those initially approaching the design of an ontology.

2.2 Reasoning OPs

Reasoning OPs are applications of Logical OPs oriented to obtain certain reasoning results, based on the behaviour implemented in a reasoning engine. Examples of Reasoning OPs include: classification, subsumption, inheritance, materialization, de-anonymizing, etc.

Reasoning OPs, when declared on top of an ontology, inform about the state of that ontology, and let a system decide what reasoning has to be performed on the ontology in order to carry out queries, evaluation, etc. Examples of Reasoning OPs are so called normalizations. In [51, 52] five normalizations have been identified (cf. chapter “Ontology Engineering Environments”).

2.3 Correspondence OPs

Correspondence OPs include Reengineering OPs and Mapping OPs.

Reengineering OPs provide designers with solutions to the problem of transforming a conceptual model, which can even be a non-ontological resource, into a new ontology. Mapping OPs are patterns for creating semantic associations between two existing ontologies.

Reengineering OPs are transformation rules applied in order to create a new ontology (target model) starting from elements of a source model. The target model is an ontology, while the source model can be either an ontology, or a non-ontological resource, e.g. a thesaurus concept, a data model pattern, a UML model, a linguistic structure, etc. Reengineering OPs are described in terms of metamodel transformation rules. We distinguish two types of Reengineering OPs.

Schema reengineering patterns are rules for transforming, e.g. a non-OWL DL metamodel into an OWL DL ontology. For example, consider the use of SKOS [31] for Knowledge Organization Systems (KOS) reengineering to a knowledge base (an OWL ABox), based-on the SKOS TBox. Transformation Logical OPs are a kind of schema reengineering patterns. In principle, all modelling problems can be represented as higher-order logical expressions, and if we have to represent them, e.g. in OWL DL, we implicitly apply a schema reengineering pattern in order to stay within the expressivity of OWL DL. However, we also (pragmatically) distinguish between transformation and schema reengineering patterns because of the different intention of the designer. In the first case, the designer wants to directly represent a modelling solution in a certain representation formalism, e.g. OWL DL,⁷ while in the second case the designer wants to reengineer, e.g. an existing non-OWL DL model into an OWL DL ontology.

Refactoring patterns provide designers with rules for transforming, i.e. refactoring, e.g. an existing OWL DL source ontology into a new OWL DL target ontology. In this case, the transformation rule has the effect of changing the type of the ontology elements that are involved in the refactoring. For example, let us consider the case in which an ontology defines an object property for representing the relation of preparing a coffee, which holds between agents and coffees. Now, let us consider a change of requirements, so that a designer has to represent that the coffee is prepared by an agent at a certain time by using a certain tool. In order to address such a change in OWL DL, a designer has to apply an n-ary relation Logical OP, because preparing a coffee has now four arguments: agent, coffee, time interval, and tool. The n-ary relation Logical OP plus the description of how to apply it in order to replace an object property from an existing ontology is a Refactoring OP.

Mapping ontology design patterns Mapping OPs refer to the possible semantic relations between mappable elements, as defined in [25]. There are three basic semantic relations that are used for mapping assertions: equivalence, containment, and overlap. They can be supplemented by their negative counterparts, i.e. not equivalent, not contained, and not overlap or disjoint, respectively. Mapping OPs provide designers with solutions to relate two ontologies without changing the logical types (e.g. owl:Class) of the ontology elements involved.

2.4 Presentation OPs

Presentation OPs deal with usability and readability of ontologies from a user perspective. They are meant as good practices that support the reuse of ontologies by facilitating their evaluation and selection. Examples are Naming OPs and Annotation OPs. The former are conventions about how to create names for namespace, files, and ontology elements in general (classes, properties, etc.). They are good practices that boost ontology readability and understanding by humans, by supporting homogeneity in naming procedures. Annotation OPs provide annotation properties or annotation property schemas that can be used in order to improve the understandability of ontologies and their elements.

An example of Naming OP relates to namespace declared for ontologies. It is recommended to use the base URI of the organization that publishes the ontology (e.g. http://www.w3.org for the W3C, http://www.fao.org for the FAO, http://www.loa-cnr.it for the Laboratory for Applied Ontologies (LOA) etc.) followed by a reference directory for the ontologies (e.g. http://www.loa-cnr.it/ontologies/). Additionally, it is also important to choose an approach for encoding versioning, either on the name, or on the reference directory.

2.5 Lexico-Syntactic OPs

Lexico-Syntactic OPs are linguistic structures or schemas that consist of certain types of words following a specific order, and that permit to generalize and extract some conclusions about the meaning they express. They are useful for associating simple Logical and Content OPs with natural language sentences, e.g. for didactic purposes.

2.6 Content Ontology Design Patterns (CPs)

CPs encode conceptual, rather than logical design patterns. In other words, while Logical OPs solve design problems independently of a particular conceptualization, CPs propose patterns for solving design problems for the domain classes and properties that populate an ontology, therefore addressing content problems [14]. CPs are instantiations of Logical OPs (or of compositions of Logical OPs), featuring a non-empty signature. Hence, they have an explicit non-logical vocabulary for a specific domain of interest (i.e. they are content-dependent). CPs provide solutions to domain modelling problems and affect only the specific region of the ontology dealing with such domain modelling problems. They are typically reused by applying specialization, extension, and composition to them. In principle, CPs do not depend on any specific language, however in order to reuse them as building blocks, they have to be implemented in some way. In the context of this chapter, we deal with CPs in a Semantic Web context. Hence, we use OWL as a reference formalism for representation.

3 Towards a Catalogue and Repository of CPs

In this section we focus on CPs. We define them, and explain the dependencies between CPs and use cases (Sect. 3.1). Section 3.2 lists the characteristics that differentiate CPs as special ontologies (such characteristics cross the boundaries between ontology engineering, cognitive science, and linguistics). Finally, we describe two CPs (Sect. 3.3).

The way to document OPs can be compared to the typical way followed for SE patterns. The mainstream approach for describing SE patterns is to use a template, although there is no standard format. A description of the most well-known SE pattern templates can be found at Martin Fowler’s web site.⁸ The templates used for describing SE patterns follow quite closely that suggested by Alexander [1]: given an artifact type, the pattern provides examples of it, its context, the problem addressed by the pattern, the involved “forces” (requirements and constraints), and a solution.

In order to describe CPs, we follow a similar approach: each CP is associated with a catalogue entry including the following set of information fields.

Name provides a name for the pattern; Intent describes the Generic Use Case addressed by the pattern; Competency questions contains examples of competency questions that the knowledge base associated with the CP needs to address; Also Known as provides other names (if any) with which the pattern is known; Scenarios provides examples of requirements, expressed in natural language, which can be modeled by using the pattern; Diagram depicts a UML class diagram representing the pattern; Elements describes the elements (classes and relations) included in the pattern, and their role within the pattern; Consequences provides a description of the benefits and/or possible trade-offs when using the pattern; Known uses gives examples of realistic ontologies where the pattern is used, Extracted from/Reengineered from provides the reference ontology/conceptual schema (if any), from which the pattern has been extracted/reused; Related patterns indicates other patterns (if any) that are either a specialization, generalization, composition, or component of the pattern being described. Furthermore, this field may indicate other patterns that are typically used in conjunction with the described one. Important similarities and differences with other patterns can be also described here; Building block provides references to implementations of the pattern, a URI. In the case of CPs for Semantic Web ontologies, this field provides the URI of an OWL file (containing an implementation of the pattern).

Section 3.3 contains two examples of CPs that are described by means of a simplified version of the catalogue template. Such a catalogue can be found at the ontologydesignpatterns.org web portal [36], a dedicated wiki site through which a lightweight repository of CPs can be accessed. In fact, [36] allows users to download, propose, and discuss CPs. Furthermore, each CP includes a set of annotations⁹ that can be exploited by Semantic Web applications. The reader can refer to chapter “Ontology Repositories” for more details on ontology repositories.

3.1 CPs and Competency Questions

CPs are reusable solutions to recurrent modelling problems. As known from a long time in conceptual modelling (cf. the difference between class and use case diagrams in UML) and knowledge engineering (cf. the distinction between domain and task ontologies in UPML [32]), these problems have two components: a domain and a use case (or task). A same domain can have many use cases (e.g. different scenarios in a clinical information context), and a same use case can be found in different domains (e.g. different domains with a same “competence finding” scenario).

Ontologies are usually considered models for a domain, but their use case is usually unknown. As reusable solutions, CPs must explicitly encode both a domain and a use case. Since use cases are extremely diversified, a catalogue of CPs requires the notion of a “Generic Use Case” (GUC), i.e. a generalization of use cases that can be provided as examples for an issue of domain modelling. A GUC is the expression of a recurrent scenario in different domain ontology projects.

Being generic at the use case level allows us to divide, or to refactor the design problems of a use case, by composing different GUCs. We can hierarchically organize GUCs from the most generic to the most specific ones, and from the “purest” (e.g. “which objects take part in a certain event?”) to the most articulated and applied ones (e.g. “what protein is involved in the Jack/Stat biochemical pathway?”).

The intuition underlying GUC hierarchies is based on a methodological observation: ontologies must be built out of domain tasks that can be captured by means of competency questions [23]. A competency question is a typical query that an expert might want to submit to a knowledge base of its target domain, for a certain task. In principle, an accurate domain ontology should specify all and only the conceptualizations required in order to answer all the competency questions formulated by, or acquired from, experts. A GUC cannot do much as a guideline, unless we are able to find formal patterns that encode it. CPs are the solution to this issue. Based on the above assumptions, we define a CP as:

CPs are distinguished ontologies. They address a specific set of competency questions, which represent the problem they provide a solution for. Furthermore, CPs show certain characteristics, i.e. they are: computational, small, autonomous, hierarchical, cognitively relevant, linguistically relevant, and best practices.

3.2 General Characteristics of CPs

CPs are components that represent, and possibly help solving a modelling problem arising across different use cases. E.g. the agent-role pattern provides a solution to represent agents that play some role. We have sketched their theoretical basis in Sect. 2, and explained their dependance on use cases (Sect. 3.1). Before providing a sample list of CPs against an example use case (Sect. 3.3), we now describe a more inclusive set of general, pragmatic features of CPs. These features, besides positioning CPs in a wider scientific context, give hints on how to discover or to extract CPs from existing knowledge resources.

Computational components. CPs are language-independent, and should be encoded in a higher-order representation language. Nevertheless, their (sample) representation in OWL is needed in order to (re)use them as building blocks over the Semantic Web.

Small, autonomous components. Regardless of the particular way a CP has been created, it is a small, autonomous ontology. Smallness (typically two to ten classes with relations defined between them) and autonomy of CPs facilitate ontology designers: composing CPs enable them to govern the complexity of the whole ontology, because of the explicit rationales and the amount of know-how provided by the users of a same CP library. Smallness also allows diagrammatical visualizations that are aesthetically acceptable and easily memorizable.

Hierarchical components. A CP can be an element in a partial order, where the ordering relation requires that at least one of the classes or properties in the pattern is specialized. A hierarchy of CPs can be built by specializing or generalizing some of the elements (either classes or relations).

Inference-enabling components. There are combinations of ontology elements that do not allow any useful inference, e.g. a taxonomy with two sibling classes, an object property alone, etc. A CP allows some form of inference, e.g. a taxonomy with two sibling disjoint classes, a property with explicit domain and range set, a property and a class with a universal restriction on that property, etc.

Cognitively relevant components. CP visualization must be intuitive and compact, and should catch relevant, “core” notions of a domain [14].

Linguistically relevant components. Many CPs nicely match linguistic patterns called frames. A frame can be described as a lexically founded OP. The richest repository of frames is FrameNet [3]. Frames can be used for validating CPs with respect to lexical coverage, for lexicalizing them, and can be reengineered as CPs.

Best practice components. A CP should be used to describe a “best practice” of modelling. Best practices are intended here as local, thus derived from experts, emerging from real applications. The quality of CPs is currently based on the personal experience and taste of the proposers, or on the provenance of the knowledge resource where the pattern comes from. However, evidence from reusability across different projects, large-scale applications, and open rating systems will provide a good base for CP evaluation.

3.3 Samples of CP Catalogue Entries

In this section we show two CPs taken from [36], Each CP is presented in a catalogue-like way, and with reference to the OWL language. For space reasons, we describe each CP with a simplified catalogue entry composed of: the Name (including possible alternative names), the Intent (i.e., the GUC), Competency questions, some Examples of its application, the Diagram describing its structure, the Elements and the role they play in the pattern, and some General Remarks that indicate general guidelines about how to use it, including relations to other CPs. The complete entry¹⁰ also contains a field named building block that provides references to implementations of the pattern, i.e. repository of reusable components. In the case of CPs for Semantic Web ontologies, this field provides the URI of an OWL file (containing an implementation of the pattern). We have used TopBraid Composer¹¹ in order to produce the OWL encoding. With the same tool, we automatically generated a diagrammatical visualization based on a UML profile for OWL. UML classes (boxes) are used in order to depicts OWL classes. Two kinds of OWL classes can be visualized in a diagram: named classes (owl:Class, in white boxes) and anonymous classes (in grey boxes), e.g. owl:Restriction with owl:someValuesFrom. UML generalization (arrow with a large end) corresponds to rdfs:subClassOf, while UML association (arrow with a small end) corresponds to owl:ObjectProperty. Finally, UML class attributes (statements inside white boxes) are used in order to indicate either rdfs:domain and rdfs:range, or owl:Restriction with owl:allValuesFrom. When a class name is preceded by a prefix, e.g. sit:, it is interpreted as a class imported (e.g. by owl:imports) from another (typically more general) CP that is indexed by means of that prefix.

In the rest of this section we use the OWL terminology in order to describe the proposed design solutions, e.g. object property, datatype property, etc.

3.3.1 The information realization CP

The information realization CP is extracted from the Dolce + DnS Ultra Lite ontology,¹² and represents the relations between information objects like poems, songs, formulas, etc., and their physical realizations like printed books, registered tracks, physical files, etc..

The information realization CP is associated with information according to the catalogue entry fields reported below:

Intent: to represent relations between information objects and their physical realizations.

Competency questions: which physical object realizes a certain information object? Which information object is realized by a certain physical object?

Diagram: Fig. 2 shows a UML diagram of the information realization CP.

Fig. 2

The information realization CP UML graphical representation

Elements:

• InformationObject: a piece of information, such as a musical composition, a text, a word, a picture, independently from how it is concretely realized.

• InformationRealization: a concrete realization of an InformationObject, e.g. the written document containing the text of a law.

• realizes: a relation between an information realization and an information object, e.g. the paper copy of the Italian Constitution realizes the text of the Constitution.

• isRealizedBy: a relation between an information object and an information realization, e.g. the text of the Constitution is realized by the paper copy of the Italian Constitution.

General remarks: this CP¹³ allows to distinguish between information encoded in an object and the possible physical representations of it. The Multimedia ontology (cf. chapter “Ontologies for Cultural Heritage”) uses this CP.

3.3.2 The Time Indexed Person Role CP

The time indexed person role is a CP that represents time indexing for the relation between persons and roles they play, e.g. George W. Bush was the president of the United States in 2007. This CP is also extracted from the Dolce+DnS Ultra Lite ontology.

According to its associated catalogue entry, the main information associated with this CP are the following:

Intent: to represent time indexing for the relation between persons and roles they play.

Competency questions: who was playing a certain roles during a given time interval? When did a certain person play a specific role?

Diagram: see Fig. 3, the elements which compose the CP are described in the Elements field.

Fig. 3

The time indexed person role CP UML graphical representation

Elements:

• Entity: anything: real, possible, or imaginary, which some modeller wants to talk about for some purpose.

• Person: persons in commonsense intuition, i.e. either as physical agents (humans) or social persons.

• Role: a Concept that classifies a Person.

• TimeInterval: any region in a dimensional space that aims at representing time.

• TimeIndexedPersonRole: a situation that expresses time indexing for the relation between persons and roles they play.

• hasRole: a relation between a Role and an Entity, e.g. “John is considered a typical rude man”; your last concert constitutes the achievement of a lifetime; “20-year-old means she’s mature enough”.

• isRoleOf: a relation between a Role and an Entity, e.g. the Role “student” classifies a Person “John”.

• isSettingFor: a relation between time indexed role situations and related entities, e.g. “I was the director between 2000 and 2005”, i.e. the situation in which I was a director is the setting for a the role of director, me, and the time interval.

• hasSetting: the inverse relation of isSettingFor.

General remarks: this CP¹⁴ allows to assign a time interval to roles played by people.

4 Creating and Working with CPs

This section discusses how CPs can be created, and provides guidelines on how they can be practically (re)used. Section 4.1 describes four approaches to create CPs, while Sect. 4.2 shows the main operations that are performed for reusing a CP, and describes the possible situations of CP selection and usage that can occur in practice.

4.1 Where do Content Ontology Design Patterns Come from?

CP creation and usage rely on a common set of operations.

Import::

consists of including a CP in the ontology under development. This is the basic mechanism for reusing CPs (and ontologies in general). By importing a CP, the importing ontology ensures the set of inferences allowed by the CP in its corresponding knowledge base. Elements of an imported CP cannot be modified.

Specialization::

can be referred to ontology elements or to CPs. Specialization between ontology elements of a CP consists of creating sub-classes of some CP’s class and/or sub-properties of some CP’s properties. A CP c ₁ is a specialization of a CP c if c ₁ imports c, and at least one ontology element from c ₁ specializes an ontology element from c.

Generalization::

A CP c ₁ is a generalization of a CP c if c ₁ imports c, and at least one ontology element from c ₁ generalizes an element from c.

Composition::

consists of associating classes (properties) of one CP with classes (properties) of other CPs, by means of some OWL axiom.

Expansion::

consists of adding new classes, properties and axioms to the ontology to the aim of covering the requirements that are not addressed by the reused CPs.

CPs come from the experience of ontology engineers in modelling foundational (cf. chapter “Foundational Choices in DOLCE”), upper-level, core [15], or domain ontologies. Informally, the distinction between these kinds of ontologies relates to the degree by which an ontology covers the domain of interest, cf. chapter “What Is an Ontology” for details. Assuming the above distinctions, there are four main ways of creating CPs, which can be summarized as follows:

Reengineering from other data models. A CP can be the result of a reengineering process applied to different conceptual modelling languages, primitives, and styles. Knowledge resources that can be reengineered to produce candidate CPs are database schemas, knowledge organization systems such as thesauri, and lexica. For more references, the reader can refer to [20] that describes a reengineering approach for creating CPs starting from UML diagrams [35], workflow patterns [49], and data model patterns [27].

Specialization/Composition of other CPs. A CP can be created by composing other CPs, or by specializing another CP, (both composition and specialization can be combined with expansion, see below).

Extraction from reference ontologies. A CP can be extracted from an existing ontology, which acts as the “source” ontology. In this case, the CP corresponds to a fragment of the source ontology, which constitutes its axiomatic background context. A CP is axiomatized according to the fragment it extracts. E.g. the co-participation CP depends on a set of axioms from the DOLCE ontology [9], which state that an event has at least one participant, that co-participation requires two participants in a same event, that participants must participate at least partly at the same time, etc. If a modeller specializes the co-participation CP for representing, e.g. an academic lecture or a football match, the reasoning services will operate with reference to the co-participation axioms, without the need for encoding them again. However, a CP is autonomous, and only the axioms that have been extracted from the reference ontology are actually used by an ontology that reuses a CP. Therefore, reasoning services do not need to also process the general axiomatic context from the reference ontology.

Creation by combining extraction, specialization, generalization, and expansion The definition of a CP can be the result of an extraction (see above), followed by specialization and/or generalization of some ontology elements, and expansion.¹⁵

4.2 How to Use Content Ontology Design Patterns

Supporting reuse and alleviating difficulties in ontology design activities are the main goals of setting up a catalogue of CPs. In order to be able to reuse CPs, two main functionalities must be ensured: selection and application.

Selection of CPs corresponds to finding the most appropriate CP for the actual domain modelling problem. Hence, selection includes search and evaluation of available CPs. This task can be performed by applying procedures for ontology selection [41, 28] and evaluation [13] (cf. chapter “Ontology Engineering Environments”).

Informally, a GUC, i.e. the intent of a CP, must match an actual use case. Once a CP has been selected, it has to be applied to the domain ontology. Typically, application is performed by means of import, specialization, composition, or expansion (see Sect. 4.1). In realistic design projects, the operations are usually combined as it is shown by the example of Sect. 5.

Several situations of matching between GUCs and actual use cases can occur, each associated with a different approach to using CPs. The following summary assumes a manual (re)use of CPs. However, an initial library of CPs is already available [36], and tool support to their selection and usage can take into account the principles informally explained in the summary below as base requirements. Precise or redundant matching. The CP matches a GUC, which is either more complex or directly usable to describe the local use case: the CP has only to be imported in the domain ontology.

Broader matching. The CP matches a GUC that is more general than the local use case: the CP’s catalogue entry may contain reference to less general CPs that specialize it. If none of them is appropriate, the CP has firstly to be imported, then it has to be specialized in order to cover the domain part to be represented.

Narrower matching. The CP matches a GUC that is more specific than the local use case: the CP’s catalogue entry may contain references to more general CPs. If none of them is appropriate, a the CP has firstly to be imported, then it has to be generalized according to the local requirements.

Partial matching. The CP partly matches a GUC that does not cover all aspects of the local use case (it is simpler): the CP’s catalogue entry may contain references to CPs it is a component of. If none of such compound CPs is appropriate, the local use case has to be partitioned into smaller pieces. One of these pieces will be covered by the selected CP. For the other pieces, other CPs have to be selected. All selected CPs have to be imported and composed.

In all the above situation, expansion is performed when needed.

5 Use Case Example in the Music Industry Domain

As an example of usage we design a small fragment of an ontology for the music industry domain. The ontology fragment has to address the following competency questions:

Which recordings of a certain song do exist in our archive?

Who did play a certain musician role in a given band during a certain period?

The first competency question requires to distinguish between a song and its recording, while the second competency question highlights the issue of assigning a given musician role, e.g. singer, guitar player, etc., to a person who is member of a certain band, at a given period of time. The intent of the information realization is related to the first competency question with a broader matching. The intent of the time indexed person role partially and broadly matches the second competency question. Hence, we select these two CPs as building blocks for our ontology.¹⁶

We proceed by importing and composing the two selected CPs in our ontology (the information realization CP is associated with the prefix ir:; the time indexed person role CP is associated with the prefix tipr:). Additionally, we might want to import the time interval CP¹⁷ that allows us to assign a date to the time interval. In order to complete our ontology fragment we create: the class Song that specializes ir:InformationObject, the class Recording that specializes ir:InformationRealization, the class MusicianRole that specializes tipr:Role, the class Band, and the object property memberOf (and its inverse) with explicit domain, i.e. tipr:Person, and range, i.e. Band. A screenshot of the resulting ontology fragment is shown in Fig. 4.¹⁸ On the left side of the picture ontology classes are shown, on the right side there are ontology properties, while at the bottom there are the imported CPs. Notice that CPs can be very useful when they address issues in a specific domain. For this reason, an ontology fragment like this one might be proposed as a CP¹⁹ if it is associated with a successful application in an ontology design project.

Fig. 4

The music industry example

6 Conclusion and Remarks

Ontology design is a crucial research area for semantic technologies. Many bottlenecks in the wide adoption of semantic technologies depend on the difficulty of understanding ontologies and on the scarcity of tools supporting their lifecycle, from creation to adaptation, reuse, and management. The lessons learnt until now, either from the early adoption of Semantic Web solutions or from local, organizational applications, put a lot of emphasis on the need for simple, modular ontologies that are accessible and understandable by typical computer scientist and field experts, and on the dependability of these ontologies on existing knowledge resources.²⁰

In this chapter, we have described a breed of components, called Ontology Design Patterns, and tools that will support ontology design at the level that is more natural to domain experts and laymen, i.e. the level at which small, expertise-aware components can be assembled as easy-to-apply, easy-to-customize building blocks.

The quality of these components is expected to be evaluated with respect to known good practices, as well as in the large testbed of organizational or web-scale open rating systems. In order to allow the maximum transparency and flexibility, OPs are supplied with a rich set of metadata for their explanation, rationale declaration, use case history, evaluation criteria, etc. In this chapter, we have sketched a typology of OPs, then focused on Content Ontology Design Patterns (which are most beneficial to ontology design) in terms of their background, definition, communication means, related work beyond ontology engineering, exemplification, creation, and usage principles.

There is still a lot of work to be carried out for populating repositories of patterns, discoverying or extracting them from existing ontologies, assisting users in their application, defining a robust semantics and algebra for them, etc. (cf. [42]). The larger context of ontology design research is still very young, and many ideas are just emerging, for example in (semi-)automatizing the creation and evaluation of ontologies, based only on informal documentation from users, a set of software components, and a repository of design patterns. In a larger report [37] and by setting up the ontologydesignpatterns.org web portal [36], we make some steps towards the open issues. Moreover, we have designed a set of experiments that are going to be performed in order to show OPs’ effectiveness, e.g. in teaching ontology design, lower the cost of ontology projects, etc. However, some initial experiences with PhD students classes, and the employment of CPs in of our own recent projects have provided us with concrete proof of the benefits deriving from their application.