HAL Id: hal-01217349
https://hal-paris1.archives-ouvertes.fr/hal-01217349
Submitted on 19 Oct 2015
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of
sci-entific research documents, whether they are
pub-lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d’enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
Towards a Generic Context Model for BPM
Oumaima Saidani, Colette Rolland, Selmin Nurcan
To cite this version:
Oumaima Saidani, Colette Rolland, Selmin Nurcan. Towards a Generic Context Model for BPM. 48th
Annual Hawaii International Conference on System Sciences (HICSS’2015), Jan 2015, Kauai, Hawaii„
United States. �10.1109/HICSS.2015.494�. �hal-01217349�
Towards a Generic Context Model for BPM
Oumaima Saidani 11
Université Paris 1 Panthéon-Sorbonne
Centre de Recherche en Informatique, 90, rue de Tolbiac
75634 Paris Cedex 13 France Oumaima.Saidani@univ-paris1.fr
Colette Rolland 1
1
Université Paris 1 Panthéon-Sorbonne
Centre de Recherche en Informatique, 90, rue de Tolbiac
75634 Paris Cedex 13 France Colette.Rolland@univ-paris1.fr
Selmin Nurcan 1 2
2
Sorbonne management School 21, rue Broca 75005 Paris France
Selmin.Nurcan@univ-paris1.fr
Abstract
This paper introduces a new context modeling approach for the business process management field. The proposed approach aims at identifying and formalizing the contextual knowledge relevant to business processes in order to be able to adapt business processes according to the context. This approach has the particularity to be generic and extensible; it can be integrated with many business process modeling approaches. It is based on ontologies and has two layers, i.e. generic layer and specific layer. Throughout the paper we compare the proposed approach with the related work in order to clearly demonstrate why we propose this approach.
1. Introduction
In the current economic, organizational and technological environment, the context in which business processes are executed is constantly changing. The context can be related to the organization, to the actors, etc. This fact requires to define adaptive and context-aware business process engineering approaches. The definition of adaptive and context-aware business process models is of a great interest. However, solutions proposed for this area are limited. Indeed, most existing approaches that address the adaptation of business processes do not take into account the context. Instead, they focus on the intrinsic means of changing the process model and its instances after a need for change is observed. These approaches take into account only the reactive part of the adaptation and ignore stimuli for change, i.e., the context. However, we believe that taking into account this stimuli and its impact on the behavior of process is essential to ensure the adaptation of business processes since Knowledge related to the context is an essential resource for adapting business processes.
Several approaches that stress the importance of supporting the context and dealing with context awareness in the business process engineering have been proposed [24], [25], [26], [2], [27], however, these approaches are insufficient and no appropriate context model for the BPM has been defined. Likewise, research on adaptive business processes focus essentially on mechanisms to capture the variability.
As the context constitutes the proactive part of the business process adaptation, hence it is a stimulus for change that affects the execution of a business process. The major advantage of context-awareness in a business process modeling approach is the ability to use contextual information to adapt the process.
This paper proposes a new approach and a meta-model for the context representation in the field of BPM called: CM4BPM (Context Meta-Model for Business Process Management). Our aim is to be able to identify and to formalize the factors whose variations require changes in the processes execution, i.e. context. The proposed model aims at taking into account contextual factors which are explicitly related to business processes and representing dependency situations on the context.
The remaining part of the paper is organized as follows. In the next section, we present the related works. Section 3 presents a meta-model for the context presentation and details the concepts introduced in the proposed meta-model. We introduce in section 4 a context model which is based on ontologies. Finally, we conclude with section 5.
2. Background and related work
2.1. Context awareness
There are many approaches that deal with context awareness in several areas, such as service
engineering [14], [19], communications [6], [32], ubiquitous computing [34], multimedia [17] and business process engineering [5], [7], [40]. Several definitions of context have been proposed, however, there is no real consensus on the definition of this concept since it is used in many research fields. The context is defined by Chihani et al. [8], [9] as all information intrinsic to an entity, e.g. user, which can be acquired and made explicit in order to enable them to adapt their behavior to the state of the entity. According to Chihani et al. [8], [9] the context is related to facts, to rules and axioms that can be used to describe the state of an entity, e.g. user, device, at a given time. As well, most definitions of context mention the location as an essential element of the context [5].
Winograd [41] highlights that the word context has been adapted from the language field, composed of con (with) and text, refers to the meaning that must be deduced from the adjacent text.
Dey [10], [11], [12] provides the following definition: Context is any information that can be used to characterize the situation of the entities that are considered relevant to the interaction between a user and an application, including the user and the application themselves.
[23] provides four axes of context definition on which most researchers agree:
- There is no context without context: the notion of context should be defined in terms of a purpose. For our part, the objective sought is the adaptation of business processes.
- The context is an information space that serves the interpretation: the capture of the context is not an end in itself, but the data captured must serve a purpose. In our case, the data are interpreted in order to better serve the business actors.
- The context is an information space shared by several actors, e.g. user, system.
- The context is a space of infinite and evolving information: the context is not fixed but is built over time.
The context-awareness is considered as a particular type of formal logic in which theories and artificial intelligence algorithms, e.g. inference rules, can be applied in order to automate the deduction of new contextual information and reasoning on facts about the representative state of the user [8], [9]. It is a field that was initiated in the course of nineties through the work of Schilit and Theimer [30 ] and Schilit et al. [29], These studies define context-awareness as the ability of an application to discover and react to changes in the environment where the user [29]. A system is considered to be context-aware if it is able to collect context information, detect
changes in relevant context, and make an intelligent and automatic adaptation to the current state of the environment [29]. Salbert et al. [28] define the context-awareness as the ability of a system to act in real time with data from the context. Dey et al. [10], [11] consider that a system is context-sensitive if it uses contextual information for providing useful information or services to the user. The value depends on the task of the user.
Moreover, many works use names close to the notion of context awareness such as “adaptive” and “reactive system”.
2.2. Context modeling
The context modeling permits the description and the structuring of the contextual information. Several models are available for different context domains. There is a multitude of classifications that have been proposed for context models based on the data structure used for the description and exchange of context [5], [9] and [13]:
- The Key-value models (or attribute-value [10], [11] and [42]: the context is represented as a pair (attribute, value). The attribute represents the name of the contextual information. The value represents the current value of this information. This method has the advantage of being easily implemented. Indeed, the management of the context consists in browsing the list of available contexts. However, these models lack expressiveness since they do not represent the relationships between contextual information [4], [8], [9]. This method has been used in particular by the first models proposed such as those proposed in [10] and [42].
- The models based on XML [36] and [18]: they use a hierarchical data structure. The depth of this structure depends on the context described.
- The models based on MDA (Model Driven Architecture) [8], [9], graphical models [33]: this modeling approach is used to create high-level models or models which conform to MOF (Meta-Object Facility).
- Graphical models: RDF is a language for describing labeled directed graphs. It is based on triples (subject, predicate, and object). The subject is the resource being described, the predicate is a type of property that can be applied to this resource, and the object represents data or other resource. Each triplet is an oriented arc labeled with the predicate, where the source node is the subject and the destination node is the object. [34] is based on RDF schemas for modeling context.
- Logical models: the context is expressed as a set of facts or rules. The main disadvantage of this type of
modeling is its high level of formalization [13]. This method is used in [1].
- Models based on ontologies: this approach seems to be the most promising; it allows to specify concepts and relationships between different components of the ontology. On the other hand, this method allows to add semantics to contextual elements [13]. Ontologies have been widely used in modeling context e.g. [17], [14].
It seems essential that business processes engineering approaches have a model for the representation of contextual information.
2.3. Context awareness in BPM
There are many approaches that deal with the context awareness in the business process management. These approaches give various definitions of the context. It is defined in [35] as the set of circumstances in which a business process can be used. According to Born et al. [7], the context defines the environment in which a business process is used. They define the business context as a description of a specific business circumstance. Rosemann et al. [24], [25] define context as the minimum set of variables containing all relevant information impacting the design and the implementation of a business process.
In BPM, the contextual information can be classified into several categories reflecting the nature of the information observed and treated. Rosemann et al. [24], [25] propose a categorization of contextual information using the concept of layer: (i) the immediate context which includes those elements that go beyond the constructs that constitute the pure control flow, and covers those elements that directly facilitate the execution of a process, (ii) the internal context which covers information on the internal environment of an organization that impacts the business process, (iii) the external context which captures elements that are part of an even wider system whose design and behavior is beyond the control sphere of an organization, and (iv) the environmental context which resides beyond the business network in which the organization is embedded but nevertheless poses a contingency effect on the business processes. It captures the overall environment as a system with comprehensive boundaries. Balabko et al. [2] distinguish two types of contextual information, i.e. the state and the behavior of a role. UN / CEFACT [35] introduced the concept of business context and specifies it as a group of eight categories of context : (i) the context of the business process: it is the description of the business process, the business activity, e.g. purchase,
or the business partnership, e.g. interaction between partners to achieve a goal, (ii) the context related to the products: it includes various types of information about products or services used by a business process, e.g. goods, (iii) the context related to markets: it characterizes a given business sector, business partners, (iv) the geopolitical context: it includes the geographical, the political or the cultural influence on the business process, (v) the context related to formal constraints: it represents the legal or government restrictions, (vi) the context related roles: it concerns information on the actors of a business process, (vii) the context related to support roles: it concerns information related to non-partner roles, e.g. data required by a third party shipper, and (viii) the context related to the system capacity: it captures the limitations of the systems. Born et al. [7] propose a context meta-model for classifying the contextual information into categories of context. The authors give examples of categories, e.g. industry, geography, period, but do not define a fixed set of categories. In [7], each class of context refers to several context values. Furthermore, Saidani et al. [27] propose a taxonomy for categorizing contextual information which includes four types of contextual information : (i) the context related to the location, (ii) the context related to time, (iii) the context related to resources - material and human -, e.g. age, and (iv) the context related to the organization, e.g. organizational structure.
3. The proposed context meta-model
In this section, we introduce the different concepts used to describe the contextual information and the relationships between them. Figure 1 shows the CM4BPM meta-model. We present in light gray color the concepts that are not belonging to the context meta-model, but which are related to the meta-model concepts. As the figure shows, the context meta-model is independent from any process meta-model. The two meta-models are related through the class Business process component (BPC) that belongs to a business process meta-model and Contextual situation which belongs to the proposed context meta-model. A business process component is a general concept which represents a part of the business process model, i.e. an activity, a sub-process, a task, a sub-sub-process, etc. This relationship expresses the fact that a business process component cannot be executed unless one or more contextual conditions are met. It also expresses the influence of the context on the selection of the adequate business process component during the adaptation.
Figure 1.The proposed context meta-model
The concepts of the proposed meta-model are described in the following:
- Context entity: the context is structured using the concept of Context entity. This concept represents a part of the contextual information. Examples of context entities are: Actor, Environment and Process. This concept is similar to that of context entity defined by Wang et al. [38], [39]. Context entities are of two kinds: context attributes and contextual relationships.
- Context attribute: each context entity is represented by a set of context attributes. A context attribute is a measurable atomic characteristic which makes explicit contextual information. For example, the Actor entity can be characterized by the following context attributes: Availability, Experience.
- Contextual relationship: the context entities are connected together by contextual relationships. For instance, the context entity Actor is linked to the context entity Location by means of the contextual relationship Is located at.
- Context element: this concept allows to characterize a context entity that can be a context attribute or a contextual relationship. A context element may be relevant to one or more goals of the process. For example, the context element Actor availability is relevant to the goal Manage loan request.
Context elements are of two kinds: static or dynamic. A context element is static if its value is fixed, e.g. Date of birth. A context element is dynamic if its value can change dynamically, e.g. Date, or vary, e.g. Location of an actor. Table 1 shows a partial definition of the context entities and the context attributes; it gives the value type and the method of capture of each context attribute.
- Method of capture: the method of capture specifies how the value of a context element is determined. The measurement can be done by logical or physical sensors, e.g. GPS, electronic agenda, RFID, etc. The value of the context element can be deduced from the values of other elements using inference rules which are defined simultaneously with the definition of the
context model. The method of capture can be implicit for context element values which are obtained for instance by the access to the information system or to the electronic agenda. The method of capture can also be explicit if the values of the context element are provided explicitly.
- Contextual situation: a contextual situation is defined by one or more context elements with the associated values. The following table gives some examples of entities and context attributes that can characterize these entities according to the business domain. We specify in the table the value type of each attribute and the associated methods of capture.
Table 1. Partial definition of entities and context attributes
Context entity
Context
attributes Value type Method of capture
Actor Availability Boolean {Implicit (access to an electronic agenda, access to the information system (IS)), Explicit} Experience Boolean {Deduced, Explicit, Implicit (access to the IS)} Organizatio
nal unit Structure String
{Explicit, Implicit (access to the IS)}
Resource
Availability Boolean
{Explicit, Deduced, Implicit (access to the IS)}
Sharing Boolean {Explicit, access to
the IS }
Goal Satisfaction
state Boolean
{Explicit, Implicit (access to the IS)}
Process
Duration Time {Explicit, Implicit
(access to the IS)}
Deadline Time {Explicit, Implicit
(access to the IS)} Functional entity (task, …) Nature Enum {mandatory, optional} {Explicit, Implicit (access to the IS)}
Time
Date Date
{Implicit (access to the IS), Explicit, Deduced}
Hour Hour {Implicit (access to
the IS), Explicit}
Location
Zip code Integer
{Explicit, Implicit (access to the IS), Deduced}
City String
{Explicit, Deduced, Implicit (access to the IS)}
4. A context ontology for BPM
Many studies evaluate different methods of context modeling [5], [8], [8], [13] and [31] show
that ontology-based models have a greater expressiveness and meet better the requirements and the goals of the context modeling. These studies justify the use of ontologies by the following reasons: - An ontology allows the knowledge sharing in a distributed system.
- An ontology includes declarative semantics allowing the development of reasoning on contextual information.
- With an explicit representation of a common ontology, the interoperability of applications is ensured.
Moreover in [17] a set of needs and goals related to the context ontology design are defined which are: - The simplicity: the terms used and the relationship should be as simple as possible in order to facilitate the developers’ work.
- The flexibility and the scalability: the ontology should support the simple addition of contextual elements and new relationships.
- Genericity: ontology should not be limited to a particular type of context, but rather take into account different types of context.
- Expressiveness: the ontology must allow describing the context in detail.
For all these reasons, we chose to adopt a model which is based on ontologies in order to provide a simple, flexible and expressive context model which facilitates sharing knowledge and making reasoning on contextual information, in particular to deduce new contextual information from provided ones.
In this section, we introduce a context model which is an instance of the meta-model introduced in the previous section. The proposed context model is based on ontologies and has then the particularity to be generic and extensible. Thus the contextual information can be structured and stored using the proposed model.
The nature of the contextual information is related to the business domain, e.g. information systems engineering, BPM, ubiquitous computing, etc. For the BPM field, we consider contextual information all information reflecting changing circumstances and having an impact on the business process design and execution. The activity duration, the actor experience, the resource availability, time and place, are examples of relevant contextual information for the BPM field.
We distinguish two types of contextual information:
- Contextual information which are independent of business domain and business processes, e.g. the actor availability, the process execution duration. - Contextual information which are dependent of the domain or of the business process. For instance, in a
loan handling business process, the significance of a loan request can be considered as a contextual information that is relevant to the business process.
Figure 2. The two levels of the proposed context model
As well, some types of contextual information may be common to many business areas (e.g. location of an actor) while others are specific to a given domain, or organization(s). We believe that engineering approach adaptable business processes must be able to consider different types of contextual information independently of the business domain,
process and organization and should not be limited to information context relevant to one area and not relevant to other areas.
Most approaches that support context awareness and provide a categorization and / or modeling contextual information consider contextual information independently of business processes [25], [26], [27], [28].
We propose to model the contextual information similarly to [39], on two levels:
- A generic level that is independent from the business domain and the business processes. This level will be expressed with an upper ontology. - A level that is specific to the business domain and to the business processes. This level will be expressed with domain specific ontologies.
The proposed separation into a generic level and a specific level ensures, on the one hand, the flexibility in the definition of the contextual information which is specific to a given business domain, and on the other, the reuse of general concepts.
In the following, we begin by describing the generic level of the proposed model, and then we describe the domain specific level.
4.1. The upper context ontology - Context
model of generic level
The upper ontology represents the generic level and describes the general characteristics of the context entities that are common to all business areas. Our goal is to define a context model for BPM, we have identified a minimum set of context entities, e.g. environment, and context elements, e.g. is located at (see Figure 2), that we consider to be relevant to all business processes and business fields. We have identified the context elements that are related to the actor, to the process, to resources and to the business environment that seem essential for the representation of the context in BPM. Context entities and context elements that we suggest can be extended according to the business needs of the organization. Figure 2 shows the upper ontology that defines the set of concepts currently used in business processes including for instance the following context entities: Actor, Organization, Process, etc. Each of these context entities is associated with contextual relationships allowing to express its relationships with the other context entities.
We have identified the following main context entities for the upper ontology:
- Process. It includes the contextual factors that may characterize a business process such as the performance time.
- Environment. It includes the contextual factors that characterize the process runtime environment such as the spatial and the temporal factors.
- Goal. It includes contextual factors related to the business process goals and to their satisfaction. For example: Goal satisfaction.
- Organizational entity. It is used to represent the contextual factors characterizing the organization such as the characteristics of the actor workplace, the type of the organizational structure, e.g. hierarchical structure, transversal structure.
- Actor. It represents the contextual factors related to the actor, such as personal characteristics, e.g. the age, the location, as well as the characteristics in relationship to the actor work, e.g. the participation, the mobility, the tasks he is trying to achieve). Other factors reflecting the relationship between the actors can characterize the Actor entity, such as the collaboration and the communication quality. - Resource. It includes the characteristics of business objects, such as the availability of a resource.
- Functional entity. A functional entity represents the characteristics of functions, activities, tasks and sub-processes that compose the process, such as task duration or documentation.
4.2. Domain specific context ontologies -
Specific context model
Context ontologies specific to business domain define the details of general concepts and their characteristics in specific business fields and according to the application needs. For example, in a process of academic domain, the location entity can be characterized by the region attribute. The time entity may be characterized by the semester attribute. Moreover, in a hotel reservation management process, the time entity can be characterized by the season attribute.
Contextual information represented by an ontology specific to domain are information that are recognized by the analyst or the business engineer as having an impact on the business process model, and whose values are not necessarily constant and may vary throughout the business process life cycle. The following table gives examples of context elements characterizing the level specific to domain to a management loan applications process.
We emphasize that it is not possible to enumerate exhaustively the entire relevant context element and this even in a particular business domain. In our approach, contextual data can be collected using several methods. They can be explicitly collected from actors, for example through questionnaires or
by observing the working methods and the actor behavior. They can also be inferred from other contextual information using inference rules. Figure 3 shows the partial definition of the ontology specific to the business domain “Loan request management”. In addition to the generic entities defined in the upper ontology, a set of context entities is defined to model the characteristics specific to this field.
Figure 3. Partial definition of the domain specific context ontology
4.3. Expressions of the context model with
OWL language
OWL (Web Ontology Language) [38] is one of the languages most widely used for the expression of ontologies [16]. The large number of available tools for defining, processing, interpretation and interrogation of OWL justify the great popularity of
this language. We show in this section the possibility to express the proposed context model with OWL.
For the upper ontology, entities of the proposed model are represented with OWL abstract classes. Regarding domain specific ontologies, they can extend the abstract classes by subclasses. A class hierarchy is defined. The constructor “subClassOf” allows structuring entities into a hierarchy of classes and subclasses in order to extend the upper ontology with new concepts specific to the domain.
Attributes are represented in OWL using properties: DatatypeProperty. The DatatypeProperty property is a relationship between a value or a data and a class instance; this is the equivalent of a table field and a relational database. Contextual relationships are represented by properties in OWL with ObjectProperty properties type. ObjectProperty property is defined between two individuals of a class or several OWL classes. Each of them is associated with a set of properties.
Table 2. Capture methods
Context element Type Capture methods
Actor availability Logic {Explicit, electronic agenda access}
Actor experience Logic Deduced
Actor recency Logic Explicit
Loan application importance
Logic Deduced
Loan amount Logic IS access
Completeness request Logic {Explicit, IS access} Application loan state Logic {IS access, Process trace}
4.4. Reasoning on the context
Reasoning on the context consists in using contextual information in an intelligent way by using techniques of interpretation and knowledge inference. It is clear that a business process engineering approach that supports context-awareness process approach must have methods of reasoning to interpret contextual information and derive new knowledge from other. Reasoning about the context can be (i) "user-defined": the user defines explicit reasoning rules, or (ii) "implicit", e.g. ontological reasoning based on rules on classes and properties of an ontology. Some contextual information can be deduced, explicitly or implicitly, from other less abstract knowledge.
4.4.1. User-defined reasoning
.
The reasoning defined by the user is a flexible reasoning way that allows the user to define explicitly reasoning rules for deriving high-level contextual information (abstract)from those of low level (concrete). These rules can be defined in logic (first-order or propositional). Consider the example of the context attribute “Passenger affluence”, its value can be deduced from the value of the attribute “Number of passengers”. This requires defining, explicitly, a reasoning rule specifying for example that if the number of passengers exceeds a certain number, the passenger affluence can be considered important. The use of abstract contextual information is motivated by the following facts:
- Some contextual information need to be refined in other information to enable their measurement. - In the business process analysis phase, the reasoning is usually made in qualitative terms. In fact, business analysts use qualitative expressions in order to describe the contextual information.
We propose to use inference rules to perform the reasoning in order to deduce contextual information and to define new contextual information. We give in the following two examples of inference rules explicitly defined by the user:
<LoanRequestAmount <10000> →
<LoanImportance = No> (1) <ActorRecency <5> → <ActorExperience = No> (2)
The inference rule (1) allows deducing the value of context element “Loan request significance” from the value of the context element “AmountLoanRequest”. Thus, if the value of the loan request amount is less than 10000, then the loan application is not considered as significant.
4.4.2. Ontological reasoning. There is a set of rules on the classes and the properties of an ontology allowing making inferences. For example: symmetry, equivalence and transitivity. For example, in the example of the context ontology described in the previous section, we have defined the contextual relationship “is localized at” between two individuals of the same context entity (class) “Location” or two individuals entities (classes) “Location and actor and Location”. Accordingly, knowing that an actor Dupont is currently localized at his office number 315, which is part of the PMF local, inference rules can be used to infer that the actor Dupont is localized at PMF, since the relationship “is located at” is transitive. Table IV illustrates the reasoning rules used, the explicit contextual information and the implicit contextual information (deduced).
4.4.3. Reasoning expression with rule language. We propose to use the SWRL rule language (Semantic Web Rule Language) [15]. This is an ontology language integrating a rule language
(OWL-DL (Web Ontology Language) and (RuleML-Rule Markup Language). SWRL allows the instance manipulation with variables (? X? Y,? Z). SWRL rules are constructed according to this scheme: history result. Antecedent is a conjunction of atoms and consequent is a single atom.
The following rule expresses Rule 1 defined in the previous section by SWRL language:
lower (? x1, 10000) ∧ HasAmount (? x2,? x1) ⇒ Ordinary (? x2)
(3)
In this example, lower (? X1, 10000) ∧ HasAmount (? X2,? X1) represents the antecedent, ordinary (? X2) represents the consequent.
Table 3. Ontology based reasoning
OWL reasoning rules (?P rdf:type owl:TransitiveProperty) ∧ (?A ?P ?B) ∧ (?B ?P ?C) ⇒ (?A ?P ?C) (?P owl:inverseOf ?Q) ∧ (?X ?P ?Y) ⇒ (?Y ?Q ?X) INPUT Explicit contextual information <owl:ObjectProperty rdf:ID="est -localise-a"> <rdf:type="owlTransitiveProperty"/> <owl:inverseOf rdf:resource="#contains"/> </owl:ObjectProperty> <Acteur rdf:ID="Dupont"> <locatedIn rdf:resource="#Bureau315"/> </Acteur > < Bureau rdf:ID="Bureau315"> < locatedIn rdf:resource="#PMF"/> </ Bureau> OUTP UT Explicit contextual information <Acteur rdf:ID="Dupont"> <locatedIn rdf:resource="#PMF"/> </Acteur > <Building rdf:ID="PMF"> < contains rdf:resource="#Bureau315"/> < contains rdf:resource="#Dupont"/> </Building> <Bureau rdf:ID="Bureau315"> < contains rdf:resource="#Dupont"/> </Bureau>
5. Conclusion
We have presented in this paper a novel approach for context modeling for the field of BPM. We have introduced CM4BPM: a meta- model for the representation of the context which can represent the contextual information on two levels based on:
- a context model level expressed by a generic ontology upper context.
- a model for specific context expressed by domain specific ontologies allowing to define general concepts in specific areas of business.
We have also shown the possibility to express the context model available with OWL. Capture contextual data and reasoning about the context are also discussed in this paper.
Furthermore, we have discussed the limits of the current approaches that deal with the context awareness in the field of business process management. Although the contextualization and the adaptation issues are discussed bravely in this paper, they will be developed in details in our future works. In our future works we will develop adequate strategies for the adaptation of business process models. These strategies are based on a set of operators and rules of adaptation allowing to derive process models from an initial process model. The selection mechanisms will rely on techniques derived from the decision-making field. We will also develop a substantial case study in order to further demonstrate the full expressiveness of our model. We will also propose in our future work a support tool for our approach which will cover the process management, the adaptation and the context management.
10. References
[1] Aucher, G., Grossi, D., Herzig, A., Lorini, E., "Dynamic Context Logic”, Proceedings of the Second International Workshop, LORI, Chongqing, China, 2009. [2] Balabko, P., and Wegmann, A., “Context Based Reasoning in Business Process Models”, Las Vegas, USA. IEEE Information Reuse and Integration, 2003.
[3] Balabko, P., Wegmann, A., Ruppen, A., Clément, N., “The Value of Roles in Modeling Business Processes”, CAiSE Workshops (2), 2004, pp. 207-214.
[4] Baldauf, M., “A survey on context-aware systems”, International Journal Ad Hoc and Ubiquitous Computing, Vol. 2, No. 4, 2007.
[5] Bettini, C., Brdiczka, O., Henricksen, K., Indulska, J., Nicklas, D., Ranganathan, A., Riboni, D., “A survey of context modelling and reasoning techniques. Pervasive and Mobile Computing”, 6(2):161–180, 2010.
[6] Blum, N., Lampe, S., Magedanz, T., “Enabling context-sensitive communication experiences”, in Proceedings of the 14th International Conference on Intelligence in Next Generation Networks (ICIN’10), Berlin, Germany, 2010.
[7] Born, M., Kirchner, J., Muller, J. P., “Context-driven Business Process Modelling”, The 1st International Workshop on Managing Data with Mobile Devices (MDMD 2009), Milan, Italy, 6 - 10, May 2009.
[8] Chihani, B., Bertin, E., Jeanne, F., “Context-Aware Systems: A Case Study”, Digital Information and Communication Technology and Its Applications, Communications in Computer and Information Science, Volume 167, 2011, pp 718-732.
[9] Chihani, B., Bertin, Suprapto, I.S., Zimmermann, J., Crespi, N., “Enhancing Existing Communication Services with Context Awareness”, Journal of Computer Networks and Communications, Volume 2012.
[10] Dey, A. K., Abowd, D. G., “Towards a better understanding of context and context awareness”, In Computer Human Interactions Workshop on the What, Who, Where and How of Context Awarness, 2000. [11] Dey, A. K., “Understanding and Using Context”, Personal and Ubiquitous computing, Springer Verlag, vol. 5, n° 1, 2001.
[12] Dey, A.K., Salber, D., Abowd, G.D., “A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications. Special issue on context-aware computing in the Human-Computer Interaction (HCI) Journal, Volume 16 (2-4), 2001.
[13] Ferry, N., Lavirotte, S., Rey, G., Tigli, J., "Adaptation Dynamique d'Applications au Contexte en Informatique Ambiante", Research Report I3S (Université de Nice - Sophia Antipolis / CNRS), number I3S/RR-2008-20-FR, Sophia Antipolis, France, 2008.
[14] Han, S.N., Lee, G., Lee, G., Crespi, N., “Semantic Context-aware Service Composition for Building Automation System”, IEEE Transactions on Industrial Informatics, Vol: PP, no. 99, March 2013.
[15] [Horrocks et al. 04] Horrocks, I., Patel-Schneider, P.F., Boley, H., Tabet, S., Grosof, B., Dean M., “SWRL: A Semantic Web Rule Language Combining OWL and RuleML”, W3C Member Submission 21 May 2004. [16] Jacob, C., Pfeffer, H., Steglich, S., “Employing Context Information and Semantics to Advance Responsiveness in Service Composition”, Context-Aware Mobile and Ubiquitous Computing for Enhanced Usability: Adaptive Technologies and Applications. IGI Global, 2009. [17] Kim, J.D., Son, J., Baik, D.K., “CA5W1H onto: ontological context-aware model based on 5W1H,” International Journal of Distributed Sensor Networks, vol. 2012, Article ID 247346, 11 pages, 2012.
[18] Knappmeyer, M., Kiani, S.L., Fra, C., Moltchanov, B., Baker, N., “ContextML: A light-weight context representation and context management schema”. 5th IEEE
International Symposium on Wireless Pervasive Computing (ISWPC), Modena, Italy, 2010.
[19] Mehra, P., “Context-aware computing : beyond search and location-based services,” IEEE Internet Computing, vol. 16, no. 2, 2012.
[20] Petit, M., "L'informatique contextuelle", technical report, South Britany University (UBS), Vannes, 2005.
[21] Ploesser, K., Recker, J., Rosemann, M., "Supporting Context-Aware Process Design: Learnings from a Design Science Study“. Business Process Management Workshops 2010, 2010, pp. 97-104.
[22] Ploesser, K., Recker, J., Rosemann, M., "Challenges in the context-aware management of business processes: a multiple case study", 19th European Conference on Information Systems (ECIS), Helsinki, Finland, 2011. [23] Rey, G., Coutaz, J., "Le Contexteur : une abstraction logicielle pour la réalisation de systèmes interactifs sensibles au contexte", In Proceedings of Interaction Homme Machine, 2003, pp. 105-112.
[24] Rosemann, M., and Recker, J., “Context-aware Process Design Exploring the Extrinsic Drivers for Process Flexibility”, 7th Workshop on Business Process Modeling, Development, and Support, Luxembourg, 2006.
[25] Rosemann, M., Recker, J., Flender, C., Ansell, P., “Context-awareness in business process design”. 17th Australasian Conference on Information Systems, Adelaide, Australia. 2006.
[26] Rosemann, M., Jan C., R., Christian, F., “Contextualisation of business processes”, International Journal of Business Process Integration and Management 3(1), 2008, pp. 47-60.
[27] Saidani, O, Nurcan, S., “Towards Context-Aware Business Process Modelling”, The 8th Workshop on Business Process Modelling, Development, and Support (BPMDS'07), Trondheim, Norway, June, 2007.
[28] Salber, D., Dey, K. A., Abowd, D. G., “Ubiquitous Computing: Defining an HCI research agenda for an emerging interaction paradigm”, In Georgia Tech GVU technical report. 1998.
[29] Schilit, B.N., Adams, N., Want, R., “Context-Aware Computing Applications”, Proceedings of the IEEE Workshop on Mobile Computing Systems and Applications, Santa Cruz, USA, 1994.
[30] Schilit, B.N., Theimer, M.M., “Disseminating active map information to mobile hosts”. IEEE Network, vol. 8, n°5, septembre/octobre 1994, pages 22-32.
[31] Strang, T., Linnhoff-Popien, C., “A context modeling survey”. Workshop on Advanced Context Modelling, reasoning and Management, Ubicomp, 2004.
[32] Toutain, F., Bouabdallah, A., Zemek, R., Daloz, C., “Interpersonal context-aware communication services”, IEEE Communications Magazine, vol. 49, no.1, pp. 68–74, 2011.
[33] Truong, H.L., Dustdar, S., Corlosquet, S., Dorn, C., Giuliani, G., Peray, S., Polleres, A., Reiff-Marganiec, S., Schall, D., Tilly, M., “inContext: A Pervasive and Collaborative Working Environment for Emerging Team Forms”. In International Symposium on Applications and the Internet, SAINT'08. Turku, FINLAND, 2008.
[34] Tusch, R., Jakab, M., K¨opke, J., et al., “Context-aware UPnP-AV services for adaptive home multimedia systems”, International Journal of Digital Multimedia Broadcasting, vol. 2008, Article ID 835438, 2008.
[35] United Nations Centre for Trade Facilitation and Electronic Business: Core components technical specification - part 8 of the ebXML framework, 2003. [36] Venezia, C., Lamorte, L., “Pervasive ICT Social Aware Services enablers”. 14th International Conference on Intelligence in Next Generation Networks (ICIN). Berlin, Germany, 2010.
[37] OWL Web Ontology Language Overview, W3C
Recommendation 10 February 2004,
http://www.w3.org/TR/owl-features/.
[38] Wang, X. H., Gu, T., Zhang, D.Q., Hung, Pung, H.K., “Ontology Based Context Modeling and Reasoning using OWL", Pervasive Computing and Communications Workshops, 2004, pages 18-22.
[39] Wang, J., Jiang, J., "Research on Flexible Management of Business Process", Communications in Computer and Information Science Volume 308, 2012, pp 804-811.
[40] Wieland, M., Nicklas, D., Leymann, F., “Benefits of Business Process Context for Human Task Management”, International Journal of Trade, Economics and Finance, Vol. 2, No. 4, August 2011.
[41] Winograd. T., “Architecture for Context, Human Computer Interaction”, Lawrence Erlbaum Ed., Vol. 16, 2002, pages 401-419.
[42] Yamabe, T., Takagi, A., Nakajima, T., "Citron: A Context Information Acquisition Framework for Personal Devices”. International Conference on Embedded and Real-Time Computing Systems and Applications, 2005.
