Many industries experienced a shift in sourcing and logistics strategies, the industrial demand for more dynamic logistics solutions with adequate IT support is increasing. Due to advances in wireless sensor networks and technologies, the transportation area in logistics industry is the most promising application field for new types of innovative services. The emerging applications in this field require an integrated knowledge base to provide enhanced customer services. The aforementioned trends will lead to service innovation if the adaptation of business models is ensured. Our earlier work focused on adaptable business models [1] and argued that knowledge representation techniques are suitable concepts to improve selforganization [2]. In this paper we introduce the core component of the knowledge architecture represented as ontologies and report experiences from the development process. The contributions of this paper are (a) a detailed description of the ontology construction process based on a realworld scenario, (b) experiences from the development process and, (c) proposed adaptations of an established ontology engineering approach.
The logistics industry has changed under the impact of the internal European market and of an increasing globalization into a high-technology industry, making intensive use of modern information technology. At the same time, the industrial demand for more dynamic logistics solutions with adequate IT support is increasing. Within the logistics industry, the transportation area is the most promising application field for new types of intelligent services, since advances in wireless sensor networks and sensor/actuator technologies allow for new ways of tagging and tracking goods and vehicles.
From the perspective of enterprises offering transportation services, the above technology trends will only lead to successful service innovation if the underlying business model can be adapted to new opportunities and the organizational and ITinfrastructure provide adequate support. In earlier work we showed that selforganizing systems contribute to adaptability of business models [1] and that knowledge architectures and knowledge representation techniques are suitable concepts to improve self-organization [2]. This paper will focus on the engineering process of the actual core component of the knowledge architecture: an ontology for transportation surveillance (OTS).
Ontology-based modeling approaches are frequently applied when the models to be developed are supposed to contribute or be the basis for knowledge-based systems in enterprises. Experience reports and practice in the field of ontology engineering usually focus only on construction principles for the ontology, the use of certain modeling languages or ways to avoid flaws (see section 3.2). Experiences with ontology engineering methods, the integration of enterprise stakeholders or work distribution are rarely reported. The aim of this paper is to contribute to the body of knowledge in ontology engineering for service innovation by reporting from a project in ontology development for transportation, which is supposed to be used for new kinds of services based on wireless sensor networks and an adaptable knowledge base. The contributions of this paper are (a) a description of the ontology construction process based on a real-world scenario, (b) experiences from the development process and, (c) proposed adaptations of an established ontology engineering approach.
The remaining part of the paper is structured as follows: section 2 introduces the industrial application case including requirements to the knowledge base. Section 3 summarizes the background for the work from the area of ontology engineering. Section 4 describes the ontology engineering process performed in much detail. Section 5 discusses experiences from the ontology engineering project. Section 6 summarizes the work and draws conclusions. 2
The application case from transportation industries selected for this paper (see Fig. 1) 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 an integration and orchestrated interpretation of different information sources, such as on-board vehicle information systems, traffic control systems and fleet management systems. The aim is to use wireless sensor networks (WSN) in trailers for innovative applications. The wireless sensor network is installed in the position lights of a trailer. Each position light carries a sensor node able to communicate with neighboring nodes and equipped with a radar sensor. The radar sensor could be used for protecting the goods loaded on the trailer against theft, offering additional assistance to the driver of the truck (e.g. blind spot support) or for surveillance of the goods (e.g. sealing different compartments of the trailer). 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.
One of the use cases defined in the project is a new service, which is offered to protect the goods loaded on the trailer against theft. More precisely, the main doors of the trailer are equipped with an additional “electronic” seal. An analysis of current work procedure in the case study showed that when transporting expensive goods, the sending unit of a hauler mounts a physical seal on the trailer’s doors and takes a picture of this seal. At the destination, the receiving unit checks whether the seal is broken and compares it with the picture taken at the destination. This error-prone manual sealing process would be improved with an electronic seal. If the electronic seal protection service is booked by the trailer owner, the goods are loaded on the trailer, doors closed, and seal device is activated, which also activates the protection mode for the trailer. At arrival, the responsible person sends the “unlock” request. If the authorization process for the responsible person is successful and the person is in the close vicinity of the trailer, the electronic seal is de-activated. In order to implement such service, various kinds of knowledge need to be available; 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 by inferring new knowledge, according to what is offered to the customers by the booked IT services. For this purpose, the knowledge base had to accommodate basic transportation domain knowledge, the sensors and their observation possibilities, and a conceptual model for situations.
As a background for the work presented in this paper, we will describe relevant work in the area of ontology engineering. 3.1
Ontology construction is a challenging task and ontology engineers are in need of
methods and guidelines to increase the possibility of the project success ([8], [9]).
Due to the fact that the methodologies for ontology development have been
subject to research during a number of years there has been a series of approaches
proposed for developing ontologies [3]. We share the view that ontology
development methodologies can be classified as experience-based methodologies and
evolutive prototypes [
Under the investigated approaches for ontology engineering, we selected the method of Noy & McGuinness mainly due to our experiences from earlier ontology development projects. The approach was extended in the development of the Ontology for Trailer Surveillance (OTS) by two more steps. After creating instances, the rules for more powerful reasoning need to be formulated, which also provide a consistent knowledge base. Next, the concept of defined classes is applied, i.e. if an individual fulfills the necessary and sufficient conditions given by the defined class, then it is inferred to be a member of this class. Table 1 summarizes the analyzed approaches and the reasons why they were not applied in the ontology development. 3.2
There is only a number of articles that reflect 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. [8] discusses strong points and weakness of the Systematic Approach for
Building Ontologies (SABiO) ontology development approach and proposes
improvement opportunities. [9] develops an ontology based on the guidelines
provided by METHONTOLOGY, examines the method utility and addresses the
drawbacks. [
In this section we describe the development of a knowledge base represented by the Ontology for Trailer Surveillance (OTS) for the transportation use case presented in section 2. In this section, we first motivate the basics of the OTS and then construct the knowledge base that provides the required features. 4.1
As discussed in section 2, the ontology needs to be able to capture knowledge about sensors, situations and the application domain of transportation as such. For this purposes different information models in sensors, observations, situation (awareness) and time domains are investigated. Utilizing the reusable components of these models, the domain model should be able to conceptualize the knowledge base for offering services in transportation sector. Moreover it should serve a basis to prepare a list of important terms for the particular domains, which could be used as classes and/ or properties.
Part of the domain model covers the sensors in the trailers and the control
hierarchy, which at least consists of the sensor nodes and the trailer gateways and the
trailer fleet of a customer of a service type. For the trailer-WSN related part of the
domain model, The Open Geospatial Consortium (OGC) sensor web enablement,
in particular the observations and measurements (O&M) and The Starfish Fungus
Language (*FL) [7], was taken as starting point to allow expressing the sensing
procedures. Both specifications assure a possible integration with Sensor
Observation Service (SOS), a standard that allows querying observations, sensor metadata
as well as representations of observed features. In this respective, concepts from
an observation ontology, Semantic Sensor Observation Service (SemSOS or
O&M-OWL), are adopted, which takes the advantages of representing the sensor
data in OWL and enabling reasoning over sensor observations [
OTS adopts the situation awareness paradigm, which describes the state of
affairs by observing the relations between objects or entities, as the relations
between subjects constellate various situations [
OWL provides minimal support for modeling the temporal relations as well as
temporal information. As a result, ontologies often cannot fully express the
temporal knowledge needed by applications, users and engineers develop ad hoc
solutions. OTS adopts Allen’s time intervals algebra that has six basic time intervals
constituting a sum of 13 temporal interval relations [
Step 1: Determine the domain and scope. In this step the requirements for the ontology to be developed are listed. In addition to the requirements presented in section 4.1, the OTS should cover the transportation domain with a primary focus on the surveillance of the transportation instances at ground (haulage), i.e. trucks and trailers. OTS aims to serve as a knowledge base to offer flexible customer services to protect the transport instances from thievery by processing contextual knowledge, which may arise from different situations. In order to specify the requirements on the ontology, we put together a list of competency questions. As shown in Table 2, the questions are classified in accordance with their abstraction level, which is detailed in section 5. Step 2: Consider reusing existing ontologies. We searched for the existing ontologies that might be reused, i.e. 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, e.g. through the models, ontologies and approaches introduced in section 4.1, it was practicable to identify important terms & controlled vocabularies (Step 3), to define the classes, class hierarchies as well as the relationships between them (section Step 4&5). Hence, it is possible to reuse existing ontologies or even models as an instrument to identify semantic specifications in the domain. This also offers the possibility to align the ontology to the existing knowledge base or standards in the future.
Step 3: Enumerate important terms in the ontology: Although it has not been
prescribed in Noy & McGuinness Methodology the terms utilized in the
knowledge base should semantically be explained in order to create a basic
terminology and a common understanding among the users as well. For this purposes,
we defined some key concepts in trailer surveillance domain such as Event
(concepts which are caused by observations [
Step 4: Define the classes and the class hierarchy. Important concepts like Observation, Event, Sensor, Situation or Feature are represented as classes. For naming the classes the CamelCase naming convention is applied. The situation classes define and implement the customer services. Hence they are the most important classes in the OTS. The situation class has six defined subclasses four of which represent the services (see Fig. 2). New services can emerge in the future, which require the assessment of different situations. For instance, the ElementarySituation class has no direct function in the OTS whereas it might be used in the future to exploit customer’s preparedness to pay for the services, e.g. booking an elementary situation can be provided at a lower price than booking a complex situation, which is represented by ComplexSituation class. Such services can be realized by adding more rules to the knowledge base. An excerpt from the class hierarchy is illustrated in Fig. 2. Step 5 & 6: Define the properties and cardinalities. The classes alone cannot provide enough information in an ontology, the properties of these classes are also necessary to constitute the OTS. Due to the low support of OWL concerning the modeling of temporal relations (see section 4.1), we applied the object properties “before, during, equal, meets” following Allen´s temporal intervals. To represent the time information in intervals, hasBegin-hasFinish data type properties are used. The object property deliversIn is used to capture information about the trailers that deliver the goods in particular cities, which are entered manually by the trailer or goods owner to the information base. After defining the properties, the Noy & McGuinness Methodology determines the cardinality of the properties, which can be carried out parallel to step 5.
McGuinness Methodology by not only creating instances, but also specifying rules and defined classes. The rules are mainly created to provide consistent time representation such as “if an event meets a second event, which in turn meets a third event, then the first event is before the third event” or to contribute to the consistency of the ontology.
The defined classes have necessary and sufficient conditions that have a definition. Classes, all of whose individuals satisfy this definition, can be inferred to be subclasses of a defined class. In the OTS, the concept of the defined classes is used for defining certain event and situations. As an example, a “distance event” is represented by the following conditions: i) there is an individual, which is a member of an event class that is created based upon an observation and ii) the observation has at least one result and iii) the result has at least one hasDistance data type property with an integer value greater than “1”. The first and second conditions are named as “pattern conditions” since most of the defined classes reuse, extend and build upon them. We argue that identification of such reusable fragments are beneficial for the ontology engineer when creating rules and conditions.
Experiences and recommendations presented in this chapter were based on the industrial case introduced in section 2 and the engineering process described in section 4. The experiences include the areas of ontology development method, ontology reuse and tool selection.
Ontology Development Method
Developing an ontology is necessarily an iterative process with several interrelationships between the process elements. To maintain the overview, relate the outcomes of the different phases of ontology development and to determine the improvement points method application is required. The ontology engineer should consider the use case requirements to decide which method provides the best support and in some situations and the methodology must allow the engineer to carry out minor adaptations. In this respective, the method of Noy & Mc Guinness was chosen, which consists of 7 steps. This approach is extended applying two more steps as described in section 3.1.
The most important step in the ontology development is determining the scope. For which purposes is it being developed? What are the competency questions that an ontology has to answer? Such questions specify the requirements that the developed ontology should meet. When constructing the competency questions, the necessity of classifying the questions and giving them an explicit structure became apparent. Therefore we classified the competency questions as high-level and lowlevel questions. Questions with a high-level abstraction can be adapted to various domain ontologies, which conceptualize observation models and they can be referred as "domain-level questions". The choice of word ”domain” is intentional and designates the reusability aspect of high-level competency questions by other ontology engineers. The concrete implementations of high-level questions are realized with the help of low-level questions. These are relevant for an application in a given domain, for which the ontology needs to be developed respectively. Thus, the low-level questions are referred as ”application-level questions”. For instance, in a scenario where an engineer develops an ontology for an ecological domain to sustainably manage the natural environment, the engineer would probably need to model the observed data, identify their relevancy and appropriately integrate the sensory information. Therefore domain-level questions, such as "what is being observed" or "which sensors propagate the observations" has to be answered. The ”application-level questions” on the other side would relate to the ontology use.
Due to time and resource restrictions the investigation in transportation domain was not executed in detail and thus the domain specific competency questions were formulated on a rather general level (see also following subsection). This had consequences in the latter stages of the ontology development, e.g. domain specific transportation terms were not specified in detail in OTS.
Ontology Reuse
Even though the early development phases of the ontology included an extensive investigation of existing ontologies and their possibilities of reuse in the relevant fields such as situation awareness, observing and measuring sensory information and time representation, we were not able to use an off-the-shelf ontology. The identified ontologies were only to some extent suitable to meet the competency questions. Thus, we recommend developing clearly defined competency questions also for supporting the selection of reusable ontology parts. Nevertheless, the extensive search process for relevant models and ontologies has given an idea of how to name the concepts and relate them to each other (steps 4, 5 and 6). To some extent, this can be considered as reuse of concepts and relations from ontologies rather than as reuse of ontology parts. As a result the ontology engineer should think of reusing existing ontologies also as an instrument to identify semantic specifications of the relevant domain, e.g. situations, observations and sensors. Such specifications would also enhance the interoperability of the knowledge base to the existing ontologies or standards. Also from the standardization point of view our investigation in the transportation logistics domain did not result in significant outputs, i.e. no guidelines were identified including the semantic of the terms in the domain, models and frameworks were not publicly accessible.
Tool selection
Exact specification of the ontology requirements has an important impact on the
development process. This was the case during the tool selection. As there was no
support to carry out a requirement analysis in Noy & McGuinness method, the
Protégé 4.x was chosen as the ontology development tool at the beginning of the
project based on the positive experiences in the past. In fact, using the 4.x versions
instead the 3.4.x version affected the modeling of the temporal information. We
applied the valid-time temporal model represented in [
Based on an industrial research and development project, the paper describes experiences from an ontology development process for offering innovative services in transportation industry. The developed ontology will form the basis for various services offered by an enterprise active in the transport domain with the intention to exploit the potential of new types of sensor and actuator systems for the purpose of information logistics and security services. The main limitation of the research is that the empirical grounding should be improved by evaluating the ontology as well as increasing the number of cases applying the OTS.
Future activities will have to include work on the ontology as such and on services using the ontology. The ontology so far was not constructed as a complete enterprise ontology for the enterprise under consideration but as an application ontology for the defined purpose. The main reason for this differentiation is that an enterprise ontology for the remaining part of the business does not yet exist and will have to be developed. Converting the documented business processes into ontology parts might be a suitable way to start this development. Furthermore, additional services on top of the trailer surveillance might require adjustments in the ontology for accommodating other sensor types or situations to recognize.
From a service development perspective, we also developed the overall
knowledge architecture for all knowledge-based services using the ontology and
its instantiation, the knowledge base (cf. [