A survey and classification of principles for domain-specific ontology design patterns development

4.1.1 Typology of data modeling patterns

We found three different types of data modeling patterns in the considered literature – logical patterns, physical patterns and structural patterns.

Logical patterns are reusable models that capture domain entities and their relationships, devoid of their physical implementation details. They are called logical because they are patterns for logical data models. On the other side, physical patterns are implementations of logical patterns in a target platform technology; they are parts of physical data model. For one logical pattern, there could be many different corresponding physical patterns depending on target platform, data manipulation and access strategies. For instance, Hay’s patterns are all pure logical patterns, with no concerns of physical implementations, while Silverston’s and Blaha’s patterns encompass both logical and physical aspects. We will mention some of their patterns in Section 4.1.2.

Structural patterns are not concerned with capturing entities’ content, as opposed to the logical and their physical patterns; but rather with the structural organization of the entities. Structural patterns, as those in Silverston and Agnew (2011), are patterns for creating hierarchical relationships, aggregation (sets) of entities, or categories and classification of entities, and graphs. They have a basis in topology and graph theory (Blaha, 2010). For example, Blaha’s ‘Hardcoded Tree’ pattern is a structural pattern for capturing organization of hierarchies whose levels and type sequences do not change frequently over time. Or, the ‘Directed Graph’ pattern for capturing structures such as map of flights between airports, or a collection of equipment in the manufacturing plant (Blaha, 2010). Hay (1996) also provides structural patterns to model hierarchies, classification or categories of entities. The structural patterns can be logical, devoid of actual implementation details, or physical, addressing actual implementation details in a target platform.

4.1.2 Vertical–horizontal variability in data modeling patterns

Based on the terminology in Verelst (2004), we define horizontal and vertical variability of design patterns as follows. Horizontal variability is the possibility of organizing the design patterns into two general groups: universally applicable (or, cross-domain) and domain-specific (e.g. for manufacturing information modeling or health-care information modeling), without having a specialization relation between the universally applicable and domain-specific ones. On another side, the vertical variability is further specialization of the universally-applicable or domain-specific design patterns. E.g. the design patterns for manufacturing information modeling may be specialized into the discrete manufacturing and process manufacturing information modeling patterns. Therefore, the design patterns vertically laid are specializations of the design patterns horizontally laid and, in a more formal way, could be linked to them using the subsumption (is-a) relationship. A domain-specific design pattern may or may not be a vertical variation of a universally-applicable design pattern.

For example, in Hay (1996), universal data modeling patterns are Parties, Organizations or Products; while Structure and Fluid Path, Flow or Process are not specializations of the universal patterns but rather specific patterns for process manufacturing industry. Those patterns are horizontally laid. Many of Hay’s data modeling patterns capturing universal concepts (e.g. Party), can be specialized into subtypes (e.g., Employee), which can be viewed as their vertical variability and patterns at a lower level of generalization.

Similarly to Hay’s, Silverston’s patterns also span from universal to domain-specific. Silverston’s universal data modeling patterns are similar to Hay’s (e.g., Parties, Products, Parts or Product Category). Silverston (2001b) provides domain-specific data modeling patterns for data models for discrete manufacturing. For instance, Part Substitution, Inventory Item Configuration, Production Runs or Production Run Types. Silverston also provides for capturing both universal concepts (e.g. Party) and their vertical specializations (e.g., ShipToParty, ShipFromParty specialization of Party). In Silverston and Agnew (2011), the authors provided highly generalized data modeling patterns, such as Declarative Role or Contextual Role, which provide for modeling of any entity roles.

Blaha’s (2010) patterns are also at different levels of generalization. For example, his Item-ItemDescription is a pattern highly generalized to provide models that capture data of some item and that item description, regardless of what the item is. For example, Aircraft with ‘tailNumber’ attribute, is an item, and AircraftDescription with attributes ‘manufacturer’ and ‘models’, is the item description. Blaha’s patterns, which he calls archetypes, are all universal and generalized data concepts. The archetypes may be applied or specialized for particular domains. For instance, the archetypes are Actor, Address, Position, Product or Part. Additionally to the archetypes, Blaha introduces “canonical model patterns” as ready-to-use complete data models for specific purposes.

4.1.3 Design principles for data modeling patterns

The preceding data modeling patterns are empirically grounded, which means derived from the accumulated practical experience in resolving recurring data modeling tasks. Their design and development principles are not clearly documented; however, by analyzing their documentation, we derived several pattern design principles, as discussed next.

A model size principle (DP1)7

A normalization principle (DP2) that asks for certain normalization form of data modeling patterns. One of the earliest such normalization forms, the Third Normal Form (3NF), was developed in Codd (1972) for relational databases’ schemas. 3NF principle is very specific to the relation database modeling and its application ensures referential integrity in the database and no data duplication. In short, 3NF suggest that the non-primary attributes of a database table should be dependent on the primary key only, and that every non-primary attribute of the table should be dependent on the whole of a primary key when the primary key consists of two or more attributes. In Silverston (2001a), the author argued that data modeling patterns should also be developed with the normalization principle in mind, by applying 3NF normalization. In this same paper, the author describes an important related principle, called a no-derive attribute principle (DP3). This associated principle keeps data model patterns devoid of attributes that can be derived from other attributes. Importantly, the normalization does not necessarily apply to physical data model patterns since these patterns may be de-normalized to meet performances in accessing and updating the data. Logical data model patterns are typically normalized into 3NF.

A generalization principle (DP4) that seems to be a prominent design principle for generalized data modeling patterns in Silverston and Agnew (2011). This principle recognizes that wide variety of information requirements can be captured in the same data structure. Sometimes this principle is called an abstraction (DP5). Specifically, Blaha (2010) pointed out an applicability and abstraction as characteristic of his archetypes. The archetypes are universally applicable concepts, not domain-specific concepts. Certainly, the wider applicability implies higher abstraction in data modeling patterns.

The DP1–DP5 principles address mainly the functional aspects of design patterns, and so, determine the conceptual coverage of a data modeling pattern.

Further, Blaha highlights several anti-patterns that should be avoided in data modeling for relational databases. Those anti-patterns include symmetric relationships, ambiguous naming and descriptions of entities, disconnected-isolated entities/properties or multiple inheritances. Blaha’s avoidance of anti-patterns principle (DP6) can be seen as a general principle where each specific anti-pattern recommendation is a specific principle in patterns design.

On the other side, nonfunctional requirements are determined with operational aspects such as physical implementation concerns, computational performance or maintainability of data modeling patterns. Depending on specific nonfunctional requirements specific we found out that techniques such as indexing policies, de-normalization of tables, or table partitioning strategies, are typically applied. For physical data model patterns, the invariability of a database schema to additional, new, logical entities may be a requirement, which can be met by a generic table structure for storage of a variety of entities. So, such observation may be interpreted also as the generalization principles. The intended purpose of data can determine the design of patterns. For example, if data are going to be used for analytical purposes, physical data model patterns should provide for that purpose. An example of such a pattern is a STAR schema (Silverston, 2001a) that binds data to different analytical dimensions. This may be a design principle formulated as – adhere to a structure designed to meet required operational aspects (DP7).

Data modeling patterns are frequently represented using graphical diagrams and textual descriptions. Hay and Silverston used Case*Method (Barker, 1990) data modeling notation. Blaha used both UML (Unified Modeling Language) and IDEF1X (Integration Definition for Information Modeling) notations. Additionally to the graphical representation, Silverston provided computer-processable representations of his patterns via SQL scripts to allow their use and adoption for building the data or database models. For example, one can use SQL representation of data modeling patterns and utilize them by importing scripts into CASE tool for adoption and further refinement. Case*Method, UML or IDEF1X notation suffice for logical data model patterns. However, SQL representation is necessary for physical data model patterns. That is because UML and IDEF1X to SQL mapping might not be one-to-one. Hence, additional implementation concerns need to be considered when using data modeling patterns captured in UML or IDEF1X.

4.1.5 Applicability to semantic modeling of the domain-specific information

Data modeling patterns are design patterns provided primarily for design of E-R (relational database) models. Those patterns contain details such as primary keys, foreign keys, alternative keys and associative entities for capturing many-to-many relationships between entities. Having such details, it is questionable if those design patterns can provide for reference ontology development, even if available in OWL representation. Relational models and OWL ontologies are significantly different since OWL ontologies can capture both the content and semantics of entities.

Assuming the data modeling patterns translated into OWL, they could serve as some starting, but likely distant, point in capturing semantics of domain-specific information. For instance, Hay’s Geographic Location pattern encompassing party and location entities, if implemented in OWL, may provide for ‘Where is manufacturer located?’ or ‘What locations a manufacturer serves?’, in a case of MSC domain. Composition of Blaha’s Actor and Location patterns could provide for that purpose as well. Terminologically, there are many matching concepts in the data modeling patterns to concepts in MSC domain. For instance, Part, Product, Product Category, Location, Unit of Measure, Measure, Process, Condition, Asset/Equipment Type, Material or Material Type. But many concepts might be missing.

Certainly, additional effort would be needed to re-design the data modeling patterns from relational database viewpoint to OWL DL perspective. In particular, Blomqvist (2010) has developed several ODPs by translating some of Hay’s and Silverston’s patterns into OWL DL. A one-to-one translation approach was applied where an entity/property in a data model pattern was mapped to a concept/property in OWL. Then, patterns were reviewed with help of domain experts and updated where necessary since the patterns inherently assumed a data modeling paradigm not easily translatable into the DL paradigm (Blomqvist, 2010). Nevertheless, even if potentially applicable data modeling patterns are provided in OWL DL form, their further adaptation (e.g., specialization, extension, simplification) would be needed to meet the domain-specific information requirements.

4.2.1 Typology of software analysis model patterns

The analysis patterns proposed in Coad (1992), Fowler (1997) and Arlow and Neustadt (2004) are of similar nature to the data modeling patterns, which we discussed in Section 4.1, in the sense that they provide also for the essentially the same purpose, which is information or conceptual modeling. Therefore, we identified conceptual analysis model patterns and structural analysis model patterns as two different types of software analysis model patterns.

Specifically, conceptual analysis model patterns, such as Fowler’s or Arlow’s Party, or Coad’s Item-ItemDescription pattern, provide for capturing business concepts and their properties. Structural analysis model patterns provide for structural organization of data, such as hierarchical organization, or n-ary relationships (e.g. Fowler’s Organization Hierarchy pattern, Arlow’s N-ary relationship).

Conceptual analysis model patterns and structural analysis model patterns are of similar purpose and scope to the logical data model patterns and structural data modeling patterns, respectively. However, they differ in a modeling paradigm. Data modeling patterns are influenced by the relational modeling paradigm, while software analysis patterns are influenced by the object-oriented modeling paradigm.

We note that Arlow and Neustadt (2004) have introduced archetypes and archetype patterns as software analysis patterns. According to Arlow and Neustadt, an archetype is defined as “a primordial thing or circumstance that recurs consistently and is thought to be a single universal concept”. An archetype pattern is explained as collaboration between archetypes that occurs consistently and universally in business contexts. For instance, their Party archetype pattern is a composition of several archetypes including Party, Organization and Address archetypes. An archetype pattern notion is essentially the same as software analysis pattern notion, with the difference that archetype patterns are always concerned with Arlow and Neustadt’s archetypical concepts.

4.2.2 Vertical–horizontal variability in software analysis model patterns

Similarly to data modeling patterns, software analysis patterns may vary vertically and horizontally. For instance, Fowler’s (1997) analysis patterns are organized by domains where patterns emerged from domains such as Accountability, Observation and Measurements, Inventory and Accounting, Planning, and Trading. This organization does not imply that all the Fowler’s patterns are domain-specific. Some are universally applicable (e.g., Party, Organization, Observation, Measurement, Atomic Unit, Compound Unit), while others are applicable to particular domains only (e.g., Accounts, Transactions or Balance Sheet for an accounting domain). Fowler provides a number of specializations of his universally-applicable patterns. Examples include observations and measurements specialized for corporate finances.

Archetypes and archetype patterns in Arlow and Neustadt (2004) capture universal business concepts such as Party, Organization, Address, Money, Order, Product, Communication, Responsibility or Product Catalog archetypes/patterns. There are domain-specific archetype patterns such as Customer Relationship Management archetype pattern. According to Arlow and Neustadt (2004), their archetypes and archetype patterns may be specialized or extended to adapt to specific context. For example, EmailAddress or GeographicAddress archetypes are specializations of Address archetype. Hence, the vertical–horizontal variability is very often present in the collection of software analysis patterns.

Notably, software analysis patterns are often abstractions. As such, they can capture abstract concepts that have no real-world counterparts. For instance, Coad’s Item-ItemDescription analysis pattern is an abstraction of things that share the same description (metadata). Structural software analysis patterns are generally abstractions of structural concepts.

4.2.3 Design principles for software analysis model patterns

To the best of our knowledge, the analyzed object-oriented software analysis model patterns are also empirically grounded. That is, they are not provided within a structured methodology having an explicit set of pattern design principles. Similarly to data modeling patterns, conceptual coverage of software analysis model patterns reveals supported functional requirements. Software analysis patterns in Coad (1992), Fowler (1997) and Arlow and Neustadt (2004) seem unconcerned with run-time and implementation requirements such as operational performance or memory storage requirements, which are of great concern to data modeling patterns.

In particular, Coad (1992) does not provide design principles for his patterns explicitly. Rather, he emphasizes the reoccurrence as the main characteristic of his patterns. Coad points out that a pattern is a recurring structure of classes and objects that applies again and again in different object-oriented analysis and design efforts. Coad’s observation is that patterns in object-oriented analysis may be found by identifying recurring structures in software analysis models and observing those lowest-level building components and their relationships to establish higher-level components for their further reusability in modeling. The reoccurrence is more a pattern identification principle, than a pattern design principle. However, to us, it could be considered as a design principle if paraphrased into a rule saying that patterns should encompass only the concepts that reoccur in a particular domain or across domains and attributes of those concepts as well as relationships between the concepts (DP8).

Next, according to Fowler, the software analysis model patterns are discovered “by looking at what happens in day-to-day development, rather than by academic invention”. However, from Fowler’s work we derived two design principles. He suggests that software analysis model patterns should be the simplest model possible, devoid of any flexibility if flexibility is unlikely to be utilized (DP9). This principle can be called as a minimal conceptual coverage or minimal model size (same as the DP1). In particular to the model size, all Fowler’s analysis patterns encompass more than single concept, but no more than a few concepts (DP10). Another of Fowler’s suggestions is a sufficient abstraction of a pattern (DP11), to provide for applicability of patterns in different contexts. These two Fowler principles come as no surprise as aimed to patterns which serve as only a starting point in modeling.

In Arlow and Neustadt (2004), the authors argued that there are four essential characteristics of the business archetypes and archetype patterns as software analysis model patterns: (1) universality – consistent occurrence in business domains and systems, (2) pervasiveness – occurrence in both the business and software domain, (3) deep history – a long time existence and (4) self-evidence to domain experts. For us, these four characteristics reveal a design principle saying particularly that patterns should capture universal, recurring concept in some domain (DP12). The universal and recurring concepts in some domain are naturally self-evident to the domain experts, so we do not consider the ‘self-evidence’ as an additional principle, but as intrinsic to the DP12 principle. The pervasiveness, to us, should be contemplated as the pattern design principle. Further, Arlow and Neustadt emphasize the principle of variation (DP13) in archetypes. This means that archetypes have invariant and variant parts, which allow them to achieve applicability in different contexts that may require different models of the same thing. Arlow and Neustadt incorporated the convergent engineering approach (Taylor, 1995) in creation of archetype patterns. This approach proposes business modeling by means of object-oriented modeling to ease conversion of business models into object-oriented software systems. In the convergent engineering, business modeling begins with the identification of business elements and their subclasses and ends by establishing relationships between business elements to capture how they work together. According to Arlow and Neustadt, archetypes and archetype patterns are identified from practical experience or informal domain knowledge, and built by generalizing recurring concepts in existing software analysis models (DP14). Therefore, Arlow and Neustadt also use the generalization as a pattern design principle.

Several characteristics of software patterns are summarized in Winn and Calder (2002) and we contemplate them as possible candidates for design principles. First, a characteristic that underpins all others is that a software pattern is generative. This means that it can have a number of concrete and different instances. Further, a software pattern (c1) implies an artifact, which means that patterns are building components for software models, (c2) bridges many levels of abstraction, from concrete to abstract artifacts, to provide for ease of problem understanding and problem solving, (c3) is both functional and nonfunctional,8

Although patterns for the software design phase such as those offered by Gamma et al. (1995) are not our primary interest, it is worth mentioning principles for their design. A profound requirement in software design patterns is a reusable and flexible design of software implementations. In the object-oriented programming paradigm, the reusability and flexibility is achieved by applying the encapsulation abstraction, inheritance, delegation of responsibilities by object compositions, and polymorphism principles. Software design patterns for object-oriented software are results of applying those principles. The encapsulation (DP17) and again abstraction are principle applicable to software analysis patterns as well.

Software analysis model patterns are also represented graphically and textually. For the object-oriented analysis model patterns, naturally, object-oriented notations are used. Coad (1992) used his own graphical notation to represent object-oriented analysis model patterns. Fowler (1997) used Martin’s and Odell’s (1994) notation for object-oriented models but later switched to UML. Arlow and Neustadt (2004) used UML9

Computer-processable representations of the software analysis model patterns we investigated are not provided, to the best of our knowledge. However, Arlow and Neustadt proposed a component-based modeling approach based on the MDA (Model Driven Architecture) to use their archetypes and archetype patterns as parameterized and reconfigurable components for conceptual modeling. By following MDA principles, business archetypes and archetype patterns should be captured as models in UML, and serializable into XML Metadata Interchange (XMI) format to allow their use in different UML modeling tools. Using UML tools, the parameterized components can be further re-configured by adding new details, excluding optional elements, and combining components together into more comprehensive models. Then they may be instantiated in two ways – isomorphic or homomorphic – by defining MDA-based model-to-model transformations. An isomorphic instantiation creates one class for each archetype, while homomorphic instantiation creates more than one class for each archetype. Arlow and Neustadt define this feature as a pleomorphism, which is an adaptation of an archetype pattern into different forms that meet different specific requirements. More importantly, a pleomorph always adheres to the semantics of its base archetype pattern. A base archetype pattern describes the common semantics across all its pleomorphs.

As stated earlier, discussion of applicability of the software development patterns for semantic modeling of domain-specific information such as MSC information makes sense only for the software analysis model patterns. For the software analysis model patterns, their representation in an ontology language such as OWL DL is needed if we want to use them for semantic modeling of domain-specific information. However, even if provided in OWL DL, their further adaption could be needed to meet specific requirements of a specific domains, such as the requirements from Table 1 in case of the MSC domain. Only a few of the software analysis patterns could be adapted to capture some of the MSC information, assuming their OWL representation. For instance, Fowler’s Unit, Quantity, Measurement and Observation patterns in OWL representation could provide for ‘What is the hole diameter size?’ or ‘What is the hole diameter size tolerance?’ or ‘What are typical production runs?’ CQs. Possibly applicable are patterns from Arlow and Neustadt (2004) library for capturing measure units, quantities (measurements), and general concepts such as party, address, organization, product or product catalog.

4.3.1 Typology of ontology design patterns

According to the ODP classification provided in Suarez-Figueroa et al. (2012) and Presutti et al. (2008), ODPs can be grouped into six different types, each addressing different aspects in ontology development. The Structural and Content ODPs are among those types of most interest to the ontology design, hence, to our discussion.

Content ODPs also may vary both vertically and horizontally. For instance, the ODP Portal provides both universally applicable and domain-specific Content ODPs. In fact, the ODP Portal organizes Content ODPs according to the domain applicability. For example, Transition ODP, which represents basic knowledge about transitions, that include events, states, processes and objects, is assigned to the manufacturing domain. In the portal, some of Content ODPs are vertical specializations and extensions of universally applicable or domain-specific Content ODPs. For instance, Person ODP is specialization of Agent ODP. Specialization means specializing some of the ODP elements, either classes or attributes. Any Content ODP can be further adapted and specialized to any specific context if needed. There are no restrictions in their use. In Gangemi (2005), the Content ODPs are classified into foundational and core ODPs, depending whether a Content ODP captures a foundational (universal) or a core (domain) concept. Structural ODPs, including Logical ODPs, in the analyzed libraries are all abstractions, devoid of any specific domain vocabulary; hence, universally applicable and with no vertical specialization.

4.3.3 Design principles for ODPs

According to Blomqvist (2009), there are at least two different approaches for constructing ODPs.

The first approach is to extract ODPs from existing ontologies or similar sources such as legacy libraries of reusable components. In fact, many of Content ODPs published in the ODP Portal are extracted from the DOLCE (Masolo et al., 2004) foundational ontology. In Gangemi and Chaudhri (2009), the authors reported the creation of Content ODPs by translating CLIB components into OWL representations. Blomqvist (2010) reported on the creation of Content ODPs by translating the software analysis patterns from Fowler (1997) and data modeling patterns from Hay (1996) and Silverston (2001a) into OWL DL representations.

The second approach is to develop principles of good design and construct ODPs that reflect them. This approach is of interest to our research. Currently, such good design principles do not exist (Hammar, 2011b). Below, we provide ODP design criteria and characteristics that we extracted from the following papers: Clark and Porter (1997), Clark et al. (2000), Aranguren (2005), Gangemi (2005), D’Antonio et al. (2007), Presutti et al. (2008), Blomqvist (2010), Hammar (2011a) and Hammar (2014). We have considered those criteria and characteristics as possible principles for the ODP design and development. Let us highlight the main findings.

In Clark and Porter (1997) and Clark et al. (2000), the authors had characterized the Reusable Components and Knowledge Patterns as highly abstract theories (the abstraction principle – DP18), which capture a small number of concepts (DP19). In D’Antonio et al. (2007), the OPAL ontology design patterns are also characterized as abstraction (DP20) and, thus, provided as parameterized templates (DP21). Certainly, the abstraction, as we have discussed before for data modeling and software analysis patterns, may be adopted to be an ODP design principle. It means that an ODP captures a concept that is super-categorical for all subordinate concepts. The number of concepts, or the size of the model, is also selected before as the design principle, and may be adopted to be an ODP design principle too.

In Aranguren (2005), ODPs, or more specifically, Manchester’s Logical ODPs, are also characterized as abstractions that hide OWL DL complexity (DP22) and provide for efficient reasoning. Each Manchester’s Logical ODP encompasses a few number of abstract concepts and structural–logical relationships; however, precise guide or quantification of the number of encompassed concepts is not given in Aranguren (2005). Hiding OWL complexity may also be an ODP design principle, although a very generalized one, while the efficient reasoning is more a requirement.

Presutti et al. (2008) summarized characteristics of Content ODPs as follows (c1) requirements covering components, (c2) computational component, (c3) small, autonomous components for better diagrammatical visualization, (c4) hierarchical components based on specialization or generalization, (c5) cognitively relevant components that are intuitive and compact, catching relevant, “core” notions of a domain, (c6) linguistically relevant components that match linguistic patterns called frames from repositories such as FrameNet,12

In addition to these characteristics, the authors also discuss anti-pattern characteristics that describe what a Content ODP should not be. For example, Content ODPs should not be a single isolated class or list of unrelated classes. They also should not be a single property with neither range nor domain defined, or list of such properties. The anti-pattern characteristics may be adopted to be ODP design principles (we refer to all them using id DP25), as there are very precise in saying what should be avoided in an ODP implementation. OWL representation pitfalls summarized in Rector et al. (2005), such as absence of “closure axiom” to close off the possibility of further additions for a given property, are similar and can be contemplated as anti-pattern recommendations as well.

In Gangemi (2005), intuitive and compact visualization of Content ODP is pointed out as an essential ODP design principle. A Content ODP “requires a critical size, so that its diagrammatical visualization is aesthetically acceptable and easily memorizable” (DP26).

In Blomqvist (2010), the author mentioned that granularity, sometimes called conceptual coverage should be such that the ODP encompasses only concepts which are needed for one specific modeling problem, but with a small number of concepts so that all aspects can be visualized at the same time. We adapt this as a design principle (DP27). The author goes on to say that an ODP follows OWL modeling best practices such as specifying inverse properties, adding comments, applying naming conventions – also this statement can be considered as a ODP design principle (DP28).

In Hammar (2011a), the author describes results of his work in developing a quality model for evaluating ODPs and emphasizes criteria including understandability, modifiability, minimal size, feasibility, completeness, expandability, performance, testability, ease of applicability, and documentation availability. The mentioned criteria are very general and as such they represent ODP requirements more than design principles to ODP development. From this work, we only take out a minimal size while at the same time being feasible complete ODP design principle (DP29), as which we already derived in works in data model and software analysis model patterns.

Finally, Hammar (2014) recently studied effects of ODP design decisions on reasoning performances. From the literature review, Hammar in his work (2014) has identified several performance-affecting indicators, grouped into language expressivity profile indicators, inheritance hierarchy structural indicators, and indicators related to the logical axioms employed in an ontology. Upon the experimentations with effects that indicators may have on the reasoning performances, he provided several recommendations to the ODP design: (1) avoid the use of multi-parent classes (DP30); (2) limit the number of property domain and range definitions to the minimum required by the ODP requirements (DP31); (3) use appropriate OWL 2 profiles to enhance performances (DP32); (4) avoid designs that give a high count of ingoing/ongoing edges per node (DP33); (5) limit the use of class restrictions, such as enumerations, property restrictions, intersections, unions, or complements to the minimum required by the ODP requirements (DP34); (6) avoid developing ODPs that cause a deep subsumption hierarchy (DP35); (7) limit the use of existential quantication axioms to the minimum required by the ODP requirements (DP36); (8) rewrite general concept inclusion axioms into property restrictions if possible (DP37). All of them are very concrete recommendation for development of ODPs and therefore, we contemplate them as ODP design principles.

ODPs are usually represented with graphical diagrams and textual descriptions. More specifically, Content and Structural ODPs in the ODP Portal, then the W3C ODPs and Manchester ODPs, are represented using UML or UML-like diagrams accompanied with textual descriptions. Those textual descriptions are usually structured into several parts such as the ODP name/title, functional specifications, implementation notes, consequences or side-effects, a source of the ODP, list of related ODPs, etc. The ODP Portal in most cases uses CQs to document the functional specification of their ODPs. The CQs are given informally using natural-language, which is probably not the best approach considering needs for ODP’s search and retrieval.

Computer-processable representations of ODPs are not as rare as computer-processable representations of data model and software analysis model patterns. For instance, Content ODPs in the ODP Portal are provided as reusable building blocks as “small” OWL ontologies. The building blocks can be directly imported or copied into other OWL ontologies, and then adapted to meet needed requirements. To that end, there is a NeOn Toolkit (2012) for search, retrieval and specialization of the Content ODPs available from the ODP Portal. However, ODPs may be provided in other forms too, not necessarily as “small” OWL ontologies. For instance, D’Antonio et al. (2007) have introduced BusinessActor, BusinessObject, BusinessProcess, ComplexAttribute and AtomicAttribute ODPs as parametrized templates. D’Antonio et al.’s ODPs are foundational enablers of their OPAL (Object–Process–Actor Modeling Language) framework for modeling business ontologies.

The main difference between ODPs as parameterized templates vs. ODPs as building blocks is how they are used in an ontology development. The ODPs as parameterized templates must be first populated with values and then, if needed, instantiated or transformed into OWL. Whereas ODPs as building blocks are very small-scale OWL ontologies that can be imported or copied directly into an OWL ontology. The parameterized-template approach seems more flexible than the building-block approach. Moreover, for some types of ODPs, it is the only meaningful approach. While Content ODPs can take either the parameterized template or building block form, the Logical ODPs are not bound to any concrete domain terminology. Thus, logical ODPs are more appropriate in the parameterized template form. In fact, Co-Ode (Collaborative Open Ontology Development Environment) (2009) project provided all Manchester’s Logical ODPs as parameterized templates as well as the parameterized template editor plugin for Protégé ontology management tool. That plugin uses OPPL, an Ontology Pre-Processing Language (Egana et al., 2008), which is an abstract formalism for manipulating OWL ontologies at the level of graph patterns. A graph pattern is any recurring structure in an OWL graph, a notion different from the ODP notion.

4.3.5 Applicability to semantic modeling of domain-specific information

Good practices in using OWL or solutions to OWL limitations, such as Structural and Logical ODPs, may be applicable to semantic modeling of domain-specific information such as MSC information. However, the applicability will certainly depend on concrete domain-specific information requirements. As stated earlier, there is no available library of Content ODPs that could sufficiently cover the requirements of the reference MSC ontology. In particular, by reviewing specifications of the Content ODPs in the ODP Portal and CQs they claim to support, no satisfied coverage for functional requirements of reference MSC ontology was found. In the ODP Portal, only one Content ODP is categorized as specific to the manufacturing. That is a Transition ODP, which however, provides for capturing concepts not within the scope of MSC information. From that portal only those Content ODPs that provide for capturing structural organization of data such is a Bag ODP or Collection ODP, or for capturing a general concept such as Party ODP, Location ODP are potentially applicable in the specific field of our interest.