Keywords

1 Introduction

During the last decade, significant progress was made in development methods, engineering tools and application environments of ontologies, which resulted in a growing interest from industry in applying ontologies for solving various industrial problems. Research and development in ontology engineering during the last years focused on techniques for reusing ontologies or parts of them, automation of laborious tasks like ontology population or conversion of texts to ontologies, matching between ontologies or the standardization of knowledge representation and its interlinkage with data. Integration with other technology areas, like knowledge management, enterprise knowledge modelling, or information systems is another reason for the increasing use of semantic technologies in industry.

This paper presents experiences and recommendations for ontology construction projects with focus on industrial application contexts. Our aim is to contribute to the body of knowledge in the field of ontology construction by taking a focus on practices. The research is based on a number of case studies that were carried out in industrial enterprises from different domains. Two of these cases were caused by the fact that modern market opportunities require companies to introduce new strategic objectives and tools. They have to build strategies that provide maximum flexibility and can optimally respond to changes in their environment [3, 7] In order to cope with these requirements, companies need to deeply transform both their product development structure and the structure of their business processes. Enterprise modelling can significantly contribute into this transformation since in this respect models are often used as a supportive means that are able to capture and represent different aspects and constructs of an enterprise [14]. Usually, enterprise models consider different enterprise aspects and rise to different meta-levels. In this regard, application of ontologies as conceptual bases that can clarify relations within and between different abstraction levels is believed to be helpful. Ontologies have shown their usability for this type of tasks. They provide a way of knowledge representation, which is widely used today for intelligent analysis of knowledge. As a consequence of this, ontologies will also have the power to clarify the relations between focal areas and the constructs within a focal area [18]. Ontologies are content theories about the sorts of objects, properties of objects and relations between objects that are possible in a specified knowledge domain. They provide potential terms for describing the knowledge about the domain [2].

The remainder of the paper is structured as follows: After a brief description of important concepts and methods for ontology construction (Sect. 2) and the research approach taken (Sect. 3), three industrial cases of ontology development from different application domains are introduced (Sect. 4). Experiences and recommendations are presented and discussed (Sect. 5) related to development strategy, development methodologies and user participation. Conclusions and future work are presented in Sect. 6.

2 Background

The background for this work primarily comes from the field of ontology construction. From the many different definitions of the term “ontology” in computer science related research, Gruber’s proposal will be used in this paper: “An Ontology is a formal, explicit specification of shared conceptualization.” [6].

Ontology Representation: For case 1 and 3 presented in Sect. 4, Protégé frames or the W3C recommendation ontology language OWL (Web Ontology language) are used to represent the ontology. An OWL ontology consists of Individuals, Properties and Classes. In case 2 an object-oriented constraint network paradigm [15] is applied, which supports capturing of constraints in a more sophisticated way. The OOCN-based ontology consists of Classes, Class Attributes (Values), Value Domains and Constraints. The Class Instances (Individuals) are stored separately from the ontology. The OOCN representation can be transformed to OWL and vice versa.

Ontology Development Methods: Ontology construction is a challenging task and ontology engineers are in need of methods and guidelines to increase the possibility of the project success. There has been a series of approaches proposed for developing ontologies. Despite the fact that the methodologies for ontology development have been subject to research during a number of years, there is no one ‘correct’ way or methodology for developing ontologies. Previous analysis of ontology development methodologies [12] showed differences in the guidelines provided for the user of the ontology and in the coverage of the ontology lifecycle, i.e. is the ontology construction covered or also evaluation, use and supporting activities? Table 1 shows a (non-exhaustive) list of existing methodologies with selected features.

Table 1. Selected ontology development methodologies
Full size table

Experience Reports in Ontology Engineering: There is only a small number of articles that reflect on experiences and practices from ontology engineering and provide the results of applying a development method, most of the work reports experiences with ontology development methods in the conclusion sections, if at all. Reference [5] discusses strong points and weakness of the Systematic Approach for Building Ontologies (SABiO) ontology development approach and proposes improvement opportunities. Reference [8] develops an ontology based on the guidelines provided by METHONTOLOGY, examines the method utility and addresses the drawbacks. Reference [10] presents results of the practice of ontological engineering without addressing any specific method. Reference [1] reflects experiences from merging different ontology development methods and best practices in software engineering. Finally, our previous work in [9] reports on experiences from ontology construction in practice, which is substantially extended and revised in this paper by including many more cases.

3 Research Approach

From a research methodology perspective, we performed a qualitative analytical survey. Since our objective is to derive experiences for ontology engineering in practice our focus has to be on data sources containing very detailed experience reports and rich case descriptions. As this type of report is quite sparse in scientific literature on ontology engineering (see Sect. 2) we decided to base our analytical survey only on ontology development projects performed in our own research groups. For these projects, the original project documentation and the personnel involved in the project are available. The projects analysed originated from three research contexts, (i) Rostock University (Germany), research group business information systems, (ii) St. Petersburg Institute for Informatics and Automation (Russia), Computer-aided Systems lab and (iii) School of Engineering at Jönköping University (Sweden), research group information engineering who in some projects jointly worked on the tasks.

The analysis of the projects was done in distributed teams using a joint list of aspects to be investigated. Table 2 shows the list of projects analysed.

Table 2. Ontology construction projects analysed in this paper
Full size table

4 Industrial Cases of Ontology Construction

This chapter introduces the industrial cases forming the basis for discussion of experiences in Sect. 5. When selecting these cases, the objective was to achieve a wide heterogeneity regarding the type of project (research project, applied research, contract development), the application domain and the purpose of the ontology developed (information structuring, model integration, product codification).

4.1 Autoliv Electronics

The first industrial case was taken from automotive industries. Automotive manufacturers and suppliers have to manage a large number of product variations and their integration into a specific car model. In order to manage and control variety, manufacturers and suppliers increasingly recognize the need to manage project entities like models, documents, metadata, and classification taxonomies in such a manner that the integrative usage of these entities is supported.

The application scenario for the ontology developed is integration of different kinds of structures reflecting the artefacts and their interrelations. On the one hand, model hierarchies have to be captured, indicated and implemented by different modelling levels (system, software, hardware, etc.), which furthermore will have model instances (artefacts) to be managed. On the other hand, term networks and taxonomies have to be considered as equally important. These networks represent organizational structures, product structures or taxonomies originating from customers that are closely related to artefacts. Explicit denotation of these relationships is considered beneficial for identification of reuse potential of components or artefacts.

The ontology construction was performed in a Swedish automotive supplier of software-intensive systems. The development process applied is an enhanced version of the METHONTOLOGY process as described in 2.2. Most important knowledge sources were (1) a description of the suppliers internal software development process with defined procedures for all major aspects of software development and software project management and (2) documentation of two example cases for requirement handling, including original customer requirements, system and functional requirements, and (3) interviews and working sessions with members of the software development department were conducted including project manager, software developers and engineers. The resulting ontology consisted of 379 concepts and with an average depth of inheritance of 3.5 [20].

4.2 Festo

The second industrial case originates from long-term joint work with Festo AG&Co KG, an industrial company that has more than 300 000 customers in 176 countries supported by more than 52 companies worldwide with more than 250 branch offices and authorised agencies in further 36 countries [13]. In this case the goal was to build a problem-oriented ontology for the given, specific purpose. Some early steps of this collaboration related to implementation of the product codification system have been reported in [17]. As a result it was more reasonable to build a new ontology using the formalism that met the requirements than to try to adapt other existing ontology models like CYC or SENSUS.

The complete approach used in this case relies on the ontological knowledge representation for its sharing. The ontology describes common entities of the company’s knowledge and relationships between them. Besides, the dynamic nature of the company requires considering the current situation in order to provide for actual knowledge or information. For this purpose, the idea of contexts is used. Context represents additional information that helps to identify specifics of the current transaction. It defines a narrow domain that the user of the knowledge management platform works with. One more important aspect covered by the approach is the competence profiling. Profiles contain such information as the network member’s capabilities and capacities, terminological specifics, preferred ways of interaction, etc.

The approach is based on the idea that knowledge of the company can be represented by two levels for the modelling purposes. The knowledge of the first level (structural knowledge) is described by a common ontology. In order for the ontology to be of reasonable size it includes only most generic common entities. The common ontology is used to solve the problem of knowledge heterogeneity and enables interoperability between heterogeneous information sources due to provision of their common semantics and terminology. It describes all the products (produced and to be produced), their features (existing and possible), production processes and production equipment. This ontology is used in a number of different workflows. The tools are interoperable due to the usage of the common ontology and database. Knowledge map connects the ontology with different knowledge sources of the company. Knowledge represented by the second level is an instantiation of the first level knowledge.

The ontology creation operation was done automatically based on existing documents and defined rules of the model building. The resulting ontology consists of more than 1000 classes organized into a four level taxonomy, which is based on the VDMA (Verband Deutscher Maschinen – und Anlagenbau, German Engineering Federation) classification [19]. Taxonomical relationships support inheritance that makes it possible to define more common attributes for higher level classes and inherit them for lower level subclasses. The same taxonomy is used in the company’s PDM and ERP systems. For each product family (class) a set of properties (attributes) is defined, and for each property its possible values and their codes are defined as well. The lexicon of properties is multilingual and ontology-wide, and as a result the values can be reused for different families. Application of the central single ontology provides for the consistency of the product codes and makes it possible to instantly reflect incorporated changes in the codes. The place of the developed ontology in the product development and configuration process is shown in Fig. 1 (the detailed description of the process can be found in [16]).

Fig. 1.
figure 1

Product development and configuration process for the Festo case

Full size image

4.3 Trailer Surveillance Ontology

The third case is based on an industrial research and development project from transport and logistics industries. One of the world’s largest truck manufacturers is developing new transport related services based on integration and orchestrated interpretation of different information sources, like on-board vehicle information systems, traffic control systems and fleet management systems. The case aims at using wireless sensor networks in trailers for innovative applications. The wireless sensor network is installed in the position lights of a trailer and could be used for protecting the goods loaded on the trailer against theft, offering additional assistance to the driver of the truck or for surveillance of the goods. The wireless sensor network in the position lights is controlled by a gateway in the trailer, which communicates with the back-office of the owner of the trailer or the owner of the goods, and – for some application cases – with the on-board computer of the truck.

In order to implement the above services, various kinds of knowledge need to be available and combined, which is one of the main purposes of the ontology development performed in the case. Observations acquired through the different sensors in the trailer have to be combined with information coming from other sources, like an authentication service for the driver’s identity. Furthermore, we have to detect potential critical events, according to what is specified by the IT services. For this purpose, the ontology had to accommodate transportation domain knowledge, the sensors and their observation possibilities, and a conceptual model for situations.

The ontology development followed an extended version of “ontology development 101” [4]. The resulting ontology for transport surveillance (OTS) was developed in several iterations. OTS adopts the Semantic Web Rules Language (SWRL) for modeling rules which provides the ability to add Horn-like rules expressed in terms of OWL concepts. Observing the relations between objects or entities, situation awareness (or assessment) aims at providing a projection based on situations, which describe a state of affairs adhering to a partial view of the world. A subject is aware, if he is capable of observing some objects and making inferences from these observations.

5 Experiences

Experiences and recommendations presented in this section were based on the industrial cases introduced in Sect. 4 and findings from other research and development projects applying ontologies (see Table 2 in Sect. 3). The experiences regarding user participation (5.3) are to a large extent already reported in earlier work (see [9]). They are included in this paper as they were confirmed by the later cases and additional recommendations were added.

5.1 Development Methods

Concerning the ontology construction methodologies, we applied ontology development 101, METHONTOLOGY, XD and OntoSME, as already shown in Table 2. As the individual experiences with these methods have been reported in detail in previous publications (see Table 2), we will focus in this section on the general view.

Although ontology development 101 is considered as rather limited method due to its focus on ontology construction only and the closeness to Protégé as a tool, we find it still one of the most useful approaches when focusing of the core content of its seven development steps and adapting it to contemporary tool support. As in all modelling and development projects, domain and scope of a project should be clearly defined and reuse of proven solutions should be considered, which make the first two steps important. Competency questions from our view are a valuable way to express scope and focus. In case 3 after iteratively listing the competency questions, we searched for the existing ontologies that might be refined or extended. Unfortunately neither transport domain ontologies nor information models for the truck-trailer surveillance domain were identified. Nevertheless the reviewed models were to some extent reusable and beneficial, e.g. through the models, ontologies and approaches, it was practicable to identify important terms & controlled vocabularies, to define the classes, class hierarchies as well as the relationships between them. Hence, it is possible to reuse existing ontologies or even models as an instrument to identify semantic specifications in the domain. The way of defining attributes and value ranges of the concepts and of capturing instances (steps 5 to 7) is affected by the selected tool. Nevertheless, the activities as such remain important and required.

5.2 Concept Identification During the Development Process

Additional experiences contributed by this paper concern the identification of relevant concepts, relation and properties or constraints. One aspect to discuss is whether to work top-down, bottom-up or middle-out. Our impression from ontology development projects indicates that experience from enterprise modelling concerning these strategies can be applied as rule of thumb for ontology projects.

Top-down approaches should be used in application domain well-known to the project team where the complexity in terms of required level of detail and the scope of the development is clearly defined. An example from our background would be the Festo case, where the existing codification system, number of products and potential variation limited the complexity of problem at hand. In cases with unclear or unknown complexity, there is the danger of consuming the resources allocated to the project before reaching the goal of having developed an ontology. Bottom-up approaches can result in a number of thoroughly defined parts of an ontology, which are not very well interlinked and do not cover the intended scope of the ontology. These “solution islands” often contain more details than required for the purpose of the ontology. Our recommendation is to always test suitability of the bottom-up approach by using it in a pre-study with limited scope and clearly defined evaluation criteria. Finally the middle-out approach is from our experience suitable to explore both, complexity of the problem at hand and required level of detail, in application fields unknown to the ontology expert. The approach was used in the trailer surveillance case in order to capture sensor related concepts in combination with situations to be detected. What level of detail of situation information was needed in order to describe the sensor information in sufficient detail became only clear during the ontology development process.

In addition to this generalisation/specialisation strategy, we recommend to also have different lifecycle phases of an ontology in mind during the development process, such as the conceptual, implementation and application stage. In the first stage the main elements, structures, relations and constraints of an ontology are identified based on the knowledge of the domain experts and other knowledge sources. This stage should be independent from the actual ontology representation or ontology engineering tool to be used in order to avoid unnecessary dependencies from implementation technology. The implementation stage codes the result from the conceptual stage in appropriate representation with a suitable tool, which allows for selection of the implementation technology based on the lessons learned from the conceptual stage. The last stage optimizes the implementation for application purposes, which for example can include additional instances or axioms for consistency purposes. To distinguish between these different phases is part of several methods, such as METHONTOLOGY. However, many other methods do not make this strict distinction, which is why this paper emphasizes the importance of clear separation.

5.3 User Participation

Since more than a decade, participative modelling is recognized as valuable and practicable instrument contributing to solving design problems in particular in organizational contexts (see e.g. [11]). As opposed to the traditional approach of gathering facts by interviewing stakeholders in an organization and afterwards developing a solution without stakeholder involvement, the participative way of working includes development of the intended solution with direct involvement and contribution of the future users, like modelling in facilitated group sessions.

Experiences from ontology development projects like the cases presented in Sect. 4 indicate the value of user participation even for ontology development projects. The main recommendations are to thoroughly prepare participation and to concentrate on the conceptual stage of development.

The preparation of user participation should start with the key persons at the industrial company, who should be introduced to the potentials and limits of ontology use. However, this introduction should not include representation techniques or technical details of ontologies, since this usually is not relevant for decision makers and could create distraction from the modelling task. By clearly defining purpose of the project, intended use of ontologies and known limits, the expectation of the industrial partner can reflect the realistic possibilities. This should preferably happen before the ontology development starts.

After sufficient management information and attention, the intended participative steps of the ontology development should be prepared by individual discussions with the participants. Each participant should be informed about the purpose of the ontology development project and the intended way of working. However, main purpose of these individual discussions is to start identifying existing knowledge sources in the organization relevant for the ontology development, to build up trust to the participating users, and to increase their commitment to the project.

During the participative parts of the ontology construction, focus should be on the conceptual stage of the ontology development and on use of techniques like card sorting or pencil and paper sketches. Main reason for this is to not put the burden of learning and understanding the formalities of an ontology language on the domain experts and end users participating. A notation that everyone understands should be used, otherwise to too much attention is lost when the participants try to understand the notation used.

5.4 Organizational Changes Triggered by Ontology Development

In the Festo case we observed that ontology development was part of an organizational change process towards a more knowledge-aware organisation. Implementation of complex changes in large companies faces many difficulties: business process cannot be stopped to switch between old and new workflows; old and new software systems have to be supported at the same time; the range of products, which are already in the markets, has to be maintained in parallel with new products, etc. Another problem is that it is difficult to estimate in advance which solutions and workflow would be efficient and convenient for the employees. Hence, just following existing knowledge management implementation guidelines is not possible and this process has to be and iterative and interactive.

During the work on the mentioned case studies the following observations related to knowledge management implementation in companies have been made:

  • Engineers and managers are concentrated on their work and cannot pay enough attention to additional tasks related to trying new knowledge-based workflows. This was in a higher degree applicable to the product managers and product engineers. At the levels of production engineers and production managers, this issue was less obvious, because the “experimental” knowledge-based production planning could be done in parallel with the actual one.

  • A target knowledge management consisting of people volunteering to assist in implementing knowledge management in the company group has to be formed. These people have to be experts in their roles and in several other roles, which would re-use some of the knowledge of this role. They will be involved into the processes of building the initial common ontology and implementing knowledge-based workflows, thus slowly involving other roles into the process of knowledge management implementation.

  • Role-based approach makes it possible to implement knowledge management incrementally, with initiative coming from employees. E.g., an experimental knowledge-based support of one workflow could be implemented for one user role letting the users estimate its efficiency and convenience. Then, workflows reusing some of the knowledge of the experimental workflow can be added, etc. Representatives of other roles seeing the improvements of the implemented knowledge-based workflows also wish to join and actively participate in the identification of the knowledge needed for their workflows and further turning their workflows into the knowledge-based ones.

6 Conclusions

Based on the analysis of a number of ontology development projects performed in three different research groups and on the discussion of three industrial cases in detail this paper presented a number of experiences and recommendations for ontology construction in an industrial context, which can be summarized as follows:

  • Consider using “simple” methods, like ontology development 101, for the construction phase of ontologies; adapt the methodology to the situation at hand, e.g. regarding tool use and iteration of phases

  • Use top-down development for well-known domains with clearly defined scope; use middle out development for unknown application fields; always perform a pre-study before deciding to use bottom-up development; clearly separate between conceptual, implementation and application stage

  • Create realistic expectations on company management side; use participative work mainly in the conceptual stage, i.e. avoid details of ontology representation

  • Prepare for accompanying organizational change projects triggered by ontology development; investigate the role structures in the organization “neighbouring” the ontology development project

Although the work presented in this paper is based on quite a few industrial cases, the main limitation of the research is that the empirical grounding should be improved by an increased number of cases. The recommendations presented are considered useful, but they cannot be expected accurate for all industrial cases. Future work will include further elaboration on the recommendations. The above list of recommendations should be extended in more detailed guidance or good practices for ontology developers. Furthermore, there are a number of experiences from industrial projects not discussed in this paper because they were just based on a single case, like the use of ontology design patterns, the reuse of existing ontologies, or the integration of ontologies with existing IT-systems in the companies under consideration.