Workﬂow Semantic Description for Inter-organizational

Cooperation

Nomane Ould Ahmed M’Bareck and Samir Tata

GET/INT, 9 rue Charles Fourier, 91011 Evry, France

Abstract. The work we present here is in line with a novel approach for inter-

organizational workﬂow cooperation that consists of workﬂow advertisement,

interconnection, and cooperation. For advertisement, workﬂows should be de-

scribed. Nevertheless, by using a description language like XPDL only syntac-

tic problems can be solved. In this paper, we propose a three steps method for

workﬂows semantic description. First, workﬂows described using XPDL, are an-

notated to distinguish cooperative activities and non cooperative ones. Second,

to preserve privacy, a view, that we call cooperative interface, for each differ-

ent partner is generated. Third, cooperative interfaces are described using OWL

according to an ontology we have deﬁned for cooperative workﬂows.

1 Introduction

In context of globalization, organizations are increasingly using process-aware informa-

tion systems to perform automatically their business processes. Based on such systems,

organizations focus on their core competencies and access other competencies through

cooperation, moving towards a new form of network known as virtual organization.

To support cooperation, one has to deal with issues such as automatic workﬂow

discovery, established workﬂow preservation, and privacy respect. In fact, cooperation

needs a certain degree of inter-visibility in order to perform interactions and data ex-

change. Nevertheless, cooperation may be employed as a cover to internalize the know-

how of partners. In order to preserve privacy and autonomy, one must reduce workﬂow

inter-visibility to be as tiny as the cooperation needs.

For inter-organizational workﬂow cooperation, two main families of approaches are

developed: top-down and bottom-up. Within the top-down family, several approaches

were deﬁned [2]. We can cite among others: capacity sharing, subcontracting, case

transfer, loosely coupled, and public-to-private approaches. The most promising ap-

proach is the public-to-private one [1] that consists of three steps. First, the organiza-

tions involved agree on a common public workﬂow, which serves as a contract between

these organizations. Second, each task of the public workﬂow is mapped onto one of

the domains (i.e., organization). Each domain is responsible for a part of the public

workﬂow, referred to as its public part. Third, each domain makes use of its autonomy

to create a private workﬂow, using some inheritance rules. Problems to be encountered

with this family of approaches include mainly autonomy of local workﬂow processing,

Ould N. and Tata S. (2006).

Workﬂow Semantic Description for Inter-organizational Cooperation.

In Proceedings of the 1st International Workshop on Technologies for Collaborative Business Process Management, pages 62-71

 SciTePress

conﬁdentiality that prevents complete view of local workﬂow [3], and especially ﬂexi-

bility that needs no deﬁnition of a global workﬂow that deﬁnes cooperation between lo-

cal workﬂows. In addition, a drawback is the lack of the preservation of pre-established

workﬂows. In fact, in this approach, one has to look for which rules, in what order and

how many times one has to apply them in order to match the pre-established workﬂow

with the public part which is deduced from partitioning of the public workﬂow. If not

impossible, this is hard to do. Moreover, there is no deﬁned procedure to do that.

Within the bottom-up family, we have developed the CoopFlow [4,5] approach in-

spired by the Service-oriented Architecture that requires three operations: publish, ﬁnd,

and bind. Service providers publish services to a service broker. Service requesters ﬁnd

required services using a service broker and bind to them. Accordingly, our approach

consists of three steps: workﬂow advertisement, interconnection, and cooperation. To be

advertised, workﬂow must be described. Nevertheless, languages for workﬂow descrip-

tion lack semantics, which holds up the issues of automatic discovery of workﬂows. In

line with our approach, we propose here a three steps method for workﬂows semantic

description.

The rest of this paper is organized as follows. Section 2 discusses related work in the

area of workﬂow description. Section 3 summarizes our bottom-up approach to inter-

organizational workﬂow cooperation. Section 4 is devoted to semantic description of

workﬂows. Conclusion and perspectives are presented in Section 5.

2 Related Work

To describe inter-organizational workﬂows, big efforts have been made and many lan-

guages have been proposed. In the following we present a survey of these propositions.

Business Process Execution Language for Web Services (BPEL) [7] is a language

for specifying business processes behavior based on Web services and business interac-

tion protocols. BPEL process allows the deﬁnition of abstract and executable processes.

It does not support many concepts that are paramount for inter-organizational cooper-

ation. In fact, it does not proﬁt of the rich concepts of exiting workﬂow management

systems as the notion of manual activities, applications, nor addresses the integration

with them, since it uses Web services exclusively which represent a limit to call other

types of services (i.e. activities).

XML Process Deﬁnition Language (XPDL) [8] was proposed and standardized by

Workﬂow Management Coalition. Its principal entities are Workﬂow Process, Activity,

Transition, Application, and Participant. Certainly the description provided by XPDL is

rich but it cannot be published to a registry especially for two reasons. The ﬁrst is that

the description provides too many information and consequently it doesn’t preserve the

privacy of partners’ workﬂows. The second reason is that the description is syntactic

and so it doesn’t allow automatic discovery.

OWL-S [10] is an ontology and a language based on OWL [9] and dedicated to de-

scribe semantically Web services. It was developed to achieve automatic Web service

discovery, invocation, composition and inter-operation. OWL-S ontology is organized

in three modules: ServiceProﬁle, ServiceModel, and ServiceGrounding. ServiceProﬁle

describes ”what the service does”; it speciﬁes inputs and preconditions required by the

service as well outputs and effects. Also, other important attributes for the discovery

are speciﬁed as temporal and geographical constraints. ServiceModel describes ”how

the service works”. It describes how to interact with the service. In other term, it de-

scribe the ﬂow of control of services. ServiceGrounding shows how an agent can access

the service. OWL-S is not adapted to workﬂow description. Indeed, the information

necessary for discovery is divided between the Service Proﬁle and the Service Model.

Consequently, in order to discover a workﬂow described with OWL-S both the Service

Proﬁle and the Service Model should be published and the algorithm of matching must

jump between them to decide if two workﬂows match or not. Moreover OWL-S does

not dictate any constraint between Service Proﬁle and the Service Model. Consequently,

there is no mean to identify inconsistencies between them.

WSMO [12] is an ontology for describing various aspects related to semantic Web

services. It is intended to achieve automatic Web services discovery, invocation, compo-

sition and inter-operation. WSMO is based on four concepts: ontologies, web services,

goals and mediators. Ontologies provide machine-readable semantics for Web services,

Goals and Mediators. Goal speciﬁes objectives that a client might have when consulting

a Web services. Mediator allows to link heterogeneous resources and resolves incom-

patibilities that arise at different levels. The WSML language [13] is used to formalize

WSMO. The use of WSML for describing WSMO ontologies is its main drawback. In

fact, there are not yet tools to create, parse or manipulate these ontologies. Finally the

jargon used by OWL-S and WSMO is not meaningful for workﬂows.

3 CoopFlow: An Approach for Workﬂow Cooperation

To support virtual organizations, we have developed a novel approach that consists of

three steps: workﬂow advertisement, interconnection, and cooperation. In this section

we present this approach using a running example.

3.1 Example

Consider an example involving a client and a product provider. Figure 1-(a) presents

the client’s workﬂow using Petri nets [11]. First, the client sends an order for a product.

Then she receives a notiﬁcation. When the product is ready, she receives the delivery

and the invoice. Finally, she pays for the ordered product. Figure 1-(c) presents the

provider’s workﬂow. First, the provider waits for an order request. Then he notiﬁes the

client that his/her order was taken into account and he assembles the components of

the product. After that, two cases can happen: the client is a subscriber (s/he often or-

ders products) or s/he is not. In the ﬁrst case, the provider sends the product and the

invoice and waits for the payment. In the second case, the provider sends the invoice,

waits for the payment and then sends the product. Cooperative activities, represented

by ﬁlled transitions in Figure 1, are the ones that send and/or receive data to/from ex-

ternal partners. The examples given here only show cooperation between two partners.

Nevertheless, our work also addresses cooperation between more than two partners.

Fig.1. The client and the provider workﬂows and their cooperative interfaces.

3.2 Workﬂow Advertisement

To set up cooperation, each partner has to advertise its offered and required activities

within their workﬂows, control ﬂow, and data ﬂow, that we call cooperative interface.

Broadly speaking, a workﬂow cooperative interface is a projection of a workﬂow on

the cooperative activities that interact with one partner type [4]. Figure 1-(b) presents

the workﬂow cooperative interface of the client and Figure 1-(d) presents the provider’s

one. Semantic description of cooperative interfaces are published to a registry (i.e. the

control ﬂow, the data ﬂow and a semantic description of cooperation activities).

3.3 Workﬂow Interconnection

Partners loking for organizations with complementary skills can make use of cooper-

ative interfaces they published. In order to construct an inter-organizational workﬂow,

we have to match cooperative interfaces. Matchmaking takes into account the ﬂow of

control, the data ﬂow and semantic descriptions of cooperation activities. Given two co-

operative interfaces, the matchmaking result can be (1) positive (i.e. interfaces match)

(2) negative (i.e. interfaces do not match at all) or (3) conditional (i.e. interfaces match

if a given condition holds). If the matchmaking result is not negative, the cooperative

interfaces are then interconnected. In our example presented above, the matchmaking

result is conditional: the client cooperative interface (see Figure 1-(b)) and the provider

cooperative interface (see Figure 1-(d)) match if the client is a subscriber. The result

of this step (i.e. workﬂow interconnection) is an inter-organization workﬂow, and a set

of cooperation policies that deﬁne cooperative partners and their interfaces (i.e. coop-

erative activities, their order of execution,...) and constraints on workﬂow interactions

(e.g. the matchmaking condition).

3.4 Workﬂow Cooperation and Monitoring

The third step within our approach for workﬂow cooperation consists in the inter-

organizational workﬂow deployment and execution. To do that, we have developed the

CoopFlow framework [5] that allows different WfMSs to interconnect and cooperate

their workﬂows. In addition to cooperation, this framework mainly enforces coopera-

tion policies identiﬁed during the workﬂow interconnection step.

4 OWL4W: OWL for Workﬂow Description

One of our objectives is to allow partners to automatically discover each other. Therefor,

we focus, in this section, on identifying important information to be described to allow

inter-organizational workﬂow cooperation and how this information is described using

OWL-based workﬂow description language.

4.1 Identiﬁcation of Important Information for Cooperation

Our goal is to describe workﬂows in such manner that allows, for a given need, auto-

matic and dynamic discovery. Let us, for example, suppose that a company of mobile

phones with SIM card wishes to look for suppliers. Complex requests can be formulated

as ”look for a supplier located in France, able to treat an ordering of mobile phone with

SIM card and return me a notiﬁcation before September 20, 2005”. Currently, this task

must be performed by human. To be able to deal with such request, it is not always

necessary to advertise all workﬂow activities to describe the provided service.

To identify information to be described, we considered two main aspects. First of

all, we propose to hide non co-operative activities to preserve privacy since they are only

deﬁned to achieve internal tasks while cooperative activities interact with the external

partners. Secondly, even if the description of workﬂow is intended to be computer-

interpretable, it should be understandable by person who isn’t specialist. That enables

to have a high level abstraction of the workﬂow and as consequence allows the workﬂow

to be discovered by a greater number of users. To meet this end, in our description we

give only the control ﬂow (represented by activities and their transitions), the data ﬂow

(represented by Input/Output) and some additional attributes like deadline of activities,

quality and location of provided service...We do not describe information concerning

implementation of activities, resources nor activities’ execution mode.

4.2 Description of Identiﬁed Information

Several languages were proposed to describe workﬂows. Among those we can cite

XPDL. The description that we propose consists in starting from a ﬁrst internal XPDL

workﬂow description and generate from it a semantic description of cooperative in-

terfaces. The choice of XPDL as a starting point can be motivated by the fact that it

contains all information that somebody can wish to know on a workﬂow. We ﬁnd there

description of data ﬂow, control ﬂow and also a description of the resources. In the fol-

lowing we present how we proceed to generate a semantic description from XPDL one.

This is done in three steps: annotation of XPDL description, abstraction of interfaces,

and semantic description.

The ﬁrst step consists in annotating the initial description of workﬂow by adding for

each cooperative activity information about the partner (formal parameter) with which

it will interact. Thanks to annotations, the second step generates a set of interfaces for

each workﬂow. The Figure 1-(d) shows the interface generated for the workﬂow shown

in Figure 1-(c). Finally, the third step describes each interface using OWL. The partial

conversion from XPDL to OWL description that is out of this article’s scope can be done

automatically. In the following we give the XPDL description of the example given in

ﬁgure 1-(c) and we use this example to illustrate these steps.

4.3 XPDL Description of the Example

Since descriptions of all the activities of the example are broadly the same, we give here

the description of the NOTIF activity (i.e. the provider notiﬁes the client that his/her or-

der was taken into account). We suppose that we have an application called Email which

implement the activity NOTIF. Email has two inputs, orderNum and EmailAdss, and

one output Message which is the notiﬁcation sent to the partner. EmailAdss is extracted

from the order and the orderNum is generated by the activity RECEIVE ORDER.

<ActualParameter>orderNum</ActualParameter>

<ActualParameter>EmailAdss</ActualParameter>

<ActualParameter>Message</ActualParameter>

</ActualParameters>

</Tool>

</Implementation>

</TransitionRefs>

</Split>

</TransitionRestriction>

</TransitionRestrictions>

<StartMode>Automatic</StartMode>

<FinishMode>Automatic</FinishMode>

</Activity>

4.4 Step 1: XPDL Description Annotation

To distinguish between non cooperative and cooperative activities that interact with ex-

ternal partners on one hand and between cooperative activities that interact with differ-

ent partners on the other hand, this ﬁrst level of description was introduced. For this end

we add an attribute Partner which is speciﬁed for each cooperative activity and which

is deﬁned by the means of the element Extended Attribute. Cooperative activities of a

workﬂow which will cooperate with the same partner (those which will belong to the

same interface) will have the same name. This acts like a formal parameter. The value of

this element (the identity of the client and if s/he is a subscriber or not) will be provided

only at the interconnection (cf. Section 3.3) step within the CoopFlow approach.

In our example we quote that the following activities are cooperative: RECEIVE

ORDER, NOTIF, SEND INVOICE, RCEIVE PAYMENT, SEND PRODUCT, SEND PROD-

UCT AND INVOICE and RECEIVE PAYMENT. The others are not. The value of name

for NOTIF cooperative activities is Client. We give in the following the description of

this activity. The description of the others can be easily deduced.

<!-same as above->

</TransitionRestrictions>

</Activity>

4.5 Step 2: Interfaces Abstraction

The realization of a consequent task requires the implication and the cooperation of a

set of organizations. However, this cooperation should not lead to the disclosure of the

know-how of each organization. In order to preserve this know-how we abstract each

workﬂow by a set of interfaces and those interfaces will be advertised. Each interface

consists of a set of activities which will cooperate with the same partner. Abstraction is

done using an original technique based on the exploitation of linear invariants in Petri

nets [6]. This abstraction became possible thanks to the annotation done in step 1.

Figure 1-(d) shows the abstract interface of the workﬂow in ﬁgure 1-(c). Now we

give the description of the interface shown in ﬁgure 1-(d). We can observe that the ac-

tivity NOTIF is not connected any more to the activities COMPONENET 1 and COM-

PONENT 2 but it is now connected to SEND INVOICE and SEND INVOICE AND

PRODUCT which are cooperative. The impact of this modiﬁcation is that the transition

restriction of the NOTIF will change. The type of restriction was AND and it becomes

XOR because the restriction type of ASSEMBLE activity was XOR. Since this later will

be hidden then the restriction on the transition between NOTIF activity on the one hand

and SEND INVOICE and SEND INVOICE AND PRODUCT activities on the other hand

will be XOR. We give in the following the description of this NOTIF activity. The de-

scription of the others can be easily deduced.

<ActualParameter>orderNum</ActualParameter>

<ActualParameter>EmailAdss</ActualParameter>

<ActualParameter>Message</ActualParameter>

</ActualParameters>

</Tool>

</Implementation>

</TransitionRefs>

</Split>

</TransitionRestriction>

</TransitionRestrictions>

</Activity>

4.6 Step 3: Semantic Description with OWL

The description we present here consists in deﬁning ontology for the co-operative work-

ﬂows. This ontology aims at describing, in a non ambiguous way, the cooperative work-

ﬂows so that a software agent can automatically exploit information on those. Beneﬁts

of the use of an ontology are known and multiple, but the ﬁrst which can come to mind

relates to the improvement of the discovery of workﬂows’ interfaces and their inter-

connection to construct an inter-organizational workﬂow. This ontology endeavors to

describe workﬂows in order to be able to carry out the automatic workﬂow discovery.

The ontology we propose here is the semantic description of the interface obtained in

step 2. It thus describes, in OWL, the data ﬂow, the control ﬂow and a set of additional

attributes for workﬂows. Also it gives a textual description of the provided service and

the name and the address of the company which holds the workﬂow.

The ontology we give here enables the semantic description of abstract interfaces

obtained in the step 2. We point out that an interface is a workﬂow. The upper concept

in this ontology is the Interface (see Figure 2). The Interface is composed of a set of

activities. Each activity has a set of transitions (transition), a set of parameters (param-

eter), a deadline and possibly some restrictions (restriction) on transitions. An activity

can be located at a well speciﬁed place and it could have attribute which specify the

quality of provided service. Each parameter has a type and an order. The order makes

it possible to order inputs and outputs when this is necessary and it is used primarily

by the matchmaking algorithm. For example, let us consider that we have two activi-

ties A1 and B1 and each one has one input and one output. A1 receives a product and

then sends the payment while B1 receives the payment and then it sends the product.

Even if inputs and outputs of these two activities refer to the same concepts of an on-

tology, these two activities don’t match because the sending and reception order of the

parameters is not the same. To deal with this issue, we added the attribute order. To

express the deadline of the activity we deﬁne the class Deadline as being an instance

of the class TemporalThings of the Time ontology

employed in OWL-S. Each transi-

tion has a starting activity (TransTo), an arrival activity (TransFrom) and also it has a

condition. We represent a condition as logical Formula. The concept Region refers to

an ontology containing the areas of the world. The quality of services provided by the

activity should be speciﬁed by a third entity. Finally, there are four kinds of restrictions

an activity could have on transitions: SplitXOR, SplitAND, JoinXOR, and JoinAND. A

Split speciﬁes that the incoming transitions of the activity are split. A Join speciﬁes that

the outgoing transitions of the activity are joined. The type of both Split and Join could

be AND or XOR. AND means that the transition are executed in parallel. XOR means

that one transition is executed.

Activity

Transition

hasTrans

Parameter

hasRest

Restriction

hasDeadline

Deadline

LocatedIn

Region

hasTemporalThing

TemporalThing

hasActivity

Inteface

xsd#Integer

anyURI

hasType

hasOrd

TransTo

TransFrom

Condition

hasCond

hasParam

Fig.2. OWL4W: classes and properties.

Now we give the description of the NOTIF activity given in example. Firstly we

deﬁne the type of input/output used by the activity. Each type refers to a concept in an

ontology. Then, we give the deﬁnition of the NOTIF activity and one of its transitions.

<hasType

rdf:resource="http://www.w3.org/2001/XMLSchema#Integer"/>

</Input>

<hasType

rdf:resource="http://www.bpOnto.org/order#EmailAddress"/>

</Input>

http://www.isi.edu/ pan/damltime/time-entry.owl

</Output>

</Activity>

</Transition>

5 Conclusion and Perspectives

In this paper we presented a new approach for workﬂow inter-organizational coopera-

tion, by proposing a workﬂow description combining XPDL and OWL. This description

is semantic and preserve the privacy of partners. To elaborate this description, workﬂow

is ﬁrstly described in XPDL. Then we identify the cooperative activities of workﬂow.

Once the cooperative activities are identiﬁed, they are described using OWL according

to an ontology we have deﬁned for cooperative workﬂows. Our objective now within

the CoopFlow approach is to develop a registry to which we can publish semantic de-

scriptions of workﬂows to enable dynamic and automatic discovery of workﬂows. We

are currently implementing a matchmaking algorithm based on graph similarity.

References

1. van der Aalst W.-M.-P., Weske, M.: The P2P Approach to Interorganizational Workﬂows.

CAiSE (2001) 140-156

2. van der Aalst W.-M.-P.: Loosely Coupled Interorganizational Workﬂows: Modeling and An-

alyzing Workﬂows Crossing Organizational Boundaries. Information and Management Jour-

nal 37 (2000) 67-75

3. Zhao, J.-L.: Workﬂow Management in the Age of E-Business. The 35th HICSS. (2002)

4. Chebbi, I., Dustdar, S., Tata, S.: The view-based approach to dynamic inter-organizational

workﬂow cooperation. Data Knowl. Eng. 56(2) (2006) 139-173

5. Chebbi, I., Tata, S.: CoopFlow: A Framework for Inter-organizational Workﬂow Coopera-

tion. OTM Conferences (1) (2005) 112-129

6. Kali, K., Tata, S.: Abstraction-based Workﬂow Cooperation Using Petri Net Theory. 14th

IEEE WETICE. Sweden (2005)

7. T. Andrews and al.: Business Process Execution Language for Web Services. (2003)

8. Workﬂow Management Coalition. XML Process Deﬁnition Language. (2005)

9. Smith, M. K., Welty, C., McGuinness, D. L.: OWL Web Ontology Language Guide. (2004)

10. M. David and al.: Bringing Semantics to Web Services: The OWL-S Approach. Semantic

Web Services and Web Process Composition Workshop. (2004) 26–42

11. van der Aalst W.-M.-P. : Interorganizational Workﬂows: An Approach based on Message

Sequence Charts and Petri Nets. SAMS journal. (1999) 34(3) 335–367

12. Feier, C., Domingue, J.: D3.1v0.1 WSMO Primer, Final Draft. DERI. 2005

13. J. De Bruijn and al.: Web Service Modeling Language, Final Draft. DERI. 2005