Ontology-based approach for context modeling in enterprise applications

G Model

COMIND-2600; No. of Pages 14 Computers in Industry xxx (2014) xxx–xxx

Contents lists available at ScienceDirect

Computers in Industry journal homepage: www.elsevier.com/locate/compind

Ontology-based approach for context modeling in enterprise applications Drazˇen Nadoveza *, Dimitris Kiritsis E´cole Polytechnique Fe´de´rale de Lausanne, Laboratory for Computer-Aided Design and Production, STI-IGM-LICP, Station 9, CH-1015 Lausanne, Vaud, Switzerland

A R T I C L E I N F O

A B S T R A C T

Article history: Received 17 December 2013 Received in revised form 17 June 2014 Accepted 11 July 2014 Available online xxx

Today, enterprise applications provide large amounts of data and finding the right information on time for a given purpose is often a challenge. In these environments, users do not know what information is important, why it is important and finally, how to find this important information. Therefore, an enterprise application has to decide which information is relevant in certain a situation for certain a user. In order to accomplish that, the context of the information must be taken to account. Moreover, this application must be able to capture the context of the application user as well as the overall business context which describes the situation in which information is relevant. In this paper we propose an ontology-based context model which captures the general concepts about user and business context. Also, we discuss the challenges for context reasoning and interpreting and we present a case study to demonstrate the benefits of the developed concepts. ß 2014 Elsevier B.V. All rights reserved.

Keywords: Context modeling User context Business context Ontology engineering Software engineering

1. Introduction Over the past years, reliance on enterprise applications for providing and storing information has grown rapidly. These applications are becoming increasingly more complex and are going to be used eventually on any number of devices, from mobile smart phones to industrial computer networks. Thus, to increase their efficiency and electiveness, applications will need to be made aware of the context they are being used in, in order to automatically adapt to it. Sandkuhl [1] states that in today’s information society, information is considered as an important production factor in addition to capital, human resources and material. Furthermore, the task of finding the right information to support a work task, a business decision, or a cooperation process is often very difficult. Some studies revealed that 39% of all business executives spend more than 2 h per day in searching for the right information [2]. This proves that the main challenge is no longer to guarantee the existence of much needed information, but rather to find and provide the right information [1,3].

* Corresponding author. E-mail addresses: drazen.nadoveza@epfl.ch (D. Nadoveza), dimitris.kiritsis@epfl.ch (D. Kiritsis).

The motivation for this work lays in the fact that in certain situations not all information provided by an information system is important and relevant to the end user. Modern enterprise information systems provide huge amounts of information and in these large volumes very often the user cannot identify appropriate and important information at the right time. Moreover, in complex business environments users may not be fully aware of the current situation which in turn can negatively influence the decision making process. So, it is very important to provide the appropriate information to the user considering the respective situation. However, even if the user is provided with this information, the problem is not essentially solved. The user also has to understand why the provided information is important which means that he/she has to comprehend the current situation or to be aware of the context in which this situation happened. In this way, the user is able to fully understand the real meaning of the information. Therefore, it has become crucial for enterprise applications to be aware of the context they are being used in. Nowadays, enterprise applications collect and store various kinds of data and information. This data describes users as well as the various aspects of business. This means that if properly interpreted, this data could be used to describe the overall user and business context. However this is no easy task as context data is subject to constant change and can be highly heterogeneous. This paper proposes an approach to solve these problems by providing an ontology-based context model and rules for its

http://dx.doi.org/10.1016/j.compind.2014.07.007 0166-3615/ß 2014 Elsevier B.V. All rights reserved.

Please cite this article in press as: D. Nadoveza, D. Kiritsis, Ontology-based approach for context modeling in enterprise applications, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.07.007

G Model

COMIND-2600; No. of Pages 14 2

D. Nadoveza, D. Kiritsis / Computers in Industry xxx (2014) xxx–xxx

interpretation. This model will classify with the help of OWL-built ontologies the context of the users (the employees of a business who are accessing the system) and the context of the business. The user and business context will allow for an enterprise application to anticipate which information is important and relevant in order to serve it to the appropriate user. Since the solution utilizes contextual information and provides information and services according to it, the proposed approach could thus be characterized as ‘‘context-aware’’. This paper reviews the notion of context as well as various methods for context modeling and proposes an approach for context modeling in enterprise applications. After the introduction section the formal definitions of context are discussed. The requirements that any context model must meet are presented in Section 2 as well as the review of the context modeling methods with special focus on the ontology based modeling in Section 3. Section 4 gives an overview of the proposed approach for the context interpretation and the context ontology is introduced and presented together with the outstanding features of the approach. Finally, a case study based on the industrial scenario is presented in Section 5.

2. Context definition The meaning of the term context had an evolution toward a larger acceptance and now the meaning generally accepted is that context is the set of circumstances that frames an event or an object [4]. Context is increasingly being used in various disciplines like psychology, especially since the emergence of situated cognition theories [5], those theories considering cognition in its natural context [6]. However, it is difficult to find a relevant satisfying definition for every discipline. Some approaches emerge in Artificial Intelligence ([4,7]). In his work on formalization of context, McCarthy [8] pointed out the difficulty in computer science of modeling context because context possesses an infinite dimension. Furthermore, he addresses the difficulty in translating contextual assessment that has been conducted in the psychological or philosophical realm into formal computational logic. Parker et al. [9] emphasize the necessity when considering context to also consider the human ability to analyze the context of a situation and rank the different stimuli of the outside environment. Bazire and Bre´zillon [4] analyzed a corpus of 166 definitions of context found in a number of domains and came to the conclusion that context can be derived from anything that is significant in a given moment including the environment, an item within that environment, a user, or even an observer [9]. Even though context is a difficult concept to grasp and define, a widely accepted general definition is as follows: Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves. [10] Another widely accepted definition of context is given by Bre´zillon and Pomerol and it says that context is: That which constrains something without intervening in it explicitly. [11] These definitions outline two different notions related to context: information about the relation of an entity vis-a-vis its situation and using this information to help an application complete its task. However, Zimmerman [12] states that this definition is too formal and universal and missing an important operational part. Indeed, the type of information needed to define

the entity-situation relation is not defined in the above definition but is required for any pragmatic approach to context modeling. The authors of [12] propose the following five categories of context information: individuality, activity, location, time and relations. Considering the origin of the context information, it can be retrieved from internal and/or external sources. Internal context is represented by data and information that comes from the system, such as system state, events that happen etc. On the other hand, external context is represented with information coming from outside the system, such as device type, location etc. Some authors have classified context depending on the way data is captured into three groups: physical context, virtual context and logical context. Physical context is represented with data coming from physical sensors such as GPS devices, light sensors etc. Virtual context is based on information coming from software applications or services. For example the position of the user can be determined by browsing his electronic calendar, emails etc. Finally, logical context is derived from information coming from various information sources. It combines information both from physical and virtual sensors [13]. Although most authors refer to abstract context sources, the mainly used and tested sources currently are physical sensors. Virtual and logical sensors are capable of providing useful context data as well and this will be incorporated in this research [13]. 3. Context modeling As shown in the previous section, context information can be obtained in a wide range of forms. Thus, efficient and effective means of modeling the information are needed. One of the biggest problems in the existing solutions is the variety of the used context models as well as the different ways to find and access the context sources. Every system and framework uses its own format to describe context and its own communications mechanisms to access it. Standardized formats in this domain however are crucial for the enhancement of context-aware systems to shift the focus from the communication between context sources and users to the development of valuable context services. Before moving on to the state of the art of context modelling, the requirements that these models must meet are given. A context model must meet the following requirements as defined in [14]:  Applicability. A context model should be able to be used for many different applications entered around a single task. This requirement entails that context models must be flexible in the way they can complete a given task, due to the fact that context data is heterogeneous.  Information analysis. Context information, as already stated, can be of many different types, since it is extracted from a multitude of sources. The model must be able to compare the information resulting from different measurements. Furthermore, the model must be able to determine the source of information and how it has previously been processed. This requirement is known as traceability. Finally, acquired data from multiple sources may be incomplete or contradict itself, resulting in the need for methods for resolving such issues.  History. Any context model must provide a means of storing and accessing past information. Indeed past information can be useful to make predictions that may be valuable for present decisions.  Inference. The information acquired from devices such as sensors is only raw data, also known as low-order context. A context model is required to able to apply reasoning on loworder context data in order to obtain high-order context on which to base decisions.

Please cite this article in press as: D. Nadoveza, D. Kiritsis, Ontology-based approach for context modeling in enterprise applications, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.07.007

G Model

COMIND-2600; No. of Pages 14 D. Nadoveza, D. Kiritsis / Computers in Industry xxx (2014) xxx–xxx

In the literature there exists a variety of context modeling techniques. The main methods are first presented briefly. The ontology-based context modeling approach are separately presented last and in more depth as it possesses key advantages.  Key-value models. Simple and easy to manage, key-value context models are based on a list of attributes that are assigned values describing the application’s environment ([15,16]). However this method clearly lacks efficient means of meeting the aforementioned requirements such as quality control, analyzing relationships and inferring higher-order context [16].  Markup scheme models. This category of context models uses markup languages such as XML and even RDF(S) to develop hierarchical data structures [15]. These types of models can be seen as an enhancement of key-value models as they group related key-value pairs under specific markup tags and provide basic reasoning methods [16]. However they still possess the same limitations as key-value models.  Graphical models. Graphical modeling techniques use diagrams with explicit symbols to help map out the relationships and interactions between objects belonging to the domain being modeled [15]. The graphical aspect of these methods possesses the advantage of being easier for humans to understand and implement.  Logic-based models. Logic-based models use simple abstract mathematical rules that give the ability to derive and conclude new facts after reasoning of a set of known facts [15].  Object oriented models. These types of models try to use object oriented programming techniques to describe context. Such techniques used are encapsulation (hiding and grouping variables inside classes) and inheritance (hierarchy of classes with property inheritance) [15].

3.1. Ontology-based models Ontologies are, in the general sense of the term, a set of concepts and relationships used to describe a particular domain of knowledge. In other words they provide the vocabulary for a domain. The above modeling techniques possess distinct methods of modeling context. Due to their varying approaches, they each meet different requirements as described earlier. However, none of them are able to meet all of the requirements in a satisfactory manner. On the other hand ontology-based models are particularly promising due the fact that they possess the potential to meet most, if not all, of the previously described requirements. The main point exposed is that ontological models use simple description logic languages to build complex models. Ontology models are known for the following advantages for context modeling:  Due to the fact that they are based on simple yet flexible description languages, they have a high expressive power [17]. This is important for context modeling, as context data can evolve and be heterogeneous.  They possess a high degree of formality, facilitating knowledge sharing of heterogeneous context data [16]. Indeed they provide predefined classes, properties and rules that provide a formal basis on which to create new classes and properties for specific context domains.  Reusability is also an important advantage of ontology models. Indeed, [18] demonstrates the use of generic and reusable upper ontologies such as CONON [18] or CoDAMoS [19] on top of which one can create unique and domain-specific ontologies.

3

 Finally, the formal rules provided provide logical reasoning mechanisms. This allows, as already stated, for inference of new information based on lower-order raw data as well as to evaluate context by checking for consistency, compatibility, incompleteness and ambiguity ([14,18]). Thus, we see that being based on description logics, ontology modeling is well-suited for describing context. However they do possess notable disadvantages:  Ontology based models are computationally expensive for complex context domains [16]. Indeed these domains demand extensive computational effort to maintain decidability, so much so that languages such as OWL-DL (a widely used subset of OWL) have reduced the number of provided classes and properties, thus favoring ensured decidability over expressive power.  They are not well adapted for modeling temporal descriptions of context as little support is provided in this respect [16]. Despite these problems, ontology-based context models remain the current best hope for developing context-aware applications. Considerable research is being made into developing ontologies specifically designed for context descriptions, generally by extending existing basic ontology languages such as OWL [20]. Such ontologies include CONON [18], CoDAMoS [19] and SOUPA [21] ontologies that define new classes related to applications that interact with humans. There are many more of these new ontologies being developed, but most of them rely on a common vocabulary base, in order for them to remain interoperable [14]. This last point is very important as there will probably never be a single solution due to the large number of requirements. Instead, integrated ontologies working together may be needed depending on the type of tasks an application will be used for [16]. However, most of the current available context models are applied in pervasive and ubiquitous computing and are meant to capture only the low level physical context. Context models for complex enterprise applications which are able to describe the context in which an enterprise application has to provide its services are not being addressed in the research community so far. Also, since a significant amount of information that can be considered as context is already available in the various industrial systems, the utilization of virtual and logical context could greatly improve the usability of the enterprise applications without investing a lot of resources in a new information infrastructure. 4. Proposed approach for context-aware systems 4.1. Concept overview In order to have context-aware services, the most important aspect of the application is to be able to acquire context information and then to model it in a way that can be properly interpreted and managed. As mentioned previously, context information has to satisfy different requirements such as: applicability, history, inference, analysis. But beside these functional requirements, one of the most important properties of context is that it is dynamic and thus context information is dynamic too. This corresponds to the fact that the context information volume is always increasing, which is especially highlighted in dynamic enterprise environments. In order to correctly model context information, various application domains in which a model could be applied should be taken into account. This basically means that it is necessary to provide a generic model which can be used in various application domains and use-cases. Having a generic model provides the

Please cite this article in press as: D. Nadoveza, D. Kiritsis, Ontology-based approach for context modeling in enterprise applications, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.07.007

G Model

COMIND-2600; No. of Pages 14 4

D. Nadoveza, D. Kiritsis / Computers in Industry xxx (2014) xxx–xxx

distinct advantages of easy context information exchange as well as reusability of the model. On the other hand, it significantly reduces the expressiveness of the model and requires more computing to interpret it. Therefore, this approach proposes the upper model (ontology) which specifies only the common and generic concepts of context and supports context information exchange. However, it is not possible to model different domains only with the upper model, which means that for each case, a domain specific model should be specified. This domain specific model should extend the generic upper model and describe the specific domain in more detail. One of the advantages of the proposed solution is that it supports the reuse of already existing models using them as domain specific ontology and linking them with the upper ontology. The use of this approach encompasses the interoperability benefits from the upper ontology and the expressiveness from the domain specific ontology. But what exactly could be considered as context information in an enterprise application? Since, according to Dey, context could be any information which can characterize the situation of an entity [10], it is necessary to identify what kind of context information is available to describe the situation of an entity, where an entity is the information which is of relevance to the end user. Furthermore, Bre´zillon’s and Pomerol’s definition [11] implies that context should help determine (constrain) the information relevance but not change the information’s meaning. Therefore, since the information is to be provided to the user, logically it depends on the user which consumes that information, in a way that it has to satisfy his needs taking into account both his personal and business situation. However, this is not enough since the application also has to be aware of the current state of the business which means that the final information depends on what is going on in the enterprise or so to say, to be aware of the overall business situation. Finally, the information which has to be served to the user also depends on itself, which means that it depends on its content. It is important to note that the most of this information already exists in the modern enterprise applications, such as ERP, MES, etc. Today, these systems cover different aspects of the enterprise and integrate various tools and applications which generate a large volume of information which can certainly be considered as context. But how could this context information can be used? The proposed approach is based on the three major steps illustrated in Fig. 1, which are necessary to execute/pass in order to deliver the relevant information to the end user. The first step is actually to capture and pick the information which is considered as context model with an ontology. This context could be considered as low order context and it is usually information which is already available in the system or coming from physical sensors (e.g. location). This information (sometimes even the location of the user) is usually gathered by the so called virtual sensors. This step allows for further context information interpretation as well as exchange of context information between different applications. Since the low order context could come in large volumes and can change very quickly, sometimes it can be very difficult to

Fig. 1. Steps for context interpretation.

interpret it and use it directly. Therefore the intermediate step is added in which the low order context is interpreted as user and business states. Basically in this step the context information is discretized and made more convenient (and less dynamical) for further usage. The low order context is transformed into the so called higher order context which is more suitable for further rulebased interpretation. This transformation, or state assessment, is done using predefined rules. Also, it is important to note that some user and business states could be directly imported from different external or internal sources (e.g. some web agents). Finally, states are used in the last step to define the current situation and according to it, provide the appropriate information to the end user. Situation is considered to be a set of currently active business and/or user states. Again rules are used to interpret the situation and select appropriate information which should satisfy the end. 4.2. Proposed context model This section gives an overview or the proposed context ontology for modeling context in enterprise applications. As previously stated, formalization and generalization of all context information would be an impossible task, but some general concepts are fundamental for describing the situation in which an application is executed. These general concepts are modeled as an upper ontology and provide the basis for further domain-specific context model extensions. The upper ontology describes general concepts like space, matter, object, event and action while domain ontologies specify the vocabulary and properties related to a generic domain or a generic task by specializing the terms introduced in the upper ontology. Different enterprise applications and different use-cases presume different context models which could be described with domain-specific extensions of the upper-level context ontology. The core of the proposed concept is the upper context ontology which should be able to describe any situation, in which context, certain information provided by the information system is relevant. Due to the nature of enterprise applications and the information which they provide, the upper ontology has been separated in three parts (sub-models). As illustrated in Fig. 2 the upper context ontology’ three interconnected sub-models are: (a) user context, (b) business context and (c) information feature model [13]. The user context model captures all the information concerning the end user which is accessing the system. That information varies from the simple user’s name and role, or the device which he used to access the system, to the business activities he is currently involved in. The business context model captures the current state of the business and must be able to define the overall business situation. It captures various ongoing, past and future business activities as well as the relevant events which have occurred during some business activity or by using some business resources. And lastly, information

Fig. 2. Conceptual context model.

Please cite this article in press as: D. Nadoveza, D. Kiritsis, Ontology-based approach for context modeling in enterprise applications, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.07.007

G Model

COMIND-2600; No. of Pages 14 D. Nadoveza, D. Kiritsis / Computers in Industry xxx (2014) xxx–xxx

5

features can be considered as basic information providers in the information systems; they can be GUI widgets as well as simple data queries. Therefore, the Information feature model has to be able to define the nature of the application feature as well as the information which it provides. Most of the existing context ontologies generically model different context variables. These models lacks of expressivity and the significant efforts should be made for the interpretation of it. Furthermore, mostly they focus on the user context, while business context, as a concept described in this work, doesn’t exist. Lastly, most of the systems utilizes only the physical context (coming from physical sensors) while virtual context, coming from the existing data, is neglected. 4.3. Upper ontology One of the key requirements an ontology-based context model must respect is applicability [16]. Thus we define what is called an upper ontology infrastructure, as a generic set of classes and property relations which can be used in different applications and domains. The model of the upper ontology is composed of multiple classes and subclasses and is based on the conceptual model found in [13]. Fig. 3 shows the basic concepts of this ontology which model the context as well as the information features to be presented to the end user. The main class is the ContextEntity class which abstracts all information which could be considered as context. ContextEntity is specialized by two subclasses, the UserContext and BusinessContext classes. The InformationFeature class represents all business information that users would wish to access. It doesn’t represent specific information but rather it specifies the type of information, the entities to which it refers as well as the way to retrieve it. Moreover, it could be said that Information Features represent the basic information providers of an information system. Typically these are GUI components such as widgets, data tables, UI forms etc., but this approach also considers other information providers such as data queries, information aggregators such as KPIs, data calculators etc. It is assumed that each information system has a predefined number of information features which can be described with our model during design-time. We differentiate between two basic types of information features [13]:  Non-parameterized information features: Very simple information providers which always serve the same information. A typical example is gauge, which shows to the user the temperature of the shop floor.  Parameterized information features: Information providers which serve information depending on the parameters which are passed to it. For example, this can be a widget which shows to the user information about a specific business activity, where the activity ID is a parameter. 4.4. User context ontology User context represents the various entities and concepts which are considered as relevant for describing the current user situation and its interaction with the system. It captures the information

Fig. 4. UserContext class and subclasses.

about the user identity, his physical location as well as his interaction with the other users. Furthermore, the user’s position in the business, his/her involvement in the business activities as well as his/her responsibilities and preferences could be considered as user context. Of course, this information depends on the type of application, domain and business organization of the enterprise. Regarding the origin of this information, it usually already exists in the systems with the exception of the physical location and accessing device. In the user context ontology, every information which describes user’s context is represented with the super class UserContext and it is directly inherited from the ContextEntity class. Figs. 4 and 5 illustrate the class hierarchy of the User context ontology and the following text briefly specifies the most important concepts, relations and properties.  User. This class contains the individuals that are accessing the system in order to obtain information features. It is the core of the UserContext class, since all the other classes are related to it through object property relations shown in Fig. 5. Indeed all other subclasses of ContextEntity exist in order to describe the context of a given user.  User status. This class groups the information regarding a user’s work statusand consists of two subclasses: UserWorking and UserNotWorking.  Location. The location of the user is also an important part of his context. A user’s location can be absolute (spatial coordinates) or relative (conference room, production floor, etc.) and thus two subclasses are defined: AbsoluteLocation and RelativeLocation.  Role. A user’s role represents his position in a business’ hierarchyand determines which Information Features he/she has access to. This is done through the Permission class and the has Permission object property.  Access device. The access device is the device (PC, Machine terminal, tablet, phone, etc.) the user is using to access the system.  Area of responsibility or AOR represents a set of different business activities and resources for which a user is responsible for.  Area of interests or AOI class represents user preferences for specific Information Features. AOI’s are updated manually by the user.

4.5. Business context ontology

Fig. 3. Upper ontology.

Business context represents the various entities and concepts which are considered as relevant for describing the current

Please cite this article in press as: D. Nadoveza, D. Kiritsis, Ontology-based approach for context modeling in enterprise applications, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.07.007

G Model

COMIND-2600; No. of Pages 14 6

D. Nadoveza, D. Kiritsis / Computers in Industry xxx (2014) xxx–xxx

Fig. 5. User class and its object property relationships.

business situation. It captures all the information which are necessary to describe what is currently going on in the business. Basically the business context could be defined with three basic information: information about current, past and future business activities; information about the resources used/consumed/ produced during these activities and; information about expected or unexpected events which occurred. Depending on the enterprise application, this information might be directly retrieved from the system or imported from external sources or even specified by a user. Furthermore, business context is very domain dependent, which means that different business domains require further specialization of the concepts from the upper ontology. The business context ontology is represented with the super class BusinessContext which is directly inherited from the ContextEntity class. The class hierarchy of the BusinessContext as well as the most important concepts, relations and properties are shown in Figs. 6 and 7 and described in the following text.  Business activity. This class describes the past, current, and future activities of a business. Like the user class described before, the BusinessActivity class is at the core of the BusinessContext class. Indeed as shown in Fig. 7 the other subclasses are related to it via object properties.  Activity status. This class describes the status (ongoing, cancelled, etc.) of any given business activity.  Activity result. It defines the final result of a business activity.  Business resource. In general, a business activity requires a given resource (e.g. a machine or a person) in order to be completed.  Business event. The above classes of the business context model are simple and general concepts that will not always be of particular interest to any user. However the BusinessEvent class describes events that are more user-orientated, as they describe

sudden changes in the system that can be of direct interest to users.

4.6. From low-order context to higher-order context: Inferring the business and user states Up to this point, the described UserContext and BusinessContext provide a means of classifying and relating through properties data that is either provided by the application itself or manually updated by the user. This data can be viewed as being low-order context data. However, in any real implementation of these models this would not suffice due to the dynamic nature of context and the specificity of different domains. Indeed one must remember that these business and context models are just a general upper ontology and that they will be completed during implementation with specific domain ontology. The simple concepts described before could be specialized with multiple classes, sometimes containing a hundred or even a thousand individuals. Therefore, even with the provided context data, getting the right information to the right user at the right time might be still too difficult. Due to these problems, a further concept is required: the business and user states. The purpose of these two concepts is to discretize the low order context data and to provide the very essence of business and user context information in a more simple and accessible manner. Thus two new concepts are defined named UserState and BusinessState, which specify the predefined states (or descriptions). In order to assess these states, SWRL [22] rules have to be specified by an appropriate expert. When certain individuals of the low-order context models have certain properties, then the appropriate state will be activated through an SWRL rule. Hence both the BusinessState and UserState classes specify states depending on the situation of the user context and business context. The final step would be to implement rules stating that if certain business states and user states are currently activated, then the particular user would be interested in specific information features. One can thus see that the concept of states allows filtering the complex and dynamic low-order context information in order to obtain short and easily usable descriptions of what is currently going on inside a business. Fig. 8 gives an overview of this process. Furthermore, these descriptions can also be used as valuable information to describe the actual situation to the end user. 4.7. Putting the information in the context—Explaining the situation to a user

Fig. 6. BusinessContext class and subclasses.

Up to now, this paper has mostly addressed the problems of modeling the context and providing the appropriate information to the end user. However, in order to efficiently consume the provided information, it is essential that the user also understands it. More specifically, it means that he/she has to know why certain information is important for him/her. Isolated information out of

Please cite this article in press as: D. Nadoveza, D. Kiritsis, Ontology-based approach for context modeling in enterprise applications, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.07.007

G Model

COMIND-2600; No. of Pages 14 D. Nadoveza, D. Kiritsis / Computers in Industry xxx (2014) xxx–xxx

7

Fig. 7. BusinessActivity class and its object property relationships.

context doesn’t mean anything to the user. It could lead to ambiguity and to thus be wrongly interpreted which could further lead to wrong decisions. Moreover, a lot of users would not even consider the recommended information if they did not understand the context or situation in which it is relevant. Therefore the system has to be able to put back the information in the original context in order to explain the current situation to the user. The outstanding capabilities of ontologies and the completeness of the model allow doing it smoothly and without a lot of processing. One way to do this is ‘‘unwinding the rules’’, which means to process all the axioms which were inferred by the reasoner in order to specify the relevant information feature. Basically, all the inferred axioms have to be parsed in natural language as a way to form a valid explanation. The other and more elegant way is to annotate the states and use those descriptions in order to explain the situation since it is defined as a set of currently active states.

5. Case study The upper ontology model already described is a generic model intended for wide applicability. However, when implemented this model has to be extended for a specific domain with the definition of new classes, properties and relevancy rules. This section will now discuss an example of such an implementation. The chosen test case is that of a manufacturer of bottled juice drinks. This case is inspired by the PLANTCockpit project and the use-case of the one of the industrial partners involved [23]. It consists of different business activities necessary to complete the order-to-delivery process and provide the ordered goods to the customer right on time and with adequate quality. The business activities workflow of the test case is illustrated in Fig. 9. The manufacturing plant first receives purchase orders from customers. The processing step is the actual production of the drinks. Then a quality control takes place before filling the drinks into bottles. The bottles are then transported inside the plant to the

Fig. 8. User and business states usage for the information features selection.

Please cite this article in press as: D. Nadoveza, D. Kiritsis, Ontology-based approach for context modeling in enterprise applications, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.07.007

G Model

COMIND-2600; No. of Pages 14 8

D. Nadoveza, D. Kiritsis / Computers in Industry xxx (2014) xxx–xxx

Fig. 9. Business activities workflow of a manufacturer of bottled juice drinks.

loading docks where they await external transport to their final destination for delivery. Each of these steps is described by information features in the form of orders (e.g. Process order, Filling order, etc.). These orders contain very vital information such as start and end times, resources to be used for task completion, etc. The problems arise when the manufacturer receives up to a 100 customer orders a day. For each customer order received, subsequent orders from processing to delivery have to be created by the employees of the production planning department. It is inevitable in any manufacturing business that deviations will arise, resulting in the need for active searches toward finding a solution. This requires today an active search in different data sources and linking disparate data; a process which is very time consuming and mostly performed when delays have already occurred and is thus too late to find a solution. For example, such deviations can occur when raw materials or semi-final products are not provided at the right time to the production line. The reasons for these issuescan vary: problems/delays in production orders, problems in the logistical chain inside the plant, delays on transports from external suppliers, productions in time but with insufficient quality, etc. The Information concerning the delays in the procurement and transport of these raw materials and semi-final products today is not automatically redirected to the appropriate person and as a result, valuable time is lost in order to find alternative raw materials and/or reschedule production and filling process orders. In the current situation of the manufacturer in question, the production planners have to manually sort through the various orders in a process that is highly time consuming and may result in

solutions that are usually discovered too late. Thus, the objective is to apply the upper ontology described in Section 4 and extend it for the manufacturer in question in order for the system to provide the appropriate information features to the right employees automatically when production deviations arise. 5.1. Extending the upper ontology In order to illustrate the practical usage of the proposed concepts, the upper ontology is extended with the domain ontology which corresponds with the chosen test case. It is important to note that some of the concepts are simplified and adapted in order to perform faster prototyping and at the same time demonstrate the proposed concepts. The case study is completely implemented in the Prote´ge´ [24] ontology editor and ERP data from the manufacturer is simulated. In the following text the domain specific extensions for the upper ontology will be presented as well as the usage examples based on two test scenarios. 5.1.1. Business resources In this test case, it is the manufacturing resources that are of main interest. However, it must be noted that a company will have of course other resources such as financial, material and research resources. As shown in Fig. 10, the BusinessResource class of the upper ontology has been specialized with multiple classes. The production resources of interest were considered to be part of the Swiss manufacturing plant of the company. The SwissPlant class contains a ProductionLine subclass containing four individuals: two filling lines and two processing lines.

Fig. 10. BusinessResource subclasses and individuals implemented for this scenario.

Please cite this article in press as: D. Nadoveza, D. Kiritsis, Ontology-based approach for context modeling in enterprise applications, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.07.007

G Model

COMIND-2600; No. of Pages 14 D. Nadoveza, D. Kiritsis / Computers in Industry xxx (2014) xxx–xxx

9

Fig. 11. BusinessActivity subclasses and individuals implemented for this scenario.

5.1.2. Business activities The BusinessActivities class of the upper ontology was specialized with four activity subclasses for processing, quality control, filling and transportation. For each subclass one individual (e.g. Filling1) was created (Fig. 11). In order to identify that all these individuals are in fact the different activity stages for one single customer order, they were all given one same Product ID attribute through a newly defined hasProductID object property. The concept of the product ID was implemented to facilitate the writing of SWRL rules concerning the status of the different activities. However, one must understand that this concept is only a workaround to the fact that in the current version of Prote´ge´, there exists no means of inferring new individuals, meaning that all individuals must be created manually. Nevertheless, in a real implementation of the model, this drawback would not exist as the context model would be created with a more complete means than a ontology editor like Prote´ge´. Thus when an activity for a certain customer ends, the next activity corresponding to that customer order would automatically be created. 5.1.3. Business events The BusinessEvents class was also specified with various types of events and alarms for the various stages of production. Therefore,

there are events and alarms which describe different situations concerning the processing, filling, transporting, etc (Fig. 12). 5.1.4. Activity status Various simple activity statuses like Completed and Ongoing were implemented as shown in Fig. 13. 5.1.5. Information features The information features implemented for this business scenario are business objects of the manufacturer’s ERP that describe the various stages of production:  Purchase order: Incoming message from a customer in various forms (email, phone call, fax etc.) which is a starting point to enter a customer order in the system.  Customer order: It describes all information from the purchase order into the ERP system and carries the ‘‘demand’’ from the customer.  Process order: Description of all information concerning production process.  Filling order: Description of all information concerning the filling.  Inspection lot: Collection of all reference information for the bulk, after the quality inspection.

Fig. 12. BusinessEvents subclasses and individuals implemented for this scenario.

Please cite this article in press as: D. Nadoveza, D. Kiritsis, Ontology-based approach for context modeling in enterprise applications, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.07.007

G Model

COMIND-2600; No. of Pages 14 10

D. Nadoveza, D. Kiritsis / Computers in Industry xxx (2014) xxx–xxx

Fig. 13. ActivityStatus subclasses and individuals implemented for this scenario.

 Internal transportation order: It describes all information concerning transportation within the plant (conveyor belt, forklifts).  Transportation order: It describes all actual outgoing transportation info from the external transportation company. Includes all delivery information (what, when, where, to whom, etc.).  Delivery: Description enclosing all outgoing delivery info: what (+ quantity) to deliver, to whom (customer), where (address) and when (delivery date) etc. The resulting class hierarchy is shown in Fig. 14. An order was created for each stage of production (e.g. ProcessOrder1). These orders describe the production activities for the same product, illustrated in Fig. 11, and thus also have the same Product ID. 5.1.6. User roles For this test case seven users are created with different roles in the company:

 Two filling line managers: Each operator is responsible for his filling line and is interested in all ongoing activities concerning his line. These users were implemented as individuals of the User class and each given a role through the performs object property, illustrated in the diagram of Fig. 15. For the purpose of demonstration, some basic logic rules were written concerning the Plant employee hierarchy. Indeed with each role, one can automatically infer a user’s superiors, peers and subordinates using SWRL statements combined with isSuperiorOf, isPeerTo, isSubordinateOf object properties provided by the upper ontology. Later, it will be shown how this information could be used in the test case. An example of such a rule statement is the following:

Performs ð?u1;  A plant manager: Responsible for the whole plant and interested in the overall performance.  A processing line manager: Responsible for the two processing lines A and B of the plant. He is interested only in the deviations of the planned processing.  A filling line manager: Responsible for the two filling lines A and B of the plant. He is interested only in the deviations of the planned filling.  Two processing line operators: Each operator responsible for his processing line and is interested in all ongoing activities concerning his line.

?rÞ; performs ð?u2; ?rÞ ! isPeerTo ð?u1; ?u2Þ

Stating that if two users u1 and u2 have the same role r then they are peers. Similar rules were written for the isSuperiorOf and isSubordinateOf properties. An example of the inferred information for the plant manager is shown in Fig. 16, taken from Prote´ge´. 5.1.7. User locations and access devices The Location class was extended with some simple subclasses and individuals reflecting various locations of the production plant (Fig. 17). Only the RelativeLocation subclass was extended as the AbsoluteLocation subclass would have been too complicated and

Fig. 14. InformationFeatures subclasses and individuals implemented for this scenario.

Please cite this article in press as: D. Nadoveza, D. Kiritsis, Ontology-based approach for context modeling in enterprise applications, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.07.007

G Model

COMIND-2600; No. of Pages 14 D. Nadoveza, D. Kiritsis / Computers in Industry xxx (2014) xxx–xxx

11

Fig. 15. User class populated with the different individuals, each performing a role.

5.1.8. User status The upper ontology also provided the UserStatus class for determining whether or not the user is working. Various statuses were implemented such as UserOnVacation and UserOnBreak (Fig. 19).

Fig. 16. From the simple statement that the user performs the PlantManager role, his situation in the plant employee hierarchy is inferred (yellow property assertions). (For interpretation of the references to color in this figure legend, the reader is referred to the web version of this article.)

not very interesting to implement (it would have required some sort of positioning device like GPS). Some simple SWRL rules were again implemented giving the ability to infer the relative location of a user based on which access device is being used. An example of such a rule statement is the following: accessedWithð?u; ProcessingLineBTerminalÞ 1 isLocatedInð?u; ProcessingFloorÞ Stating that if the user u accessed the system from the ProcessingLineBTerminal then the user u is located in the ProcessingFloor. The various access devices implemented are shown in Fig. 18. Of course other means of determining the position exist such as employees using access cards to enter various zones of the plant.

5.1.9. Assessing business and user states to select relevant information features The previous section focused on describing the various extensions brought to the upper ontology. As shown, the upper ontology grew into a more complex model with a number of new subclasses and individuals. One must remember that the business scenario in question has been simplified and that in any real implementation the domain context model would be far greater. A business might have over a hundred customer orders per day, resulting in as many production orders. The number of business activities, resources and users would also be very high. Thus we see the need to use business and user states to help describe in a more succinct manner what is happening at any given moment in the business. This section focuses on demonstrating through several tests how predefined business and user states can be activated and how these states can be used to select the relevant Information Features for various users. Some simple examples of business states that were defined as individuals of the BusinessState class are as follows:  ProcessingOngoingAsPlanned.  ProcessingOngoingBehindSchedule.  AbnormalFillingState.

Fig. 17. Location subclasses and individuals implemented for this scenario.

Please cite this article in press as: D. Nadoveza, D. Kiritsis, Ontology-based approach for context modeling in enterprise applications, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.07.007

G Model

COMIND-2600; No. of Pages 14 12

D. Nadoveza, D. Kiritsis / Computers in Industry xxx (2014) xxx–xxx

Fig. 18. AccessDevice subclasses and individuals implemented for this scenario.

Fig. 19. UserStatus subclasses and individuals implemented for this scenario.

 BadQualityState. Also the following states are some examples of user states implemented:  UserWorking.  UserNotWorking.

5.1.10. Test 1: Processing behind schedule In this test, the status processing activity Processing1 was set to OngoingBehindSchedule, as shown in Fig. 20. With the following rule the corresponding business state was activated: ProcessingActivityð?pÞ; hasStatusð?p; OngoingBehindScheduleÞ; describedByð?p;?oÞ ! activateBusinessStateðProcessingOngoingBehindSchedule; trueÞ; isRelevantð?o; ProcessingOngoingBehindScheduleÞ

This rule states that if any processing activity p has a current status set to OngoingBehindSchedule and is described by an Information Feature order o, then the corresponding business state is activated (set to boolean value true) through the object property activateBusinessState. Furthermore this rule will make the system infer that the Information Feature order o is relevant to this activated business state. The result is shown in Fig. 21. As we can see in yellow, the state is inferred to be activated. Finally, we want the processing line manager to be informed of the fact that there is a processing activity which is behind schedule. This is done through the following relevancy rule:

activateBusinessState ðProcessingOngoingBehindSchedule; trueÞ; describedByðProcessingOngoingBehindSchedule;?oÞ; BusinessActivityð?aÞ; usesð?a;?rÞ; describedByð?a;?oÞ; hasStateð?u; UserWorkingÞ; isResponsibleForð?u;?rÞ; performsð?u; LineManagerÞ ! isInterestedInð?u;?oÞ This rule basically states that if the business state ProcessingOngoingBehindSchedule is activated and described by a certain business order o, then the user whose state is UserWorking and who is responsible for the resource being used for the activity that is

Fig. 20. Prote´ge´ property assertions and inferred information (in yellow) about Processing1 activity. (For interpretation of the references to color in this figure legend, the reader is referred to the web version of this article.)

Fig. 21. Inferred information (in yellow) about business state ProcessingOngoingBehindSchedule. (For interpretation of the references to color in this figure legend, the reader is referred to the web version of this article.)

Please cite this article in press as: D. Nadoveza, D. Kiritsis, Ontology-based approach for context modeling in enterprise applications, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.07.007

G Model

COMIND-2600; No. of Pages 14 D. Nadoveza, D. Kiritsis / Computers in Industry xxx (2014) xxx–xxx

Fig. 22. Inferred information (in yellow) about the Processing Line Manager. (For interpretation of the references to color in this figure legend, the reader is referred to the web version of this article.)

behind schedule is interested in the order o. In this case, the user in question is the processing line manager. As we can see from Fig. 22, he is indeed inferred to be interested in such order (ProcessingOrder1). Furthermore, we can ask the system why it deems the processing line manager interested in ProcessOrder1. The result of this query in Prote´ge´ is shown in Fig. 23. The figure shows all the steps the system took in order to infer the final result. The explanation as we can see is complicated as it shows all the steps undertaken, some of which are not very interesting. However, in a real implementation of the model, a user friendly interface would be developed. For example, one could imagine that the processing line manager would receive on his desktop computer or business smartphone a notification. He would then open it and be shown the relevant information feature along with succinct and easy to understand explanation as to why the system deemed it necessary for him to be notified. 5.1.11. Test 2: Filling alarm and line manager on vacation In this test a FillingAlarm event arises on the ongoing business activity Filling1. However, the filling line manager is currently on vacation. The goal is to see if the system is able to understand this context and alert the filling line manager’s peer. Since the first test was described in detail, the current test description will be more succinct. The main relevancy rule that is used to accomplish the desired result is as follows: activateBusinessStateðFillingAlarm; trueÞ; describedByðFillingAlarm;?oÞ; BusinessActivityð?aÞ; describedByð?a;?oÞ; usesð?a;?rÞ; hasStateð?u1; UserNotWorkingÞ; performsð?u1; LineManagerÞ; isResponsibleForð?u1; ?rÞ; hasStateð?u2; UserWorkingÞ; isPeerToð?u1; ?u2Þ ! isInterestedInð?u2; ?oÞ

13

Fig. 24. Inferred information (in yellow) about the Processing line manager. (For interpretation of the references to color in this figure legend, the reader is referred to the web version of this article.)

The rule basically states that when a FillingAlarm is activated but the person in charge of the activity on which the alarm event is happening is not working, then the system should search for that person’s peer and notify him of the information feature describing the activity that is the source of the alarm. Please note that the criteria for the peer selection in this simple example are the same user role. However, in more complex scenarios and examples, the peer selection and the corresponding rules could be much more complex. The result of this rule in the case of this test should be to notify the processing line manager, as he is the peer of the production line manager. This is indeed the case as is shown in Fig. 24. As in the first test, the processing line manager would be notified through a user interface. He would receive the filling order in question. Since he is not responsible for the filling process, he could for example click on a button Explain and receive an explanation stating that since his colleague is on vacation he is the one to be notified of the alarm. 5.1.12. Final remarks on the tests As we can see, the above model provides a means for notifying with the correct information features the appropriate person based on low-order context information. Of course the tests and domain model are far from complete, but the purpose was to give the reader a sense of what this type of model is capable of achieving. Furthermore, the number and complexity of business and user states would be far greater and more specific. However, we can see that the purpose of such states is to describe in a more succinct manner the business and user contexts. In this way, the writing of relevancy rules is greatly facilitated.

Fig. 23. Explanation given by Prote´ge´ as to why the processing line manager is interested in ProcessOrder1.

Please cite this article in press as: D. Nadoveza, D. Kiritsis, Ontology-based approach for context modeling in enterprise applications, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.07.007

G Model

COMIND-2600; No. of Pages 14 14

D. Nadoveza, D. Kiritsis / Computers in Industry xxx (2014) xxx–xxx

6. Conclusions This work proposed an ontology-based context model as a solution to the problem of getting the right information to the right person in a business environment. The first part of the model presented was the upper ontology model, consisting of an infrastructure of generic classes and properties intended for widespread application in the manufacturing industry. The model was mainly divided into two parts: the description of the user’s context through classes such as his Status, Location and Role, and the description of the business context through such classes as BusinessActivity, ActivityStatus and BusinessResource. The InformationFeatures class was also defined containing the various documents and data a user might be interested in. Furthermore two concepts were added to the model called the UserState and BusinessState classes. These classes provide a means of filtering the context information in order to obtain a simpler and more succinct description of both context entities. Finally it was shown how based on a user’s state and the current state of the business, one could write SWRL relevancy rules in order to determine which information feature is deemed relevant to the user. In this manner, the user no longer has to actively search through large sets of data at the cost of wasting valuable time. Instead, the system recommends and notifies the user automatically of relevant information as well as explains why the provided information is relevant. The second part of this work focused on implementing a domain specific extension of the upper ontology model using the ontology editor Prote´ge´. The simplified business scenario was that of a manufacturer of bottled juice drinks. Once the extended context model was described, two tests were performed in which alarms arose during production. The reader was able to see, using SWRL relevancy rules based on the user and business states, how the system could automatically notify the appropriate user. Furthermore the user in question would have the possibility to ask the system for an explanation as to why he/she is being notified. This is a key advantage of using an ontology-based context model. Indeed, by asking for such an explanation, the user will be presented with the various steps the system took when assessing the business and user states and selecting the appropriate information feature. Thus, this new set of information will be added to that of the information feature notification, thereby increasing the user’s understanding of what is currently going in the business. Therefore the user will be able to make better decisions in less time.

[7] Patrick Bre´zillon, Representation of procedures and practices in contextual graphs, Knowl. Eng. Rev. 18 (2) (2003) 147–174. [8] J. McCarthy, Notes on Formalizing Context, 1993. [9] J.E. Parker, D.L. Hollister, A.J. Gonzalez, P. Bre´zillon, S.T. Parker, Looking for a Synergy between Human and Artificial Cognition, in: Modeling and Using Context, Springer, Berlin, Heidelberg, 2013, pp. 45–58. [10] A. Dey, Understanding and using context, in: Personal and Ubiquitous Computing, 2001 Retrieved from hhttp://dl.acm.org/citation.cfm?id=593572i. [11] P. Bre´zillon, J. Pomerol, Contextual knowledge sharing and cooperation in intelligent assistant systems, in: Le Travail Humain, 1999, pp. 1–33 Retrieved from hhttp://www.jstor.org/stable/10.2307/40660305i. [12] A. Zimmermann, A. Lorenz, R. Oppermann, An operational definition of context, in: Modeling and Using Context, Springer, Berlin, Heidelberg, 2007, pp. 558–571. [13] D. Nadoveza, D. Kiritsis, Concept for context-aware manufacturing dashboard applications, Manufacturing Modelling, Management, and Control, vol. 7, 2013. [14] R. Krummenacher, T. Strang, Ontology-based context modeling, in: Proceedings Third Workshop on Context, 2007, hRetrieved from http://elib.dlr.de/47459/01/ CAPS07CameraReadyVersion.pdfi. [15] T. Strang, C. Linnhoff-Popien, A context modeling survey, in: Workshop Proceedings, 2004, Retrieved from hhttp://elib.dlr.de/7444/i. [16] C. Bettini, O. Brdiczka, K. Henricksen, J. Indulska, D. Nicklas, A. Ranganathan, D. Riboni, A survey of context modelling and reasoning techniques, Pervasive Mob. Comput. 6 (2) (2010) 161–180, doi: 10.1016/j.pmcj.2009.06.002. [17] D. Ejigu, M. Scuturici, L. Brunie, An ontology-based approach to context modeling and reasoning in pervasive computing, in: Fifth Annual IEEE International Conference on Pervasive Computing and Communications Workshops (PerComW’07), 2007, pp. 14–19, doi: 10.1109/PERCOMW.2007.22. [18] X.H. Wang, T. Gu, D.Q. Zhang, H.K. Pung, Ontology based context modeling and reasoning using OWL, in: IEEE Annual Conference on Pervasive Computing and Communications Workshops, 2004. Proceedings of the Second, 2004, pp. 18–22, doi: 10.1109/PERCOMW.2004.1276898. [19] D. Preuveneers, J. Van Den. Bergh, Towards an extensible context ontology for ambient intelligence, in: Ambient Intelligence, 2004, pp. 148–159 Retrieved from hhttp://link.springer.com/chapter/10.1007/978-3-540-30473-9_15i. [20] D.L. McGuinness, F. Van Harmelen, OWL web ontology language overview, W3C Recommendation 10 (10) (2004), 2004. [21] H. Chen, F. Perich, T. Finin, a. Joshi, SOUPA: standard ontology for ubiquitous and pervasive applications, in: The First Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services, MOBIQUITOUS 2004, 2004, pp. 258–267, doi: 10.1109/MOBIQ.2004.1331732. [22] I. Horrocks, P. Patel-Schneider, SWRL: a semantic web rule language combining OWL and RuleML, in: W3C Member . . ., (May), 2004. [23] PLANTCockpit, PLANTCockpit Consortium, PLANTCockpit, 2013. [24] H. Knublauch, R.W. Fergerson, N.F. Noy, M.A. Musen, The Prote´ge´ OWL plugin: an open development environment for semantic web applications, in: The Semantic Web—ISWC 2004, Springer, Berlin, 2004, pp. 229–243. Drazˇen Nadoveza has received his master degree in Applied Computer Science in 2009 from the University of Novi Sad, Serbia. Since 2010 he is working on his Ph.D. thesis in the Laboratory for Computer-Aided Design and Production (LICP) of the Swiss Federal Institute of Technology in Lausanne (EPFL). His major research interests include: context-aware systems, software architectures, Semantic Web, business intelligence, Life-cycle Assesment and Product Lifecycle Management.

References [1] K. Sandkuhl, Information logistics in networked organizations: selected concepts and applications, in: W. Aalst, J. Mylopoulos, N.M. Sadeh, M.J. Shaw, C. Szyperski, J. Filipe, J. Cardoso (Eds.), Enterp. Inf. Syst., 12, 2009, pp. 43–54, Retrieved from hhttp://dx.doi.org/10.1007/978-3-540-88710-2_4i. [2] Delphi Group, Perspectives on Information Retrieval, Delphi Group, Boston, MA, 2002. ¨ . Johnsen, J. Weitzenbo¨ck, S. Brynestad, T. Mestl, Technology Outlook, [3] R. Skjong, O Det Norske Veritas, Norway, 2004p. 109. [4] M. Bazire, P. Bre´zillon, Understanding context before using it, in: A.K. Dey, Boicho Kokinov, D. Leake, R. Turner (Eds.), International Conference on Contexts, 2005, pp. 29–40, Retrieved from hhttp://link.springer.com/chapter/10.1007/ 11508373_3i. [5] W.J. Clancey, No title, in: Situated Cognition: How Representations are Created and Given Meaning, 1998 hRetrieved from http://cogprints.org/661/1/133.htmi. [6] C. Seifert, Situated Cognition and Learning. The MIT Encyclopedia of the Cognitive Sciences, The MIT Press, Cambridge, 1999.

Dimitris Kiritsis is a faculty member at the School of Engineering of EPFL. He has more than eighteen years of research and teaching experience with the LICP Laboratory of EPFL, including initiating and leading international research projects in the domain of closedloop PLM with applications of product embedded information devices, product lifecycle modelling and simulation, ontology based engineering, predictive maintenance and engineering asset management and sustainable manufacturing. Dr. Kiritsis is the initiator and scientific responsible of the FP6 IP 507100 PROMISE. He is currently involved in the FP7 FoF projectLinkedDesign as well as in the FP7 ICT project eSAVE and the FP7 NMP project SuPLight. Dr. Kiritsis was also involved in the FP7 FoF CSA ActionPlanT contributing to the produced roadmap and responsible for the activities on Industrial Learning.

Please cite this article in press as: D. Nadoveza, D. Kiritsis, Ontology-based approach for context modeling in enterprise applications, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.07.007