Experiences from Ontology Development for Service Innovation in Transportation Industries Hasan Koç, Birger Lantow and Kurt Sandkuhl University of Rostock, Institute of Computer Science, Chair Business Information Systems Albert-Einstein-Str. 22, 18059 Rostock, Germany {hasan.koc, birger.lantow, kurt.sandkuhl}@uni-rostock.de Abstract. 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 net- works 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 ear- lier work focused on adaptable business models [1] and argued that knowledge representation techniques are suitable concepts to improve self- organization [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 de- tailed description of the ontology construction process based on a real- world scenario, (b) experiences from the development process and, (c) pro- posed adaptations of an established ontology engineering approach. Keywords: Service innovation, experience report, transportation surveil- lance, information logistics, enterprise ontology. 1 Introduction The logistics industry has changed under the impact of the internal European mar- ket and of an increasing globalization into a high-technology industry, making in- tensive use of modern information technology. At the same time, the industrial demand for more dynamic logistics solutions with adequate IT support is increas- ing. Within the logistics industry, the transportation area is the most promising ap- plication field for new types of intelligent services, since advances in wireless sen- sor 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 Copyright © 2015 by the authors. Copying permitted for private and academic purposes. This volume is published and copyrighted by its editors. 136 business model can be adapted to new opportunities and the organizational and IT- infrastructure provide adequate support. In earlier work we showed that self- organizing 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 engineer- ing process of the actual core component of the knowledge architecture: an ontol- ogy 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 en- gineering 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 adapt- able 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 on- tology 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. Sec- tion 3 summarizes the background for the work from the area of ontology engi- neering. Section 4 describes the ontology engineering process performed in much detail. Section 5 discusses experiences from the ontology engineering project. Sec- tion 6 summarizes the work and draws conclusions. 2 Application Case: Trailer Surveillance in Transportation 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 interpreta- tion of different information sources, such as on-board vehicle information sys- tems, traffic control systems and fleet management systems. The aim is to use wireless sensor networks (WSN) in trailers for innovative applications. The wire- less 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 driv- er of the truck (e.g. blind spot support) or for surveillance of the goods (e.g. seal- 137 ing different compartments of the trailer). The wireless sensor network in the posi- tion 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. Fig. 1: Simplified Architecture of the Application Case 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 expen- sive 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 destina- tion. This error-prone manual sealing process would be improved with an elec- tronic 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 elec- tronic seal is de-activated. In order to implement such service, various kinds of knowledge need to be available; observations acquired through the different sen- sors 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. 138 3 Background As a background for the work presented in this paper, we will describe relevant work in the area of ontology engineering. 3.1 Ontology Engineering Methodologies 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 sub- ject 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 devel- opment methodologies can be classified as experience-based methodologies and evolutive prototypes [10]. Both types consist of two phases on a very high level; the specification phase to acquire informal knowledge on the domain, and the conceptualization phase, which structures and represents this knowledge formally. These are normally followed by additional phases, such as evaluation, actual im- plementation, deployment and integration with a usable system. Under the investigated approaches for ontology engineering, we selected the method of Noy & McGuinness mainly due to our experiences from earlier ontolo- gy development projects. The approach was extended in the development of the Ontology for Trailer Surveillance (OTS) by two more steps. After creating in- stances, the rules for more powerful reasoning need to be formulated, which also provide a consistent knowledge base. Next, the concept of defined classes is ap- plied, 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 summariz- es the analyzed approaches and the reasons why they were not applied in the on- tology development. Table 1: Analyzed Methods for the engineering of OTS Method Name Method Type Reason for including or excluding Uschold&King’s meth- Experience- Evaluation step was not part of the project as- od [4]. based signment TOVE [22]. Experience- Formal specification of important concepts de- based creases the understandability of concepts by stakeholders METHONTOLOGY Evolutive Very detailed and complex for the project pur- [5] pose Noy&McGuinness [20] Evolutive Ease of use and experiences from earlier appli- cations 139 3.2 Practices in Ontology Engineering 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 re- ports 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 im- provement opportunities. [9] develops an ontology based on the guidelines pro- vided by METHONTOLOGY, examines the method utility and addresses the drawbacks. [11] presents results of the practice of ontological engineering without addressing any specific method. [10] reflects experiences from merging different ontology development methods and best practices in software engineering. Finally [12] reports on lessons learned during the development of an ontology using the EXPLODE method for value-added publishing. As a result of these findings we argue the necessity of experience reports in ontology engineering domain. 4 Development of the Ontology for Trailer Surveillance In this section we describe the development of a knowledge base represented by the Ontology for Trailer Surveillance (OTS) for the transportation use case pre- sented 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 Basics of the Ontology for Trailer Surveillance 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 hier- archy, 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 Observa- tion Service (SOS), a standard that allows querying observations, sensor metadata as well as representations of observed features. In this respective, concepts from 140 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 [19]. OTS adopts the situation awareness paradigm, which describes the state of af- fairs by observing the relations between objects or entities, as the relations be- tween subjects constellate various situations [21]. A subject is aware, if he is ca- pable of observing some objects and making inferences from these observations. To represent various situations and the relations between them, Semantic Web Rules Language (SWRL) is used, which provides the ability to add Horn-like rules expressed in terms of OWL concepts [6]. Table 2: Modelling domains and selected approaches Domain Selected Approaches Modelling Rules SWRL Modelling Time Allen´s Model Information Valid Time Model Modelling Sensors and OGC Standards Observations SemSOS Modelling Situations Situation Awareness OWL provides minimal support for modeling the temporal relations as well as temporal information. As a result, ontologies often cannot fully express the tem- poral knowledge needed by applications, users and engineers develop ad hoc solu- tions. OTS adopts Allen’s time intervals algebra that has six basic time intervals constituting a sum of 13 temporal interval relations [17]. On top of this, the valid- time temporal model is applied [18], which represents the time information by providing a lightweight temporal model. The selected approaches as well as their application domains are illustrated in Table 2. 4.2 Application of Noy & McGuinness Approach 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 re- quirements 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. 141 Table 3: Competency questions and their classification Concept Code Abstraction Level Domain-Level Application Level Observation OCQ 1 Which observations are propagated Give me the observations from a feature of interest? which are assessed from a particular trailer instance Sensor SeCQ 1 Which sensors provide the observa- Which sensor instances tions? provide information about the velocity? Event ECQ 3 Which events are captured from the Is trailer 1 in a safe loca- features? tion? Situation SCQ 1 What is the temporal property of a When was the e-seal of particular situation? trailer1 broken? Step 2: Consider reusing existing ontologies. We searched for the existing on- tologies that might be reused, i.e. refined or extended. Unfortunately neither transport domain ontologies nor information models for the truck-trailer surveil- lance domain were identified. Nevertheless the reviewed models were to some ex- tent reusable, e.g. through the models, ontologies and approaches introduced in section 4.1, it was practicable to identify important terms & controlled vocabular- ies (Step 3), to define the classes, class hierarchies as well as the relationships be- tween 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 termi- nology and a common understanding among the users as well. For this purposes, we defined some key concepts in trailer surveillance domain such as Event (con- cepts which are caused by observations [16]), Feature (representation or the ab- straction of the real world entity that exists in physical reality [15]), Observation (act of observing a property [7]), Phenomenon (a physical property that can be ob- served and measured [7]), Sensor (a source producing a value within a value space representing a phenomenon in a given domain of discourse [14]). In this step, we mostly used the approaches that were introduced in section 4.1 alongside with the ontologies that we have searched for reusability purposes. Step 4: Define the classes and the class hierarchy. Important concepts like Ob- servation, Event, Sensor, Situation or Feature are represented as classes. For nam- ing the classes the CamelCase naming convention is applied. The situation classes define and implement the customer services. Hence they are the most im- portant 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 El- ementarySituation class has no direct function in the OTS whereas it might 142 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. Fig. 2. Class hierarchy in OTS 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 infor- mation about the trailers that deliver the goods in particular cities, which are en- tered manually by the trailer or goods owner to the information base. After defin- ing the properties, the Noy & McGuinness Methodology determines the cardinality of the properties, which can be carried out parallel to step 5. Step 7: Create instances, rules and defined classes. This step extends the Noy & McGuinness Methodology by not only creating instances, but also specifying rules and defined classes. The rules are mainly created to provide consistent time repre- sentation 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 con- sistency of the ontology. The defined classes have necessary and sufficient conditions that have a defini- tion. 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 mem- ber of an event class that is created based upon an observation and ii) the observa- tion 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 condi- tions are named as “pattern conditions” since most of the defined classes reuse, extend and build upon them. We argue that identification of such reusable frag- ments are beneficial for the ontology engineer when creating rules and conditions. 143 5 Experiences from Ontology Engineering 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, on- tology reuse and tool selection. Ontology Development Method Developing an ontology is necessarily an iterative process with several interrela- tionships between the process elements. To maintain the overview, relate the out- comes of the different phases of ontology development and to determine the im- provement points method application is required. The ontology engineer should consider the use case requirements to decide which method provides the best sup- port 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 de- veloped 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 low- level questions. Questions with a high-level abstraction can be adapted to various domain ontologies, which conceptualize observation models and they can be re- ferred 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 re- alized 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 ob- served" 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 specif- ic 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 144 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 ex- tensive 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 ontol- ogies 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 se- mantic specifications of the relevant domain, e.g. situations, observations and sen- sors. 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 sig- nificant 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 [18], which is compatible with SWRL and can be queried with SQWRL. However the temporal built-ins re- quired for querying temporal data were not supported in Protégé 4.2. We recom- mend defining the requirements that a tool has to fulfill after formulating the com- petency questions and searching for reusable ontologies. 6 Summary and Future Work Based on an industrial research and development project, the paper describes experiences from an ontology development process for offering innovative ser- vices 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 ser- vices using the ontology. The ontology so far was not constructed as a complete enterprise ontology for the enterprise under consideration but as an application on- 145 tology 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 on- tology parts might be a suitable way to start this development. Furthermore, addi- tional 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. [13]). However, the architecture primari- ly identifies the building blocks of the knowledge base and the interfaces between potential applications and is not presented in this paper due to space limitations. Implementation of new services, like the electronic fence and electronic seal, re- quires additional work. We expect that the development activities also will result in update request for the ontology and insights in adaptation needs in the process. References 1. Sandkuhl, K.; Borchardt, U.; Lantow, B.; Stamer, D.; Wißotzki, M. (2012) Towards Adaptive Business Models for Intelligent Information Logistics in Transportation. In: Perspectives in Business Informatics Research - 11th International Conference, BIR 2012, Nizhny Novgorod, Russia, September 24-26, 2012. Satellite Workshop & Doc- toral Consortium Proceedings. 2. Smirnov, A.; Sandkuhl, K.; Shilov, N. (2013): Multilevel self-organisation of cyber- physical networks: synergic approach. In International Journal Integrated Supply Ma- nagement 8 (1/2/3), pp. 90–106. 3. Corcho, Ó.; Fernández-López, M.; Gómez-Pérez, A. Methodologies, tools and lan- guages for building ontologies: Where is their meeting point? Data Knowledge Engi- neering, 46(1):41–64, 2003. 4. Uschold, M.; King, M. (1995). Towards a methodology for building ontologies. Arti- ficial Intelligence Applications Institute, University of Edinburgh, Edinburgh. 5. Lopez, F.M.; Perez, A.G. and Juristo, N. (1997) Methontology: from ontological art towards ontological engineering. In Proceedings of the AAAI97 Spring Symposium, pages 33–40, Stanford and USA. 6. O’connor M, Knublauch H, Tu SW et al. (2005) Writing rules for the semantic web using SWRL and Jess. Protégé With Rules WS, Madrid. 7. Cox, S. (2013) Geographic information — Observations and measurements V2.0. OGC Abstract Specification. http://portal.opengeospatial.org/files/?artifact_id=41579. Accessed 10 July 2015 8. Falbo, R.A. (2004) Experiences in Using a Method for Building Domain Ontologies. In: 16th International Conference on Software Engineering and Knowledge Engineer- ing (SEKE 2004), International Workshop on Ontology in Action (OIA 2004), Alber- ta, Canada, pp 474–477 9. Park, J.; Sung, K.; Moon, S. (2008) Developing Graduation Screen Ontology Based on the METHONTOLOGY Approach. In: Networked Computing and Advanced Infor- 146 mation Management, 2008. NCM ’08. Fourth International Conference on, vol 2, pp 375–380 10. Brusa, G.; Caliusco, M.L. and Chiotti, O. (2006) A Process for Building a Domain Ontology: An Experience in Developing a Government Budgetary Ontology. In: Pro- ceedings of the Second Australasian Workshop on Advances in Ontologies - Volume 72. Australian Computer Society, Inc, Darlinghurst, Australia, pp 7–15 11. Mizoguchi, R. (2001) Ontological Engineering: Foundation of the Next Generation Knowledge Processing. In: Web Intelligence: Research and Development, vol 2198. Springer Berlin Heidelberg, pp 44–57 12. Hristozova M.; Sterling L. (2003) Experiences with ontology development for value- added publishing. In: Proceedings of the 3rd Workshop on Ontologies in Agent Sys- tems (W11 OAS 2003), held in conjunction with the 2nd International Conference on Autonomous Agents and Multi-Agent Systems (AAMAS 2003). International Founda- tion for Autonomous Agents and Multiagent Systems, pp 17–24 13. Sandkuhl, K. (2013) Pattern Use in Knowledge Architectures: An Example from In- formation Logistics. Proceedings 12th International Conference on Perspectives in Business Informatics Research, Warsaw, Poland, September 23-25, 2013. LNBIP 158, pp. 91-103, Springer. 14. Neuhaus, H.; Compton, M. (2009) The Semantic Sensor Network Ontology: A Gener- ic Language to Describe Sensor Assets, AGILE 2009 Pre-Conference Workshop Chal- lenges in Geospatial Data Harmonisation, 02 June 2009, Hannover, Germany. 15. Probst, F. (2007) Semantic Reference Systems for Observations and Measurements. PhD, University of Münster 16. Yau, S.S.; Liu, J. (2006) Hierarchical Situation Modeling and Reasoning for Pervasive Computing. In: Proceedings of the The Fourth IEEE Workshop on Software Technol- ogies for Future Embedded and Ubiquitous Systems, and the Second International Workshop on Collaborative Computing, Integration, and Assurance (SEUS- WCCIA’06). IEEE Computer Society, Washington, DC, USA, pp 5–10 17. Hemalatha, M.; Uma, V. and Aghila, G. (2012) Time ontology with Reference Event based Temporal Relations (RETR). International Journal of Web & Semantic Tech- nology 3(1) 18. O’Connor, M.; Das, A. (2011) A Method for Representing and Querying Temporal In- formation in OWL. In: Biomedical Engineering Systems and Technologies, vol 127. Springer Berlin Heidelberg, pp 97–110 19. Henson, C.A.; Pschorr, J.K.; Sheth, A.P. et al. (2009) SemSOS: Semantic Sensor Ob- servation Service. In: Proceedings of the 2009 International Symposium on Collabora- tive Technologies and Systems. IEEE Computer Society, Washington, USA, pp 44–53 20. Noy F. N.; McGuinness, D.L. (2000) Ontology development 101: A guide to creating your first ontology. Development, 32(1):1–25, 2000. 21. Kokar, M.M.; Matheus, C.J. and Baclawski, K. (2009) Ontology-based Situation Awareness. Inf. Fusion 10(1): 83–98. 22. Fox M (1992) The TOVE project towards a common-sense model of the enterprise. In: Industrial and Engineering Applications of Artificial Intelligence and Expert Systems, vol 604. Springer Berlin Heidelberg, pp 25-34 147