Gautier, Lionel Merci Donc À Michel

Paul G Franck

Xenia Rizky

Zheng, Shadan, Romain Merci À Andrès

Laura

Safae

Seb Audrey

Loïc, Tiexin Alexandre Reb

A BPM classi cation B Business Process Modeling Notation C Collaborative Ontology

Un grand philosophe du 21 ème siècle a un jour comparé la réalisation d'une thèse à un long voyage, tels les marins naviguant sur les océans. Si, pour moi, ce voyage s'est avéré si plaisant, loin des écueils, c'est sans doute parce que j'ai eu la chance de l'e ectuer en compagnie d'un excellent équipage et avec l'aide et le soutien des meilleurs guides.

Frédérick, je te remercie pour ta con ance et pour m'avoir fait embarquer dans ce bateau. L'esprit de "vestiaire" que tu sais instiller au sein de l'axe IO en fait une équipe formidable parmi laquelle je suis très heureuse d'évoluer. Ce joyeux mélange entre ton esprit créatif bouillonnant d'idées toujours plus motivantes, et ton (parfois très) improbable sens de l'humour, fait que travailler avec toi se révèle toujours être un vrai plaisir.

Matthieu, merci d'avoir aussi su guider ce voyage, dans le beau comme le mauvais temps. Travailler avec toi m'amène à toujours pousser un peu plus loin les niveaux d'abstraction, sans jamais perdre de vue les applications concrètes. Merci pour ton e cacité et ta disponibilité à toute épreuve. Tu réponds toujours présent et avec humour (même si tu es parfois le seul face à mes petits jeux de mots...), et c'est une joie.

Jacques, je te remercie de m'avoir aidée à esquisser la cartographie de mon voyage. Tes idées débordantes, et qui fourmillent en permanence, me permettent d'orienter mon travail vers des horizons parfois insoupçonnés. Merci de ton soutien sans faille, et de la rigueur que tu sais amener dans les recherches que tu entreprends. Une dernière chose... n'oublie pas que tu me dois toujours un Twix! I thank Hamideh Afsarmanesh for having reported the thesis and for her motivating enthusiasm for exploring further research areas. As well, I thank Raúl Poler for having accepted to report my PhD thesis and for his constructive point of view.

General Introduction

"Begin at the beginning, " the King said, gravely, "and go on till you come to an end; then stop. "

-Lewis Carroll, Alice in Wonderland

In the last years, inter-organizational collaborations have become a necessity, rather than a strategy, for a company to remain competitive in its environment. Hence, it becomes harder and harder for an isolated enterprise to stay competitive and survive in the current economic context.

Moreover, the advances made in IT and Management sciences have allowed enterprises to become more agile and reactive when sharing their resources and know-hows, and are thus more prepared to face new challenges and market opportunities. Another explanation is that the recent advances in information technologies always allow faster and easier ways to communicate. Working with distant partners and heterogeneous information systems becomes easier for companies, thanks to research works on interoperability. Hence, for a company located in France, working with other companies, whichever their IT devices, software environment or even languages, turns out to be more and more feasible. The emergence of several types of inter-organizational collaborations, such as Virtual Organizations, Virtual Enterprises or Virtual Supply Chains, clearly shows the advantages of such tools.

In general, organizations choose between various degrees of sharing such as information exchange (i.e. communication) or activity sharing (i.e coordination) when setting new collaborations. The term collaboration can be used to describe the generic behavior of organizations working together. However, from a technical point of view, this terminology rather stands for goal sharing, in which the organizations join their forces to achieve common objectives.

Here, the notion of collaborative business process comes as a cornerstone of collaborations. It de nes and orders the di erent activities that need to be executed to reach the common goals. Nowadays, for the broker of a collaboration, setting up the collaborative network -i.e. the design-time of the collaboration -is achieved in three phases: (i) de ning the objectives of the collaboration, (ii) nding the partners of the collaboration to achieve them, and (iii) establishing the adapted inter-organizational business process that will further be orchestrated during the

Introduction Générale

Ces dernières années, la capacité à établir des collaborations inter-organisationnelles est devenue, plus qu'une stratégie, une vraie nécessité pour les entreprises désireuses de rester compétitives. E ectivement, pour une entreprise isolée, il devient de plus en plus di cile de survivre dans le contexte économique actuel.

Les récents progrès réalisés, à la fois dans les technologies de l'information et dans le domaine du génie industriel, ont amené plus d'agilité et de réactivité aux entreprises partageant leurs ressources et leurs savoir-faire. Ainsi, elles sont mieux préparées à relever de nouveaux dé s et à répondre à de nouvelles opportunités de marché. Les avancées réalisées en informatique permettent de communiquer de plus en plus facilement et de plus en plus rapidement, ce qui favorise ce récent essort pour les collaboration inter-organisationnelles. Travailler avec des collaborateurs éloignés géographiquement, ou dont les systèmes d'information sont hétérogènes est plus aisé grâce aux travaux de recherche et industriels réalisés sur l'intéropérabilité des systèmes. Ainsi, pour une entreprise localisée en France, travailler avec d'autres entreprises, quelque soit leurs systèmes d'information, leurs environnements logiciel, ou même leurs languages, se révèle de plus en plus envisageable. L'émergence de nombreux types de collaborations interorganisationnelles comme les organisations virtuelles, les entreprises virtuelles ou les chaînes logistiques virtuelles démontre les avantages de tels outils.

Généralement, lorsque les organisations créent de nouvelles collaborations, elles choisissent parmi di érents degrés de partage, comme le partage d'information (i.e. communication) ou le partage d'activités (i.e. coordination). Le terme collaboration peut en fait être utilisé pour décrire le comportement générique des organisations lorsqu'elles travaillent ensemble, mais, d'un point de vue technique, il s'appplique plutôt au partage d'objectifs communs, pour lesquels les organisations unissent leurs forces. Dans ce cas, la notion de processus collaboratif est une pierre angulaire des collaborations inter-organisationnelles: cela dé nit l'ordre des di érentes activités devant être réalisées a n d'atteindre les buts communs. De nos jours, pour l'organisation désireuse de créer une nouvelle collaboration, l'étape de création de la collaboration -le design-time de la collaboration -est souvent partagé en trois phases: (i) la dé nition des objectifs de la collaboration, (ii) la recherche des partenaires permettant de les remplir et (iii) l'établissement d'un processus métier inter-organisationnel -qui permet par la suite d'orchestrer cette collaboration pendant le run-time. Or, ces étapes sont souvent réalisées de façon humaine, et sont donc laborieuses, chronophages et gourmandes en ressources.

L'automatisation du design-time des collaborations inter-organisationnelles est un sujet riche, qui soulève des problèmes complexes que l'on peut dé nir selon trois questions quoi/qui/quand:

1. Quels sont les services métier devant être mis en place pour atteindre les objectifs de collaboration? (Quoi?)

2. Quelles organisations peuvent fournir ces services métier pour obtenir les meilleurs résultats (selon des critères non-fonctionnels comme le temps de réalisation ou le coût)? (Qui?)

3. Quand les organisations doivent-elles réaliser ces services métiers? (Quand?)

Dans le cadre de cette thèse, ces trois questions ont amené à ré échir sur les façons pertinentes de représenter et acquérir les connaissances permettant de caractériser le contexte de la collaboration, puis, d'exploiter ces connaissances a n de déduire un processus métier collaboratif optimisé répondant aux objectifs de collaboration.

Ces travaux de recherche ont été menés dans le cadre de deux projets: le projet MISE (Mediation Information System Engineering) et le projet FUI OpenPaaS. D'une part, le projet MISE a été initié en 2004 et a, depuis, subi trois itérations. Réalisé au sein de l'axe Intéropérabilité des Organisations, au Centre Génie Industriel de l'Ecole des Mines d'Albi-Carmaux, MISE a pour but de supporter les collaborations inter-organisationnelles du design-time jusqu'au run-time, en y ajoutant une étape d'agilité intervenant comme une boucle de rétroaction pour adpater dynamiquement les collaborations aux changements (du run-time sur le run-time ou du run-time sur le design-time). Cette thèse succède à plusieurs autres thèses centrées sur l'automatisation du design-time. En e et, à chaque itération du projet, MISE ambitionne de lever de nouvelles hypothèses. Après les travaux réalisés dans le cadre du projet MISE 2.0, cette thèse vise à lever l'hypothèse faite que les partenaires de la collaboration sont déjà connus lors du design-time, ce qui amène une forte complexité lors de la déduction de processus collaboratifs.

D'autre part, le projet OpenPaaS est un projet français visant à implémenter un Réseau Social d'Entreprises (RSE) sur une plate-forme en tant que service, pour supporter et faciliter les collaborations inter-organisationnelles. Le RSE est un moyen de regrouper de nombreuses entreprises a n qu'elles puissent travailler ensemble: soit en échangeant des informations comme sur n'importe quel autre RSE, soit en exploitant des services dédiés à la mise en place de nouvelles collaborations ou au support des collaborations déjà créées. Les informations collectées par le RSE sont intégrées sous la forme de connaissances, a n que les travaux de recherche menées au cours de cette thèse puissent en tirer parti pour caractériser les contextes collaboratifs.

Ainsi, cette thèse s'est déroulée dans un environnement scienti que très riche, à l'intersection entre le génie industriel et le domaine des systèmes d'information.

Le Chapitre 1 vise à fournir un large point de vue sur ce vaste contexte, en détaillant les tenants et aboutissants des travaux de recherche menés dans cette thèse.

Une fois cernées les problématiques et le contexte de mise en oeuvre de cette thèse, le Chapitre 2 permettra de faire une premier pas vers la réponse à la question précédente Qui? en établissant une revue de littérature sur les facteurs non-fonctionnels habituellement pris en compte dans la sélection de partenaires. Ce chapitre résultera en un cadre structuré sur les facteurs nonfonctionnels, particulièrement adapté au contexte des RSEs.

Puis, le Chapitre 3 sera centré sur l'acquisition des connaissances sur les collaboration interorganisationnelles, dans le but de permettre une future déduction de nouveaux réseaux collaboratifsl. Pour cela, l'approche menée peut être décrite en deux étapes: (i) concevoir la structure des bases de connaissances et (ii) peupler ces dernières avec des connaissances extraites d'autres bases déjà existantes ou acquises directement auprès des utilisateurs du RSE.

Le Chapitre 4 détaillera comment les résultats obtenus aux Chapitres 2 et 3 peuvent être exploités dans le but de répondre simultanément aux question quoi/qui/quand. Finalement, un processus métier collaboratif quasi-optimal est obtenu à partir (i) de la description de la situation collaborative, par les utilisateurs et (ii) des connaissances déjà existantes, injectées dans le système d'information, comme décrit dans le Chapitre 3.

Finalement, le Chapitre 5 s'intéresse à la mise en oeuvre de ce système et propose aux lecteurs un cas d'illustration décrivant les outils informatiques qui ont été développés dans le cadre de cette thèse, et leur utilisation dans un exemple de réponse automatisée à un appel d'o res.

Context and Problem Statement

"Every step is a rst step if it's a step in the right direction. " -Terry Pratchett, I Shall Wear Midnight

Introduction

A short return to the past shows that, in 1776, Adam Smith (1723-1790) wrote his economy treaty entitled An Inquiry Into the Nature and Causes of the Wealth of Nations [1]. Within this broad synthesis of ideas and observations on his contemporary economy, A. Smith remains particularly famous for his thoughts about the division of labor. The specialization of the workers in each di erent operations lets them improve their e ciency and consequently the factory gains in productivity. However this specialization naturally leads to two facts: the need of a deep degree of cooperation between the workers but also a form of outsourcing so that anyone can exchange his products to obtain the other products he wants (even though the term "outsourcing" was rst used as a business strategy a couple of centuries later). Decades after the industrial revolution, Frederick Taylor (1856-1915) developed his new theory on scienti c management -referred as Taylorism -with The Principles of Scienti c Management [2], and improved the productivity by establishing and analyzing work ows, and Henry Ford (1863-1947) developed the rst mass production lines for the T-Fords.

Then, around the 50's, the digital revolution appeared with the rst computers and brought the society to a next level. About this, van der Aalst [3] mentions a continuous improvement of the productivity through technical innovations, new ways to organize work and nally new digital infrastructures. According to Lummus and Vokurka [4], the 80's constitute the beginning of the era of supply chain management: collaborative relationships within and beyond the organizations becomes a major concern. In 1993, Wortmann et al. [5] published a prospective report on the manufacturing systems for the Commission of the European Communities.

According to this report, three pressures (globalization, environmental concerns in production and the evolution of business and organization structures) would lead to the inter-enterprise integration. Retrospectively, the evolution over the last twenty years proves them right, with the emergence of new paradigms both in computer science and management science to support inter-organizational collaborations.

This chapter aims at providing the reader a large scope on these two disciplines and situating this thesis and its challenges in such a context. Therefore, Section 1.2 is dedicated to the di erent types of Collaborative Networks of Organizations (CNO): their structure, their behavior and their speci c properties. As an application case, the virtual supply chain will be described. IT systems are able to provide the interoperability required by such collaborative networks, hence, the Section 1.3 focuses on the IT tools that allow supporting Business Process Management (BPM) approaches. These two parts will help the reader position the French OpenPaaS project at the junction of two main thematics and also situate this PhD thesis works within the MISE (Mediation Information System Engineering) project, in Section 1.4. Finally, from this large scope will emerge the challenges and the main issues these research works aim at answering.

Collaborative Networks of Organizations 1.2.1 Framework for characterizing the collaborative networks

This Section focuses on the di erent types of networks of organizations that are commonly used in order to provide a large vision of their characteristics and usage contexts. Based on a literature review oriented on three axes of study, a new framework is proposed for characterizing these collaborative networks according to (i) the degree of sharing between the partners, (ii) the topology and (iii) the perspective of the network.

axes of study

Camarinha-Matos et al. [START_REF] Luis M Camarinha-Matos | Towards an architecture for virtual enterprises[END_REF] have analyzed the evolution of CNOs across the time. They characterize a CNO through 4 terms:

• Duration: long or short term;

• Geometry: internal behaviour, exclusivity or many alliances for a partner and xed (e.g. little variation among the partners) or dynamic structure;

• Visibility: which partners can be seen by another partner;

• Coordination: which structure is used between the partners;

Rajsiri [START_REF] Rajsiri | Knowledge-based system for collaborative process speci cation[END_REF] introduces the collaboration by detailing di erent types and levels of collaboration, and then focuses on the network con guration factors broken down into three topics:

• The inter-enterprise relationships: deal with the speci c roles of enterprises within CNOs.

• The topologies of networks: concern the structure of networks.

• The dependencies and coordination mechanisms: the possible interactions within a CNO.

Here, a three dimensional framework is proposed to characterize CNOs according to:

1. The intensity or degree of sharing between the partners, that deals with the coordination [START_REF] Luis M Camarinha-Matos | Towards an architecture for virtual enterprises[END_REF] and the levels of collaboration in the works of Rajsiri [START_REF] Rajsiri | Knowledge-based system for collaborative process speci cation[END_REF].

2. The network management topology refers to the geometry and the visibility in the works of Camarinha-Matos et al. [START_REF] Luis M Camarinha-Matos | Towards an architecture for virtual enterprises[END_REF] and the topologies studied in Rajsiri [START_REF] Rajsiri | Knowledge-based system for collaborative process speci cation[END_REF].

3. The perspective of the CNO, that not only focuses on the duration of the collaboration [START_REF] Luis M Camarinha-Matos | Towards an architecture for virtual enterprises[END_REF], but also on the goals pursued by the collaboration.

Degree of sharing

The degree of sharing in a CNO is what the partners decide to have in common when working together. In the literature, four inclusive degrees of sharing, as illustrated in Figure 1.1, are usually mentioned:

• Communication: Touzi [START_REF] Touzi | Aide à la conception de Système d'Information Collaboratif, support de l'[END_REF] de nes communication as a simple data exchange.

• Coordination: Camarinha-Matos et al. [START_REF] Luis M Camarinha-Matos | Collaborative networked organizations-concepts and practice in manufacturing enterprises[END_REF] describe a coordinated network, whose activities are executed in a prede ned order to reach a speci c goal. In the same vision, Dameron [START_REF] Dameron | Structuration de la coopération au sein d'équipes projet[END_REF] refers to coordination as a way "to order parts according to a logical plan". Dameron [START_REF] Dameron | Structuration de la coopération au sein d'équipes projet[END_REF] insists on the fact that the coordination is static and does not take place as an action.

Touzi [START_REF] Touzi | Aide à la conception de Système d'Information Collaboratif, support de l'[END_REF] writes that it is "sharing and synchronizing tasks".

• Cooperation: Camarinha-Matos et al. [START_REF] Luis M Camarinha-Matos | Collaborative networked organizations-concepts and practice in manufacturing enterprises[END_REF] mention an autonomous work from each partner of the CNO, which have their own objectives. There is a leading entity, but also a sharing of the resources, in order to create a nal product or service.

• Collaboration: it is hardly distinguishable from cooperation and authors have generally di erent point of view. On the one hand, Touzi [START_REF] Touzi | Aide à la conception de Système d'Information Collaboratif, support de l'[END_REF] does not make any di erence between the two terms, and already mentions a sharing of the objectives between the participants of the cooperation. On the other hand,Camarinha-Matos et al. [START_REF] Luis M Camarinha-Matos | Collaborative networked organizations-concepts and practice in manufacturing enterprises[END_REF] make a clear di erence and the objectives are only shared in a collaboration. Dillenbourg [START_REF] Dillenbourg | Some technical implications of distributed cognition on the design on interactive learning environments[END_REF] considers that collaboration comes along with the permanent interaction between partners, but is not totally independent of cooperation in the sense that two partners working with the same resources will instinctively distribute sub tasks in order to work more e ectively.

• Fusion: Touzi [START_REF] Touzi | Aide à la conception de Système d'Information Collaboratif, support de l'[END_REF] mentions integration, whilst Bénaben [START_REF] Bénaben | Conception de Système d'Information de Médiation pour la prise en charge de l'Interopérabilité dans les Collaborations d'Organisations[END_REF] uses the term fusion as "the a liation of the partners to the same entity". Including the previous levels, it also adds a common structure and leads to the term of interoperability by enabling interactions within the CNO.

Network management topology

The evolution of such communities of organizations has led to the establishment of speci c types of management. CNOs can respect di erent types of architectures (i.e. topologies), which enable speci c relationships between partners. Here, an organization is considered as a node and a network as a graph. The power of decision is studied along two axes: the integration decision -on the overall static organization of the CNO -and the coordination decision -related to the dynamic management of the network. These axes come from the works of Stadtler [START_REF] Stadtler | Supply chain management and advanced planning--basics, overview and challenges[END_REF], explained in Part 1.2.2.

• Peer-to-peer (cf a in Figure 1.2): Each node can interact with the others without any hierarchy. The power of decision is equally shared between the nodes and there is no particular forms of integration decision or coordination decision in the network and the responsabilities are distributed. Peer-to-peer (P2P) networks are considered to be rare because they often emerge spontaneously and do not require a global management : each node knows its own tasks to achieve [START_REF] Katzy | Reference models for virtual organisations[END_REF][START_REF] Karvonen | Characterizing virtual organizations and their management[END_REF][START_REF] Ted | The agile virtual enterprise: cases, metrics, tools[END_REF].

• Chain-like (cf b in Figure 1.2): Croom et al. [START_REF] Croom | Supply chain management: an analytical framework for critical literature review[END_REF] have analyzed the literature on supply chain: the chain-like topology can be associated to the supply chain management, a coordinated system in which partners are ordered depending on information, service or materials transfers, to the end customer (e.g. to achieve a speci c nal goal) [START_REF] Ellram | Supply-chain management: the industrial organisation perspective[END_REF][START_REF] Hau | Material management in decentralized supply chains[END_REF][START_REF] Rock | Logistics partnerships and supply chain restructuring: survey results from the us computer industry[END_REF][START_REF] Keah Choon | A framework of supply chain management literature[END_REF].

Consequently the coordination decision process exists to de ne the order of appearance of the organizations during the collaboration but no organization takes a global decision: coordinated parts are managed by each organization for its own needs and nally consitute a global chronological chain of tasks. • Star-like (cf c in Figure 1.2): An organization is at the center of the collaboration and sets the exchange standards and rules to comply. This topology is rather used in a xed structure with long term customer/supplier relationships in which the collaborative project requires a strong coordination decision. Interactions are exclusively established between the supervisor and the partners. Both integration decision and coordination decision are managed by the central entity.

• Grid-like (cf d in Figure 1.2): Zhu [START_REF] Zhu | Topologies of agents interactions in knowledge intensive multi-agent systems for networked information services[END_REF] de nes this topology as follows: each node can interact with its neighboor nodes, moreover nodes are gathered into groups that are supervised by a facilitator and a node can only be part of one group. If a node needs to interact with another node that is not its neighbor, it should pass through its facilitator.

For each group the facilitator makes the coordination decisions, it is up to all the facilitators to take integration decisions and global coordination decisions.

Perspective of the network When choosing the type of CNO it is important to know its perspective. More than the duration, this characteristic also depends on the goal of the CNO. It can be developed along three levels:

• One project goal: Camarinha-Matos et al. [START_REF] Luis M Camarinha-Matos | Towards an architecture for virtual enterprises[END_REF] depict short-term alliances established for a project. These one-shot CNOs are "made for single business opportunity" and "dissolved at the end of such process". Camarinha-Matos and Afsarmanesh [START_REF] Luis M Camarinha-Matos | Classes of collaborative networks. Encyclopedia of Networked and Virtual Organizations[END_REF] mention the term "Grasping-opportunity driven CNOs": the collaborative system o ers an answer to a speci c and unique business opportunity. Consequently, the network is designed once for the entire project life.

• Program goal: Camarinha-Matos and Afsarmanesh [START_REF] Luis M Camarinha-Matos | Classes of collaborative networks. Encyclopedia of Networked and Virtual Organizations[END_REF] use "Goal-oriented networks" to describe a mid-term CNO where partners have clearly de ned roles. The CNO is dedicated to the program, which can be product-oriented or project-oriented. The program life consists of a repeated loop of a pre-established project structure with a known end.

• Program ow: Camarinha-Matos and Afsarmanesh [START_REF] Luis M Camarinha-Matos | Classes of collaborative networks. Encyclopedia of Networked and Virtual Organizations[END_REF] depict long-term agreements between potential partners, that can be quickly con gured, as soon as a new type of opportunity emerges. It results in series of projects or programs, each adapted to a type of opportunity. In line with this type of perspective, Andres and Poler [START_REF] Andres | Dealing with the alignment of strategies within the collaborative networked partners[END_REF] mention the issues encountered by heterogeneous CNOs, in which organizations have di erent strategies. They deal with the alignment of the partners' strategies to nd a relevant strategy to activate for positive results for all the partners. According to Andres and Poler [START_REF] Andres | Dealing with the alignment of strategies within the collaborative networked partners[END_REF], such approach helps leading to a more stable collaborative network, which could bene t to small and medium enterprises.

Classi cation of the CNO regarding the proposed framework

It is interesting to list and study the typical kinds of CNOs and to try to confront them to the proposed framework.

Extended Enterprise (EE) Davis and Spekman [START_REF] Wilson | The Extended Enterprise: Gaining Competitive advantage through collaborative supply chains[END_REF] consider that an EE is an enterprise network composed by each enterprise that takes part at least one time during the whole process of production: "from the raw material to the end-use comsumption". Davis and Spekman [START_REF] Wilson | The Extended Enterprise: Gaining Competitive advantage through collaborative supply chains[END_REF] consider an EE as a long term relationship between partners established in a supply chain structure.

Camarinha-Matos and Afsarmanesh [START_REF] Luis M Camarinha-Matos | Virtual enterprise modeling and support infrastructures: applying multi-agent system approaches[END_REF] describe an EE as follows:

Collaborative Networks of Organizations

"

A dominant enterprise extends its boudaries to all or some of its suppliers.

"

An EE typically allows the dominant organization to quickly establish a network to answer to the needs of a costumer.

Martinez et al. [START_REF] Ta Martinez | Virtual enterpriseorganisation, evolution and control[END_REF] depict the same star topology with one or more hierarchic leader rm(s) surrounded by partners. An EE is depicted as a long-term partnership on a mature market, in which the actors achieve a common process. According to Martinez et al. [START_REF] Ta Martinez | Virtual enterpriseorganisation, evolution and control[END_REF], complex EE can include more than one leader rm but a leader systematically globalizes the exchanges and therefore one non-leader partner cannot communicate with another (as proposed in the grid topology).

Virtual Enterprise (VE) According to Camarinha-Matos et al. [START_REF] Luis M Camarinha-Matos | Towards an architecture for virtual enterprises[END_REF], the di erence between a VE and an EE lies in the fact that it has a more democratic structure, following a peer-to-peer topology. The duration can be variable and ts as well a one project as a program goal perspective.

The VE is considered as a way to share skills but not necessarily goals. Martinez et al. [START_REF] Ta Martinez | Virtual enterpriseorganisation, evolution and control[END_REF] bring a di erent point of view on VE and do not make a frank di erence between a VE and an EE, which is considered as a type of VE. According to the authors "the success of the project depends on all co-operating as a single unit" and every organization provides its own competences to the network. There are short-term and "consortium" VE to answer either to a particular bid for a unique product or to a new market for customized or semi-standardized products. Therefore Martinez et al. depict a one project or program goal perspective.

In terms of hierarchy, Martinez et al. [START_REF] Ta Martinez | Virtual enterpriseorganisation, evolution and control[END_REF] consider a non-hierarchical relationship with "probability of leadership", which reminds of a grid-like or a peer-to-peer structure. Zhang and Li [START_REF] Zhang | Information modelling for made-to-order virtual enterprise manufacturing systems[END_REF] mentions a "master company". Binder and Clegg [START_REF] Binder | Enterprise management: a new frontier for organisations[END_REF] propose a new framework where a VE presents a "loose [. . . ] collaborative venture" with a "low degree of integration" and Pollalis and Dimitriou [START_REF] Yannis | Knowledge management in virtual enterprises: A systemic multi-methodology towards the strategic use of information[END_REF] depict an evolution from hierarchical structures to "network forms of organizations, such as the VE".

If the collaboration is important, for Binder and Clegg [START_REF] Binder | Enterprise management: a new frontier for organisations[END_REF] the VE has to present "a uni ed face to externals" but it doesn't mean that partners share process together. Indeed, they keep their autonomous behaviors and can be part of many VEs for example. Zhang and Li [START_REF] Zhang | Information modelling for made-to-order virtual enterprise manufacturing systems[END_REF] base their de nition on Rolstadås [START_REF] Rolstadås | Enterprise modelling for competitive manufacturing[END_REF] where a VE is managed as "one total unit" but Pollalis and Dimitriou [START_REF] Yannis | Knowledge management in virtual enterprises: A systemic multi-methodology towards the strategic use of information[END_REF] rather mention common resources utilization.

Zhang and Li [START_REF] Zhang | Information modelling for made-to-order virtual enterprise manufacturing systems[END_REF], Pollalis and Dimitriou [START_REF] Yannis | Knowledge management in virtual enterprises: A systemic multi-methodology towards the strategic use of information[END_REF] agree on a short relationship particularly dynamic with a certain turnover among the partners. The aim of a VE is to quickly establish a network that can answer to opportunities emerging from a new market for example. Zhang and Li [START_REF] Zhang | Information modelling for made-to-order virtual enterprise manufacturing systems[END_REF] de ne a product-oriented structure around a master company as a program goal structure.

Virtual organization (VO) Camarinha-Matos and Afsarmanesh [START_REF] Luis M Camarinha-Matos | Collaborative networks: a new scienti c discipline[END_REF] consider a VE as a particular VO, in that a VO concerns any kind of partners either enterprises or any other kind of organizations, but both share the same characteristics. Karvonen et al. [START_REF] Karvonen | Characterizing virtual organizations and their management[END_REF], based on Kürümlüoglu et al. [START_REF] Kürümlüoglu | Base concepts[END_REF], de ne a VO as a short-term consortium that is created to answer a punctual demand of a customer, with a precise lifecycle. Since it is established for a unique request, the structure should be adapted to the case. Any of the star chain or peer-to-peer topologies could be adopted, depending on two factors: "the level of dependencies" between the partners and "the risk involved in the VO objective". There is a coordination of the VO and the partners share resources that are part of the VO management. Although there is no speci c need to share goals or processes, and it seems that its degree of sharing also should be adapted to the objective of the VO.

Abuelmaatti and Rezgui [START_REF] Abuelmaatti | Virtual organizations in practice: a european perspective[END_REF] agree with Camarinha-Matos and Afsarmanesh [START_REF] Luis M Camarinha-Matos | Collaborative networks: a new scienti c discipline[END_REF] and give a very general picture of the concept of VO that seems to include any type of CN. It can adopt a chain, star-like or peer-to-peer topology and basically requires establishing a coordination level. The authors relates that lately there is a need of higher performance, especially for SMEs networks and the exchanges between partners are attempted to evolve, which could be understood as an eventuality to reach a "fusion" level if needed.

Clusters A cluster of organizations is an interesting type of CNO to study: it is described as one of the earliest form of CNO by Camarinha-Matos et al. [START_REF] Luis M Camarinha-Matos | Collaborative networked organizations-concepts and practice in manufacturing enterprises[END_REF]. An industrial cluster brings together a group of companies, usually within the same geographic area, to share "some buyer-supplier relationships, common technologies and tools, common buyers, distribution channels or common labor pools, all contributing to some form of cooperation or collaboration when business opportunities arise". It can therefore be classi ed as a program ow perspective collaboration. As it aims at responding rapidly to opportunities, it is important that the partners share the same infrastructures. No particular hierarchy is mentioned and it seems to be close to a peer-to-peer relationship. Morosini [START_REF] Morosini | Industrial clusters, knowledge integration and performance[END_REF] gives a precise de nition of an industrial cluster where:

"

A signi cant part of both the social community and the economic agents work together in economically linked activities, sharing and nurturing a common stock of product, technology and organizational knowledge in order to generate superior products and services in the marketplace.

"

Moreover, Morosini [START_REF] Morosini | Industrial clusters, knowledge integration and performance[END_REF] considers that a group of individuals have a leadership and facilitate cooperation or knowledge sharing between the partners, for example. The cluster is a long-term relationship in which a common knowledge capital is kept.

The Virtual Supply Chain speci c case

Short history of logistics

Baron Antoine-Henri de Jomini (1779 -1869) analyzed war tactics from Caesar's military campaigns to his contemporary Napoleonic wars. In his book The Art of War [36], he particularly formalized the importance of the logistics (also called "the art of moving armies"): rst used for the basic management of the military camp, the word evolved with the "art of the war" and, at the beginning of the nineteenth century, it became a strategic role assigned to the chief of sta . As underlined by Lauras [START_REF] Lauras | Méthodes de diagnostic et d'évaluation de performance pour la gestion de chaînes logistiques: application à la coopération maison-mère-liales internationales dans un groupe pharmaceutique et cosmétique[END_REF], the latter military o cers had henceforth to deal with the whole supplying of provisions, munitions and materials with the associated responsibilities from the decision making to the coordination and the monitoring.

After World War II, the concept has naturally been extended to the enterprises in the 50's in the United States. Although the notion of logistics has always existed since at least the Egyptian pyramids, it has only been perceived as a key success factor of companies in recent decades. According to the French Associations for Standards (AFNOR -Standard X 50-600), logistics can be seen as the methods and means which goal is to optimally manage product, nancial and information ows. Thus, the concept of supply chain is inherent in it and can now be expanded.

Supply Chain Management

The term of "Supply Chain Management" (SCM) is commonly accredited to the british Booz Allen consultant and logistician Keith Oliver, during an interview from the Financial Times. Laseter and Oliver [START_REF] Laseter | When will supply chain management grow up? Strategy and Business[END_REF] explain that, in 1982, the SCM rst referred to the whole supply chain as a single entity by breaking the silo perception within companies and integrating production, marketing distribution, sales and nance altogether. Besides, moving towards cross-functional business processes became a motto for Hammer and Champy [START_REF] Hammer | Reengineering the Corporation: Manifesto for Business Revolution[END_REF] in their famous work Reengineering the Corporation: A Manifesto for Business Revolution. After some years, SCM is no more about intra-enterprise process but rather about cross-organizational collaborations, as mentioned by Mangan et al. [START_REF] Mangan | Global logistics and supply chain management[END_REF] as the integrated supply chain (cf. Figure 1.4). Christopher [START_REF] Christopher | Logistics and supply chain management[END_REF] also claims that SCM is about relationships between buyers and suppliers: "The focus of supply chain management is on co-operation and trust and the recognition that, properly managed, the 'whole can be greater than the sum of its parts "', and argues the fact that it is more about a network than a chain of suppliers and customers. In our application of the SCM within the works of this thesis, the de nition of Aitken [START_REF] James M Aitken | Supply chain integration within the context of a supplier association: case studies of four supplier associations[END_REF] is adopted: " A network of connected and interdependent organizations mutually and cooperatively working together to control, manage and improve the ow of materials and information from suppliers to end users. The roof of the SCM house is composed by the competitiveness and the customer service tiles, which are de ned by Stadtler as the ultimate objective: simultaneously improve the e ciency of the SCM and also ful ll the customer expectations. In order to obtain such result, the SCM lies on two main pillars: integration of organizational units and coordination of ows. Let's brie y recall the hidden concepts behind those two expressions:

• Integration of organizational units brings together the "choice of partners", "network organization and inter-organizational collaboration" and "leadership", which are rather static concerns. The rst topic aims at selecting the best partners in order to set up a new supply chain (SC). SC are generally created for medium-term partnerships, in opposition with the virtual company which rather ful lls single orders. The second topic is all about controlling a somehow "non-hierarchical" network of independent organizations that are only linked through the common goal of the current supply chain (i.e. strong risk of separation as soon as the collaboration is no longer a priority for one of the partners). Finally, the last topic concerns the presence of a leading partner or committee to align the partners' decisions.

• Coordination of ows goes through three other aspects "information and communication technology", "process orientation" and "advanced planning", which are rather dynamic concerns. The information technologies enable to easily exchange data between the partners and facilitate the decision making processes. Besides, the establishment of not only cross-functional but also cross-organizational processes allows improving the supply chains. As a third point, Stadtler [START_REF] Stadtler | Supply chain management and advanced planning--basics, overview and challenges[END_REF] explains that SCM also requires an advanced planning system that enables both a high level and a very detailed level scheduling (intraand inter-organization point of view is adopted here).

Collaborative Networks of Organizations

Integration:

Advanced planning

Process orientation

Use of information and communication technology

Coordination:

Customer service

Competitiveness

SCM

Figure 1.5 -House of Supply Chain Management, [START_REF] Stadtler | Supply chain management and advanced planning--basics, overview and challenges[END_REF].

These research works are most interested in the four bricks: "choice of partners", "network organization and inter-organization collaboration", "use of information and communication technology" and "process orientation", as highlighted in Figure 1.5. Besides, SCM has evolved these last years, and is now in line with the IT progress: it has led to Virtual Supply Chain (VSC).

Virtual Supply Chain

According to Christopher [START_REF] Christopher | Logistics and supply chain management[END_REF], Gunasekaran and Ngai [START_REF] Gunasekaran | Build-to-order supply chain management: a literature review and framework for development[END_REF], the advances of information systems and the apparition of e-commerce has naturally led to the electronic supply chain. For Christopher [START_REF] Christopher | Logistics and supply chain management[END_REF], the concept of VSC underpins the extended enterprise by enabling to di use and share information among the partners of the collaboration: "Even more importantly it is information shared between partners in the supply chain that makes possible the responsive ow of product from one end of the pipeline to another". In other words, the de nition of the VSC can be based on a sentence from Gunasekaran and Ngai [START_REF] Gunasekaran | Build-to-order supply chain management: a literature review and framework for development[END_REF]:

"

In VSCs, a network of rms provides di erent products or services so that a complete service can be performed by the virtual organization.

"

Rayport and Sviokla [START_REF] Rey | Exploiting the virtual value chain[END_REF] study the two parallel worlds of resource-management and information, and ask the question: how to integrate the information point of view on the value chain? They propose the marketspace concept, which idea is to create value from information through ve main activities: gathering, organizing, selecting, synthesizing and distributing information. The authors develop many ideas around the marketspace with knowledge gathering and exploitation e.g. enhance the e ciency and the responsiveness of the production depending on customers' demand. Using IT systems enables visibility (i.e. coordinate and monitor the activities within a company), mirroring capability (i.e. create new full virtual value chains) and establish new customer relationships.

A further step to these possibilities is considered here: gathering and exploiting knowledge to automatically establish new VSCs.

Interoperability, towards Mediation Information Systems

Interoperability concept has rst been applied to computer science in the early 90's and then has been generalized to products and systems study. The concept relies on establishing tools that enable facilitated collaborations between heterogeneous systems. In fact, all the previous types of networks are trying to achieve interoperability at di erent levels. But what is exactly interoperability? In 1991, IEEE [45] gives the following de nition: "Ability of a system or a product to work with other systems or products without special e ort on the part of the customer. Interoperability is made possible by the implementation of standards. ". Pingaud [START_REF] Pingaud | Rationalité du développement de l'interopérabilité dans les organisations[END_REF] extends the de nition to any systems willing to work together: " Interoperability is the ability of systems, natively independent, to interact in order to build harmonious and intentional collaborative behaviors without modifying deeply their individual structure or behavior.

"

According to the ISO14258 [START_REF]Industrial automation systems and integration -Concepts and rules for enterprise models[END_REF] standard , interoperability can happen on three di erent levels:

• The integrated approach consists in systems that use the same standard format to communicate.

• The uni ed approach deals with the establishment of a common metamodel to allow semantic equivalence of the systems.

• The federated approach enables a on-the-y matching between models of systems using di erent metamodels.

These degrees of interoperability can be reached by crossing the syntactic interoperability and semantic interoperability barriers [START_REF] Kim | Syntactic and semantic interoperability: new approaches to knowledge and the semantic web[END_REF]. According to Jain and Singh [START_REF] Jain | Ontology based information retrieval in semantic web: A survey[END_REF], syntactic interoperability "means that applications must be able to read data and present information", whereas semantic interoperability "de nes that data that is exchanged should be understandable". Syntax and semantic are two barriers that should be raised to enable the collaboration between several systems. A way to break the underlying technological frontiers between heterogeneous systems is to implement mediation information systems, according to the works of Bénaben et al. [START_REF] Bénaben | Mediation information system design in a collaborative soa context through a mdd approach[END_REF]. Such type of mediation information system has been and is still developed under the MISE project umbrella, which will be further detailed in Part 1.4.1. As mentioned in Part 1.1, the establishment, the analysis and the monitoring of work ows have become key success factors for enterprises when enhancing their productivity. According to van der Aalst et al. [START_REF] Wil | Business process management: A survey[END_REF], work ows are commonly considered as only a part of BPM. Basically, van der Aalst et al. [START_REF] Wil | Business process management: A survey[END_REF] extend the de nition of BPM given by Weske [START_REF] Weske | Business process management: concepts, languages, architectures[END_REF]:

" Supporting business processes using methods, techniques, and software to design, enact, control, and analyze operational processes involving humans, organizations, applications, documents and other sources of information.

"

But, what exactly is a business process? Weske [START_REF] Weske | Business process management: concepts, languages, architectures[END_REF] provides a somewhat limited de nition in that it states that "Each business process is enacted by a single organization, but it may interact with business process performed by other organizations", which does not take into account inter-organizational business processes. While, Vernadat [START_REF] Vernadat | Techniques de modélisation en entreprise: applications aux processus opérationnels[END_REF] de nes a process as a set of activities executed in order to achieve at least one objective, Davenport and Short [START_REF] Thomas | Information technology and business process redesign[END_REF] give this close de nition:

"

We de ne business processes as a set of logically related tasks performed to achieve a de ned business outcome.

"

They also emphasize two characteristics of business processes:

• "They have customers; that is, processes have de ned business outcomes, and there are recipients of the outcomes. Customers may be either internal or external to the rm. "

• "They cross organizational boundaries; that is, they normally occur across or between organizational subunits. Processes are generally independent of formal organizational structure. "

Business process lifecycle

The BPM approach can be ful lled through several tools applied in the di erent states of the studied system. Several BPM lifecycles have been de ned in the literature, some are rather oriented towards a business perspective and others also take into account the technical level i.e. the level that involves IT engineers to implement and execute the process. Wetzstein et al. [START_REF] Branimir Wetzstein | Semantic business process management: A lifecycle based requirements analysis[END_REF] propose a decomposition through four phases:

1. Process Modeling is about "drawing" the business process according to modeling languages and by using speci c graphical modeling tools.

2. Process Implementation consists in transforming and enriching this business process model into an executable model. In the context of Service Oriented Architecture (SOA) the executable model could be a Business Process Execution Language (BPEL) model that states for each task of the business process which web service should be invoked.

3. Process Execution deals with the execution of the process with a process execution engine.

4. Process Analysis, which goal is to monitor it as it is running: an analysis of the business process through speci cally chosen key performance indicators allows to evaluate and to enhance it.

van der Aalst [3], Weske [START_REF] Weske | Business process management: concepts, languages, architectures[END_REF], Jung et al. [START_REF] Jung | An integration architecture for knowledge management systems and business process management systems[END_REF] agree on a rather high-level decomposition of BPM phases, that could be summarized through four steps:

1. model that is related to the previous process modeling step [START_REF] Branimir Wetzstein | Semantic business process management: A lifecycle based requirements analysis[END_REF].

2. enact that rather includes the previous implementation and execution steps [START_REF] Branimir Wetzstein | Semantic business process management: A lifecycle based requirements analysis[END_REF].

3. analyze embedded in previous analysis step [START_REF] Branimir Wetzstein | Semantic business process management: A lifecycle based requirements analysis[END_REF].

4. manage rather also included in previous analysis step [START_REF] Branimir Wetzstein | Semantic business process management: A lifecycle based requirements analysis[END_REF].

In order to keep the business/IT level consideration, Benaben et al. [START_REF] Benaben | Supporting interoperability of collaborative networks through engineering of a service-based mediation information system (mise 2.0). Enterprise Information Systems[END_REF] split the cycle into two overall parts: the design-time (when the process is modeled) and the run-time (when the process is executed). In addition, Jung et al. [START_REF] Jung | An integration architecture for knowledge management systems and business process management systems[END_REF] mention the semantic BPM and propose an integration of knowledge management within the BPM lifecycle, which brings a clearly interesting third point of view on BPM . The Figure 1.6 summarizes all these perception of BPM and thus also includes the use of knowledge.

These research works will only focus on the design-time step which relates to the creation of business processes. However the current part shows that BPM is a whole cycle, and the choices made within the design-time cannot be uncorrelated of the run-time.

Business Process Modeling tools

With the growing interest of the industrial and academic worlds for BPM, many tools and languages have been established to support for this approach. This part aims at giving an overview of them and arguing the choices made in this thesis. Ko et al. [START_REF] Ko | Business process management (bpm) standards: a survey[END_REF] o er a wide literature review on the di erent business process modeling standards and speci cations that exist. They propose to study them according to three types:

• The graphical standards: used to "draw" the business processes. They allow a more human perception, and they are therefore adapted for illustrating and reegineering for example. • The execution standards: are computer compliant and o er a way to automate business processes on run-time.

• the interchange standards: to facilitate data portability between di erent graphical standards for example.

The same authors provide a diagram to guide the users on the type of BPM standard to choose depending on the use they have. This diagram can be found in Appendix A. According to it, either graphical of execution standards could be chosen to t the process design step of the BPM lifecycle.

Malekan and Afsarmanesh [START_REF] Soleimani | Overview of business process modeling languages supporting enterprise collaboration[END_REF] focus their survey on the BPM standards to describe speci cally collaborative networks. Patig et al. [START_REF] Patig | It requirements of business process management in practice-an empirical study[END_REF] have conducted a wide survey on the BPM tools used by major companies to describe their processes. As a result, it appears that most of them use text or tables to express their business processes. About the speci c languages they use BPMN rst, then UML, EPC, BPEL and the various IDEF methodologies.

Thus, plenty of BPM representations are available, and the speci c use here should be expanded. This thesis focuses on automating the design-time of BPM (as explained later in Part 1.4.1), and more precisely on establishing new business processes based on business opportunities that the users would like to ful ll. In such a context, there are some constraints that the chosen BPM standard should o er:

• The design-time and run-time cannot be thought independently. The design-time modeling language must at least enable a transformation from it to an executable model, or be directly executable.

• Even if generated automatically, these business processes should be understandable by the users so that they can adapt them easily, if they do not t entirely their expectations.

If not, this business process would not facilitate their collaborations anymore.

Consequently a graphical language has been chosen. Besides, in its second version, BPMN 2.0 [START_REF]Business Process Model OMG[END_REF] now o ers a standard notation supporting work ow orchestration, as underlined by Poizat and Salaün [START_REF] Poizat | Checking the realizability of bpmn 2.0 choreographies[END_REF].

Context of the PhD thesis

These research works were achieved within both a French FUI project, OpenPaaS, and an internal program MISE (Mediation Information System Engineering).

MISE: Mediation Information System Engineering

The MISE program gathers several works of former or actual PhD students of the axis Interoperability of the Organizations at the Industrial Engineering research center of Mines Albi. The evolution of these works for the last ten years has led to a complete cycle for supporting

Introduction to the model driven architecture paradigm

The BPM approach enables to build collaborative business process models that describe the dynamic of the collaboration. However, obtaining a business process model and deploying and orchestrating it on a MIS are not trivial steps. The Model Driven Engineering (MDE) and especially the Model Driven Architecture (MDA) provide a set of tools which particularly suits these steps, by allowing abstract descriptions of systems in order to help at designing IT systems.

The MDE approach appeared in the late 80's with the Computer-Aided Software Engineering (CASE) that proposed a kind of Integrated Development Environement (IDE) according to the description made by Merbeth [START_REF] Merbeth | On the functional and architectural integration of case systems[END_REF], whilst the development of software products became more and more complex. Yet, the US Air Force commissioned the developers of the well known Structured Analysis and Design Technique (SADT) to develop a new modeling method that would rather focus on the functional perspective of a system: the IDEFØ(Integrated Computer-Aided Manufacturing -ICAM -now famous as Integrated DEFinition) [START_REF] Richard | IDEF family of methods for concurrent engineering and business re-engineering applications[END_REF], which would then be followed by a series of 16 extensions o ering di erent points of view to describe systems. In 2001, the Object Management Group (OMG) 1 published its rst version of the MDA speci cation [START_REF] Miller | Object management group: Mda guide[END_REF] -which is now an OMG's trademark. OMG [START_REF] Omg | Object management group: Mda guide rev[END_REF] states that:

"

MDA provides an approach for deriving value from models and architecture in support of the full life cycle of physical, organizational and IT systems.

"

This approach is composed of several models that can be basically positioned within a "Y" structure (cf. Figure 1.7):

• The Computer Independant Model (CIM) allows to describe the requirements for the system. It is independent of the implementation and, thus, is often called the business model, and helps both at understanding the problem to solve and at gathering vocabulary and knowledge.

• The Platform Independant Model (PIM) brings a solution to the requirements de ned in the CIM, but does not address the IT constraints.

• The Platform Model (PM) describes the IT technologies used for the system.

• The Platform Speci c Model (PSM) is situated at the junction of the PM and the PIM: it is the concrete IT solution to the CIM's requirements. According to Bénaben [START_REF] Bénaben | Conception de Système d'Information de Médiation pour la prise en charge de l'Interopérabilité dans les Collaborations d'Organisations[END_REF], two main principles of MDE have emerged from this MDA decomposition: (i) MDA relies on the various models describing di erent perceptions (i.e. level of abstraction) of the system and (ii) model transformation mechanisms can be developed in order to obtain the models (e.g. from CIM to PIM). Such MDA approach has been adopted within the MISE program which therefore deserves to be explained in details.

MISE overview and positioning

Launched in 2004 by Frédérick Bénaben, the MISE program aims at providing a MIS to address the interoperability issues [START_REF] Benaben | Mise 3.0: An agile support for collaborative situation[END_REF] and provides a support for collaborative situations, whatever the eld of the collaboration (crisis situation, virtual enterprise environment, etc.). Actually, the rst observation was that setting up collaborations (design and run-time) was really time-consuming. It indeed required (i) to know the coalition of organizations willing to work together, (ii) for all the organizations, to establish how they would collaborate (who is doing what and when, i.e. the inter-organizational collaborative process), and (iii) to involve IT engineers to eventually deploy the latter process on a IT platform. The requirements of such a collaborative behavior are numerous:

• A step for nding and selecting is required upstream: this is a laborious biding process, that IT technologies can nowadays simplify in a more e cient way (i.e. wider scope of organizations and more and more e cient tools to optimize their selection).

• It is important to highlight that the core skills of each organization cannot be imposed i.e. each organization has its own way to achieve its activities, which should thus be respected by the collaborative IT system. However the inter-organizational ways to collaborate often create problems, since a high-level perception of the system is needed, which is not Figure 1.8 -MISE overall structure, [START_REF] Benaben | Supporting interoperability of collaborative networks through engineering of a service-based mediation information system (mise 2.0). Enterprise Information Systems[END_REF].

always an obvious thing for specialists of each domains. Fortunately, the problem can be transposed in terms of knowledge gathering and exploitation, so that an IT system could understand the collaborative context and provide an overall perception of the system.

• Obtaining a technical work ow, from a business process consists in composing technical services in a certain order to e ectively ful ll the business process. The service composition discipline has became one of the burning challenges of computer science these last years.

• Providing agility to the system, so that it can be reactive. It is indeed incredibly time and resource-consuming to re-implement an information system for each collaboration.

Hence, the IT system should be able to support on-the-y the design-time and the runtime.

The system relies deeply on the MDA and can be decomposed as a succession of models and model transformations, as depicted in Figure 1.8. In fact MISE design-time can be seen as cascading boxes to obtain the di erent types of models: the collaborative situation model, the collaborative behavior model and the collaborative work ow model. Then, the run-time consists in deploying the resulting work ow and provides an agility service to allow feedbacks in realtime so that the work ow coud be adapted if something goes wrong. MISE has experienced three iterations and each of them has brought its bundle of improvements on one or more of the boxes.

MISE design-time description

Since this PhD thesis focuses exclusively on the design-time, it is interesting to have a look on the advances made on the design-time through MISE 1.0 and MISE 2.0 before getting to the expected novelties of MISE 3.0. In Figure 1.9 the steps 1 to 6 provide an illustration of the tools that have been implemented at the beginning of the PhD thesis. The chronological improvements can be summarized as follows.

MISE1.0 was initialized from 2004 and ended in 2010. First, Jihed Touzi's researches [START_REF] Touzi | A model-driven approach for collaborative service-oriented architecture design[END_REF] focused on the transformation rules from the CIM to the PIM (i.e. from a BPMN business process to a UML based logic model work ow), so that the processes could be executed. However, the main hypothesis of his works relied on the fact that the users could themselves provide the CIM. Besides, to be exploited into further PIM, the CIM had to contain a lot of information, and asking the users to provide was an ambitious thing. That is why Vatcharaphun Rajsiri's PhD [START_REF] Rajsiri | Knowledge-based system for collaborative process speci cation[END_REF] rather focused on how to automatically deduce a CIM from knowledge about the collaboration. Her works dealt with (i) gathering knowledge on the collaborative context, (ii) establishing two collaborative ontologies (one describing collaborative systems with their actors their roles, ... and the other one containing a high amount of business processes, based on the MIT Process Handbook of Malone et al. [START_REF] Thomas W Malone | Organizing business knowledge: the MIT process handbook[END_REF]) and (iii) implementing the logic rules to deduce collaborative processes that ts the collaborative context based on (i) and (ii). Finally, Sébastien Truptil's PhD [START_REF] Truptil | Interoperability of information systems in crisis management: Crisis modeling and metamodeling[END_REF] took place within the speci c crisis context: he established a new metamodel to descibe the collaborations between the di erent stakeholders of such situations. Based on this metamodel, he also implemented a corresponding collaborative ontology and the process deductions rules, which allowed him to go from CIM to PIM. Then he worked on the transformation from the PIM to the PSM, to nally obtain a BPEL le that could be executed.

MISE2.0 design-time has entirely been realized through Wenxin Mu [START_REF] Mu | A methodology proposal for collaborative business process elaboration using a model-driven approach[END_REF], Nicolas Boissel-Dallier [START_REF] Boissel-Dallier | Mediation information system engineering based on hybrid service composition mechanism[END_REF] and Sarah Zribi's PhD [START_REF] Zribi | Towards a service and choreography governance framework for future internet[END_REF] theses. The two rst theses were conducted at the same time and provided complementary approaches. Wenxin Mu's works [START_REF] Mu | A methodology proposal for collaborative business process elaboration using a model-driven approach[END_REF] focused on enhancing the acquisition of knowledge and the deduction of a BPMN process. The novelty relies on three points:

• During the knowledge gathering, function models allow to know the capabilities of the organizations and collaborative network models acquire information about the collaborative network, the partners, the partners' relations, sub-collaborative networks and also collaborative objective (through semantic links between the models drawn by the users and the collaborative ontologies of the IT system).

• New semantic and logic rules to deduce MIS-ready business BPMN processes that are compliant with the ISO 9001:2000 standard (i.e. three-level business process: decision, operation and support) ISO [START_REF] Iso | NF EN ISO 9001 version 2000[END_REF].

Figure 1.9 -Implementation of MISE 2.0, [START_REF] Benaben | Supporting interoperability of collaborative networks through engineering of a service-based mediation information system (mise 2.0). Enterprise Information Systems[END_REF].

• an enhancement of the deduction rules to better deal with gateways.

Right after the PIM deduction, Nicolas Boissel-Dallier [START_REF] Boissel-Dallier | Mediation information system engineering based on hybrid service composition mechanism[END_REF] focused on automatically getting a PSM. In this context, he implemented a n-to-m reconciliation between business activities of the BPMN PIM process and technical web services to obtain the collaborative work ow to be executed. Finally Sarah Zribi's PhD [START_REF] Zribi | Towards a service and choreography governance framework for future internet[END_REF] allowed to integrate the non-functional dimension to N. Boissel-Dallier's reconciliation service: she aims at implementing QoS (Quality of Service) into the reconciliation algorithms.

MISE3.0 aims at providing an even more "automated" tool for inter-organizational collaboration. Guillaume Macé-Ramète [START_REF] Macé-Ramète | A road crisis management metamodel for an information decision support system[END_REF] has worked on the whole MISE system in crisis management context. As part of his thesis, he modeled a core collaborative metamodel, which will be more detailed in Chapter 3: the goal is to provide an overall structure for any type of collaborations, that can be specialized with speci c domain layers depending on the needs of the user. This metamodel both involves organizational and IT levels of the collaborations. Based on all these researches, experiences, feedbacks, the current PhD thesis comes as a sequel of W. OpenPaaS is an advantageous environment to enhance inter-organizational collaborations because of several things:

• On a business level: each organization and its communities (i.e. the employees that share the same function within the organization) create an account on the platform and describe themselves. Then, interactions can happen thanks to collaborative services, in a very loosely way: both within the organization so that the employees/communities can communicate with each other and with the other organizations (cf. Figure 1.10).

Furthermore, social networks have now enter the daily life of a lot of people who consequently already know such environment. Thus, the human-machine interactions are facilitated, which is, for example, highly useful for the knowledge gathering step of MISE. • On a technical level: it relies on a Platform as a Service (PaaS), which is one of the three layers of Cloud Computing. According to Dillon et al. [START_REF] Dillon | Cloud computing: issues and challenges[END_REF], several concepts of the Service Oriented Architecture (SOA) can be easily applied to Cloud, such as the service description, discovery, composition and management. Besides, basically, the PaaS hosts SaaS (Softwares as a Service). The Figure 1.11 illustrates the use of OpenPaaS: (i) a set of collaborative SaaS are natively provided (such as shared calendar, videoconference, instant messaging, etc.), (ii) the organizations can provide their own SaaS, by deploying them directly on the PaaS via a module manager and (iii) the organizations can use these SaaS (under privacy conditions) (cf. Figure 1.11).

OpenPaaS design-time

The research works of this thesis that have been led within the OpenPaaS project, leverage the social aspect of OpenPaaS to address new challenges in supporting inter-organizational collaborations, during the design-time.

The Figure 1.12 illustrates in three steps the aims of the design-time supported by OpenPaaS:

1. The communities of the subscribing organizations create their pro le via a Pro le Modeler, where they describe their business activities.

2. Assuming that a community of any organization has a business opportunity to ful ll, but does not know how to achieve it and who to work with, it can propose a new collaborative opportunity on the platform, via an Objective Modeler.

3. Based on the repository of all communities' pro les and the objective described in the collaborative opportunity model, a business process deduction service selects the appropriate partners and describes their collaboration with a BPMN inter-organizational process.

Problem statement

Questions

As mentioned in Part 1.4.1, Vatcharaphun Rajsiri and Wenxin Mu already worked on a system for gathering collaborative knowledge and deducing inter-organizational business processes. However, the speci c context of OpenPaaS leads to raise some strong hypothesis of the previous works. Eventually, it is no more about specifying functional requirements to collaborate (i.e. deduce process that are "working"), but also to optimize them on non-functional criteria (e.g. time, cost, quality...). Hence, the thesis should answer various questions:

• The process deduction service is integrated within an ESN, which constrains the way to gather information about the collaborative context. Besides, to be fully e ective and user-friendly enough, the knowledge gathered from users should be su cient and minimal.

>Question 1: Which is the su cient but minimal knowledge to gather so that the business process could then be deduced?

• The coalition of partners is not initially known: while Wenxin Mu's works made the assumption of a set of partners coming together to ful ll their common or individual objective of collaboration, only (i) the objective of collaboration of the broker and (ii) a repository of organizations' pro les are gathered here.

>Question 2: Which are the functional mechanisms that allow selecting the partners, their business activities and transform that knowledge into a business process?

• Because it is an open platform dedicated to any company and any type of collaborations (i.e. many companies should be able to provide the same business activities), the organizations evolve in competition: when selecting the partners, only the "best" should be kept to achieve the collaboration, along the lines of VE and VSC paradigms.

>Question 3: Which are the non-functional criteria typically used to select partners (whatever the domain eld of the collaboration)? And how to use them in OpenPaaS context?

• Partners can not be selected one-by-one: for example to optimize the deduced process on time aspects, the set of all fastest organizations does not necessary lead to the fastest process (because of obvious tasks sequencing and parallelism issues when creating the process). >Question 4: How to conciliate both functional mechanisms and non-functional optimization when deducing the nal process, so that the whole process can be non-functionally evaluated?

Outline

Designing automatically inter-organizational collaborations is both a matter of computer and management sciences. Thus, the choices made to answer these questions are in line with both disciplines and also with the projects OpenPaaS and MISE since the results should be integrated as a part of them. Figure 1.13 relates the outline of this PhD report and also highlights the main contributions that have been developed and implemented to answer the four latter questions. The non-functional dimension is often met either in management science (e.g. to select best partners in bidding processes) or in computer science (e.g. to select best web services in service composition problems). Many terms can be used depending on the eld of application nonfunctional requirements, criteria, factors... but all of them address the same overall question: which are the criteria that should be taken into account when deciding who to work with? This question is not trivial. The platform o ers indeed an automated way to select partners when deducing the collaborative processes, which means that (i) the criteria should be adapted to their speci c use (i.e. be evaluable by an IT system, and consequently objective), (ii) they should comply with the needs of customers (i.e. they should adapt to a wide range of types of collaborations since OpenPaaS' collaborations could meet any business domains) and (iii) they should be assessed or informed in a relevant way to ESN context.

Chapter 2 aims at providing a new non-functional framework based on a literature review on non-functional criteria emerging from various business elds, and that is specially applied to ESNs. Non-functional criteria are also important for the two following Chapters since they are also involved when acquiring knowledge: when a company describes its pro le it also provides non-functional perception of its business (e.g. the cost of its products), and obviously in the process deduction step.

>Question 1: Which is the su cient but minimal knowledge to gather so that the business process could then be deduced?

In line with MISE previous iterations, a work has been realized on knowledge acquisition and exploitation, in order to (i) get organizations' pro les and (ii) get collaborative objectives when organizations propose new opportunities. First, knowledge reasoning means that information should be stored in a knowledge base and in a structured manner (i.e. following a speci c metamodel) such that it can be exploited to e ectively deduce collaborative processes at the end. The system integrates and updates knowledge but also creates semantic links between what the users want to describe and what the IT system already knows: in such a way, it is able to understand the users' needs. However, this means that a work should be led on "what the system already knows". In other words, generic collaborative knowledge bases should be natively implemented (generic meaning here that it is totally independent of the organizations). Second, priority has been given to the development of user-friendly interfaces so that the users can easily provide knowledge to the system: a Pro le Modeler enables the users to describe their business capabilities and store it into ontologies of collaboration, and an Objective Modeler enables the users to express their new business opportunities.

All of these steps are explained in Chapter 3: Collaborative knowledge management and acquisition.

>Question 2: Which are the functional mechanisms that allow selecting the partners, their business activities and transform that knowledge into a business process? >Question 4: How to conciliate both functional mechanisms and non-functional optimization when deducing the nal process, so that the whole process can be non-functionally evaluated?

Actually, Question 4 extends Question 2: it is not only a question of selecting partners and order their activities into a process, but also to optimize this selection. As seen in the previous part, it is about global optimization: the process should be deduced and optimize in the same time to be the most e ective. Global optimization is not a new problematic: many algorithms have already been developed in many elds (e.g. the traveling salesman and its famous solving methods). Hence, an overview of the available methods is important so that our problem can be positioned before choosing the most adapted method. Eventually, the researches have been oriented towards metaheuristics and more precisely Ant Colony Optimization (ACO) algorithm. However, it is quite uncommon to apply ACO to semantic systems and even more to the ontology exploitation. That is why a big part of the research works focuses on adapting the ACO to the collaborative ontologies exploitation.

Thus, Chapter 4 provides all explanations about the choice of the ACO and how it has been adapted to the OpenPaaS's aims.

Finally, the Chapter 5 illustrates the whole research approach through a use case and o ers a concrete visibility to the readers.

The framework for characterizing the collaboration within CNOs was presented in the Workshops of the I-ESA 2014 Conference [START_REF] Montarnal | A framework for characterizing collaborative networks of organizations. Enterprise Interoperability: Interoperability for Agility, Resilience and Plasticity of Collaborations[END_REF] and the article [START_REF] Montarnal | Social vision of collaboration of organizations on a cloud platform[END_REF], presented in the Workshops of the IWEI 2013 Conference states the context and raises the problematic of this PhD thesis.

Introduction

From the simplest buyer/seller relationships to the most complex bidding processes, making decision always remains a di cult and laborious step whatever the business eld and the nature of the decision. The rst reason is that decisions are never unidimensional: the decision maker has to think to many criteria -basically the famous advantages vs disadvantages list for "weighing the pros and the cons". The second reason concerns the way to exploit these criteria in order to take the "best" decision. About the rst previous concern, the rst thought often goes to the typical triptych cost, time and quality. However, this triptych is actually too vague and not su cient to be e ectively applied. In this regard, Cagno et al. [START_REF] Cagno | Multi-criteria assessment of the probability of winning in the competitive bidding process[END_REF] consider bids through multiple economic and technical criteria. Wu and Su [START_REF] Wu | Selection of partners in virtual enterprise paradigm[END_REF] mention that cost and time of completion are the most important factors to con gure a competitive VE, but also recognize that other dimensions such as quality, trust, credit, reliability should be considered. Indeed, numerous industrial and academic works have been conducted to address this issue. However in most of the cases the proposed criteria are quite speci c to some business domains and/or aren't provided with the corresponding metrics that would make them objectively assessable. Hence, this chapter aims at proposing a non-functional framework that relates the criteria usually taken into account for selecting partners and their business services -or products.

In a myriad of already existing surveys, Section 2.2 aims at expressing the speci c requirements of this non-functional framework by positioning it both within the literature and the OpenPaaS project context. Then, in Section 2.3, adapted criteria from various elds of application are selected in the literature with their corresponding metrics. Section 2.4 proposes a categorization of these criteria via a three-dimensional framework by applying them to the speci c needs of an ESN such as OpenPaaS. Finally, a short use-case illustrates how this framework can be used.

2.2

The need of a new non-functional framework 2.2.1 De nition of the "non-functional" dimension

Basically, the ISO 9001:2008 standard [START_REF]Quality management systems-Requirements[END_REF] de nes quality as "the degree to which a set of inherent characteristics ful lls requirements". These requirements have been de ned by several authors, and most of them agree on a di erence between functional and non-functional requirements (NFR). According to Van Lamsweerde [START_REF] Van Lamsweerde | Goal-oriented requirements engineering: A guided tour[END_REF] as well as Doerr et al. [START_REF] Doerr | Nonfunctional requirements in industry-three case studies adopting an experience-based nfr method[END_REF] the functional dimension concerns the services provided themselves while the non-functional dimension is about quality of service. The ISO/IEC/IEEE 24765:2010 standard [START_REF]Systems and software engineering -vocabulary[END_REF] is oriented towards software requirements but also o ers quite similar de nitions that can be expanded to any systems and kept as references:

"

A functional requirement is 1. a statement that identi es what a product or process must accomplish to produce required behavior and/or results (in [START_REF]Ieee standard for application and management of the systems engineering process[END_REF]) or 2. a requirement that speci es a function that a system or system component must be able to perform.

" "

A non-functional requirement is a software requirement that describes not what the software will do but how the software will do it.

"

This Chapter exclusively focuses on the non-functional dimension, by establishing a wide literature review on the usual non-functional criteria used for selecting partners.

Overview of the related literature

Actually, in the literature, Non-Functional Requirements (NFR) can be named di erently: nonfunctional factors, non-functional criteria, non-functional properties and even non-price factors also refer to the same concept. These terms depend on the business elds. Hence, Figure 2.1 summarizes the di erent areas of research concerned by them that have been studied in this Chapter, between both management and computer science. In management science, several NFRs were studied on three main topics: Supply Chain, performance analysis and make or buy relations. In computer science, two topics are particularly proli c on non-functional requirements: software quality and web service selection works.

Here again, the two areas of management science and computer science prevail: from supply chain management, to web service selection, through performance analysis (cf. Analyze step of the BPM lifecycle in 1.3.2). Each area uses speci c terms, since they actually study di erent points of view on NFRs (e.g. the web service selection NFRs are quite di erent from the key performance indicators in performance analysis, since the context is not the same). In the whole literature, non-functional criteria, properties, factors and requirements are the most used terms and have been burning topics these last ten years, as requests made on the major scienti c databases show in Figure 2.2.

Glinz [START_REF] Glinz | On non-functional requirements[END_REF] conducted a literature review on the categorization of non-functional requirements. It appears that, at this time, there was not a domain independent or a standard de nition of non-functional requirement in the engineering community. Glinz's observation is that a non-functional criteria is a constraint or an attribute that comes in opposition with the intrinsic functionality and behavior of the system, which complies with the de nition adopted in Part 2.2.1. On the one hand, the attributes can be performance level or speci c quality requirements expected by the broker. On the other hand, it can also be further constraints that the system should respect e.g. legal, environmental expectations. This Glinz's taxonomy is summarized in the Figure 2.3.

According to Glinz, the di erence between performance and quality requirements relies especially on the objectivity of the corresponding criteria: performance concerns rather objective and numerical assessment (e.g. timing, thoughput...), whereas quality deals with the perception of the system (e.g. reliability, usability...), which is rather subjective.

Besides, the concept of sustainable development has grown in the late half of the 20th century to become one of the major concerns of the current society. Its precursor, the Man and Biosphere program (MAB) was launched by UNESCO in 1971. About it, Batisse [START_REF] Batisse | Man and the biosphere: an international research programme[END_REF] mentions a certain lack of data at this time, which led to controversies, and a determination to establish data acquisition and exploitation to be able to assess environmental problems. The term "sustainable development" was then used for the rst time in 1980 [START_REF] Allen | World conservation strategy. Living resource conservation for sustainable development[END_REF]. One can note that from the beginning, sustainable development and ecological concerns have implied scienti c evidence. And, indeed, in most of the literature, such type of non-functional criteria comes along with the corresponding metrics. That is why, here, the Part 2.3.3 is dedicated to green and sustainable development criteria.

Non-functional criteria concern many areas, through several di erent keywords; they can be numerical or not, more or less impartial. In brief, apart from the sustainable development topic which has always been a very framed topic, studying non-functional criteria leads to the uncertain dimension of the human perception of what is "good" or not, all the more broad that the criteria can be seen di erently from a business domain to another. That is why there is now a need to reconcile all these points of view, in order to obtain a generic non-functional framework able to bene t to most of the existing business elds.

OpenPaaS context requirements

Obviously, the new non-functional framework resulting from this study of the literature must cover the needs of the OpenPaaS project. The use of the selected non-functional requirements is indeed constrained by the ESN in several ways: Non-functional requirements scope • Objectivity: quality, for example, is a wide topic, which is often rather subjectively understood. in order to enable an automated exploitation, these criteria should be the most objective possible. That means that for each of them, the associated sensitivity range should be adapted and distinguishable by an IT system. As a result, each criteria should go together with metrics.

• Wide scope: OpenPaaS aims at supporting any kind of collaboration, whatever their eld of application. Actually, the users should be able to nd their usual decision criteria, although all the criteria will not necessary be used together for one collaboration.

Survey on non-functional criteria for partner selection and their assessment 2.3.1 Non-functional criteria

One of the most cited and famous non-functional framework is SERVQUAL, established by Parasuraman et al. [START_REF] Parasuraman | Servqual[END_REF]. This framework rather focuses on the customer point of view: what makes him satis ed of a service and which dimensions does he take into account when assessing the quality of the service. Parasuraman et al. [START_REF] Parasuraman | Servqual[END_REF] studied several di erent services, and worked on the gap between the customer expectations and the perception of the provided service. Nyeck et al. [START_REF] Nyeck | 10 years of service quality measurement: reviewing the use of the servqual instrument[END_REF] claim that this framework has been intensively used since many years, considering SERVQUAL as the "most complete attempt to conceptualize and measure service quality". According to Nyeck et al. [START_REF] Nyeck | 10 years of service quality measurement: reviewing the use of the servqual instrument[END_REF], its success is due to the possibility to apply it to many service sectors. In its second version in 1988, SERVQUAL [START_REF] Parasuraman | Servqual[END_REF] de nes the service quality through ve dimensions established on subjective trust from the customer as well as on technical skills: tangibles, reliability, responsiveness, assurance, empathy. However, to respond our issues, SERVQUAL rather brings the main orientation of research on service selection criteria, since the SERVQUAL remains high-level.

Roman [START_REF] Roman | A taxonomy of current issues in requirements engineering[END_REF] and Boehm et al. [START_REF] Barry W Boehm | Quantitative evaluation of software quality[END_REF] propose major (and highly cited) works on the NFR topic. They actually focus on software engineering. Roman [START_REF] Roman | A taxonomy of current issues in requirements engineering[END_REF] proposes a taxonomy of NFR through ve constraints:

• Interface constraints which de ne interactions between a component (software package, hardware device or the whole system) and its environment (users, operating system, hardware, software packages).

• Performance constraints are related to time and space bounds (workload, storage space, response time), security, reliability (integrity of the information maintained or supplied by components) and survivability (e.g. o -site copies of databases).

• Operating constraints are linked to the physical constraints, human resources (skills, availability), maintenance, environment and location.

• Life-cycle constraints are dealing with the design, the maintenance and the enhancement process of the component.

• Economic constraints consider the costs on both immediate and long term.

• Political constraints represent the policies and legal issues (local law).

Roman [START_REF] Roman | A taxonomy of current issues in requirements engineering[END_REF] states that, as the component has interactions with its environment, the environment impacts the complexity of the component design. So he describes the NFR as constraints on the environment in order to reduce the component complexity. If the categories of this taxonomy are mainly domain independent, a part of the NFR are domain dependent, i.e. oriented towards software engineering problematic ("operating system" cannot be used in a business domain like food processing). NFR classi ed under political constraints and economic constraints are common to any business domain. Performance constraints and operating constraints NFR can also be applied to a product or a service, whatever the business domain is. Other NFR (Interface constraints and Life-cycle constraints) should be adapted to be more generic or at least to cover a wider domain than software engineering only.

In the eld of virtual manufacturing systems, Davidrajuh and Deng [START_REF] Davidrajuh | Identifying potential supplier for formation of virtual manufacturing systems[END_REF] present three factors to select suppliers: agility, leaness and quality. According to Charles [START_REF] Charles | Improving the design and management of agile supply chains : feedback and application in the context of humanitarian aid[END_REF], agility is the ability of an organization to respond quickly and e ciently to the unexpected (e.g. changes on customer needs). Leaness is the set of e ective costs of the supplier: these costs represent the supplier quotes but also various additional costs like transportation, taxes, etc. Quality, here, is the ability of the supplier to be, at least, ISO certi ed and to be evaluated by audits.

Xia and Wu [START_REF] Xia | Supplier selection with multiple criteria in volume discount environments[END_REF] focus on the problem of supplier selection in the eld of supply chain management. They propose a four-level hierarchy to evaluate and select suppliers: (i) objective (evaluation and selection of suppliers), (ii) criteria, (iii) sub-criteria and nally (iv) suppliers alternatives. Criteria are both qualitative and quantitative: price, quality and service. Quality and service contain sub-criteria:

• Quality: technical quality of the products, their defects and their reliability.

• Service: services the supplier is able to provide about its products (on-time delivery, supply capacity, repair turnround time and warranty period).

It is interesting to note that this analytical hierarchy process for supplier selection is not dedicated to a speci c business domain.

Garvin [START_REF] David | What does "product quality" really mean[END_REF] tries to answer to the question: what is quality for a product? As product quality can be seen through a high cost, it can also be seen just through its characteristics and attributes or it can be a correlation between the performance of the product and an acceptable cost. The objective of Garvin [START_REF] David | What does "product quality" really mean[END_REF] is to aggregate all the di erent de nitions of quality in order to establish a global framework for better understanding the main element of quality. The author has based the framework on eight dimensions: performance, features, reliability, conformance, durability, serviceability, aesthetics, perceived quality.

Hansen and Bush [START_REF] Hansen | Understanding customer quality requirements: Model and application[END_REF] aim at de ning what is the quality of a product and of a service. For this purpose, they have exploited the results of a questionnaire answered by more than 800 people. Finally, eighty criteria were classi ed according to the SERVQUAL and Garvin's dimensions. This framework is quite product-oriented, as a consequence of Hansen and Bush's eld of study (wood purchasing). One can note that Hansen and Bush [START_REF] Hansen | Understanding customer quality requirements: Model and application[END_REF] add cooperativeness as one more dimension to the thirteen axes of study about quality coming from SERVQUAL ( ve dimensions) and Garvin (eight dimensions). In addition, their framework aims at being only oriented towards service or product quality, with the choice of leaving aside price and cost dimensions. Although this framework is quite product-oriented, and rather speci c to the wood/lumber purchasing, several criteria are relevant, whatever the eld of application:

• Service reliability: "Consistent, on-schedule delivery by supplier", "Product availability" and "Accuracy of supplier's billing system".

• Responsiveness: "Supplier's ability to deliver quickly on short notice", "Eagerness of supplier's salespeople to meet your needs" and "Supplier rapidly responding to and solving problems".

• Assurance: "Knowledge and skill of supplier's sales personnel", "Manufacturing espertise of the supplier", "Dealings with supplier being held con dential" and "Supplier's ability to understand conditions of special orders".

• Empathy: "Being recognized by supplier's salespeople as a regular customer".

• Tangibles: "Supplier's physical facilities", "Tools/equipment used" and "convenience of supplier's location".

• Perceived quality: "Reputation of supplier" and "Previous experiences with supplier".

• Cooperativeness: "Supplier's willingness to ll large orders", "Supplier's willingness to ll small orders", "Supplier-arranged shipping", "Credit terms o ered by supplier", "Longterm price arrangements o ered by supplier" and "Just-in-time (JIT) delivery o ered by supplier". [START_REF] Ho | A hybrid approach to supplier selection for the maintenance of a competitive supply chain[END_REF] propose a list of thirty criteria based on a literature review from 1966 to 2000 that are commonly used for selecting partner in supply chain collaboration. Even if many of these criteria also correspond to the criteria kept from Hansen and Bush [START_REF] Hansen | Understanding customer quality requirements: Model and application[END_REF], it is interesting to cross several non-functional frameworks. Also, Ha and Krishnan [START_REF] Ho | A hybrid approach to supplier selection for the maintenance of a competitive supply chain[END_REF] o er a somewhat generic perception. Actually, their work is based on the propositions of several papers on the topic, written by Dickson [START_REF] Dickson | An analysis of vendor selection systems and decisions[END_REF], Wind et al. [START_REF] Wind | The determinants of vendor selection: The evaluation function approach[END_REF], Lehmann and O'shaughnessy [START_REF] Donald R Lehmann | Di erence in attribute importance for di erent industrial products[END_REF], Perreault and Russ [START_REF] William | Physical distribution service in industrial purchase decisions[END_REF], Abratt [START_REF] Abratt | Industrial buying in high-tech markets[END_REF], Billesbach et al. [START_REF] Billesbach | Industrial buying in high-tech markets[END_REF], Weber et al. [START_REF] Weber | Vendor selection criteria and methods[END_REF], Segev et al. [START_REF] Segev | Procurement in the internet age-current practices and emerging trends (results from a eld study)[END_REF], Min and Galle [START_REF] Min | Electronic commerce usage in business-to-business purchasing[END_REF] and Stavropolous [START_REF] Stavropolous | Suppliers in the new economy[END_REF], and twenty of their criteria seem interesting and if not always kept, at least have oriented the researches. "Price" comes as the favorite criteria for nine on ten authors. Seven of them attache importance to the "Delivery" which however does not bring more detailed position (e.g. shipping arrangement or only ability to deliver products?). Then six mention "Quality" as a key factor for selecting partners which notion could also be more detailed. The "Reputation and the position in industry" is actually important for half of the authors, which supports the results of Hansen and Bush [START_REF] Hansen | Understanding customer quality requirements: Model and application[END_REF]. Finally, four of them bring criteria that are not all so far from the one from Hansen and Bush [START_REF] Hansen | Understanding customer quality requirements: Model and application[END_REF]: "Warranties and claims", "Technical support", "Attitude", "Performance history", "Geographical location", "Labor relations", "Response to customer request", "JIT capability", "Technical capability", "Production facilities and capacity", "Operational controls", "Maintainability", "Amount of past business", "Reciprocal arrangements", "Environmentally-friendly products" and "Product appearance". [START_REF] Min | Supply chain modeling: past, present and future[END_REF] propose a set of key components for the supply chain thematic that are directly organized towards the use of this non-functional framework through three types of parameters:

Ha and Krishnan

Min and Zhou

• Goals: the "Supply Chain Drivers" that are the driving forces of the supply chain.

• Constraints: the"Supply Chain Constraints" that deal with the feasability of the supply chain.

• Decision variables: the "Supply Chain Decision Variables" related to the performances of the supply chain.

The Table 2 Non-price factors are discussed in the eld of the competitive bidding as important criteria that can increase the probability of winning in a competitive bid process in the industry. Competitive bidding is a method used to obtain goods and services at the best price and contract terms by stimulating competition among contractors and suppliers. Barnes et al. [START_REF] Barnes | Developing manufacturing competitiveness within South African industry: the role of middle management[END_REF] state that quality, innovation, adherence to standards and rapid response are the rst non-price factors that can provide an advantage into a competitive market. Cagno et al. [START_REF] Cagno | Multi-criteria assessment of the probability of winning in the competitive bidding process[END_REF] describe a set of thirteen factors to evaluate a competitive bid, in the context of the design and the construction of a process plant. These factors are classi ed under four categories: service level, plant performance, nancial conditions and contractual conditions. If some of them are strongly related to the process plant use-case, others can be extracted to be adapted to a more generic business case such as delivery time, price, terms of payment, nancial package, dependability, conformity to tender documents.

Metrics

In service quality eld, important research domains for non-functional criteria are web services and software engineering. OASIS (Organization for the Advancement of Structured Information Standards) [START_REF] Bosak | Web services quality factors version 1.0. Organization for the Advancement of Structured Information Standards (OASIS)[END_REF], an international consortium creating interoperable industry speci cations, has designed a speci cation to describe quality attributes of web services. These quality attributes are represented by functional and non-functional properties. They are classi ed under six categories: business value quality, service level measurement quality, interoperability, business processing, manageability and security. Even if this WSQF (Web Service Quality Factors) speci cation focuses on web services and do not necessary t with a more generic context, it is interesting to note that it is commonly used to select web services for orchestrating processes, as shown by Zribi et al. [START_REF] Zribi | Enhancing services selection by using non-functional properties within bpmn in soa context[END_REF]. In a way, this selection of web services is similar to the selection of partners based on non-functional criteria. Minus the domain dependent criteria, we can extract non-functional criteria from this speci cation: price, penalty and incentives, business performance, service provider reputation (for organization reputation in a generic framework), and privacy. Compared to most of the frameworks found in the literature, this speci cation has the advantage to propose the users ways to evaluate the criteria, which could be called "metrics" even if they do not always correspond to numerical formulas. The Table 2.2 gives a summary of the major criteria, with their corresponding categories and metrics.

Badr et al. [START_REF] Badr | Enhancing web service selection by user preferences of non-functional features[END_REF] studied the web services selection through non-functional properties. They designed a categorization ontology for the non-functional properties: they are divided into Quality of Service (QoS) properties (response time, accessibility, compliance with WSDL, successability, availability, encryption, authentication, access control, etc.) and Context properties (cost, reputation, organization arrangement, payment method, monitoring, location, temporal properties). Comparing this ontology to the WSQF speci cation, it appears that they share most of their criteria, exception made of three criteria (that exist only in Badr's ontology [START_REF] Badr | Enhancing web service selection by user preferences of non-functional features[END_REF]): the location, the payment method and the organization arrangement. These three criteria are relevant to the framework as they are domain independent and they add additional criteria for partner selection (location of a partner may in uence its delivery time, as well as the payment method may facilitate nancial transactions). The last criterion, "organization arrangement", is based on the knowledge gathered on the current and previous collaborations. As it allows detecting organization's preferences of partnerships, this feature is interesting to meet the suppliers' relationships category of the framework.

Answering this issue, one of the most complete work on supply chain KPIs is the SCOR (Supply Chain Operations Reference) model developed by the Supply-Chain Council [START_REF]SCOR supply chain operations reference model[END_REF] [START_REF] Bosak | Web services quality factors version 1.0. Organization for the Advancement of Structured Information Standards (OASIS)[END_REF] famous management tool for the supply chain function, divided into three main parts: process modeling, performance measurements and best practices. The performance measurements proposed in this framework are particularly interesting here. They are organized in ve main dimensions: reliability, responsiveness, agility, costs and asset management e ciency. Each of these dimensions is decomposed into three levels: rst the strategic metrics, then the metrics to identify the causes of a gap in rst level, and nally the third as a diagnosis of the second level.

For example, reliability can be assessed by "perfect order ful llment", which can be decomposed into "% of orders delivered in full", "delivery performance", "documentation accuracy" and "perfect condition". Then "% of orders delivered in full" goes with "delivery accuracy" and "delivery quantity accuracy". The SCOR also proposes a calculation method: % o f or d er s d el i ver ed i n f ul l =

Tot al number o f or d er s d el i ver ed i n f ul l Tot al number o f or d er s d el i ver ed

. The SCOR model results in more than 500 three-level metrics, which obviously can not be summed up here; even though it is a huge and accurate source for the metrics of the non-functional criteria of the nal framework.

Towards green and sustainable development criteria

Srivastava [START_REF] Samir | Green supply-chain management: a state-of-the-art literature review[END_REF] introduces the green supply chain management as a way to deal with the in uence of supply chain on natural environment, which has become a crucial issue these last years. For the author, this concept should be extended from the product design phase up to the delivery phase, i.e. all along the whole supply chain process. Schwarz et al. [START_REF] Schwarz | Use sustainability metrics to guide decision-making[END_REF] indeed claim that sustainable development is now a "core business value" for companies and the establishment of metrics helps the integration of this new dimension in decision-making processes. Ashby et al. [START_REF] Ashby | Making connections: a review of supply chain management and sustainability literature[END_REF] make a very close link between the two terms green and sustainable supply chain management. Moreover many literature reviews show the growing concerns about way to evaluate and measure the performance of green and sustainable supply chains [START_REF] Hassini | A literature review and a case study of sustainable supply chains with a focus on metrics[END_REF][START_REF] Seuring | From a literature review to a conceptual framework for sustainable supply chain management[END_REF][START_REF] Ahi | An analysis of metrics used to measure performance in green and sustainable supply chains[END_REF]. Derrouiche et al. [START_REF] Derrouiche | Integration of social concerns in collaborative logistics and transportation networks[END_REF] highlight especially that collaborative networks should now meet the sustainable development requirements through the three usual dimensions: environmental, social and economic. [START_REF] Bai | Integrating sustainability into supplier selection with grey system and rough set methodologies[END_REF] propose three tables of attributes based on a literature review, according to the three dimensions of the sustainable development. For example, the business and economic table proposes attributes re ned in 8 categories cost, quality, time, exibility, innovativeness, culture, technology, relationship. Then each category is precised through low-level criteria like delivery speed for time, or suppliers speed in development for technology. It is interesting to underline that most of the economic and business criteria of this framework are not quite distinguishable of previously cited criteria. That is why this part will only focus on the environmental and social topics. Note that the linkage between the two rst paragraphs of this literature review, i.e. quality criteria and performance criteria, showed that the rst one is very usefull to provide a common vocabulary for the designation of each criteria and the second one is quite oriented towards the formulas or technics to concretely assess them. In the same way, Bai and Sarkis [START_REF] Bai | Integrating sustainability into supplier selection with grey system and rough set methodologies[END_REF] provide a deep study about the di erent commonly used criteria but do not extend it to the metrics.

Bai and Sarkis

In this perspective, the SCOR Reference [START_REF]SCOR supply chain operations reference model[END_REF] dedicates an entire part to green topics: the GreenSCOR. Five particular metrics are provided, and should allow users to focus especially on the environmental component of the sustainable development, in supply chain sector:

• Carbon emissions (Tons CO2 Equivalent): helps measuring the green house gas emissions.

• Air pollutant emissions (Tons or kg): measures the quantity of COx, NOx, SOx, volatile organic compounds and particulate emitted.

• Liquid waste generated (Tons or kg): "includes liquid waste disposed of or released to open water or sewer systems".

• Solid waste generated (Tons or kg).

• % recycled waste (Percent).

Hutchins and Sutherland [START_REF] Margot | An exploration of measures of social sustainability and their application to supply chain decisions[END_REF] focus on the social measures of sustainable development. In particular, they deal with the selection of suppliers in the context of supply chain and consequently study the social impact of the companies. Their work on the measures of social sustainability for supply chain decision-making mentions, among others, the work of the United Nations Division of Sustainability Development [START_REF]Indicators of sustainable development: Guidelines and methodologies[END_REF] that categorizes social indicators. However, as rightly highlighted by Hutchins and Sutherland [START_REF] Margot | An exploration of measures of social sustainability and their application to supply chain decisions[END_REF], the U.N. Guidelines are very complete and all the criteria could not be applied by a company (e.g. access to drinking water or education...), even if some corporations sometimes lead philanthropic activities. Finally they propose four indicators with corresponding examples of metrics, that are not claimed to be exhaustive. Their strength lies in the fact that the criteria are quanti able and exploit generally public and available information. The indicators and the proposition of corresponding metrics are as follows:

• Labor E qui t y =

Aver ag e hour l y l abor cost C ompensat i on o f t he hi g hest pai d empl oyee

• Heal t hc ar e =

Heal t hc ar e pai d per empl oyee M ar ket c api t al i zat i on per empl oyee

• Sa f et y = D a y s not i n j ur ed per empl oyee D a y s wor ked per empl oyee

• Phi l ant r op y = C har i t abl e cont r i but i ons M ar ket c api t al i zat i on

Synthesis of the literature review

The evaluation of existing frameworks and standards about non-functional criteria for partner selection lead us to the following conclusion. A major part of existing works focus on a speci c sector since they do not need to deal with a very large scope of business elds. The literature shows that non-functional criteria are often seen as cost, delay or quality factors which is quite reductive to represent the variety of non-functional criteria. Moreover, some do not share the same granularity: some criteria can be very high or very low level depending on the studied framework. In order to be used in the context of OpenPaaS, they need to be adapted to a larger scope, but also to be measurable.

Thus, all these criteria need to be merged together in order to obtain a new adapted nonfunctional framework (i.e. that t industrial current needs), both service or product oriented, and that proposes coherent, relevant and quantitative measures. Besides, one can note that, even if they do not t perfectly with the pursued goal (i.e. covering any for at least, most of existing business domains), an adaptation can be made to keep the most relevant part of these frameworks in our proposal. Still, it remains that some frameworks intend to propose generic partners evaluation criteria but they su er from a too generic and implicit description: they propose mostly concepts or family of criteria rather than explicit sets of criteria (possibly categorized by business domain).

Most important, none of the already existing non-functional frameworks explains how to assess these criteria, and even mentions if they are adapted to human or computer evaluation. Although some of them at least linger on associated metrics, they are not adapted at all to the actual information technologies. They still need to be categorized according to how their data can be gathered in an automated context and also adapted to Virtual Breeding Environments (VBE).

OpenPaaS' Application

How to assess non-functional criteria

As an ESN, each subscribing organization must describe itself in a pro le. These pro les come as a portfolio of all of their business capabilities that they want to provide for collaborations. Thus this is where the users should access the non-functional assessment. Non-functional assessment could be indeed categorized through three types of attribution:

• Directly in an organization's pro le (cf. Figure 2.4 a): when the criteria are rather objective and can directly be informed by the provider on its pro le.

• By current or former partner's (cf.

Levels of application for the OpenPaaS' non-functional criteria

In the previous literature review a lot of non-functional criteria are discussed and some of them prove to be much more an assessment of the organization itself than just only for one of its capability. For example, if the organization has an e ective and accurate billing system, for example, consequently any of its capabilities will also have such quality of billing system. Here, it is considered that there exists a kind of inheritance of the non-functional criteria can be set up. Here, the services inherit from the organization.

Moreover, the non-functional criteria not only assess partners and their capabilities in OpenPaaS but also provide the broker a way to express its non-functional expectations for the collaboration. For example, a minimal-cost collaboration but strictly con dential will lead to choose the "best" partners, which necessarily must accept con dentiality agreements. As a consequence the organization level inherits from the collaboration level. In the same logic, every service provided by an organization inherits from its characteristics. Finally, the product level leads to questions like the size of the orders or its technical characteristics, which are quite di erent of what can be assessed on a "pure" service. Furthermore, products usually do not exist without support services all around (billing, transportation...), especially with the emergence of new productservice systems and more generally the whole thematic around servitization. That is why this framework proposes an inheritance from product to service levels.

Four levels have emerged: product, service, organization and collaboration. The Figure 2.5 illustrates these four levels of application of the non-functional criteria.

OpenPaaS' non-functional categories

As a formal illustration of what makes a product or a service valuable, Johansson et al. in [START_REF] Henry J Johansson | Business process reengineering: Breakpoint strategies for market dominance[END_REF] express four top-level dimensions: quality, service, cost and time. In order to evaluate in a qualitive way these four concepts, the authors propose that the value can be represented as follows:

Tot al v al ue = (Qual i t y * Ser vi ce)/(C ost * T i me)

(2.1)
The usual goals are indeed to improve quality and service, with lower costs and less time of process. As illustrated in Figure 2.6, the four dimensions can also be de ned through various criteria. It is important for the user to organize the numerous criteria so that he can choose the one he wants to apply to his partners selection.For this purpose, it was decided to choose the Equation 2.1 from Johansson et al. as a way to categorize these criteria. It is indeed an intuitive categorization, and it it is very relevant to the context since the four dimensions (Quality, Service, Cost and Time) t quite well the usual industrial approaches for partners selection. Four tables (Table 2.3, Table 2.4, Table 2.5 and Table 2.6) relate the selected criteria for this framework, according to the four Johansson's categories, and for each of these criteria, the corresponding de nitions, metrics and references are given. Their application level and the way to assess the non-functional criteria are also speci ed, and allow to apply them to OpenPaaS' context. In an e ort to make these tables more readable, the following abbreviations have been used:

OpenPaaS' nal framework

• Application level: App. Can be applied on the four levels: Collaboration (Col), Organization (Org), Service (Serv) and Product (Prod).

• Ways to assess the criteria: Who? Can be assessed on the three levels: Own Pro le (OP), Partners' Pro les (PP) and IT System (S).

Levels of application

Ways to fill

Categories

The Gruppo Poligra co Tiberino case

In order to give a concrete point of view on this non-functional framework, this Section aims at confronting it to a real case study. The Gruppo Poligra co Tiberino (GPT)1 provides a successful example of CNO and has been widely mentioned and studied in the academic literature thanks to the integration of the University of Perugia during its expansion phase as of 2005. Although these research works are actually independent of the GPT, it o ers an ideal real case to illustrate these research works.

Gruppo Poligra co Tiberino, the origins

The GPT is a network of 21 companies working on the eld of communication, printing, packaging and related services and products, all situated in the Umbria region, Italy.

Aver ag e hour l y l abor cost C ompensat i on o f t he hi g hest pai d empl oyee

Philantropy

Org OP

C har i t abl e cont r i but i on M ar ket c api t al i zat i on

Healthcare

Serv OP

Heal t hc ar e pai d per empl oyee M ar ket c api t al i zat i on per empl oyee

Safety

Percentage of waste recycled by the organization Serv OP D a y s not i n j ur ed per empl oyee D a y s wor ked per empl oyee 2.8. To study this system, the authors provide a decomposition into two steps:

• The creation of the CNO concerns inter alia the selection of partners to evolve in this system. These should be complementary companies likely to bring their various skills and competencies together to develop new BOs (i.e. new products or services). The geographically closeness can be rst seen as a way to reunite the organizations in spite of the lack of common information systems for example, however the structure must also be adapted to involve further external and more distant partners.

• The management phase deals with the relevant utilization of such CNO both at a management level of the whole structure and at the BO identi cation and response level.

Applying the non-functional framework to the VE/VO/VEE creation

Suppose that the editor of a photography magazine would like to nd partners to print its monthly issues, and that the non-functional framework is used to select partners via the VDO o ered by the GPT. It is interesting to think about the criteria adapted to this situation that would enable to select the best partners in this context.

First, such type of magazine aims at being competitive on a cost level, however it is not as essential as it is for a daily newspaper. However, the quality of the printing is a key success factor. Leadtimes are also not negotiable since the issues should be available in kiosk the same day every month. That could be summarized by using the following criteria:

• Quality:

-Expected quality: minimum 4.5/5. The quality of the nal product (i.e. the magazine) should be very high, since it can be seen as one of the key success factor of a Figure 2.8 -VDO model in GPT, [START_REF] Saetta | The innovative model of the virtual development o ce for collaborative networked enterprises: the gpt network case study[END_REF].

magazine about photography.

-Eagerness to meet the needs: minimum 4.5/5. It comes along with the expected quality: the partners should have the same enthusiasm for quality as the editor.

-Knowledge and expertise assessment: minimum 4.5/5. Printing photography, even for a magazine, relies on very technical methods that should be entirely controlled.

-Reliability: minimum 4.5/5. Such type of magazine implies a constant quality of product.

• Service:

-Ability to understand special orders: minimum 4/5. For each issue, the number of printed magazines are not the same: in the world of journalism, it depends on the subjects mentioned in the magazine, if they are burning topics they will probably be easier to sell.

-Large or small orders: large orders accepted. As distributed products at least all over a country, magazines are typically printed in large orders, so that they can be sent to all newsstands.

• Cost:

-Price: maximum 1€/product. Depending on the price xed for the buyers of the magazine, 1€/product is an example of the maximal price the editor (i.e. the broker in this case) is willing to pay.

-Payment methods: bank transfer accepted. Here, the editor would like to pay via bank transfer method and expect the partners to match this constraint.

Discussion

-Long-term price agreements: yes. As the editor expect to publish a monthly magazine for several years, good relationships on long term are expected, in opposite to one-shot tasks like printing invitation cards for particular celebrations.

• Time:

-On time delivery: minimum 99%. On time delivery is obviously essential for a monthly magazine.

-Delivery lead time: maximum 5 days. Supposing that during the month, the editorial board has to select the subjects of the issue and to write or select waiting articles (i.e. some articles about traveling for example can be independent of the actuality and thus sent by a photograph months before being published), 5 days could nally remain to actually print the nal version of the issue.

-Agility: minimum 3.5/5, immediate reaction time. Sometimes, editorial boards need to correct nal errors at the last moment. Even if it probably doesn't happen too often, the reaction time should be very short, so that there are not too many unsaleable magazines.

Discussion

Improving the exibility with combinations of criteria

The latter non-functional framework tries to address OpenPaaS non-functional partner selection issues by proposing a wide scope of criteria i.e. that ts very various contexts of partner selection and criteria that aims at being measurable and the most objective possible. However, its exibility could be improved for several reasons. First, even if a large scope of criteria have been studied in the literature review, there remain a certain percentage of collaborative projects that are extremely speci c on a technical point of view. In such cases, enterprises may not nd the exact criteria they need. Then, a lot of enterprises already have established their own framework when selecting their partners. Thus they do not necessarily use the exact same granularity as it is proposed here, and they need to be able to express their own level of criteria.

In this context, one solution could be easily provided by o ering the users to mix criteria and aggregate them into a new speci c criterion.

Inter-dependencies between Non-Functional Criteria

Non-functional criteria may be subject to ranking and/or inter-dependencies. Among the set of non-functional criteria, ranks may be de ned to sort criteria according the collaboration goals.

For example, con dentiality may be most important than price of the service.

Moreover, non-functional criteria can be interdependent. As underlined by Asadi et al. [START_REF] Asadi | Toward automated feature model con guration with optimizing non-functional requirements[END_REF],

changing the value of one non-functional criteria may change the value of another nonfunctional criteria. Increasing the ability to respond to a special order may increase the time delivery.

In addition, interdependence and criteria ranking may lead to a complex process selection. Looking at the previous example, it appears that if both ability to respond to a special order and short time delivery are considered as the most important criteria to deal with, their interdependency will make the process of collaborative partners selection di cult (increasing the value of the rst one will decrease the value of the second one).

Improving the selection of relevant non-functional criteria

Even if this non-functional framework comes as a potentially powerful help as a decision-making tool, the user still needs to provide a signi cant e ort. As he proposes a new opportunity of collaboration in the platform, a work should be carried about what are the relevant nonfunctional criteria to express the objectives and the constraints of this future collaboration. On this step, for now, the system can not provide any help to the user. However, a rst idea to resolve this issue could be to use the SCOR model: it proposes a correlation between processes and metrics that can be applied. Thus the system could ask the users about the type of process they want to build, and a set of corresponding and potentially relevant non-functional criteria could be advised.

Since the SCOR model only focuses on supply chain collaborations, others sources of such correlations concerning other sectors need to be found and applied as well.

Conclusion

More than an updated literature review on the burning subject of non-functional criteria to use for partner selection, this Chapter brings two contributions. (i) The literature review has initially been based on various topics as quality and performances assessment factors, but also IT or any other services and products. Some of them have been industrially approved and used for years now, both in research and industry elds. (ii) There has been a determination to provide metrics or measures associated to each adopted criterion, so that it could be useful and inspiring in industrial "non-automated" real cases as well as in OpenPaaS' automated partners selection step. It also provides a measuring scale so that the users can: objectively and easily assess current or former partners, and have a better understanding and interpretation. Bien que le framework non-fonctionnel résultant de ce chapitre ne se veuille pas exhaustif, le large point de vue adopté permet de l'appliquer dans de nombreux domaines métiers, tandis que l'association de métriques aux critères le rend adaptable à de nombreux contextes industriels de sélection de partenaires (dans le cadre de RSEs ou non).

Collaborative Knowledge Representation and Acquisition

"The beginning of knowledge is the discovery of something we do not understand. " -Frank Herbert, God Emperor of Dune

Introduction

Knowledge Management (KM) is not a recent problem. Indeed, before having been applied to expert systems around the 60's, and then to information systems around the 80's, it actually has its rst origin in philosophy through two main terms epistemology and ontology. Plato, Socrates and Aristotle could be cited as precursor philosophers that have thought of what is knowledge.

On the one hand, Descartes (1596-1650) and his Discourse on Method [START_REF] Descartes | Discours de la méthode[END_REF] in 1636, followed by Kant (1724-1804) in 1781 with, for example, the Critic on pure reason [134] are two pioneers of epistemology. According to the Stanford Encyclopedia of Philosophy [135], epistemology, in its narrow de nition, is "the study of knowledge and justi ed belief". On the other hand, Dhondt [START_REF] Dhondt | Science suprême et ontologie chez aristote[END_REF] looks back on the status of ontology in Aristotle's works [START_REF] William | Aristotle's metaphysics[END_REF] who was particularly interested in the ways to structure scienti c knowledge and how to situate each science in the universal knowledge. Beets [START_REF] Beets | L'ontologie de thomas d'aquin[END_REF] explains that the term ontology was taken over by the Scholastic, in particular with the works of Thomas Aquinas (1225-1274). In modern times, the emergence of basic expert systems has then given way to the Semantic Web -rst mentioned by the creator of the World Wide Web Tim Berners-Lee. In the Semantic Web eld, Davies et al. [START_REF] Davies | Towards the semantic web: ontologydriven knowledge management[END_REF] summarize knowledge management in fours phases: (i) knowledge acquisition, (ii) knowledge representation, (iii) knowledge maintenance and (iv) knowledge use.

This Chapter concerns the two rst points of this lifecycle and address the issue: which is the minimal and su cient knowledge to acquire in order to deduce inter-organizational business processes? This question can be answered by structuring and implementing ontologies. That is why Section 3.2 proposes a literature review on knowledge management and Semantic Web.

Section 3.3 relates the semantic structure chosen to answer this speci c problematic, whilst Section 3.4 focuses on the knowledge bases used to populate the ontologies. Finally, Section 3.5 illustrates the acquisition of collaborative knowledge within the OpenPaaS' context via a simple use-case.

3.2 From knowledge management to Semantic Web

Introduction to Knowledge Management De nition of Knowledge Management

Dalkir [START_REF] Dalkir | Knowledge management in theory and practice[END_REF] proposes a de nition of KM as follows:

" Knowledge management is the deliberate and systematic coordination of an organization's people, technology, processes, and organizational structure in order to add value through reuse and innovation. This is achieved through the promotion of creating, sharing, and applying knowledge as well as through the feeding of valuable lessons learned and best practices into corporate memory in order to foster continued organizational learning.

"

In other words, KM aims basically at capitalizing knowledge within an organization, and reusing it with the purpose of improving the e ciency or the relevance of a system. This de nition could be easily applied also to networks of organizations, for example to transmit the know-how among the partners of a supply chain. However, one can wonder what is actually knowledge? This term has been widely debated for centuries, and used by many di erent disciplines. The de nition of knowledge as a "Justi ed true belief" is commonly accredited to Plato [141]. The Cambridge English Dictionary de nes knowledge as the "understanding of or information about a subject that you get by experience or study, either known by one person or by people generally" [142]. Hislop [START_REF] Hislop | Knowledge management in organizations: A critical introduction[END_REF] mentions "the ability to de ne and understand situations and act accordingly". The de nition of Milton [START_REF] Nick R Milton | Knowledge technologies[END_REF] is illustrated by Figure 3 E ectively, the acquisition, the storage and the exploitation of growing amounts of data are currently important challenges, considering the bene ts for organizations (e.g. more e cient decision support systems, potential for open innovation, improved supply chain management...). Thus, in computer science, the distinction between data, information and knowledge has been debated, and Rus and Lindvall [START_REF] Rus | Guest editors' introduction: Knowledge management in software engineering[END_REF] give a concise summary through the three following de nitions (see Figure 3.2):

" Data consists of discrete, objective facts about events but nothing about its own importance or relevance; it is raw material for creating information.

" "

Information is data that is organized to make it useful for end users who perform tasks and make decisions.

" "

Knowledge is broader than data and information and requires understanding of information. It is not only contained in information, but also in the relationships among information items, their classi cation, and metadata (information about information, such as who has created the information). Within this PhD thesis, knowledge does not only "belong" to each organization: on the contrary, the underlying issue here is rather how to relevantly gather knowledge on all the organizations of the collaborative platform, so that it can be then exploited? In other words, the organizations are able to provide information (i.e. which business services they are able and willing to provide and which opportunities they would like to achieve), and the IT system should be able to contextualize this information in order to transform it into knowledge and exploit it(i.e. to deduce the corresponding collaborative platform).

Knowledge technologies

With the increasing interest for knowledge and its strong perspectives, many knowledge technologies and tools have emerged in computer science. Milton [START_REF] Nick R Milton | Knowledge technologies[END_REF] details ve main areas linked to knowledge:

• Knowledge Based Systems also referred as Expert Systems: usually based on Arti cial Intelligence techniques to solve problems that are commonly addressed by experts.

• Knowledge Based Engineering Systems: similar to Knowledge Based Systems, they focus on engineering eld and also require analyses and computation steps.

• Knowledge Webs: these are websites which goal is to provide a way for users to navigate over knowledge bases.

• Ontologies: can either give a representation of knowledge or a type of le.

• Semantic Technologies: provide sophisticated ways to store and manipulate information.

According to Milton [START_REF] Nick R Milton | Knowledge technologies[END_REF], "They allow web sites and other web resources to be understood and used by computer, as well as by humans". The layer cake presents six main levels of technologies linked to Semantic Web: the foundations rely on XML language and the ability of RDF language to structure information. The ontology vocabulary and the logic layers concern the ways to link these information, and as such creating knowledge and store it in an ontology le. Finally proof is related to the rules that can be set up to test the consistency of an ontology, and trust is rather oriented to the reliability of the knowledge contained in the ontology. This picture has then been updated by the W3C, to nally obtain the Semantic Web Stack that can be found in Figure 3.4, in which all the former levels can be found in detail: syntax, data interchange, ontologies, logic, proof and trust. The stack details these levels by separating taxonomies from RDF les and from ontologies les. Besides, rules and querying technologies are also split into two boxes, since they express two di erent way to exploit the knowledge contained in an ontology: the rst concerns the creation of new knowledge based on logic rules, whilst the second refers to the ability to retrieve knowledge within an ontology . It also adds a user interface layer on the top of the whole stack.

Towards semantic web

In terms of knowledge representation and acquisition, three layers can actually be put forward here: syntax, data interchange and ontologies/taxonomies.

Ontologies De nition of ontology

Leaving aside the philosophical concerns around the term ontology, let's now introduce this term in a computer science perspective. Studer et al. [START_REF] Studer | Knowledge engineering: principles and methods[END_REF] give the following de nition, based on the previous de nitions of Gruber [149] and Borst [START_REF] Nico | Construction of engineering ontologies for knowledge sharing and reuse[END_REF]:

"
An ontology is a formal, explicit speci cation of a shared conceptualization. Conceptualization refers to an abstract model of some phenomenon in the world by having identi ed the relevant concepts of that phenomenon. Explicit means that the type of concepts used, and the constraints on their use are explicitly de ned. Formal refers to the fact that the ontology should be machine-readable. Shared re ects the notion that an ontology captures consensual knowledge, that is, it is not private of some individual, but accepted by a group.

"

Guizzardi [START_REF] Guizzardi | On ontology, ontologies, conceptualizations, modeling languages, and (meta) models[END_REF] also states that "a domain conceptualization C can be understood as describing the set of all possible states of a airs, which are considered admissible in a given universe of discourse U". According to Aussenac-Gilles et al. [START_REF] Aussenac-Gilles | Les enjeux de l'ingénierie des connaissances[END_REF] an ontology comes consequently as (i) a speci cation that de nes formal semantic so that computer systems can exploit information and (ii) a perception on a domain that provides an interpretative semantic enabling a link between the human perception and the computer formalization. The W3C [153] rather focuses on vocabulary, and precises that the boundaries between those terms are quite fuzzy: "There is no clear division between what is referred to as 'vocabularies' and 'ontologies'. The trend is to use the word 'ontology' for more complex, and possibly quite formal collection of terms, whereas 'vocabulary' is used when such strict formalism is not necessarily used or only in a very loose sense".

According to Corcho et al. [START_REF] Corcho | Ontological engineering: principles, methods, tools and languages[END_REF], the ontological engineering requires four main types of components:

• Classes: they represent the concepts (resulting of the prior human conceptualization of the domain described). They can be organized on gradation levels by using inheritance relations or also metaclasses.

• Relations: usually binary relations, they are used to link the classes to each other.

• Formal axioms: described by Gruber [START_REF] Gruber | What is an ontology[END_REF] as assertions that can be used to formalize knowledge that could not be understood with the other components, and also to constrain the potential interpretations of the knowledge (in this sense, axioms enable to check the consistency of an ontology).

• Instances: also called individuals or elements. Each instance "belongs" to one, or several class(es) (that are not disjoint, according to Gómez-Pérez et al. [START_REF] Gómez-Pérez | Ontological Engineering: with examples from the areas of Knowledge Management, e-Commerce and the Semantic Web[END_REF]).

In addition, binary relations can also be used to de ne attributes that precise the concepts. proli c

Di erent types of ontologies

Di erent types of ontology have been de ned in the literature, depending on their application and their domains. Guarino [157] recalls the four main types:

• An upper-level ontology describes generic concepts not related to any application or domain.

• A domain ontology specializes the upper ontology concepts to obtain vocabulary speci c to a domain.

• A task ontology also specializes upper ontology concepts to describe tasks or activities.

• An application ontology specializes both domain and task levels of ontology. According to Guarino [157], " these concepts often correspond to roles played by domain entities while performing a certain activity".

The strength of upper-level ontologies seems to be their reusability, since they can be specialized to t various domains and tasks, and consequently various applications. Obitko [START_REF] Obitko | Modularization of ontologies -introduction to ontologies and semantic web -tutorial[END_REF] also proposes potential merges of domain and task ontologies. Both points of view are illustrated by Figure 3.5.

Upper ontology

Domain ontology

Task ontology

Application ontology

(Obitko)
Figure 3.5 -Di erent types of ontology, from [157] and [START_REF] Obitko | Modularization of ontologies -introduction to ontologies and semantic web -tutorial[END_REF].

Tools for supporting ontology-based systems

The willingness to structure ontologies has also led to the creation of tools and standards. First various languages emerged to represent knowledge at a technical level. Associated to these languages, integrated tools where created either as Application Programming Interfaces (APIs) to help the developers, or as human interface softwares rather oriented towards the strict users (or to provide easy visualization of the ontologies). This Part summarizes some of these tools and explains the choices that have been made in this PhD thesis.

Representation languages

As can be seen on Figure 3.4, many standard languages are commonly associated to Semantic Web. Gómez-Pérez and Corcho [START_REF] Gómez | Ontology languages for the semantic web[END_REF] o er a Semantic Web stack exclusively oriented towards the semantic languages (see Figure 3.6). In parallel, in 2007, Cardoso [START_REF] Cardoso | The semantic web vision: Where are we? Intelligent Systems[END_REF] comes back to the study of the works of Gómez-Pérez and Corcho [START_REF] Gómez | Ontology languages for the semantic web[END_REF] and reveals that the promising languages at this time were not so used ve years later. Actually, he conducted a study on the use of ontologies, and, among other, provides an overview of the languages and their use in academic and industrial worlds. Thus, it is interesting to confront the di erent languages to their amount of users.

XML (eXtensible Markup Language) derives from SGML (Standard Generalized Markup Language), and thus is a a tag-based language. It has been launched in 1996 by W3C and Signore et al. [START_REF] Signore | Representing knowledge in the semantic web[END_REF] argue that, thanks to its independence from platform and programming languages, XML "plays a fundamental role towards interoperability" (i.e. technological but also semantic interoperability). XML comes along with: DTD (Document Type De nition) and XSD (XML Schema De nition) that enable to de ne the structure of the le and with XML Namespaces providing nameset identi ed by URI1 references that can be used as elements and attributes in the XML document. Typically, XML is the reference language when it comes to exchange data and it also the base of many other description languages.

XOL (XML-based Ontology exchange Language) has been de ned by Karp et al. [START_REF] Peter D Karp | Xol: An xml-based ontology exchange language[END_REF]) as a language for exchange of ontology and as such, Gómez-Pérez et al. [START_REF] Gómez-Pérez | Ontological Engineering: with examples from the areas of Knowledge Management, e-Commerce and the Semantic Web[END_REF] adds that it only provides a reduced knowledge representation. Noy et al. [START_REF] Noy | Creating semantic web contents with protege-2000[END_REF] explain that XOL allows defning classes, a class hierarchy, slots, facets, and instances. According to Cardoso [START_REF] Cardoso | The semantic web vision: Where are we? Intelligent Systems[END_REF], in 2007 only 0,9% of ontologists worked with XOL.

SHOE (Simple HTML Ontology Extension

) was developed at the University of Maryland2 and provides an extension of HTML that can be used to give web pages a semantic meaning. Actually, SHOE aims at improving the search systems based ontologies, but does not o er a way to create or de ne them. Hence, He in and Hendler [START_REF] He | Searching the Web with SHOE[END_REF] argue that the key challenge of this language is to exploit knowledge bases for improving queries. SHOE represents 1,9% of the ontology languages users in 2007 [START_REF] Cardoso | The semantic web vision: Where are we? Intelligent Systems[END_REF].

OML (Ontology Markup Language) is considered as a XML serialization of SHOE, according to Antoniou et al. [START_REF] Antoniou | Introduction to semantic web ontology languages[END_REF]. Cardoso [START_REF] Cardoso | The semantic web vision: Where are we? Intelligent Systems[END_REF] highlighted in 2007 that OML was not quite used by ontologists (0% of users according to Cardoso [START_REF] Cardoso | The semantic web vision: Where are we? Intelligent Systems[END_REF]).

RDF (Resource Description Framework

) "is a framework for expressing information about resources", according to its W3C de nition [START_REF] Manola | Rdf 1.1 primer. W3C, w3c working group note edition[END_REF]. It has actually been thought as a way to exchange information between computer systems (i.e. not intended to be displayed by human). RDF has been a rst step into the Semantic Web by enabling to de ne resources and link them OIL (Ontology Inference Layer) was developed for enabling knowledge representation and ontologies exchange, based on both RDF and XML by Horrocks et al. [START_REF] Horrocks | The ontology inference layer oil[END_REF]. It de nes an ontology on three levels: the object layer deals with the instances, the rst meta-level aims at structuring the ontology and the second meta-level allows to characterize the ontology.

DAML (DARPA Agent Markup Language) is named after the US Defense Advanced Research Projects Agency (DARPA). As de ned by McGuinness et al. [START_REF] Mcguinness | Damlont: An ontology language for the semantic web[END_REF], it aimed at "making web content more accessible and understandable". Based on RDF, the DAML language is divided into two parts: (i) DAML-ONT which focuses on ontology structure by describing classes, subclasses, properties, restrictions and individuals and (ii) DAML-LOGIC oriented towards inferences and logical implications. DAML+OIL came as the fourth most used language by ontologists with 12% of users [START_REF] Cardoso | The semantic web vision: Where are we? Intelligent Systems[END_REF].

OWL (Ontology Web Language) is the worthy successor of DAML and OIL -DAML+OILand as such based on RDF-S and XML. With this language, in 2004, the W3C [START_REF] Mcguinness | Owl web ontology language overview[END_REF] proposed a way to standardize the structure of web ontologies. Basically it is implemented as XML les, and includes notions for cardinality, equality, property characteristics and restrictions, class intersection and versioning. It actually includes three sublanguages:

• OWL Lite: allows quick reasoning but is the less expressive sublanguage since it forbids union and cardinalities over 1. Thus, it seems more adapted to thesauri or taxonomies.

• OWL DL: is more expressive than OWL Lite, but also has some constraints: for instance, a class cannot be an instance of another class. Hence, it still guarantees decidability with nite time computations and provides computational completeness (all conclusions are computable).

• OWL Full: is the most expressive of those three sublanguages (a class can be a collection of individuals as well as an proper individual), however complete reasoning is not guaranteed.

Because of its decidability and its level of expressivity, OWL DL is probably the most successful language for ontologies and has been used until now in the works of the research team Interoperability of Organizations in Mines Albi. There are two main reasons: (i) the facility to work with large amount of OWL DL ontologies available over the Internet and (ii) the facility to work with former internal ontologies. Also, thanks to its success (the most used language in 2007, with almost 80% of users among ontologists, according to Cardoso [START_REF] Cardoso | The semantic web vision: Where are we? Intelligent Systems[END_REF]), several tools have been developed around the OWL language (e.g. OWL API [START_REF] Horridge | The owl api: A java api for owl ontologies[END_REF] that provides an API to easily manipulate OWL ontologies and the famous software Protégé3 that o ers an interface to visualize and manipulate ontologies). OWL 2 (Ontology Web Language Version 2) was launched in 2009 by the W3C [START_REF]{OWL} 2 web ontology language document overview[END_REF] to address various lacks of OWL 1. Grau et al. [START_REF] Bernardo | Owl 2: The next step for owl[END_REF] An ontology relies both on a way to structure knowledge with, for example, classes and properties, and also to describe the associated vocabulary. Hence, before populating the ontology with individuals (i.e. instantiating the classes), it is important to de ne its structure that will make it properly (i) adapted to the actual needs of the system and (ii) machine-processable.

Top-down versus bottom-up approaches

In the eld of cross-organizational collaborations, top-down and bottom-up approaches are both commonly used: they provide two di erent ways of achieving a collaborative work ow. In the rst case, business objectives should be decomposed into sub-objectives and/or business services, which are decomposed into technical services that could then be ordered into a sequence. In [START_REF] Schulz | Facilitating cross-organisational work ows with a work ow view approach[END_REF], Schulz and Orlowska recommend to use the two methods as follows: the top-down approach allows the coalition of organizations to establish its common work ows by describing their interactions, while the bottom-up approach is rather adapted for each organization to specialize its tasks with its own private work ows. According to this recommendation and as preconized also by Ko et al. [START_REF] Ko | Business-owl (bowl)-a hierarchical task network ontology for dynamic business process decomposition and formulation[END_REF] the top-down approach seems highly adapted in the case of business objectives and capabilities decomposition as required for the business process deduction.

Ontology and Model Driven Architecture

In Chapter 1, Model Driven Engineering and Model Driven Architecture were introduced and the whole MISE program was positioned over this type of IT architecture. In the late 90's, the OMG set up the Meta-Object Facility (MOF) standard, based on UML, whilst they foresaw the danger of the emergence of several non-compatible metamodels at a time when the use of models in computer science was exploding [START_REF] Bézivin | From object composition to model transformation with the mda[END_REF]. Atkinson and Kühne [START_REF] Atkinson | Model-driven development: a metamodeling foundation[END_REF] provide the vision of OMG's infrastructure (see Figure 3.7) a four-layer decomposition, from a meta-metamodel decomposed into a meta-model, to a model (the User Concepts layer) and data or instances (the User Data layer). In MISE program, Bénaben [START_REF] Bénaben | Conception de Système d'Information de Médiation pour la prise en charge de l'Interopérabilité dans les Collaborations d'Organisations[END_REF] proposes to gather knowledge about collaborative situations, by using a metamodel as a "receptacle" that would be (i) loose enough to adapt any collaborative situation and (ii) meaningful enough to contain exploitable knowledge. Hence, the metamodel states the generic concepts of any collaborations and their relations to each other. Based on this metamodel, a collaborative ontology can then be developed and implemented by establishing the same structure (classes, relations and axioms), and then populated with instances of the concept to characterize speci c collaborations. This approach is schematized in Figure 3

A metamodel to support inter-organizational collaborations

As previously mentioned, an ontology is coherent if its structure ts exactly the needs: in the case of this PhD thesis, the functional goal is to support collaboration by gathering capabilities and collaborative objectives and deducing corresponding business processes. Figure 3.8 -Metamodel as a receptacle to build ontologies , [START_REF] Bénaben | Conception de Système d'Information de Médiation pour la prise en charge de l'Interopérabilité dans les Collaborations d'Organisations[END_REF] Basically, a metamodel layer is commonly used to describe a system, and UML is one of the most used language for that. Crane eld and Purvis [START_REF] Eld | Uml as an ontology modelling language[END_REF] argue several reasons for that: besides the strong IT community awareness of UML standard, the UML class diagram is very close to the RDF-S language. In fact, the W3C also pinpoints many direct relations between the two languages in [START_REF] Walter | A discussion of the relationship between rdf-schema and uml[END_REF]: UML is able to represent all RDF-S concepts (on which OWL is based). Finally, UML has been dedicated to human-to-human exchange, and, for this reason, it is easier to introduce the structure of an ontology using this standard, even if the ontology development involves RDF-S.

The collaborative ontology developed to support collaborations during this thesis is based on the metamodel established within the MISE project. This metamodel has evolved through the three iterations of the project and the various applications that has been made of it. Macé-Ramète et al. [START_REF] Macé-Ramète | A road crisis management metamodel for an information decision support system[END_REF] propose a core metamodel that provides the generic concepts of a collaboration and that can be specialized with layers according to the speci c applications (e.g. crisis management). This approach is illustrated in Figure 3.9. This core metamodel (see Figure 3.10) is based on ve main parts:

• Behavior part deals with the concepts linked to the collaborative process, and as such includes the process, event and activity classes.

• Actors part concerns all the classes in relation with the partners of the collaboration, it obviously corresponds to the partner class but also the collaborative network, mediator, • Context rather focuses on the context of the collaboration with the environment components and the characteristics of the collaborative opportunity.

• Objective part brings the notion of opportunity (or threat in crisis management), fact which can explain to the emergence of the collaboration.

• Performance notions allow assessing the system during the run-time of the process, and as such relies on Key Performance Indicators (KPI) that are measured, and which values should t the best the performance objectives.

Schematically the core metamodel comes along with a clear global mechanisms: (i) the Behavior of the collaboration and its Performances can be de ned according to the Context and the Objective and the Actors of the collaboration. Since these research works only focus on the deduction of the Process, only some concepts have been kept and can be found in Figure 3.11.

The metamodel in Figure 3.11, can be explained from the Process class de nition. A Process aggregates several Activities. These Activities actually invoke the Capabilities that are provided by Partners, and to be feasible, these Capabilities need Flows (i.e. require input and create output).

Besides, when a collaborative Opportunity emerges, it actually deals with a speci c Objective of collaborative, which relies on a speci c set of Capabilities (that are invoked as Activities and ordered into a Process) that is ful lled by a Process, and a set of Capabilities. As it comes to the Actors of a collaboration, the set of Partners of a collaboration forms a Collaborative Network which actually exists to answer a speci c Objective. Eventually, the Mediator class can be seen as a type of Partner, whose goal is to orchestrate the Process.

It is interesting to note that since the Mediator comes as a specialization of Partner class, the role of the MIS in the Process is comparable to that of a Partner, and for this reason, the MIS has its own pool in a collaborative business process (see Appendix B).

The concepts around the description of the environment and the measure of the performances have been left aside, not because they were irrelevant in such a system (e.g. the system could be further improved by a performances measure approach), but rather because they are not used to answer our speci c problematic. However, the metamodel presented in Figure 3.11 is not su cient to deduce collaborative network in this PhD thesis' context. Hence, it will be now extended and completed according to several di erent requirements due to this speci c context.

From the collaborative metamodel to the adapted ontology-based system

Over all the concepts de ned in Figure 3.11 and their relationships, some of them describe things that could not be acquired during the run-time of the system, and, on the contrary, some could not be de ned before run-time. It is actually very important to distinguish the di erent types of knowledge, to really understand how the system works.

"Persistent" knowledge

The persistent knowledge corresponds to the knowledge that should initially be implemented into the system so that it can work as expected. Here, the nal goal is to deduce interorganizational collaborative processes to respond to collaborative objectives, which means (i) nd the capabilities that should be invoked, (ii) nd which partners are able to provide these capabilities and (iii) order these activities into a process. Basically, the rst question that emerges is which capabilities contributes to an objective? The colored classes of the class diagram illustrated in Figure 3.12 refer to the corresponding concepts: for each Objective and its Sub-objectives, there exists a set of Capabilities that achieve it. This approach is similar to the notion of task ontology mentioned in Part 3.2.3. Task ontologies and domain ontologies are quite complementary and allow to obtain application ontologies.

A similar approach has been chosen for these works: the Collaborative Ontology has been implemented as task ontology, and the Business Field Ontology as domain ontology. Let's precise their structures.

The Collaborative Ontology (CO) describes the collaborative objectives that can be achieved and how (i.e. the capabilities to invoke to achieve the objectives). Concretely, it has been structured as follows: Objectives are broken down into complementary Sub-Objectives (e.g. either the top-level objective should be achieved, or all its sub-objectives) and for each Objective, complementary Capabilities contributes to achieve it. This decomposition is represented in The Business Field Ontology (BFO) Let's gure that "Buy" is an objective to achieve, the CO would not make the di erence between the two opportunities "Buy candies" and "Buy cars". Consequently, the further BFO provides a way to specialize the opportunities according to their business domain. The only concept of the BFO is Domain, and each domain can be decomposed into SubDomain. This is depicted in Figure 3.14.

Business Field Ontology

"Social" knowledge

What could be called "social" knowledge is the knowledge that is gathered when the users are asked to provide their own information. Indeed, two types of information come directly from the users: (i) the capabilities they are able to provide and willing to share within collaborations and (ii) the business opportunities they would like to be achieved. Within the metamodel, four concepts are concerned: the Partner that provides its Capabilities and its Flows, and the proposals of Opportunities (see Figure 3.15).

Concerning the Capabilities o ered by a Partner, the metamodel has been founded on the IDEF-Østandard [START_REF]Integration de nition for function modelling (IDEF0)[END_REF]: the capability is on the center, surrounded by its ows -requires input and creates output -, its resources and its instructions, as proposed in Figure 3.16. However, in this case, resources and instructions are useless, but the intput and output allow actually to order the capability when deducing the process (i.e. a capability can be placed before another if its output are those required by the further, see Chapter 4). Actually, at this point, some limitations can be pinpointed over the metamodel, and an adaptation can be proposed.

Capability and PartnerCapability It is confusing to use the concept Capability either to express the persistent knowledge or the social knowledge. Hence, it is proposed to split this concept into Capability for the CO and PartnerCapability for the capabilities provided by the organizations (see Figure 3.17). Hence, PartnerCapability specializes Capability. Integration of Business Fields and Flows Re nement As expressed in Part 3.2.3, task and domain ontologies are quite complementary and speci c application of them can be situated at their intersection. In other words, PartnerCapabilities and Opportunities are situated at the intersection between the "users world" and respectively the Capabilities and the Objectives of the CO. This is where the BFO is used: on the one hand, an Opportunity deals with an Objective of the CO, and also concerns one or more BusinessField(s) and on the other hand, a PartnerCapability corresponds to a speci c Capability of the CO, but its Flows actually concern speci c Business Fields.

The linkage of the BusinessFields is however di erent for the Opportunities and for the Part-nerCapabilities. Di erent notions of BusinessFields intersection and union have been added in order to describe the Opportunities and the PartnerCapabilities more precisely, and consequently obtain more accurate nal collaborative processes.

• Description of Opportunities: First, in order to obtain a more exible use of the Busi-nessFields contained in the BFO, there is a possibility to choose the intersection of two BusinessFields. Hence, in Figure 3.18, one can see that one of the domains linked to the Opportunity consists actually in the intersection of two BusinessFields of the BFO. Another domain has been added that is only linked to a single BusinessField. This Opportunity should be understood as corresponding to a speci c Objective in the CO. Moreover, it concerns two domains: the rst is at the intersection of two BusinessFields, while the other concerns only one BusinessField: concretely, that means that the nal collaborative Process to be deduced will have to provide two output Flows: one must be at the intersection of BusinessFields corresponding to the rst domain of the Opportunity, the other one should concern the BusinessField of the second domain of the Opportunity. Eventually, each domain should be described with its domainType: either physical or informational. Back to the example in Figure 3.18, the rst domain has an informational domainType, and the second domain has a physical domainType. In terms of collaborative Process, that means that, among the two output Flows, one need to be a physical one and the other an informational one.

• Description of PartnerCapabilities: As it comes to describe the Flows of a PartnerCapability, those can also be described at the intersection of two BusinessFields, like "Output2" in Figure 3.19. Besides, a PartnerCapability can have several input Flows and output Flows. If more than one Flow constitutes the output of a PartnerCapability, that means that the PartnerCapability is able to provide the "union" of the Flows: either one of them, or both could be used by a successor PartnerCapability in the nal Process. Hence in Figure 3.19, the PartnerCapability is able to o er "Output1" and "Output2", which could be used (one of them or both) by a further PartnerCapability, as input. Note that, because of consistency reasons, it is not possible for a PartnerCapability to have no physical input if it has a physical Output. Non-functional attributes The particularity of both PartnerCapabilities and Opportunities are that, since they are provided by users, they not only focus on what but also on how. Indeed, assuming several organizations can provide the same Capability, the choice of a partner can only be made on speci c criteria. On the one hand, PartnerCapabilities can be assessed on non-functional criteria as proposed by the non-functional framework in Chapter 2. Hence, each criteria comes as an attribute of PartnerCapability. On the other hand, Opportunities not only focus on the Objectives that should be achieved but also their de nition should provide a way for the users to express their non-functional needs. Hence, a list of criteria with their corresponding objectives and weights (to provide the relative importance of the non-functional objectives) should be associated with the Opportunities. Figure 3.20 details both classes with example of attributes, which are not all precised here for obvious reason of readability. Extended Collaborative Ontology PartnerCapabilities are eventually stored to be reused to answer any further Opportunity. However, here, the Opportunities are not stored: they are considered as one shot Opportunities and are only used when deducing the collaborative processes. That means, that the PartnerCapabilities should be integrated as knowledge in an ontology. An Extended Collaborative Ontology (ECO) is proposed, which goal is to store the social knowledge. It includes, Objectives, their set of Capabilities and the correspond PartnerCapabilities with their Flows. Actually, this is the minimal and su cient knowledge needed for the further deduction of collaborative processes (i.e. the ECO can be considered as the application ontology here). To clarify this approach, the Figure 3.21 provides a clear description of the ECO.

Collaborative Ontology Business Field Ontology

One can note, that the ECO also embeds knowledge from the CO and the BFO, and could call it redundancy. However, this is a way to separate persistent knowledge from "social knowledge": it is useful for enhancing the maintainability of the ontology-based system.

"Deduced" knowledge

Based on the ECO, the system is able to exploit its knowledge to provide collaborative processes that ful ll the objectives of the collaboration. In other words, the exploitation goal is to deduce ve classes (see Figure 3 Now that the structures of CO and BFO ontologies have been established, they should be populated with concrete instances. This means that (i) adapted knowledge bases should be found whatever their structure or format and (ii) they should be transformed into individuals.

Knowledge bases for the Collaborative Ontology

Numerous knowledge bases exist around the notion of processes and activities (which could be also called as capabilities, skills, business services or business functions,etc.).

SCOR (Supply Chain Operations Refence) model

The SCOR model is one of the most famous knowledge base to describe processes and activities within enterprises. It does not only focus on performance metrics (as exploited in Chapter 2), but also conveys a source of knowledge on inter-organizational supply chain processes, around six top-level management processes: plan, source, make, deliver, return and enable. These levels are themselves decomposed into two sub-levels, as illustrated by Council [START_REF]Supply chain operations reference (scor®) model[END_REF] in Figure 3.23 level 2 is about the strategy of the supply chain (e.g. make-to-order or make-to-stock strategy) and level 3 focuses on the main steps that should be performed to achieve the level 2 process. The Supply Chain Council mentions the level 4 which should allow to describe the implementation of the processes. However this level is out of the scope of SCOR.

The inconvenience of the SCOR is the di culty to nd Objectives among its processes and activities, hence, it is hardly exploitable to populate the CO.

PCF (Process Classi cation Framework)

PCF [START_REF]Process classi cation framework[END_REF] has been established by the American Productivity & Quality Center (APQC) surrounded by some 80 organizations, and provides a "taxonomy of cross-functional business processes". It is actually most used for benchmarking and performance activities and claims to de ne processes comprehensively. The framework o ers twelve top-level categories of processes: ve concern operating processes (e.g. develop vision and strategy or deliver products and services) and the seven others deal with management and support services (e.g. manage nancial resources or manage information technology). Then, these categories are themselves broken down into four levels: process group, process, activity and nally task. Besides, PCF has also been developed to t speci c business elds such as aerospace and defense, banking, downstream petroleum, education... Actually it covers fteen di erent elds. All these versions of PCF are freely available as PDF and Excel les and Figure 3.24 provides a sample of the classi cation by focusing on the "Manage employee requisitions" topic.

Similarly to the SCOR, the PCF's structure is not easily adaptable to the transformation into Objectives and SubObjectives since it provides a "linear" decomposition on its four levels.

PSL (Process Speci cation Language)

The PSL [START_REF] Schleno | The process speci cation language (PSL) overview and version 1.0 speci cation[END_REF] aims at "creating a process representation that is common to all manufacturing applications, generic enough to be decoupled from any given application, and robust enough to represent the necessary process information for any given application". Is has been developed by the Nation Institute of Standard and Technology (NIST), with the university of Toronto and formerly surrounded by other industrial and academic contributors. The PSL speci cation [START_REF] Schleno | The process speci cation language (PSL) overview and version 1.0 speci cation[END_REF] details four concepts within the PSL Core, de nes as follows:

• Activity: a type of action.

• Activity-Occurence: an event or action that takes place at a speci c place and time.

• Timepoint: a point in time.

• Object: anything that is not a timepoint or an activity.

Besides, relations are de ned between these concepts. One of the di culty to adapt PSL to populate CO is its lack of bottom-up approach: it is quite di cult to de ne which PSL's concept could be transformed into Objectives.

SUMO (Suggested Upper Merged Ontology)

SUMO was developed at the beginning of the 2000's with the aim to provide a large and free upper ontology, that would nally become a standard. Pease et al. [START_REF] Pease | The suggested upper merged ontology: A large ontology for the semantic web and its applications[END_REF] explains that the main challenge to obtain such upper-level ontology is to align various sources of knowledge.

For instance, SUMO website [START_REF] Pease | The suggested upper merged ontology (sumo) -ontology portal[END_REF] explains that the upper ontology is based on: WordNet which is a lexical database for English [START_REF] Fellbaum | WordNet[END_REF], many domain ontologies from communication to sports through transportations and MILO (Mid-Level Ontology) which goal is to bridge the gap between the upper-level provided by SUMO and the domain ontologies. Thus, SUMO nally o ers a formal ontology with 25,000 terms and 80,000 axioms. The structure of SUMO and its mapping to MILO and the domain ontologies is illustrated in Figure 3.25. SUMO was written in the SUO-KIF 4 language, but has also been translated in OWL. Here again, whilst SUMO could bring a very large amount of knowledge, it is quite hard to think about a transformation of its structure into CO's metamodel.

MIT Process Handbook

The MIT Process Handbook is a key initiative of the MIT Center for Coordination Science to create "rich online libraries for sharing and managing many kinds of knowledge about business" [START_REF]Mit process handbook project[END_REF]. First proposed under a MIT licence, the MIT spin-o company Phios 5 proposes a commercial version since 1996. An online version is available 6 available and freely usable.

As explained by Malone et al. [START_REF] Thomas W Malone | Organizing business knowledge: the MIT process handbook[END_REF], this handbook aims at representing industrial processes to help managers deal with several situations: (i) redesigning business processes, (ii)design new processes, (ii) organize and share knowledge about organization process and more generally (iii) to support business processes. To respond to these needs, two problems had to be addressed: (i) the representation of organizational processes that would take into account di erent levels of abstraction and (ii) collecting and analyzing real cases to de ne how similar functions can be performed.

The MIT process handbook embeds more than 5000 processes, besides the repository also o ers alternative models such as APQC's PCF and the SCOR model. Each process de nes a collection of activities that can be broken down into sub-activities. Also, the processes achieve goals. Thus a bottom-up approach can be easily applied when using the process handbook. Another advantage of the MIT Process Handbook is that, within a project with the Department of Informatics of the University of Zurich, it was OWLized, as detailed by Kiefer et al. [START_REF] Kiefer | Semantic process retrieval with isparql[END_REF], and is available online 7 .

The handbook is organized around six key concepts, as related by Rajsiri [START_REF] Rajsiri | Knowledge-based system for collaborative process speci cation[END_REF], and illustrated in Figure 3.26

• Processes are composed of activities that can in turn be split into sub-activities.

• Resources are related to the input and output of the processes.

• Dependencies allow the coordination between activities in the process.

• Goals are achieved by processes.

• Exceptions concern fails in the processes.

• Bundle is a group of related specializations.

RosettaNet and ebXML

RosettaNet8 is a consortium of over 400 leading information technology, electronic components, smiconductor manufacturing and solution provider companies, that has been founded in 1998 and is also a subsidiary of GS1 US -formerly known as Uniform Code Council, Inc. RosettaNet proposes a collection of standards which goal is to facilitate the exchange of information within B2B collaborations. There are 7 PIPs® (Partner Interface Process) speci cations that are de ned by Damodaran [START_REF] Damodaran | B2b integration over the internet with xml: Rosettanet successes and challenges[END_REF] as " standardizing business documents, the sequence of sending these documents, and the physical attributes of the messages that de ne the quality of service".

ebXML 9 (electronic Business using XML) is a suite of standards brought by OASIS and UNCE-FACT, approved as ISO-15000 [START_REF] Pereira | Ebxmloverview, initiatives and applications[END_REF]. Initiated in 1999, this initiative also aims at standardizing e-commerce on ve levels: business process, collaboration protocol agreements, core data components, messaging and registries and repositories.

Actually both rather focus on technical exchange standards, and not really on a business level, which make them quite di cult to exploit them as knowledge bases and transform them into OWL ontologies.

BOWL (Business-OWL)

The research works of Ko [START_REF] Ko | Business-owl (bowl)-a hierarchical task network ontology for dynamic business process decomposition and formulation[END_REF] as part of the Genesis project, faced the closest issues. Actually, Genesis aimed at providing enterprises a way to obtain on-the-y cross-enterprises collaborative processes with non-functional concerns (e.g. cost, quantity, lead time...), based on the expression of a collaborative objective. Ko et al. have based their approach on a Hierarchical Task Network (HTN) ontology called Business-OWL (BOWL). The strength of their works relies on the implementation of an ontology not only as a knowledge base but that also embeds the resulting business task decomposition of the HTN. Although this approach is quite interesting, the whole BOWL le does not seem available online, hence it is quite hard to evaluate if it would be adaptable. Nevertheless, the BOWL application is very close to this PhD thesis objectives, which is quite interesting to note.

Finally, the MIT Process Handbook [START_REF] Thomas W Malone | Organizing business knowledge: the MIT process handbook[END_REF] is the most adapted to the CO, since its structure contains all the concepts of CO and OWL les are available online, free of use, which is really convenient to extract individuals.

From OWL MIT Process Handbook to the Collaborative Ontology

In order to populate the CO based on the MIT Process Handbook, an 1-to-1 model transformation has been made:

• From MIT Process Handbook's Goals to CO's Objectives

• From MIT Process Handbook's Processes to CO's Capabilities As a result an OWL ontology le was obtained, that contained all the Goals and Processes available in the online version of the MIT Process Handbook. The Appendix C provides a sample of the populated CO -implemented with OWL API [START_REF] Horridge | The owl api: A java api for owl ontologies[END_REF] as ontology reader and writter.

That being said, the MIT Process Handbook has not deen implemented for the speci c needs of the automated deduction of business processes, but rather to help process designers to analyze processes and nd other alternatives [START_REF] Lee | The pif process interchange format and framework[END_REF]. Consequently, the resulting deduced processes are not always as good as expected.

Knowledge bases for the Business Field Ontology

Kowledge bases about business domains are quite common, since most governments classify their organizations by business activities for statistical purposes. This Part aims at giving a quick overview on some of these classi cation and choosing an adapted one to populate the BFO.

North American Industry Classi cation System (NAICS)

NAICS 10 allows classifying business establishments since 1997. The initiative was launched by Canada, the United States and Mexico. According to [START_REF]North american industry classi cation system (naics)[END_REF], the last version has been established in 2012 and can be bought online, but the categories and their structure can be browsed for free. It includes twenty top-level classes, from agriculture to public administration, which are decomposed into four sub-levels. De nitions are given for each individual whatever its level.

As focused on North American business domains, some domains that could be encountered in other areas are not included. As focused on European business domains, some domains that could be encountered in other areas are not included.

Statistical Classi cation of Economic

International Standard industrial classi cation of all economic activities (ISIC)

ISIC [START_REF]United Nations and Statistical Division. International Standard industrial classi cation of all economic activities (ISIC)[END_REF] was established by the United Nations Statistics Division. Its fourth revision has been released in 2008 and most of the national or communities classi cations are based on it and derives it to t geographical areas speci city. It can be found for free online 11 . ISIC relates 21 top-level activities and has four hierarchical levels (Sections, Divisions, Groups and Classes) and at each level, de nitions are given with including and excluding rules to help organizations nd their right business domain. Besides, it can be considered as the most "international" business activities classi cation since it has not been speci ed for speci c geographical areas (i.e. some activities can have been evicted from derived classi cations since they are not represented over the corresponding area). For this reason, and because of the ease of access to this classi cation, it has been chosen to populate the BFO.

From the ISIC to the Business Field Ontology

The ISIC classi cation is really convenient, since the codes and their title (on the four levels) are downloadable as text les. A simple parser has allowed to obtain a OWL le for the BFO, by following the further transformation: each Section, Division, Group and Class becomes a BFO's Domain. Then each decomposition from Section to Division, from Division to Group and from Group to Class becomes a hasSubDomain relation. A sample of BFO can be found in Appendix D.

Illustrative use case

Brake France12 is a French food wholesaler company for enterprises. As part of OpenPaaS and end user partner, a use-case has been based on its business activities: here, it focuses on a particular bid for chocolate products. Intentionally simple, this case aims at giving the readers a clear illustration of the concepts detailed all over this Chapter and also at situating the users interaction with the RSE when (i) de ning their pro les and (ii) proposing collaborative opportunities.

Organizations' pro les modeling

As a rst step, each of the organizations of the platform uses the Pro le Modeler in order to create its own pro le by detailing the capabilities it is able to provide and want to share in collaborative contexts. Let's take the example of Brake France enterprises (see Figure 5.3):

• The organization creates a new PartnerCapability and link it to "Place Order" which is a Capability proposed in CO, since it is one of its main capabilities as a wholesaler.

• Concerning the Flows of this PartnerCapability, the input and output are detailed: (i) the input is informational and concerns the "Combined o ce administrative service activities" class of the ISIC classi cation, whilst (ii) the output is also informational and concerns an intersection of two domains have been chosen for the output: "Manufacture of cocoa, chocolate and sugar confectionery" and "Wholesale of food, beverages and tobacco". Thus, the output speci es the fact that the "Place Order" capability concerns the ability of buying wholesale of food from chocolate manufactures.

• Finally, non-functional criteria are given. Actually, only the criteria which way to inform is categorized as "'own pro le" can be initially provided by Brake France, since the other criteria will then be assessed either by the system, or by future partners. Here, Brake

Illustrative use case

France informs that the PartnerCapability can be executed in one day, with the possibility of con dentiality. Actually, Brake France's pro le is nally composed of the whole set of capabilities it is able to provide two capabilities: "order" and "Deliver" as a wholesaler, and the non-functional criteria applied either on the PartnerCapabilities they have de ned, or on the whole Partner pro le, depending of the level of application if the corresponding criteria. Hence, Brake France's pro le is illustrated in Figure 3.28.

Collaborative Objective description

Concerning the collaborative Opportunity that Brake France would like to achieve, it concerns a buying objective. Hence, the organization proposes a new Opportunity that is linked with the "Buy" Objective of the CO. The users can link as many domains as needed to specify the business elds of the collaboration. For instance, here, the "Buy" objective is linked with two domains (see Figure 3.29): one at the intersection of "Freight transport by road" and "Manufacture of cocoa, chocolate and sugar confectionery" and one concerning "Combined o ce administrative service activities". The rst domain speci es that, as a result of the process, Brake France would like to receive, by freight transport, chocolate products coming from manufactures of chocolate. By adding the second domain, Brake France also speci es that an informational administrative ow should also be generated by the process. In terms of non-functional requirements, Brake France would like here the lead delivery time to be less than 15 days, for a quantity of 300 products and a maximum total cost of 1500 euros. The weights of these criteria are 0,7 for the total cost and 0,3 for the lead delivery time.

Contributions, Discussions and perspectives

Contributions

The representation of knowledge in IT context has been widely explored these last decades, however with the increasing interest for Big Data discipline these last years, one key challenge of knowledge-based systems concerns the acquisition of knowledge. Hence, the ontology-based system described in this Chapter still su ers from some limitations that are discussed here.

Contributions, Discussions and perspectives

Discussions and perspectives

The everlasting knowledge bases issue Di culties to access real knowledge bases The lack of industrial knowledge bases with easy access remains one of the key limitations here. Actually here, the persistent knowledge allows to provide viable and relevant processes with the relation between objectives and capabilities of the CO. Hence, the viability of the nal process raises the problem of the relevancy of the initial knowledge base (here, the MIT Process Handbook): the relevancy here is not "absolute" but rather totally relative to the expectations of the users with this type of ESN. Moreover, the ambition of creating from scratch a very broad knowledge base, whatever the collaborative contexts, would probably be disproportionate given the huge variety of collaborations that have nothing to do with each other (e.g. supply chain collaborations, administrative collaborations...).

That being said, that question does not remain unexplored, quite the contrary. Two behaviors seem to emerge that can be highly complementary:

• The inter-organizational collaborative networks create their own collaborative processes and store these processes as past cases. Then, the door is open to the broad and captivating world of machine learning, or, for example, case-based reasoning, as proposed in the works of Bergmann and Schaaf [START_REF] Bergmann | Structural case-based reasoning and ontology-based knowledge management: A perfect match?[END_REF].

• Using already existing knowledge bases apparently unsuitable (i.e. following a di erent structure or metamodel), and nally adapt it, as in [START_REF] Wang | A general model transformation methodology to serve enterprise interoperability data sharing problem[END_REF] The underlying semantic issues concerning the second proposition makes it an interesting object to study more deeply.

Towards the adaptation of external collaborative ontologies Back on Chapter 1, the notion of interoperability was de ned according to three levels: integrated when all the partners use the same exchange standards, uni ed when a common metamodel is shared and federated to allow matching between models built on di erent metamodels. The approach described in this Chapter clearly implements a uni ed interoperability. What about implementing a federated approach?

The research works of Tiexin Wang and Sébastien Truptil in the Industrial Engineering Center at Mines Albi propose such approach [START_REF] Wang | A general model transformation methodology to serve enterprise interoperability data sharing problem[END_REF]. Within his PhD thesis, Tiexin Wang aims at providing a model transformation to enhance data sharing among heterogeneous IT systems. In [START_REF] Wang | Semantic approach to automatically de ned model transformation[END_REF], he provides a syntactico-semantic reconciliation that allows to nd the similarity of the classes and relations of a metamodel with those of another metamodel. Hence, it could be directly used within this PhD thesis' works: the users could provide their own collaborative ontologies, and the system could transform it to t the CO's structure.

At a lower level, this tool can be very useful to initially enhance CO by easily merging other knowledge bases with it, which would be very laborious as a human task.

Enhancing user experience It is customary to say "If you can do something complicated, you can do something simple". The user experience described here is not really optimized. However, if the syntactico-semantic reconciliation allows to exchange data from di erent metamodels it is because it is able to reason on the meaning and writing of the words. In Part 3.3.2, users directly nd their corresponding capabilities and objectives in CO and link them with their partnerCapabilities and opportunities via sameAs and nearBy relations. Given the number of individuals in CO, the task can be laborious. Also, the users are not guided in this step and misunderstandings could evict them of further deduced collaborations.

To address this issue, the syntactico-semantic reconciliation can reason on the words given by the users to directly nd the potential corresponding individuals in CO as illustrated in Figure 3.30. The whole system is detailed in [START_REF] Montarnal | A social platform for knowledge gathering and exploitation, towards the deduction of inter-enterprise collaborations[END_REF].

Conclusion

This Chapter detailed an ontology-based system in two parts: (i) the representation of knowledge i.e. the metamodel used to structure the ontologies CO and BFO so that they can be properly adapted and machine-processable and (ii) the acquisition of collaborative knowledge coming from users' information. The persistent knowledge (i.e. CO and BFO) is considered as always true and allows to link capabilities with the objectives they achieve. Social knowledge mentions the knowledge gathered with users' interactions: the collaborative opportunities and their own partnerCapabilities.

Basically, the minimal and su cient knowledge is now acquired. Last but not least, this knowledge should now be exploited to provide the brokers quasi optimal collaborative processes, which means: nding the capabilities that achieve the opportunities, then, nding the best set of partners able to provide these capabilities and nally order these capabilities into a process.

The next Chapter will therefore focus on the exploitation of this gathered knowledge in order to deduce quasi-optimal collaborative process in response to business opportunities. This approach was part of the works presented in the conferences Pro-VE 2014 [202] and SCC 2014 [START_REF] Montarnal | A paas to support collaborations through service composition[END_REF].

Résumé en français

Des philosophes de la Grèce Antique jusqu'aux systèmes d'information modernes, la gestion de la connaissance a toujours été une problématique omniprésente. Ce chapitre s'intéresse à dé nir et structurer la connaissance minimale que le RSE doit acquérir a n de pouvoir ensuite déduire un processus collaboratif, en réponse à une opportunité.

Plusieurs technologies ont été développées en informatique a n de pouvoir élaborer des systèmes à base de connaissances, des systèmes experts aux systèmes sémantiques. Dans les années 2000, Tim Berneers-Lee introduit le concept de Web Sémantique reposant sur di érentes technologies selon cinq couches: (i) le language RDF permet de structurer de l'information au sein d'un chier XML, (ii) les ontologies sont utilisées pour stocker des connaissances et les lier entre elles, (iii) des règles logiques permettent l'exploiter les connaissances d'une ontologie pour en créer de nouvelles, (iv) une couche "preuve" a pour but d'assurer la cohérence d'une ontologie et (v) une couche "con ance' est' dédiée à la abilité des connaissances. C'est la couche ontologie qui nous intéresse ici particulièrement.

Une ontologie repose d'une part sur une structure précise pour stocker de la connaissance de façon pertinente et, d'autre part, sur des individus (les connaissances) liés entre eux. Un métamodèle collaboratif est proposé pour structurer la connaissance stockée: il est basé sur les travaux réalisés dans le cadre du projet interne MISE. Ce métamodèle est adapté au contexte et aux contraintes liés au RSE. Finalement, il en résulte l'implémentation de deux ontologies: la Collaborative Ontology (CO) vise à décrire la façon dont les Objectifs de collaboration (amenés par les opportunités des utilisateurs) peuvent être remplis en exécutant des Capacités (amenées par les organisations et leurs services métier), et la Business Field Ontology (BFO) permet d'appliquer les individus de la CO, qui sont génériques, à des domaines métiers particulier.

Concrètement, la CO présente une décomposition d'Objectifs de collaboration (ex. "vendre") en sous-objectifs complémentaires. Chaque Objectif est aussi décomposé en l'ensemble des Capacités complémentaires permettant de le réaliser. La BFO consiste en une décomposition hiérarchique simple de domaines métiers. La CO été peuplée en utilisant la description de processus industriels proposée dans le MIT Process Handbook [START_REF] Thomas W Malone | Organizing business knowledge: the MIT process handbook[END_REF], et la BFO selon les activités proposées dans la classi cation ISIC [START_REF]United Nations and Statistical Division. International Standard industrial classi cation of all economic activities (ISIC)[END_REF]. Finalement, ces deux ontologies ont été implémentées sous forme de chiers OWL2.

La description des pro ls et des opportunités par les utilisateurs résulte directement de la structure de ces deux ontologies. Un pro l contient toutes les Capacités o ertes par une organisation. Chaque Capacité d'organisation est dé nie par un lien sémantique à une Capacité de la CO et détaillée selon les facteurs non-fonctionnels retenus dans le Chapitre 2. De plus, ses ux (entrées et sorties) sont décrits grâce aux domaines métier disponibles dans la BFO. De même, chaque Opportunité est dé nie par un lien à un Objectif de la CO, par des objectifs non-fonctionnels associés, et un ou plusieurs domaines métier de la BFO.

Finalement, une Extended Collaborative Ontology (ECO) est obtenue et inclut la CO et l'ensemble des Capacités (et leurs ux) proposées par les organisations du RSE. A n de répondre aux opportunités de collaboration, cette ECO peut maintenant être exploitée.

Knowledge Exploitation:

Collaborative Business Processes Deduction "Suppose presently the ants began to store knowledge, just as men had done by means of books and records, use weapons, form great empires, sustain a planned and organised war?" -H.G. Wells, The Empire of the Ants

Introduction

Already in ancient Greece, Athenian generals did not take any vital decisions -like for battles, for instance -before having consulted the Pythia in Delphi. Decision making, either as a single individual or as a whole society, has always been a laborious step. Buchanan and O Connell [START_REF] Buchanan | A brief history of decision making[END_REF] remind that after that Hamlet debated his timeless question"to be, or not to be?", men like René Descartes, Blaise Pascal and Pierre de Fermat tended to rationalize such process during the 17th century. In modern time, the arrival of the rst computers, around the 50's, has resulted in a huge revolution both in academic and industrial worlds. Initially very expensive, the computational power soon became a ordable and Power [START_REF] Daniel | Decision support systems: a historical overview[END_REF] mentions the rst computerized models to assist decision making and planning in the 60's. Eventually, Decision Support Systems (DSS) became a proper research area around the 70's. Power [START_REF] Daniel | Decision support systems: a historical overview[END_REF] distinguishes ve DSS axes: communicationsdriven, data-driven, document-driven, knowledge-driven and model-driven. Power [START_REF] Daniel | Decision support systems: a historical overview[END_REF] de nes knowledge-driven DSS as "computer systems with specialized problem-solving expertise. The expertise consists of knowledge about a particular domain, understanding of problems within that domain, and skill at solving some of these problems". When it comes to reason on ontologies to assist in decision making processes, the term "ontology-driven decision support systems" is generally used in the literature.

Chapter 3 aimed at representing and structuring knowledge on inter-organizational collaborations. The goal of this Chapter is now to exploit it as an ontology-driven DSS, in response to a collaborative opportunity, by providing the broker a "good" (i.e. depending on non-functional criteria as proposed in Chapter 2, and chosen by the broker) way to ful ll it i.e. a quasi-optimal collaborative business process. Section 4.2 shows that the classical methods for exploiting ontologies and also exact methods (i.e. to nd the optimal collaborative process among all the possibilities) are actually limited in this case because of the combinatorial nature of the problem. Hence, it has been decided to focus on metaheuristics which have proven e cients for resolving NP-hard problem. That is why Section 4.4 provides an overview on di erent metaheuristics used for this kind of problem and Section 4.5 describes the choice and the adaptation of an Ant Colony Optimization algorithm to the speci c exploitation of CO and BFO. Finally, Section 4.6 brings an overview on the performances of the proposed algorithm.

Towards a limitation of the classical methods to exploit ontologies

The Semantic Web Stack (cf. Figure 3.4) extends the ontologies box with two other axes: (i) semantic reasoning through rules and (ii) data retrieving with querying. Those are ways to exploit and bene t from the knowledge stored in ontologies. Several approaches have emerged in both axes and this part aims at bringing a short overview on the possibilities they o er and the limitations that have been encountered.

Semantic reasoning Description Logics and ontologies

According to Horrocks et al. [START_REF] Horrocks | From shiq and rdf to owl: The making of a web ontology language[END_REF], the OWL ontology language has been highly in uenced by Description Logic (DL). Baader et al. [START_REF] Baader | Description logics[END_REF] de ne DL as follows:

" Description logics (DLs) are a family of knowledge representation languages that can be used to represent the knowledge of an application domain in a structured and formally well-understood way. The name description logics is motivated by the fact that, on the one hand, the important notions of the domain are described by concept descriptions, i.e., expressions that are built from atomic concepts (unary predicates) and atomic roles (binary predicates) using the concept and role constructors provided by the particular DL; on the other hand, DLs di er from their predecessors, such as semantic networks and frames, in that they are equipped with a formal, logic-based semantics.

"

Hence, it provides them a logical formalism and brings to OWL languages huge possibilities for reasoning. Basically, DL is composed of two components, the Tbox and the Abox: The Tbox brings terminology, described by Baader and Nutt [START_REF] Baader | Basic description logics[END_REF] as "the vocabulary of an application domain". Basically, it includes concepts -set of individuals -and roles -relationships between these individuals. For instance, the further declaration allows de ning the concept woman at the intersection of two other pre-de ned concepts Human and Female:

DL
W oman ≡ Human ⊓ F emal e
The Abox contains assertions. Precisely, both concept assertions and role assertions [START_REF] Nardi | An introduction to description logics[END_REF] are embedded. For instance, the two further declarations state that the Person Lilu is a Femaleand consequently a Woman -and that Lilu's husband is Korben:

F emal e ⊓ Per son(Li l u) hasHusband (Li l u, K or ben) DL provides a set of constructors: from the basic ALC (Attributive concept Language with Complements) to its numerous extensions [START_REF] Baader | Description logics[END_REF]. Introduced by Schmidt-Schauß and Smolka [START_REF] Schmidt-Schauß | Attributive concept descriptions with complements[END_REF], ALC is the addition of the Attributive Language and the complement operator. Many extensions have emerged based on ALC, some of which are further detailed with their speci c operators in Table 4.1. Note that S stands for ALC as in the SHOIN DL, for instance.

Based on DLs, the OWL languages propose di erent levels of expressiveness (cf. Chapter 3) that, according to Horrocks et al. [START_REF] Horrocks | From shiq and rdf to owl: The making of a web ontology language[END_REF] and Motik et al. [START_REF] Motik | Owl 2 web ontology language direct semantics[END_REF], can be transcribed as follows: OWL Light corresponds to SHIF, OWL-DL to SHOIN and OWL 2 to SROIQ. As underlined by Baader et al. [START_REF] Baader | Description logics[END_REF], most of the DLs are fragments of rst-order predicate logic (for example, transitivity closure of roles requires second-order logic).

With such an expressiveness, ontologies are not only about storing and structuring knowledge into knowledge bases but also providing a smarter way to create new knowledge: in other words infer new knowledge.

Semantic Web inferences

While Scharrenbach et al. [START_REF] Scharrenbach | Unsupervised con ict-free ontology evolution without removing axioms[END_REF] mention axioms as explicit knowledge, they introduce inferences as implicit knowledge. In other words, axioms describe basic assumptions that could not be proven: the English Cambridge Dictionary de nes it as "a formal statement or principle in mathematics, science, etc., from which other statements can be obtained" [213]. Regarding the word inference, the English Cambridge Dictionary expresses it as "a guess that you make or an opinion that you form based on the information that you have" [START_REF]inference meaning, de nition in cambridge english dictionary[END_REF]. In its de nition of Semantic Web, the W3C embeds Arti cial Intelligence via the use of inference [215]: " Broadly speaking, inference on the Semantic Web can be characterized by discovering new relationships. On the Semantic Web, data is modeled as a set of (named) relationships between resources. "Inference" means that automatic procedures can generate new relationships based on the data and based on some additional information in the form of a vocabulary, e.g., a set of rules.

"

In order to infer new knowledge, a set of rules can be associated to an ontology. For instance, a simple inference could be "If Gérard is the father of Serge, and Serge the father of Simon, then Gérard is the grandfather of Simon".

In fact, here, any of the corresponding DL operators available with OWL 2 could be used with the purpose to establish inference rules and deduce new knowledge within the ontologies. For this purpose, number of reasoners have been developed like Jena [216], Pellet [217], Fact++ [START_REF]owl research at the university of manchester[END_REF] or Hermit [219].

Use of inferences to exploit collaborative ontologies

Within their PhD theses, Rajsiri [START_REF] Rajsiri | Knowledge-based system for collaborative process speci cation[END_REF], Truptil et al. [START_REF] Truptil | Interoperability of information systems in crisis management: Crisis modeling and metamodeling[END_REF], Boissel-Dallier et al. [START_REF] Boissel-Dallier | Mediation information system engineering based on hybrid service composition mechanism[END_REF] and Mu [START_REF] Mu | Caractérisation et logique d'une situation collaborative[END_REF] have also studied the deduction of BPMN and BPEL collaborative processes by exploiting collaborative ontologies. Eventually, Mu et al. [START_REF] Mu | A methodology proposal for collaborative business process elaboration using a model-driven approach[END_REF] present a meta-model and the corresponding knowledge exploitation for the deduction of business processes following the BPMN. Mu et al. [START_REF] Mu | A methodology proposal for collaborative business process elaboration using a model-driven approach[END_REF] are centered on the use of a collaborative ontology with rst-order logic rules to obtain a BPMN process from (i) a set of partner wishing to work together but without knowing how exactly to do this and (ii) business objectives of collaboration. For instance, one of the rule established by Wenxin Mu allows de ning t0-level functions (corresponding to A0-level in SADT models) from the objective of a collaborative network (i.e. a set of partners with common collaborative objectives). This rule states that if a collaborative network has a collaborative objective, then there exists a main function model which has a main function, which name is the same as the objective [START_REF] Mu | Caractérisation et logique d'une situation collaborative[END_REF]:

∀C ol l abor at i veNet wor k(X ) (∀Ob j ect i veRel at i onshi p(C ol l abor at i veNet wor k(X ),Ob j ec t i ve(X 1 ))) → ∃M ai nF unct i onMod el (X ) ∧ ∃M ai nF unc t i on(X 1 ) ∈ M ai nF unc t i onMod el (X )

The rules allowed by rst-order logic and particularly by OWL 2 expressiveness form the cornerstone of Semantic Web because it allows to easily propagate relationships among the individuals of an ontology. Hence, the ontology-based systems become always more intelligent along their utilization. Moreover, the exploitation of collaborative ontologies via rst-order logic rules, in order to deduce collaborative inter-organizational processes has already proven successful. However, it does not provide a way to make a choice when several solutions are viable unless if this choice is imposed, in which case the chosen solution would not be optimized.

Ontology queries De nition of Semantic Web queries

Basically, ontology querying makes the parallel with data retrieving within databases (i.e. by using the the Structured Query Language -SQL -with relational databases). The W3C [222] de nes it as follows: " Query in the Semantic Web context means technologies and protocols that can programmatically retrieve information from the Web of Data.

"

Scope on ontology query possibilities

The most famous language for ontology querying is SPARQL (SPARQL Protocol and RDF Query Language), which was created and developed by the W3C [START_REF] Prud | Sparql query language for rdf[END_REF] in order to allow information retrieving within RDF information representation. As de ned in the W3C recommendation [START_REF] Prud | Sparql query language for rdf[END_REF], it has four query forms:

• SELECT: "Returns all, or a subset of, the variables bound in a query pattern match".

• CONSTRUCT: "Returns an RDF graph constructed by substituting variables in a set of triple templates".

• ASK: "Returns a boolean indicating whether a query pattern matches or not".

• DESCRIBE: "Returns an RDF graph that describes the resources found".

Imagine a RDF graph as described in Code 4.1 SPARQL provides many lter and operator mappings as SQL does for databases. One of the key feature of the last version of the W3C recommendation lies is the federated queries that allow querying to several remote SPARQL endpoints, and as such merge multiple sources of knowledge.

The four types of queries made available with SPARQL are really convenient to retrieve any data in an ontology as fast and e cient "unitary operations". Besides, the perspective on ontologies merging are quite interesting. However, its limitations relies in the fact that the partners of the collaboration are not already known, which makes the problem a combinatorial one as shown in the next Part.

Combinatorial problem for exploiting the collaborative ontologies

This Part aims at bringing an overview on the combinatorial problem of exploiting the collaborative ontologies to nd the optimal collaborative process to ful ll a speci c collaborative objective. Actually, the high number of combinations comes directly from the structure of the ECO which is depicted in Figure 4.1.

According to Figure 4.1, in order to ful ll the Objective O 1 , ve possibilities exist at the objectivelevel because of the complementarity of the Objectives at each decomposition level as in Equation 4.1.

               (O
C 1_1 C 1_2 C 1_3 C 21_1 C 21_2 C 21_3 C 22_1 C 22_2 C 211_1 C 211_2 C 212_1 C 221_1 C 222_1 C 222_2 Extended Collaborative Ontology PC 21_1_1 PC 21_1_2 PC 21_1_10 PC 211_1_1 PC 211_1_10 … … Figure 4.1 -Collaborative Ontology.
Each Objective can be ful lled if all the corresponding Capabilities are executed.

For example, for Objective O 1 , three Capabilities should be executed: C 1_1 , C 1_2 and C 1_3 . Then, imagine that for each of these Capabilities, ten organizations are able to provide it, there are 10 3 combinations that allow ful lling O 1 directly (i.e. without using O 21 and O 22 and their own decomposition).

When applying this logic to the ve possibilities in Equation 4.1 and assuming that there are always ten PartnerCapabilities that provide each Capability:

• O 1 → 10 3 solutions • (O 21 , O 22 ) → 10 3+2 solutions • (O 211 , O 212 , O 22 ) → 10 2+1+2 solutions • (O 21 , O 221 , O 222 ) → 10 3+1+2 solutions • (O 211 , O 212 , O 221 , O 222 ) → 10 2+1+1+2 solutions
Eventually, there are more than two millions solutions. Hence, deducing all the possible consequent collaborative processes and nally choose the best (i.e. according to non-functional requirements) process becomes fast a highly combinatorial approach.

Note also that taking each best PartnerCapability for each Capability would be convenient but is unfortunately not realistic because of time concerns: the process must be built before being assessed.

Even if this kind of approach would not be so hard to set up by using ontology reasoning and queries, the high number of potential combinations makes it really resource and timeconsuming, as soon as a certain number of organizations have subscribed to the collaborative PaaS.

Related topics 4.3.1 Collaborative processes deduction from ontology exploitation

Of all the research works studied on the topic, the research works of Ko [START_REF] Ko | Business-OWL (BOWL)-A Hierarchical Task Network Ontology for Dynamic Business Process Decomposition and Formulation[END_REF] as part of the Genesis project, faced the closest issues. Genesis aimed at providing enterprises a way to obtain on-the-y cross-enterprises collaborative processes with non-functional concerns (e.g. cost, quantity, lead time...), based on the expression of a collaborative objective. Ko et al. have based their approach on a Hierarchical Task Network (HTN) ontology called the Business-OWL (BOWL). Hence the intelligence of the system is directly embedded into the ontology. On the one hand, this approach provides an e cient way to deduce inter-organizational collaborative processes. On the other hand, it prevents users to import their own CO so that their own knowledge bases could be exploited. As underlined in Chapter 3, the scope of open-access knowledge bases on collaboration is quite limited. That is why letting companies import their own knowledge adds more exibility to the system.

Partner selection and service composition

Many research works have been led in the eld of service composition with the guiding thread of the establishment of business processes in order to model new CNOs. These works usually deal with two main topics: (i) the management science and most of all (ii) the computer science.

Those are the two investigated topics for this section.

Service composition in management science

In management science, many works focus on the establishment of supply chain networks and more generally on the creation of Virtual Enterprises (VEs). Sha and Che [START_REF] Dy | Supply chain network design: partner selection and production/distribution planning using a systematic model[END_REF] propose a Genetic Algorithm that allows nding an optimal set of partners able to provide the required business services in the context of a supply chain. Based on a "macro-process" also called a collaborative pattern, they discover candidate partners and achieve a global optimization on various non-functional criteria as cost or capacity. This method is interesting because of the multi-objective context and the necessity of nding a whole optimal set of partners, which is 4.3. Related topics not the same as nding each atomic best partners. Even if in our case this algorithm cannot be applied, because of the hypothesis of an already known "macro-process", it leads to an interesting use of a metaheuristic.

Crispim and de Sousa [START_REF] António | Partner selection in virtual enterprises[END_REF] propose a way to select partners in the context of a VE. Making the hypothesis of a star-like collaboration (i.e. a central decision maker and a network of linked partners all around), and project(s) whose activities are known, Crispim and de Sousa [START_REF] António | Partner selection in virtual enterprises[END_REF] use a Tabu Search algorithm in order to nd the best set of partners to achieve the project(s), according to various global objectives and constraints.

Many other works have been led in management science around the composition of services or the discovery of partners, however this sample is quite representative of (i) the methods usually applied in this eld (i.e. metaheuristics) and (ii) the strong hypothesis made (i.e. the activities of the collaborative process and for some of them the structure of a rst CNO intended to be further developed to be more adapted to the collaborative objectives).

Service composition in computer science

Concerning computer science, the literature is proli c on service composition, since it is one of the main breakthroughs made possible particularly with the emergence of the SOA paradigm. Dustdar and Schreiner [START_REF] Dustdar | A survey on web services composition[END_REF] have proposed a survey on web services composition solutions, which are not so far from the scope of this PhD thesis, since web services composition approaches can generally be adapted and conducted on a business level (and vice versa). They divide the topic into two approaches: (i) the static composition aims at composing services in design-time, and relies on the hypothesis that partners are xed; (ii) the dynamic one allows the discovery of services during the run-time and leads to evolving processes. Because of obvious reasons linked to inter-enterprise business agreements, and in line with the idea of automated one shot bids, the dynamic approach is clearly discarded for this PhD thesis. According to Dustdar and Schreiner [START_REF] Dustdar | A survey on web services composition[END_REF], the service composition is closely linked to business work ows, since each business task provides information for nding corresponding technical services: a condition to t the operational needs, the linkage among the web services with message ows, events, its provider. These last information should also be deduced in the context of business process deduction. However, one can observe that the technical and business approaches are conducted on two completely di erent abstract levels and consequently with di erent input hypothesis. For instance, Boissel-Dallier et al. [START_REF] Boissel-Dallier | Mediation information system engineering based on hybrid service composition mechanism[END_REF] propose a semantic reconciliation from n business services to m web services, in order to obtain a BPEL le from a BPMN process. The transformation concerns the use of ontologies as knowledge bases for the matching between business tasks information and web services annotations: what is known about a business task is (i) its business role, (ii) its ows (input, output) and optionally (iii) its provider (i.e. one can think of "generic" business partners to be found and whose role is only made clear on a technical level). When compared, the deduction of a business process is however only based on information about "what the broker wants to do", which could be only compared to a very high-level 'business role' of the process, that should be decomposed.

Rao and Su [START_REF] Rao | A survey of automated web service composition methods[END_REF] present Arti cial Intelligence (AI) planning composition de ned by a ve-tuple {S, S 0 ,G, A, Γ}, with S the set of all possible state of the world, S 0 the initial state, G the goal state of the world, A the set of actions available and Γ the presets and e ects of each action if executed. Besides, Wang et al. [START_REF] Wang | A survey on bio-inspired algorithms for web service composition[END_REF] dedicate their survey on bio-inspired algorithm for web services composition. According to them, with the current required Quality of Service (QoS) evaluation, the issues of services composition have evolved: and based on the explanation of Canfora et al. [START_REF] Canfora | A lightweight approach for qos-aware service composition[END_REF], it has become NP-hard problems, and their solving algorithms have evolved consequently. Section 4.4 is therefore entirely dedicated to the service composition through current promising metaheuristic approaches.

Besides, Wang et al. [START_REF] Wang | Enhanced ant colony algorithm for cost-aware data-intensive service provision[END_REF] introduce an Ant Colony Optimization algorithm (ACO) enabling to nd a quasi-optimal services composition from a work ow. Even if the functional issue is not exactly the same, the application of the ACO to the speci c graph composed by a work ow is quite interesting and will be more detailed in Part 4.4.2.

Resolution of np-hard problems via metaheuristics 4.4.1 Metaheuristics

As mentioned by Wang et al. [START_REF] Wang | A survey on bio-inspired algorithms for web service composition[END_REF], new methods have emerged in the service composition eld in order to optimize the deduced nal result: one is based on local optimization, when the performances of each task is assessed (e.g. cost optimization, the costs of all the tasks can indeed be added to obtain the global cost), and the second on global optimization (e.g. global delivery time of the business process, time assessment should take task parallelism or sequencing into account, and consequently the process should be entirely deduced before assessment).

Within this PhD thesis, the second category of optimization is the most interesting, since the non-functional preferences of the broker can be based on very heterogeneous criteria including time. According to Blum and Roli [START_REF] Blum | Metaheuristics in combinatorial optimization: Overview and conceptual comparison[END_REF], the term metaheuristic comes from the greek words meta which means "beyond, to a high-level" and heuriskein, i.e., "to nd". Rosenberg et al. [START_REF] Rosenberg | Metaheuristic optimization of large-scale qos-aware service compositions[END_REF] claim that "A metaheuristic is an iterative generation process which guides a subordinate heuristic by combining di erent concepts for exploring and exploiting the search space". Blum et al. [START_REF] Blum | A brief survey on hybrid metaheuristics[END_REF] also add the notion of a general algorithm that should be slightly adapted to resolve speci c problems. In their de nition, Osman and Laporte [START_REF] Ibrahim | Metaheuristics: A bibliography[END_REF] precise that this type of method allows nding near-optimal solutions through exploration, exploitation and learning strategies: " A metaheuristic is formally de ned as an iterative generation process which guides a subordinate heuristic by combining intelligently di erent concepts for exploring and exploiting the search space, learning strategies are used to structure information in order to nd e ciently near-optimal solutions. "

Resolution of np-hard problems via metaheuristics

Dréo et al. [START_REF] Dréo | Metaheuristics for hard optimization: methods and case studies[END_REF] classify optimization methods: from combinatorial to continuous problems, and within the combinatorial problems, they detail approximate methods that lead either to specialized heuristics or metaheuristics, which can then be "of neighborhood" or distributed. Metaheuristics of the rst type progress by taking into account a single solution at a time, whilst those of the second type handle a population of candidate solutions at the same time. Luke [START_REF] Luke | Essentials of Metaheuristics[END_REF] uses the terms "single-state" and "population-based".

Overview on metaheuristics

The rst key challenge of metaheuristics is the choice of one of them among plenty of existing metaheuristics, which are usually based on the study of speci c behaviors e.g. nature-based, physics-based or also even chemistry-based [START_REF] Fister | A brief review of nature-inspired algorithms for optimization[END_REF]. This Part aims at bringing a short overview on "classical" metaheuristics that have been widely studied during the last decades. For instance, Rosenberg et al. [START_REF] Rosenberg | Metaheuristic optimization of large-scale qos-aware service compositions[END_REF] describe four famous types of metaheuristics: Tabu Search (TS), Genetic Algorithm (GA), Simulated Annealing (SA) and Ant Colony Optimization (ACO).

A brief overview on metaheuristics frequently applied on service composition allows to situate this PhD thesis and to explain the authors' choice of metaheuristic.

The SA and the TS are described as single-state methods by Luke [START_REF] Luke | Essentials of Metaheuristics[END_REF]. The SA is inspired from annealing in metallurgy, which consists in controlling materials heating and cooling to obtain a better quality by increasing the size of the crystals (i.e. in terms of thermodynamics, lower the energy of the material to obtain a more stable state) [START_REF] Rutenbar | Simulated annealing algorithms: an overview[END_REF]. According to Dréo et al. [START_REF] Dréo | Metaheuristics for hard optimization: methods and case studies[END_REF], the SA is known as a demanding method in terms of adjustments (e.g. to control the cooling), and can become very time-consuming, usually leading to parallel implementation. There is no notion of memory, in SA, which means that solutions cannot be based on previous simulations. In the literature, the SA can be associated with a GA to obtain more e cient algorithms in service composition like in the works of Gao et al. [START_REF] Gao | Qoe/qos driven simulated annealing-based genetic algorithm for web services selection[END_REF] or with a TS in the works of Ko et al. [START_REF] Ko | Quality-of-service oriented web service composition algorithm and planning architecture[END_REF]. The TS is based on human memory mechanisms. Schematically, it consists in exploring the neighborhood of an initial candidate solution, to nd better candidates. All along an iteration, a solution can be chosen even if it is worst than the previous, in order to avoid local minima. Then, Dréo et al. [START_REF] Dréo | Metaheuristics for hard optimization: methods and case studies[END_REF] explain that a memory of the last explored solutions is kept, so that the mechanism is able to forbid them: it avoids studying an already retained solution (and local minima by the same time).

The GA is considered as population-based and is a type of evolutionary algorithm [START_REF] Luke | Essentials of Metaheuristics[END_REF]. According to Luke [START_REF] Luke | Essentials of Metaheuristics[END_REF], comparing to single-state methods, the evolutionary algorithms work with a sample of solution, not just one: each potential solution a ects the choice of the next candidate. Jaeger and Mühl [START_REF] Michael | Qos-based selection of services: The implementation of a genetic algorithm[END_REF] consider the GA as characterized through a loop within four phases as applied in QoS aware web service composition: the generation of a base population composed of various solutions from random combinations, the selection of a even number of solutions, the crossing of these chosen solutions to obtain new children solutions in the population and nally the mutation of individuals. This algorithm is applied both in computer and management sciences, and for instance, Sha and Che [START_REF] Dy | Supply chain network design: partner selection and production/distribution planning using a systematic model[END_REF] applied it to select partners in a supply chain network design work. The limitations of this algorithm come from the fact that the crossing step only works if all the solutions (i.e. chromosomes) have the same number of individuals (i.e. genes). Consequently, the hypothesis that a macro-process exists enables to encode the chromosome structure from the process pattern. However, in these PhD research works, two business processes could have di erent number of tasks (depending on their granularity levels), and still ful ll the same collaborative objectives, thus they cannot be crossed together.

Ant colony algorithms are particularly adapted for combinatorial optimization in a graph structure. Dorigo and Birattari [START_REF] Dorigo | Ant colony optimization[END_REF] explain that, in theory, this type of metaheuristics can be applied to any discrete optimization problem for which some solution construction mechanism can be conceived. In the case of the composition of business process services composition, this is ideal.

Schematically, an ant colony algorithm is based on the biologic behavior of ants when searching for food. The ants evolves in a speci c graph that can be constrained or not (i.e. ability or not for an ant to go from one node to any other node of the graph). Each ant, in the algorithm, builds a candidate solution. Then, the solution is assessed: if it is a good one, the pheromone on each path of the solution is increased (i.e. intensi cation step, [START_REF] Dréo | Ant colony algorithms. Metaheuristics for Hard Optimization: Simulated Annealing, Tabu Search, Evolutionary and Genetic Algorithms, Ant Colonies[END_REF]). The pheromone is the hormonal substance that attracts ants: thus the following ants of the algorithm will be in uenced to visit the previous "good solutions" paths. However, always increasing pheromone could lead to converge too quickly to one solution, preventing the ants to explore other arcs of the graph. For this reason, each time an ant visits a path between two nodes, the pheromone of this path is also decreased (i.e. diversi cation step, [START_REF] Dréo | Ant colony algorithms. Metaheuristics for Hard Optimization: Simulated Annealing, Tabu Search, Evolutionary and Genetic Algorithms, Ant Colonies[END_REF]).

Actually, as described by Dorigo and Stützle [START_REF] Dorigo | Ant colony optimization: overview and recent advances[END_REF], ACO algorithms have evolved towards several types: from the basic ants system that has given way to extensions like elitism (the global best solution has its pheromone trails reinforced at each iteration), Max-Min Ant System (all the paths are initialized with a maximal pheromone amount, and this amount cannot lower under a minimal amount), or also rank-based (the amount of pheromone deposited is weighted for each solution according to its rank).

The need to adapt the Ant Colony Optimization to the exploitation of an ontology

Because of the ability of the ants to travel over a graph structure, the ACO seems quite adapted to exploit ECO. The agents (i.e. ants) can thus be constrained in their "paths" so that they can explore the solutions space in a proper way. This brings a real strength when deducing collaborative processes, since it can be adapted to t the matching from collaborative Objective to either the corresponding Capabilities, or its SubObjectives. It also allows obtaining candidate solutions by any completion criteria, and not only a xed number of individual as in the GAs.

Beside problems as the "traveling salesman", ACO possibilities have been explored in various eld, such as decision trees exploitation [START_REF] Fernando Eb Otero | Inducing decision trees with an ant colony optimization algorithm[END_REF] or also data-mining advances with, for example, the Ant-Miner algorithm, which goal is to discover classi cation rules from gathered data [START_REF] Rafael S Parpinelli | Data mining with an ant colony optimization algorithm[END_REF]. However, ECO brings here an unusual graph structure, in which the initial search space is a directed acyclic graph, which means that the edges of the graph have a direction (e.g. from Objectives to SubObjectives) without cycles.

Wang et al. [START_REF] Wang | Enhanced ant colony algorithm for cost-aware data-intensive service provision[END_REF] detail such ACO, adapted to a directed acyclic graph. In that article, the graph is actually a work ow and the goal of the ACO is to nd a quasi-optimal services composition for that work ow (i.e. nding the best set of service candidates that ful ll each of the abstract services of the work ow). For this purpose, Wang et al. [START_REF] Wang | Enhanced ant colony algorithm for cost-aware data-intensive service provision[END_REF] de ne the work ow as a AND/OR according to the AND/OR relationships between services and their successors. Ants begin their travel on the start event of the work ow, and then follow the work ow: when they meet AND nodes, they are replicated and when they meet OR nodes, they chose one of the path. Functionally speaking, such services composition makes the assumption that the work ow is already known. Hence, the selection is made "one-by-one" for each service of the work ow, which means that all the nodes (considering each node is a service) are always studied by the ants to nd a candidate solution. In these PhD research works, candidates' solutions either strictly belong to this high-level graph (i.e. if the solution corresponds directly to the Capabilities of the top-level Objective of the graph), or should be composed from several lower-level sub-graphs (i.e. if the Objective is decomposed into its SubObjectives: each of the SubObjectives can be seen as the top-level Objective of a sub-graph which can be potentially decomposed itself).

Eventually, as mentioned by Gendreau and Potvin [START_REF] Gendreau | Metaheuristics in combinatorial optimization[END_REF], "now, the challenge is to adapt a metaheuristic to a particular problem (...), which usually requires much less work than developing a specialized heuristic from scratch". In line with this sentence, the next Section aims at adapting the ACO to the speci c combinatorial problem of the exploitation of ECO.

Exploitation of the collaborative ontologies by an Ant Colony Optimization

The deduction of an inter-organizational collaborative process remains the critical part of the whole system. The challenge of the deduction algorithm described in this sub-section is to provide a near-optimal cross-organizational business process. Here, "near-optimal" is used to mention a business process that o ers good trade-o according to non-functional criteria as cost, delivery time, quality, etc. Concretely, the selection of all the cheapest complementary capabilities for an objective will de nitely provide the cheapest process. However, it is obviously not the case for the time criterion for example because of the parallelism or the sequencing possibilities during the service composition (i.e. when the capabilities are ordered into a collaborative process).

That is why the ambition of this deduction algorithm is to exploit the minimal knowledge it holds from ECO, in order to simultaneously provide (i) a relevant set of partners, (ii) their quasi-optimal set of capabilities and (iii) the appropriate sequence of capabilities.

According to the famous maxim "divide and conquer", the following parts allow to rst describe the optimization problem and provide a main ACO algorithm, and then detail its three subalgorithms (i.e. three steps of the ACO): the Exploration phase, the Construction phase and the Evaluation phase. Finally, an improved version of the Exploration is proposed. This ACO algorithm takes advantage of the graph structure of ECO: the ants " nd their way" all along the semantic relationships that link the Objectives, the Capabilities and the PartnerCapabilities.

Problem description

A process can be described as a sequenced set of capabilities of organizations. Thus, this optimization has two main goals: (i) nd a "good" set of capabilities and (ii) deduce the sequences of capabilities to be able to assess the corresponding process.

In the following Section, the variable capa is associated with the Capabilities contained in CO, whereas pC apa designates the PartnerCapabilities.

A set of capabilities is modeled as a vector of complementary PartnerCapabilities pC apaSet = (pC apa 1 , ..., pC apa n ). The variable ob j ec t i ve also corresponds to the collaborative Objective proposed by the broker. The variable pr ocess is used to refer to the deduced process corresponding to the sequencing of pC apaSet .

Initially, the number of cycles N and the number of ants per cycle A are given. Each ant generated begins the algorithm with an empty pC apaSet = nul l . All the paths of the ECO are also initialized with the same amount of pheromone τ 0 . One ant goes through three parts:

Exploration The ant explores the ECO, from the collaborative Objective, stored in variable ob j ec t i ve to the PartnerCapabilities, according to speci c constraints due to the structure of the ECO. At the end of the Exploration, the local pheromone is updated (i.e. decreased for the diversi cation of further candidate solutions) for each parent branch of each pC apa of the chosen pC apaSet , according to the formula 4.2.

Construction Construction and feasibility : the previous set of PartnerCapabilities is ordered.

According to the input and output of each Capability (i.e. the business domains), they are linked to each other in order to obtain a process. If this process is e ectively deduced, then it shows that this process is feasible: it is a candidate solution.

Evaluation This potential solution is evaluated according to k non-functional objectives given by the user. For each potential pr ocess previously deduced, a vector S k pr ocess is generated. Then the k evaluations are aggregated and nally S pr ocess represents the global evaluation for this potential solution. The pheromone on the visited arcs of the two best solutions of each cycle evolves according to the formula 4.3 (i.e. increases for the intensi cation of the visited paths).

The Algorithm 1 presents the corresponding main algorithm. The variables nF Ob j ec t i ves and nF Ob j ec t i vesW ei g ht s correspond respectively to the non-functional objectives (e.g. less than 500 euros) asked by the broker when giving the Objective of the collaboration, and the weights associated to each of these non-functional objectives.

Algorithm 1 OpenPaaS's ACO main algorithm.

1: procedure ACO(ob j ec t i ve)

2:
Initialize N the number of cycles, A the number of ants per cycle 3:

Initialize pheromone on all the nodes of the ECO with τ 0 4:

repeat 5: Initialize S k p 6:
for Ant=1 to A do 7:

pC apaSet ← Exploration(

Update local pheromone on each pC apa in pC apaSet , with Equation

pr ocess ← Construction(capaSet, objectiveDomains)

if pr ocess is feasible then 11:

S pr ocess ← Evaluation(process, nFObjectives, nFObjectivesWeights)

12:

end if

13:

end for 14:

Determine the best and second-best solutions 15:

Update global pheromone on the corresponding capaSet according to Equation4.3 16:

until non-functional objectives are ful lled or N is reached 17: end procedure The pheromone evolves according to two steps:

• Local pheromone: each time a path of the graph is visited, its pheromone decreases according to :

τ ar c = (1 -ρ) • τ ar c + ρ • τ0 (4.2)
• Global pheromone: at the end of each cycle. Based on the works of Dorigo and Gambardella [START_REF] Dorigo | Ant colony system: a cooperative learning approach to the traveling salesman problem[END_REF] and Bullnheimer et al. [START_REF] Bullnheimer | A new rank based version of the ant system. a computational study[END_REF], and as underlined by Doerner et al. [START_REF] Doerner | Pareto ant colony optimization: A metaheuristic approach to multiobjective portfolio selection[END_REF], an update of the global pheromone applied on the two best solutions' trails is su cient. Hence, an increasing of the pheromone of all its parent arcs according to:

τ ar c = (1 -ρ) • τ ar c + ρ • ∆τ ar c (4.3)
with τ ar c the amount of pheromone on the ar c, ρ the pheromone evaporation rate (ρ ∈ [0; 1]) and ∆τ ar c as follows:

∆τ ar c =      10 • τ 0 if ar c ∈ best sol ut i on 5 • τ 0 if ar c ∈ second best sol ut i on 0 if ot her wi se (4.4)
The three modules Exploration, Construction and Evaluation are the fundamental cornerstone of this ACO and each of the following sub sections are dedicated to them.

Exploration

Concretely, the Exploration phase is composed of a set of constraints that the ants have to respect when searching for a set of PartnerCapabilities. Actually, these constraints are due to the decomposition of the Objectives and Capabilities in the ECO. The constraints can be expressed by simple logic rules. In order to simplify this explanation, the Figure 4.2 aims at illustrating the transformation from CO to a logical graph, which is in fact the graph used by the ants in the ACO.

These are the rules of transformation that have been applied here:

• The decomposition from an Objective to its complementary Capabilities is modeled with a AND-node, since all the Capabilities should be executed to ful ll the Objective of collaboration.

• The decomposition from an Objective to its complementary SubObjectives is modeled with a AND-node, since all the SubObjectives supersede together the high-level Objective.

• The decomposition from a Capability of CO to its linked PartnerCapabilities is modeled with a OR-node, since only one organization should be chosen to execute the Capability in the process.

• Each Objective that has a SubObjective is modeled as a OR-node, since the choice should be made between the set of PartnerCapabilities to directly ful ll it, or the set of SubObjectives that decompose it.

• Each Objective that has no SubObjective is modeled as a AND-node, since the only children consist in the set of the corresponding Capabilities.

For instance, the Objective A is transformed into a OR-node that leads either to a nal AND-node for all the Capabilities, either to a AND-node of two SubObjectives B and C. Since D and E are two nal SubObjectives of the arc they are merged together into a AND-node of all their corresponding Capabilities. Based on this graph, the Exploration algorithm (cf. Algorithm 2) could be implemented. ob j ec t i veLi st is initiated with ob j ect i ve, the Objective of the collaboration. All along the algorithm this list evolves with the decomposition into SubObjectives. The list l i st pC apa is null at the beginning and grows every time an ant chooses a PartnerCapability. First, the ant is dropped on ob j ect i ve, then it chooses a child node in CO, according to the Equation 4.5 : it can be an Objective or a Capability.

• If it is an Objective, this SubObjective and its complementary Objectives are kept and added to ob j ect i veLi st , and as the parent Objective has been processed it is removed from ob j ec t i veLi st . The ant re-do this loop.

• In the case of a Capability, the child and its complementary Capabilities are kept in l i stC apa for further decomposition, and as the parent Objective has been processed it is removed from the ob j ect i veLi st . Once l i stC apa contains Capabilities to execute, the ant needs to nd partners able to provide each Capability. For one Capability of CO, many children PartnerCapabilities are able to provide it, but with di erent non-functional criteria. The ant chooses one of them, according to the usual Equation 4.5.

Algorithm 2 OpenPaaS's ACO exploration sub-algorithm. 1: procedure E (ob j ect i ve)

2:
Initialize ob j ect i veLi st with ob j ec t i ve 3:

Initialize l i st pC apa null 4:

while ob j ect i veLi st not empy do

5:

for all cur r entOb j in ob j ec t i veLi st do 6:

Initialize l i stC apa null Add ob j ect i veLi st ← chi l d and its complementary objectives Remove cur r entOb j from ob j ec t i veLi st 15: for all capa in l i stC apa do 16:

pC apa ← chosen node in children, according to Equation4.

(τ u ) α • (η u ) β ] if q ≤ q 0 J if q > q 0 (4.5)
q is a random variable chosen between 0 and 1, and J is chosen according to the following probability distribution:

p ar c = (τ ar c ) α • (η ar c ) β h∈ar cs [(τ h ) α • (η h ) β ] (4.6)
The attractiveness of an arc η ar c is found by applying the further Evaluation assessment explained in Section 4.5, applied to only one Capability. Given the non-functional Objectives P = p 1 , ..., p n expressed and weighted by W = w 1 , ..., w n the broker, the attractiveness of one arc is

η ar c = n i =1 (w i • p i ).
Obviously, this Formula can only work when the arc is positioned between a Capability and a PartnerCapability (case 1 in Equation 4.7) . For these reasons, α and β have been xed as follows:

ar c = α = 1 and β = 2 if c ase1 α = 1 and β = 0 if ot her wi se (4.7)
Finally, the whole set of PartnerCapabilities is set up. The next step is to build the corresponding process.

Construction

The process to be deduced here must respect the BPMN 2.0 speci cation [START_REF] Omg | Business Process Model and Notation (BPMN) Version 2.0[END_REF]. As stated in Chapter 1, one of the bene ts of the second version of the BPMN Standard relies on its ability to be orchestrated. In such a perspective, the deduced process must contain a pool for each partner of the collaboration but also a MIS pool which goal is to interact via message ows with all the partners during the orchestration, as stated in Appendix B. In fact, the whole skeleton of the collaborative process is therefore included in the MIS pool. This Construction phase only focuses on the deduction of the MIS pool process skeleton, since the generation of the partner tasks only consists in the replication of the MIS tasks in the right partner pool, and the creation of e message ow between the corresponding MIS task and the partner task.

The Construction algorithm takes as inputs ob j ec t i veDomai nLi st , the domains linked to the Objective of the collaboration, and pC apaSet , the PartnerCapabilities selected by the previous Exploration algorithm. Note that each domain in ob j ec t i veDomai nLi st actually includes a list of BusinessFields (one or two BusinessField(s) if it concerns an intersection between two BusinessFields) and a type (i.e. physical of informational), as explained in Part 3.3.2. In the same way, each PartnerCapability of pC apaSet has a list of input and output Flows, which also have a list of BusinessFields (with one or two BusinessField(s), if the Flow concerns an intersection of BusinessFields) and a type (i.e. informational or physical).

In order to build the collaborative process' skeleton, the whole algorithm is divided here in ve steps:

• The rst step begins with a right-to-left construction, by trying to use most of the PartnerCapabilities of pC apaSet .

• The second step is a left-to-right completion, which is a mirror algorithm of the rst step: instead of trying to nd PartnerCapabilities's predecessors by linking input Flows to preceding output Flows, it focuses on nding successor PartnerCapabilities.

• The third step aims at creating the remaining start event and optional end events.

• The fourth step nally "clean" the collaborative process by adding the parallel gateways.

In the further Construction algorithms, it is assumed that the methods of the Process object createElement(type, inputList, outputList) and createSequenceFlow(fromElement, toElement) exist.

The rst method returns an Element and takes as input the type of the Element (i.e. MISTask as a task of the MIS pool, PartnerTask as a task in the partner pool, EndEvent, StartEvent or ParallelGateway). The second method takes two Elements as input: the source and the target of the sequence ow.

In order to illustrate this algorithm step-by-step, the Figure 4.3 presents a simple case with ve PartnerCapabilities that have been selected by the previous Exploration step and should now order into a Process. All these PartnerCapabilities have one or two Flows either composed of a single BusinessField ("BF" in the Figure 4.3), or of an intersection of two BusinessFields (e.g. PC4). The Objective of the collaboration has two domains: one in the intersection of "BF3" and "BF4", and the other concerning "BF5".

First step : right-to-left construction step The Algorithm 3, presents the right-to-left rst step of the Construction algorithm. First, a new Process is created and stored in the variable pr ocess. An end event is added to the pr ocess, with ob j ec t i veDomai nLi st as an input and no output.

Then, for each input domain i nput Domai n, of each el ement of pr ocess the algorithm tries to match all the output Flows of the PartnerCapabilities of pC apaSet with the input of el ement . As soon as a pC apa of pC apaSet has an output Flow that has (i) the same type as the type of i nput Domai n of the el ement and that and (ii) the same BusinessField(s) as i nput Domai n's BusinessFields, a new MIS task is created and a sequence ow is generated between this MIS task and el ement . As such, the corresponding pC apa's MIS task is added to the Elements of the Process, and, as such its input Flows can now be used to nd other predecessors. Note that Finally the variable cond i t i on takes true as an initial value. Then, as soon as the PartnerCapabilities are tested, it turns to false. And, only if during the whole process, one PartnerCapability has been linked, it takes back true as value. Hence, this variable allows to know if there are still Elements to create, if not, the algorithm nishes.

Note that, at this step, if the domains of the Objective of collaboration have not all bee linked to any Flows of PartnerCapabilities, then the pr ocess can be considered as not feasible.

Back in the illustrative case, Figure 4.4 shows the state of the collaborative Process after this rightto-left construction step. First, as "PC3" and "PC4" both have output Flows which BusinessFields are included in the domain of the collaborative Objective, they are directly linked to the end event of the Process. Then, as "PC1" output Flow has the same BusinessField as the input Flow of "PC3", "PC1" is directly linked to "PC3". The logic is the same for "PC2". The variable pC apaSet Remai ni ng refers to the list of PartnerCapabilities that have not been used in the pr ocess generated during the rst step.

Note that, if at the end of this step, there remain PartnerCapabilities in pC apaSet Remai ni ng that have not been used, then the pr ocess can be considered as not feasible. Third step : end events and start event generation At this time, all the tasks of the collaborative Process have been found and linked. Consequently, the process is already considered as feasible. Now, the start event and the optional remaining end events need to be generated.

This step is very simple:

1. Creating the start event of the Process 2. Find the tasks of the Process that have no predecessor, and link them to the start event.

3. Find the tasks of the Process that have no successor, create an end event for each of them, and link them to the corresponding end event.

Figure 4.6 illustrates this step: as "PC2" and "PC4" have no predecessor, they are directly linked to the created start event. "PC5" has no successor, hence, a new end event is created and "PC5" is linked to this end event. Fourth step : gateways generation In order to obtain an acceptable BPMN model of the process skeleton, one last thing remains: creating the appropriate gateways. As explained, due to the context of this PhD thesis, the only gateways generated are parallel gateways. This step can be explained as follows:

1. Find the tasks that have several direct successors and for each of them, create a parallel gateways that takes this task as an input and its successors as output.

2. Find the tasks that have several direct predecessors and for each of them, create a parallel gateways that takes this task as an output and its predecessors as input.

Within the illustrative case, one can see in Figure 4.7 that three parallel gateways were generated: for example, one directly parallelizes "PC2" and "PC4" that both succeed to the start event. Nevertheless, a last human "cleaning" step is required: for instance, in Figure 4.7, there are two end events, and one of them is useless because when "PC3" is nished, "PC5" should also nish ti end the process. Here, "PC5" can directly follow "PC4" and the rst gateway could be closed after "PC5" by reuniting "PC3" and "PC5" before ending the process. In this case, this cleaning is due to the fact that there is a "longer" path in parallel of the one that ful ll the collaborative objective's domains.

Evaluation

Now that the process has been built, and consequently ts the functional needs of the broker, it must now be evaluated according to the non-functional objectives P = p 1 , ..., p n expressed and weighted by W = w 1 , ..., w n in the Objective Modeler, and associated with ob j ect i ve the objective of the collaboration.

The method applied here is synthesized by Berrah et al. [START_REF] Berrah | Information aggregation in industrial performance measurement: rationales, issues and de nitions[END_REF]. The expression of the performance of a system can be expressed in two basic ways, directly when the performance can be de ned through a single expression and indirectly when the performance is the combination of several elementary expressions and especially in the case if these expressions do not have the same dimensions. The indirect expression of the global performance of a system is concretely applied by Cliville et al. [START_REF] Vincent Cliville | Quantitative expression and aggregation of performance measurements based on the macbeth multi-criteria method[END_REF], for instance.

Here the variable pr ocess represents the deduced process in the Construction step. The performances of pr ocess are evaluated according to the n non-functional dimensions and are stored in the vector v = v 1 , ..., v n . Then, these scores are normalized according to their corresponding non-functionnal objective and are calculated as follows: s = v 1 p 1 , ..., v n p n . Finally all these unitary elementary performances are aggregated according to the corresponding weights and the nal global score is

S pr ocess = n i =1 (s i • p i ).
This approach corresponds to Algorithm 5.

Improved Exploration

A rst Exploration algorithm is presented in the Section 4.5, which can be improved. In order to improve the readability for the readers, the rst "functional" algorithm was presented, which is now improved. The weakness of the rst algorithm is indeed due to the structure of CO. To understand this fact, the hypothesis of total random choices (i.e. independant of the Equation 4.5) must be made. In this case, because of the decomposition of Objectives into SubObjectives (cf. Fig. 2), the probability for an ant is higher to choose a Capability of a high-level Objective than Algorithm 5 OpenPaaS's ACO Evaluation algorithm.

1: procedure E (pr ocess, P,W )

Initialize S pr ocess = 0 for i = 1 to n do 6:

v i ← Performance of pr ocess according to P i 7:

s i ← v i p i 8:
S pr ocess ← S pr ocess + (s i • p i ) of a low-level SubObjective. For instance, on the Fig. 4.8 the probability for an ant to choose a Capability of A is p, and the probability to choose a Capability of (H+I) is w • t • q. In the simple algorithm of Fig. 2, the weights p, .., w are all equals to 0,5. Thus the comparative chance to choose a Capability of A is 0,5 against 0,125 for (H+I).

We propose to balance the weights of all the arcs established from OR-nodes (i.e. between

Objectives and their Capabilities or their SubObjectives), except if the Objective is at the lowestlevel decomposition in order to ensure a better equi-probability. As for each OR-node, there are always two arcs possible: (i) the AND-node of a decomposition into Capabilities or (ii) the AND-node of a decomposition into SubObjectives, then, for any OR-node, exactly two children arcs exist. The probability to take one or the other is 1, which means that the two children arcs are complementary (for instance, p + q = 1).

As it comes to the rest of the equations to state, the approach begins with the lowest-level of Objective i.e. (H+I). The closest parent OR-node is G, from which the two children can be similarly chosen: v + w = 1. Then, in order to ensure the equi-probability, the two longest paths starting from each of the children OR-node arcs should be also similarly chosen. Here, the second closest parent OR-node is C. Each of the children longest arcs of C should be similarly chosen, which means that u = t • v. In the same way, for the A OR-node, it can be stated that p = q • t • v. Finally, for the B OR-node, only two single-level arcs exist, therefore r = s

This leads to the following equation system:

                             p + q = 1 r + s = 1 t + u = 1 v + w = 1 r = s v = w u = t • v p = q • t • v (4.8)
The result, for this example is:

                             p = 1/4 q = 3/4 r = 1/2 s = 1/2 t = 2/3 u = 1/3 v = 1/2 w = 1/2 (4.9)
Note that, for instance, there is twice more chance to choose the F decomposition (q • t = 0, 5) than the (H+I) (q • t • v = 0, 25). Nevertheless, this phenomena is quite normal since the F node is necessarily visited if the ant nishes with one or the other children connections of G. The F node is indeed part of two potential solutions: it has consequently twice more chance to be used.

This approach has been generally applied to the whole ECO. Assuming that the rank of an

Objective determines its maximum number of decomposition (for instance, r ank G = 1 since it can only be decomposed one time into SubObjectives, r ank C = 2 since it can be at most decomposed two times into subObjectives and r ank B = 1), then it is easily veri able that:

• The probability coe cient of an arc to be chosen, between an Objective OR-node and its SubObjectives decomposition is coe f f i ci ent ar c = r ank Ob j ect i ve 1+r ank Ob j ect i ve .

• The probability of an arc to be chosen, between an Objective OR-node and its Capabilities decomposition is coe f f i ci ent ar c = 1 1+r ank Ob j ect i ve .

Hence, as these coe cients are independent of the Objective chosen by the broker for the collaboration, ECO has been initially updated and each arc between two Objective OR-node now embeds its corresponding coe f f i ci ent ar c .

Note that the speci c choice among the children paths explained in the Equation 4.5 was momentarily forgotten. Now that the equi-probability has been resolved, it can be re-introduced.

In order to balance the choices of the arcs all along the Exploration algorithm, is has been decided to apply these equi-probability coe cients directly to the amount of pheromone of the corresponding arc. Thus the new pheromone amount of a arc newτ ar c becomes newτ ar c = τ ar c • coe f f i ci ent ar c , with τ ar c the "basic" amount of pheromone and coe f f i ci ent ar c the equi-probability coe cient of the ar c, in Equation 4.5. However, in order to be e cient, this coe cient should be applied only on this Equation 4.5. The rest of the algorithms must remain unchanged, so that the pheromone can naturally evolve, otherwise, the current equi-probabiliy method would become wrong.

Performances

In order to evaluate the performances of this ACO, it has been decided to assess the global score all along the iterations (i.e. ants cycles). For this purpose, di erent scenarios were set up by varying some of the parameters. First, the four chosen scenarios are described, and then the performance of the ACO on each of them are detailed.

Test scenarios

The scenarios have been chosen so that the behavior of the ants could be assessed, depending on two main parameters: the number of decomposition of Objectives into SubObjectives, which will be called nbOb j Level s and the number of PartnerCapabilities available for each Capability of ECO, which corresponding variable is nbP ar t ner C ap. The number of Capabilities per Objective has been set to 2, and the number of SubObjectives per Objective is also 2.

Hence, four ECOs have been generated along these parameters:

4.6. Performances

• ECO#1: nbOb j Level s = 2 and nbP ar t ner C ap = 10.

• ECO#2: nbOb j Level s = 2 and nbP ar t ner C ap = 20.

• ECO#3: nbOb j Level s = 3 and nbP ar t ner C ap = 10.

• ECO#4: nbOb j Level s = 3 and nbP ar t ner C ap = 20.

As a non-functional Objective, the top-level Objective of each ECO was always chosen -which is consistent with the choice of nbOb j Level s. As it comes to the non-functional objectives, they depend on two non-functional criteria, which are the global cost and the global time of delivery of the solution. Both objective values have been selected so that they could not be reached, in order to evaluate the convergence of the ACO, with a weight of 0, 8 for the cost and 0, 2 for the time.

Hence, the cost cost and the time of delivery t i me of each PartnerCapabilities of the ECOs were randomly generated according to the level of the Objective their corresponding Capability ful lls, which is called here par t ner C apLevel (otherwise the best solution would always directly answer the top-level Objective, which would go against the equi-probability of the edges):

• All the PartnerCapabilities have been generated with the same input and output ows, as such, even if the calculation of the global time of delivery of a process corresponds to the maximum time of the PartnerCapabilities, the time assessment algorithm is still the same: it has no impact on the evaluation of each candidate solution, but it is quite convenient to generate viable (and consequently assessable) processes.

Eventually, the intrinsic parameters of the ACO were set along the recommendation of the literature [START_REF] Wang | Enhanced ant colony algorithm for cost-aware data-intensive service provision[END_REF][START_REF] Dorigo | The ant colony optimization metaheuristic: Algorithms, applications, and advances[END_REF]:

                         number o f c ycl esN = 100 number o f ant sper c ycl e A = 10 α = 1 β = 2 ρ = 0, 1 τ 0 = 0, 1 q 0 = 0, 7

Results

The ants' behavior was observed for each of the four ECOs, and, nally, the four graphs in Figure 4.9 were obtained. One can see on these graph that the ACO is rightly converging towards 1, when minimizing the function 0,8 * cost costOb j ect i ve + 0,2 * t i me t i meOb j ect i ve for the best process found at each iteration. Global score

Iterations

Global score evolution along the iterations -ECO#3 This Chapter proposes a contribution that could be detailed along two axes: a scienti c contribution and an applicative contribution.

1 1,05 1,1 1,15 1,2 1,25 1,3 1,35 1,4 1,45 1,5
The scienti c contribution relies on the utilization of an ACO algorithm to a graph made of AND-nodes and OR-nodes. Due to the CO structure, this speci c type of graph makes the application of an ACO more complex than a basic graph. Thus, the behavior of the ants has been adapted in consequence by constraining the paths they can choose at each level of CO.

Contributions, discussion and perspectives

Besides, such structure leads to unbalanced probabilities for all the edges of the graph to be chosen by ants. An improved exploration algorithm has therefore been implemented.

The applicative contribution relies on a new way to exploit a collaborative ontology. Limitations of ontology inferences and queries were highlighted in Part 4.2, however, ontologies are still very powerfull tools. First, in the continuation of MISE project and in an easy integration concern, it was chosen to go on working with ontologies. But the main reason is rather the exibility it brings to the IT system. E ectively, ontologies are a very widespread tools both in academic and industrial worlds. As such, implementing a surrounding intelligence allows the users to bring their own ontologies even with their own inferences rules as long as the knowledge structure described in Chapter 3 is respected. Besides, in comparison with exact methods, this ACO provides limited time response with good quality results. Nevertheless, considering that there are very few works in the literature that also o er to answer collaborative opportunities without knowing either the partners of the collaboration nor a high-level pattern to follow (i.e. macro-process), it is quite hard to compare these works with other approaches.

Discussions and perspectives

There are several points that could be discussed within this ACO algorithm to exploit the collaborative ontologies. Some of them lead to further ideas that could improve this DSS.

Improvement of the construction algorithm

The construction algorithm in Part 4.5 is somehow time-consuming because it builds the process before knowing if it is viable or not -because of input and output matching. As such, there is a non -negligible probability for each pC apaSet not to lead to any candidate solutions. However, it is hard to know if the process will be viable before trying to build it. For this reason, and for this step not being a loss of time and resources, it could be interesting to exploit the "non-viable" process. Thus, a reparation algorithm would allow to discard the PartnerCapabilities that do not t into the process and choose concurrent ones that matches the right input and output.

Besides, using only BusinessDomains, even if they are quite detailed in BFO, seems not always realistic to describe the ows of the PartnerCapabilitiesOne. Thus, it could be interesting to associate a name to each ow. But consequently, it could become hard to nd viable processes that respect an exact syntactic matching between the input name of a PartnerCapability (i.e. an activitiy of the process here) and the output name of its predecessor. In fact, this aspect has deliberately not been considered since the works of Tiexin Wang [START_REF] Wang | Semantic approach to automatically de ned model transformation[END_REF] (cf. the perspectives of Chapter 3) provide such semantic reconciliation: it needs now to be integrated.

Since the broker chooses an Objective of collaboration in CO, this Objective could be a high-level or a low-level one. This means that, depending on the Objective, the part of CO exploited by the ACO varies and includes more or less decomposition levels. Thus, the parameters of the ACO, particularly the number of ants per cycle and the number of cycles, could be studied according to the complexity of the part of CO studied. In such a way, the parameters could be dynamically chosen for each opportunity so that the nal solution is good enough and the time and resources consumed to nd it are reasonable. Besides, such study would also allow to adapt the parameters whatever the ontologies directly brought by users and not only the provided CO.

Conclusion

As a conclusion, this Chapter presents in detail an ACO that has been adopted to exploit the ECO. Over the broad scope of metaheuristics, the ACO was chosen because of their ability to deal with acyclic directed graph such as ECO. Hence, ECO was transformed into a AND/OR graph corresponding to the Objectives and their decomposition into complementary Capabilities or into complementary SubObjectives. The ants of the ACO can therefore travel all along the edges and replicate if arriving to a AND node, or choosing one of the path if arriving to a OR node.

This approach shows good results, by converging fastly enough within 100 cycles of ants. Besides, the time of computing is quite fair compared to the time it actually would take when assessing all the candidate solutions. As a result, this ACO allows to o er the users a good manner to set up their collaboration, since it brings as e cient solution to deduce quasi-optimal inter-organizational collaborative processes only from ECO within good computing times. Now that the whole theory has been explained, and that it has been assessed on "randomly" generated ECOs, it is time to apply this approach to a more practical use-case, so that the readers could better see how the users can really use this decision support system.

The ACO approach and the behavior of the ants have been presented in the proceedings of the Pro-VE 2014 Conference [202].

Résumé en français

Alors que le Chapitre 3 visait à représenter et acquérir des connaissances sur les collaborations à supporter, ce chapitre a pour but de développer un système d'aide à la décision basé sur des ontologies, a n d'exploiter ces connaissances pour en déduire des processus collaboratifs quasi-optimaux. Cela nécessite trois éléments: (i) trouver les Capacités devant etre réalisées a n de remplir les Objectifs de la collaboration, (ii) trouver l'ensemble des "meilleurs" partenaires capables de réaliser ces Capacités et (iii) ordonner ces Capacités a n d'obtenir un processus. Néanmoins, le choix de l'ensemble des partenaires ne peut pas être fait de façon atomique, car, par exemple, le temps de réalisation d'un processus ne peut être évalué qu'une fois tous les partenaires choisis et leurs Capacités ordonnées (pour des questions de parallélisation des Capacités). Des calculs simples montrent que tester l'ensemble des processus pouvant potentiellement répondre à une opportunité résulte en un problème hautement combinatoire, amenant des temps de traitement irréalistes dans le contexte de ce RSE. Ainsi, les outils habituellement utilisés pour exploiter les ontologies, comme le raisonnement à base de règles logiques (i.e. inférences) et les requêtes en language SPARQL, ne peuvent pas être utilisés directement ici. Concrètement, cet algorithme peut être décrit selon trois étapes répétées sur plusieurs cycles, a n d'a ner les solutions trouvées: (i) exploration du graphe, (ii) construction d'une solution candidate et (iii) évaluation de cette solution. Initialement, chaque fourmi du cycle est déposée sur le noeud correspondant à l'objectif de la collaboration, et tous les arcs se voient attribuer une quantité de phéromone initiale. La première étape consiste, pour chaque fourmi du cycle, à explorer l'ensemble du graphe dans le respect des contraintes des noeuds de type ET/OU. Chaque arc utilisé par les fourmis est dévalué (i.e. diminution de la quantité de phréromone) a n d'éviter une convergence trop rapide des fourmis vers une solution unique (et donc de déversi er les solutions candidates). De plus lorsqu'une fourmi arrive sur un noeud de type ET, elle se réplique, tandis que sur un noeud OU, elle choisit l'un des arcs qui s'o re à elle. Une fois obtenu un ensemble de Capacités d'organisations, la deuxième étape de construction, permet de les ordonner en un processus, en réalisant des correspondances entre les ux en entrée et en sortie des Capacités d'organisations trouvées. Finalement, l'évaluation ne se fait qu'après avoir véri é la viabilité du processus candidat obtenu, et consiste à comparer cette solution aux "meilleures" solutions obtenues par les fourmis précédentes. Si le processus candidat évalué est l'un des deux "meilleurs" processus trouvés par l'ensemble des fourmis du cycle, les arcs parcourus pour l'obtenir se voient intensi és (i.e. augmentation de la quantité de phéromone). Le terme "meilleur" fait ici référence à l'évaluation d'une solution candidate vis-à-vis d'objectifs non-fonctionnels déclarés dans le modèle d'opportunité dé ni dans le Chapitre 3.

Par l'alternance entre diversi cation à chaque fourmi et intensi cation des meilleures solutions trouvées à chaque n de cycle, cet algorithme permet nalement de trouver un processus quasi-optimal, en répondant simultanément aux questions Quoi?/Qui?/Quand? évoquées dans l'introduction de cette thèse. Une évaluation des performances sur des ontologies de di érentes complexités a montré que l'algorithme présente de bonnes performances tant sur la qualité des solutions obtenues que sur le temps de calcul requis.

L'algorithme d'optimisation par colonies de fourmis détaillé dans ce chapitre amène deux contributions principales: l'adaptation de ce type de métaheuristique à un graphe ET/OU orienté et acyclique nécessite un soin particulier dans le choix des paramètres initiaux du graphe (par exemple le taux de phéromone initiale sur les arcs) mais aussi une nouvelle possibilité pour exploiter des ontologies dans le cas où requêtes et inférences ne se montreraient plus assez e caces en terme de temps de traitement. En outre, l'intelligence est indépendante de la connaissance stockée dans l'ECO. Ainsi, les utilisateurs pourraient amener leur propres ontologies de collaboration sans changer les étapes d'acquisition des pro ls et opportunités, ni d'exploitation pour la déduction de processus collaboratifs quasi-optimaux.

Introduction

In the previous Chapters, the theoretical solution was explained: from the acquisition of users' needs on functional and non-functional axes, to the response to these needs based on the exploitation of the knowledge contained in ECO, with an ACO algorithm. Up to here, the acquisition and the exploitation of the collaborative knowledge can remain somewhat abstract. Hence, this Chapter aims at bringing a concrete point of view of the system through an illustrative case. Besides, as part of the OpenPaaS project, the whole system was implemented as user interfaces. Section 5.2 details the choices that have been made for developing such collaborative platform, from the IT technologies used, to the types of user interfaces o ered. Then Section 5.3 gives a concrete illustrative case by simulating the interactions of the users with the system in a speci c context.

Implementation

Functional architecture

The functional architecture of the implemented software actually ts exactly the way the users interact with it. Those interactions are of three types: either to (i) de ne a pro le, (ii) bring a new collaborative oppotunity or (iii) visualize and optionally adapt the nal collaborative process.

Following the MDA approach as mentioned in Chapter 3, the implementation has been made as modelers i.e. user-friendly interfaces that allow users to easily use it.

Figure 5.1 was already used in Chapter 1 in order to introduce the whole articulation of this PhD thesis. Actually, the logic followed by the IT system is the same. First, as a front door, the users model their pro le via a Pro le Modeler. Then a broker propose a new collaborative opportunity through the Objectives Modeler. Then, backyard, once the knowledge and the needs are acquired from these two models, the ACO algorithm is able to exploit both collaborative ontologies (i.e. CO and BFO, also mentioned as ECO), which enables to nd a quasi-optimal set of organizations' capabilities and order them into an inter-organizational business process. Back to the front door, a third modeler the Collaborative Business Process Modeler allows the broker to visualize the nal deduced process and optionally to adapt it to special needs. As part of the OpenPaaS project, these three modelers have been plugged on the ESN implemented by the whole consortium, and which brings the users other collaborative tools rather oriented towards coordination needs (i.e. shared calendar, instant messaging...). Figure 5.2 shows that on the one hand, the three modelers rely on the collaborative ontologies CO and BFO, and are called as web services from the ESN, at each step.

The three further parts aims at bringing an overview on the tools developed in each of these • The Palette enables to model the di erent concepts available. As stated in Chapter 3, for the Pro le Modeler, these concepts correspond to (i) the organizations' capability (i.e. PartnerCapability in the metamodel presented in Chapter 3), (ii) the ows input and output and (iii) the relationships HasInput and HasOutput to link the capability with its ows.

• The File menu allows to manage the model le. Basically, it can be stored in the browser cache, or exported to the client workstation. A model that has been previously exported can also be imported. The button deploy allows to deploy the model in the server.

• The Action menu has a single button "populate ontology", which aims at acquiring the knowledge contained in the model and link it with the backyard ECO. Typically, this is the nal button of the pro le description step.

Beside these menus, shortcuts can directly be be used to create the model, within the canvas. These links between the model and the CO and BFO are achieved by double-clicking on each instance. Then a box opens with all the possible details. • The Palette enables to model the di erent concepts available. As stated in Chapter 3, for the Pro le Modeler, these concepts correspond (i) the organizations' objective of collaboration), (ii) the business domains concerned by this objective and (ii) the relationship HasDomain that links the objective with its domain(s).

Objective modeler

• The File menu is the same as for the Pro le Modeler, except that there is no "deploy" button: the objectives are not stored in the server. These are one-shot objectives that are directly processed.

• The Action menu has a single button "deduce process", which goal is to call the ACO algorithm, and give it the objective model as an input.

Beside these menus, shortcuts can directly be used to create the model, within the canvas. Figure 5.4 shows such basic model with an objective and two linked business domains.

As in the Pro le Modeler, when double-clicking on the instances they can be detailed.

Collaborative process modeler

The Collaborative Process Modeler is basically a BPMN process modeler. Hence, the only menu that changes from the other modelers is the Palette, which contains all graphical BPMN elements classi ed as events, gateways, tasks, pools and ows. This modeler aims at o ering a visualization of the nal deduced collaborative process, but also allows the broker to adapt this deduced process if did not t entirely exactly his/her expectations.

Let's now see these three modelers in action all along an illustrative case.

Technological choices

The development of this system has gone through two phases the front door modelers, and the background algorithms:

• Modelers: the modelers have actually been set up based on a generic modeler that has been developed within the Industrial Engineering Center at Mines Albi. This generic modeler can be adapted, by providing speci c xml les that embeds the meta-model of the modeler. This meta-model speci es the Palette of the modeler but also the boxes open by double-clicking on the concepts drawn in the canvas.

• Background algorithms: they are called by clicking on the menu buttons. For this PhD thesis and the project OpenPaaS, three buttons have been speci cally developed: (i) the "deploy" button to save the model le on the OpenPaaS server, (ii) the "populate ontology" button that takes the model as an input, and extract its knowledge to add it to the ECO in background and (iii) the "deduce process" button to run the ACO.

Java was used to develop the whole system, including the ACO. Moreover, all the interactions performed with ontologies have been implemented by using the Java API for OWL format, OWL API [START_REF] Horridge | The owl api: A java api for owl ontologies[END_REF]. Note that the OWL API built-in StructuralReasoner1 provides methods to implement basic queries, which were su cient for the ACO algorithm.

Illustrative case and results

Presentation of the illustrative case

In this beginning of November, while the weather forecasts announced increasingly cold days for the months to come, John, young entrepreneur and happy owner of a wholesale distribution start-up is shopping in the streets of Albi. He suddenly realizes that Christmas decorations and objects are just about to arrive in shops and malls. This idea making its way, John thinks about those funny Christmas cheap hats and decides that it may become a new business to take in Albi area. The only problem is that those products are expected to be ready for the store shelves at the beginning of December. This means that John can really not a ord wasting too much time for the establishment of the Supply Chain: he has to quickly nd competitive collaborators that will be able to work with him. Once back home, he discovers the OpenPaaS platform and decides to create a pro le for his business, and see if it could help him set up this new collaboration.

Acquisition of the collaborative knowledge via human interactions Pro les of organizations

The rst step John has to ful ll is creating a new pro le for his start-up on the Pro le Modeler. For this purpose, he has to follow the pro le modeling described in Chapter 3. He needs to describe his capabilities and link them to those contained in CO and precise their ows by linking them to BFO. The rst capability that John creates is "Place order".

As a start, he creates a basic model with a capability and its expected ows: a single output, as described in Figure 5.6.

By double-clicking on the "Capability 1", John can change the details of the capability as in Figure 5.7: its name, its associated non-functional criteria, and link it to the CO by clicking on the " nd" box. Here, John has no access to the non-functional criteria that should be informed by further partners (e.g. reputation), but he details the following:

• Delivery time (days): 1 day.

• Price (euros): 0 euro.

• Penalty/incentive: 0.

• Con dentiality: no.

• Quick on short notice delivery: yes.

Note that an "automated" box is provided: it aims at de ning if the capability is a human-task or basically a web service. If it is a web service: the capability could be linked with a SaaS deployed on the PaaS (either provided by OpenPaaS collaborative services -e.g. an automated form for administrative services-or directly by the organization). Here, John de nes the capability as a human task. Now that the capability has been detailed, it must be linked to the CO by clicking on the " nd" button in Figure 5.7. A list of all the capabilities contained in CO arises, with an input eld to make a quick search. John searches "Place order" and selects it as in Figure 5.8.

As it comes to describe the ows, the approach is quite the same: John double-clicks on the "Output 1" and details the ow name. With a " nd" button, he accesses all the business eld contained in BFO, and he can link the output to a business domain. In Figure 5.9, John links the output to "8211 -Combined o ce administrative service activities".

When the capability has been properly described, John can populate ECO with the knowledge contained in his capability model. Hence, he clicks on the "Populate ontology" button.

In background, the OWL2 le co_test.owl is updated, and a new individual appears with its corresponding data properties. The code presented in Figure 5.10 corresponds to the code updated with "Capability_1", which is John new capability. Then, John details the objective he wants to propose: in Figure 5.12 he summarizes his needs through the non-functional criteria:

• Delivery time (days): 20 days.

• Total cost (euros): 5000 euros.

• Quantity: 15000.

• Quick on short notice delivery: yes.

For the remaining criteria, he has no speci c expectations, that is why they are left in their default values (which are the minimal possibilities).

The objective should then be linked to the BFO, by clicking on the " nd" button. Here, John selects "Buy wholesale" as it is his objective as in Figure 5.13.

Finally, John needs to precise the ows concerned by his opportunity. In this case, he has one business domain. Figure 5.14 shows that John links it at the intersection of two business domains with the individuals "1410 -Manufacture of wearing apparel, except fur apparel" and "4923 -Freight transport by road" in the BFO, with a physical type of ow, to express that he is interested in buying wearing apparels with a nal transportation of the products by road accommodation.

Figure 5.12 -Objective "Buy wholesale" description.

Creation of a set of pro les

For the convenience of this illustrative case a whole set of pro les has been generated. This illustrative case basically deals with three speci c rules: wholesalers, manufacturer and carrier. Each of them actually have typical capabilities:

• Wholesalers have the following capabilities: "Obtain order" and "Deliver product" and "Send invoice".

• Manufacturer have the following capabilities: "Obtain order", "Produce" and "send invoice".

• Carriers have the following capabilities: "Obtain order", "Deliver service" and "send invoice".

Besides, ve di erent business elds are involved:

• 8211 class: "Combined o ce administrative service activities"

• 4923 class: "Freight transport by road"

• 4641 class: "Wholesale of textiles, clothing and footwear"

• 1410 class: "Manufacture of wearing apparel, except fur apparel"

• 13 class: "Manufacture of textiles" Table 5.1 presents the di erent type of pro les that have been generated, with their corresponding capabilities and their ows.

The ten pro les of each type have been generated, with random values as non-functional criteria.

Results

Once John has created its opportunity by de ning the objective "Buy wholesale", he can click on the button "deduce process". The ACO algorithm nds a nearly-optimal collaborative process, as explained in Chapter 3. As a result, a .pco le is downloaded on the client workstation, which contains the whole deduced process.

In order to visualize this process, this le should be imported into the Collaborative Process Modeler. Figure 5.15 shows this process. One can note that the chosen solution by the ACO consists in the decomposition into "Buy to producer" and "Transport". The process indeed embeds a manufacturer pool, with the "Produce" activity.

On the ten manufacturers and ten carriers, Manufacturer8 and Carrier5 have been chosen as partners to work with John, to provide him wholesales of wearing apparels.

Highlighted limitations

The concrete explanation of this illustrative case leads to highlight two limitations. First, when choosing partners, the ACO could provide a candidate process in which Manufacturer3 deals with the Produce task, but the other tasks "Send invoice" or "Obtain order" could be achieved by any of the other Manufacturers, which is a problem. In order to solve it, it could be convenient to constraints the behavior of the ants of the ACO, so that each time they select a PartnerCapability, they remember the corresponding Partner, and when choosing other PartnerCapability, they prefer those provided by this partner.

Moreover, one can note that, here, for instance, the task "Deliver service" has, as input and output ows, ' BusinessField "Manufacture of wearing apparel, except fur apparel", which is not really intuitive: a carrier able to transport wearable apparels could also transport a lot of other products. The reason here is that the Construction algorithm does not take into account the transverse nature of some PartnerCapability. In order to resolve that, a study of the transverse nature of each PartnerCapability should be made: if a PartnerCapability is considered as transverse, then it conveys automatically its input ows' BusinessFields. The question remains how to de ne the transverse nature of a PartnerCapatbility, especially if it depends on the context of the collaboration.

Conclusion

In this Chapter, a use-case was presented, which allows the readers to concretely imagine how to use the implemented DSS. Now that the inter-organizational business process has been deduced as a BPMN 2.0 process, it can be easily orchestrated: each of the activities contained in the MIS Pool is thus going to call the corresponding activities in the Partners' pools. When situated on parallel sequences after a AND gateways, the activities will be called simultaneously. Many BPMN 2.0 orchestration engines exist, one of the must famous is for example Activiti [256].

Nevertheless, one can note that the whole system relies on the knowledge brought by the users in their pro le models. Hardly avoidable at this time, it leads to make the assumption that the collaborative ontologies (i.e. CO and BFO) are understandable enough by the users and adapted to their point of view -since they have to link their concepts with CO's individuals. Already observed by Wenxin Mu in her PhD thesis [START_REF] Mu | Caractérisation et logique d'une situation collaborative[END_REF], the lack of freely exploitable collaborative knowledge is still here. This brings back to the discussions of Chapter 3: the integration of a tool for aligning heterogeneous knowledge bases, as the one developed by Tiexin Wang in his PhD thesis becomes crucial for making such system viable.

Résumé en français

Après avoir détaillé les mécanismes d'exploitation des ontologies de collaboration dans le Chapitre 4, ce chapitre vise à décrire le système qui a été e ectivement implémenté, et à amener une illustration concrète du RSE implémenté dans le cadre de cette thèse. Trois éditeurs ont été développés: (i) un éditeur de pro l, permettant aux organisations de décrire leurs capacités, (ii) un éditeur d'opportunité, permettant aux utilisateurs de proposer de nouvelles opportunités et (iii) un éditeur de processus collaboratif permettant de visualiser et éditer le processus collaboratif nalement obtenu. Les deux premiers éditeurs sont basés sur le principe décrit lors de l'acquisition des connaissances, dans le Chapitre 3.

Un cas d'illustration permet de montrer, en pratique, les intéractions entre les utilisateurs du RSE et les trois éditeurs mis à disposition, dans le cadre d'une opportunité de type chaîne logistique virtuelle "one-shot" d'achat en gros, amenée par un grossiste dont le métier est d'acheter des larges lots et de les revendre à des distributeurs. Après passage de l'algorithme d'optimisation par colonies de fourmis, un processus métier collaboratif inter-organisationnel est déduit et présente les performances non-fonctionnelles désirées par le demandeur.

Conclusion and Perspectives

"Every real story is a never ending story. "

-Michael Ende, The Neverending Story In today's economic context, the ability to create inter-organizational collaborations is a key success factor for any enterprise. These collaborations need to be always faster, but they consist, most of the time, in ephemeral organization networks developed for one-shot opportunities. Such behavior is widely permitted by the recent advances made in computer and management sciences. However, the enthusiasm for inter-organizational collaborations is such that the need of more exible, fast and e cient solutions is stronger than ever. In this context, this PhD thesis aims at automating the design-time of inter-organizational collaborations by providing an inter-organizational collaborative process as an answer to collaborative opportunities. Based on an Enterprise Social Network, the IT system that has been implemented around the acquisition and the exploitation of collaborative knowledge aims at addressing three issues: (i) which business services should be performed in order to achieve the objectives? (What?), (ii) who could provide these business services to obtain the best results (in terms of criteria such as time of completion, or cost)? (Who?), (iii) when should each organization execute its business services? (When?).

Main results and contributions of the thesis

After having presented the context of these research works both from Management and Computer science perspectives, a three-time approach was adopted in these PhD research works to address the problematic identi ed in Chapter 1.

The rst step provides a wide scope on the non-functional criteria usually taken into account within partner selection context, and, as such, has been based on a broad literature review within Management and Computer sciences. It has led to the establishment of a three-dimensional framework applied to the speci c context of Enterprise Social Networks, but which can also be used for any partners selection context. Moreover, all the non-functional requirements of the resulting framework are associated to their adapted metrics.

The second step focuses on the development of a knowledge-based system to allow for further deduction of collaborative business process. To this purpose, two ontologies have been structured, implemented and populated. The Collaborative Ontology (CO) focuses on the decomposition of collaborative objectives into sub-objectives and capabilities. The Business Field Ontology (BFO) provides a hierarchy of business domains. The organizations describe their capabilities through pro le models, by a ecting them at the intersection of both ontologies, and can as well propose a new opportunity. Both capabilities and opportunities descriptions are also extended with the non-functional criteria identi ed in the rst phase. The main contributions of this part rely on the adaptation of a collaborative metamodel to t the context of an Enterprise Social Network intended for the automation of the design-time of the collaboration. They also build on the mechanisms used by the organizations to describe themselves and their needs by using collaborative ontologies. The strength of these ontologies lies on that they are already populated with huge amount of individuals.

Deducing a "good" (i.e. regarding non-functional criteria) collaborative process may not be the same as nding each single best partner for each capability required to reach the collaborative objective (because of time concerns for example). Hence, the usual tools for exploiting ontologies are not su cient enough, and an Ant Colony Optimization (ACO) algorithm has been implemented and adapted to the speci c structure of the CO, to address simultaneously the previous What?Who?When? questions. As a result, two contributions are identi ed: the scienti c one relies on the adaptation of an ACO algorithm to a very particular type of structure (which could be de ned as an acyclic directed graph), while the applicative contribution consists in providing a new e cient way to exploit ontologies, to resolve combinatorial problems.

opportunities:

• The emergence of new pro les can be seen as an intelligent extraction of the organizations' data. As an example, Van Der Aalst [START_REF] Van | Process mining: discovery, conformance and enhancement of business processes[END_REF] has introduced the concept of process mining.

The goal is, from data-set and machine learning adapted rules, to deduce the processes of an organization. This discipline is now more and more used in the industrial world to compare the e ective processes of the organizations, with the theoretical designed processes. Hence, any organization that has deployed such technology is therefore able to automatically generate its internal processes. Each of those processes could then be seen as a capability that the organization is able to provide, and then automatically added to its pro les. In addition, the ows of the capability could also be deduced from the generated processes.

• The emergence of new opportunities can be seen as an intelligent extraction of the organizations' data within speci c collaborative contexts (i.e. economic context for business opportunities, or even crisis context, in crisis management response). In the frame of her PhD thesis and the MISE project, Anne-Marie Barthe-Delanoë [START_REF] Barthe-Delanoë | Event-driven agility of interoperability during the run-time of collaborative processes[END_REF] has developed a Complex Event Processing (CEP) that allows, from logic rules, to analyze data ows and to provide an agility service to the whole MISE scheme.

Hence, by comparing an expected model (which has been generated by the automated design-time) and a eld model (what is really happening), her research works allow to detect di erences, and to consequently dynamically adapt the collaboration, (i) either by calling again the automated design-time, (ii) or by only changing the task of the business processes that are no more appropriate, (iii) or by changing technical services that are no longer appropriate. Hence, it brings three dynamic feedback loops. Imagine now that this eld model corresponds to the current economic context. By applying speci c rules, a change in the economic context model could then be detected (e.g. detection of a new privileged market). A link could therefore be made with some of the organizations' pro les stored in the Extended Collaborative Ontology of the system (i.e. CO extended with the partners' capabilities), and an opportunity could thus be automatically proposed to these pro les.

Towards a knowledge management tool

More generally, this PhD thesis juggles with the three concepts: data, information and knowledge.

Both of these three levels bring a transitory state from the basic eld observation (data level), or the contextualized information to the structured knowledge. For example, each of the previously given perspective can be mentioned as a state transition between these three levels: the emergence of new pro les transform gathered data into information about the organization (i.e. its capabilities, which become knowledge once linked to the CO); the semantic reconciliation of Tiexin Wang can take two knowledge bases as input and merge them into another knowledge Dans le contexte économique actuel, la capacité à créer des collaborations inter-organisationnelles se révèle être un facteur clé de succès pour toute entreprise. Ces collaborations doivent être toujours plus rapides, mais, la plupart du temps, elles consistent aussi en des réseaux d'organisations éphémères développés pour des opportunités uniques (i.e. de type one-shot). Cependant, l'engouement pour les collaborations inter-organisationnelles est tel que le besoin de solutions plus exibles, rapides et e caces est plus grand que jamais. Ainsi, cette thèse vise à automatiser le design-time de ces collaborations en déduisant un processus collaboratif inter-organisationnel en réponse à des opportunités de collaboration. Basé sur un Réseau Social d'Entreprises (RSE), ce système d'information, implémenté autour de l'acquisition et de l'exploitation des connaissances sur la collaboration, répond à trois questions: (i) quels sont les services métiers qui devraient être e ectués pour réaliser les objectifs de la collaboration (Quoi?) (ii) quelles sont les organisations capables de réaliser ces services métier? (Quoi?) et quand est-ce que chaque organisation doit réaliser ses services métier? (Quand?)

Principaux résultats et contribution de la thèse

Après avoir présenté le contexte de ces travaux de recherche à la fois d'un point de vue orienté génie industriel et systèmes d'information, une approche en trois étapes a été adoptée dans cette thèse, pour répondre aux problématiques identi ées au Chapitre 1.

Tout d'abord, la première étape a consisté à donner une vision large sur les critères habituellement utilisés pour sélectionner des partenaires, et, en tant que telle, a été basée sur une vaste revue de littérature entre génie industriel et informatique. Cette étude a mené à la création d'un cadre non-fonctionnel à la fois appliqué au contexte des RSEs, mais pouvant aussi être utilisé dans n'importe quel contexte de sélection de partenaires. De plus, tous les critères non-fonctionnels du cadre non-fonctionnel dé ni sont associés à des métriques qui leur sont adaptées.

Puis, la seconde étape a été centrée sur le développement d'un sysème à base de connaissances pour permettre une future déduction de processus métier collaboratif. Pour cela, deux ontologies ont été structurées, implémentées et peuplées. La Collaborative Ontology (CO) se concentre sur la décomposition d'objectifs de collaboration en sous-objectifs ou en capacités. La Business Field Ontology (BFO), quant à elle, propose une hiérarchie de domaines métiers. Ainsi, les organisations décrivent leurs capacités grâce à des modèles de pro l, en les a ectant à l'intersection des deux ontologies. De la même manière, elles peuvent aussi dé nir de nouvelles opportunités.

Les capacités et les opportunités sont aussi dé nies selon les critères non-fonctionnels dé nis en Chapitre 2. Les principales contributions de cette partie résident dans l'adaptation d'un méta-modèle de collaboration au contexte spéci que d'un RSE dont le but est d'automatiser le le design-time des collaborations. Elles s'appuient, en outre, sur les mécanismes utilisés par les organisations pour décrire leurs pro ls et leurs besoins, en utilisant des ontologies de collaboration. La force de ces ontologies repose sur le fait qu'elles sont déjà peuplées avec de nombreuses instances.

Déduire un "bon" (i.e. selon des criètres non-fonctionnels) processus collaboratif n'est pas forcément la même chose que trouver tous les meilleurs partenaires un-à-un pour chaque capacité requise dans la réalisation d'un objectif de collaboration (à cause de l'évaluation du temps de réalisation d'un processus par exemple). Ainsi, les outils habituellement utilisés pour exploiter les ontologies ne su sent plus. Un algorithme par colonies de fourmis à donc été adapté à la structure de l'ontologie CO et implémenté: il permet de répondre simultanément aux trois questions Quoi?/Qui?/Quand?. Il en résulte deux contributions: une scienti que qui s'appuie sur l'adaptation d'un algorithme par colonies de fourmis à la structure très particulière de l'ontologie CO (pouvant être dé nie comme un graph orienté acyclique), alors qu'une deuxième, applicative, consiste en l'obtention d'un nouveau moyen e cace pour exploiter des ontologies en réponse à des problèmes à forte combinatoire.

Discussions et perspectives des travaux actuels

Les travaux de recherche conduits durant cette thèse ont montré plusieurs limites, ce qui a amené à penser à des perspectives à plus ou moins longs termes. La plupart de ces perspectives peuvent être conduites dans le cadre du projet interne MISE, dont les di érents éléments actuels, une fois intégrés, peuvent amener de nouvelles solutions innovantes ou encore d'intéressantes confrontations dans les démarches mises en oeuvre. Cela concerne en particulier la description des capacités et des opportunités (i.e. lors de la création de liens avec les instances déjà existantes dans les ontologies de collaboration) qui peut être perçue comme une étape laborieuse. D'autre part, la di culté à trouver des bases de connaissances librement accessibles pour décrire les collaborations inter-organisationnelles a aussi été mise en avant. La limite intrinsèque aux bases de connaissances choisies (i.e. MIT Process Handbook [START_REF] Thomas W Malone | Organizing business knowledge: the MIT process handbook[END_REF] et Classi cation ISIC [START_REF]United Nations and Statistical Division. International Standard industrial classi cation of all economic activities (ISIC)[END_REF]) pour peupler les ontologies de collaboration a aussi été identi ée: le fait que le système puisse travailler avec n'importe quelle CO directement fournie par les utilisateurs selon leurs besoins serait une amélioration signi cative à amener au système.

Perspectives à court terme

Ces limites rencontrées pourraient être toutes deux atténuées par l'intégration des travaux de thèse de Tiexin Wang [START_REF] Wang | Semantic approach to automatically de ned model transformation[END_REF] sur la réconciliation sémantique de modèles et de méta-modèles, dans le cadre de MISE 3.0. Cette intégration constitue une des principales perspectives à court terme qui seront données à ces travaux de recherche.

Comparaison à d'autres travaux

Peu de travaux de recherche sont orientés vers l'automatisation du design-time des collaborations inter-organisationnelles. Ainsi, il a été di cile de comparer les résultats o erts par l'algorithme d'optimisation par colonies de fourmis dans ce type de contexte. C'est pourquoi il est intéressant d'évoquer les travaux de thèse réalisés par Loïc Bidoux [START_REF] Bidoux | A model driven system to support optimal collaborative processes design in crisis management[END_REF] dans le cadre de MISE 3.0. portant aussi sur l'automatisation du design-time des collaborations inter-organisationnelles. La thèse de Loïc Bidoux s'intéresse, elle, à l'établissement de processus collaboratifs dans le cadre de la gestion de crise. Dans un tel contexte, les priorités sont di érentes des collaborations interentreprises: les processus collaboratifs doivent être déduits rapidement mais cela requiert une légère adaptation nale, réalisée de façon humaine puisque le temps est une dimension cruciale. De plus, la thèse de Loïc Bidoux porte aussi sur la gestion des ressources associées à chaque partenaire: si les pompiers d'une région précise sont tous mobilisés pour éteindre un feu, par exemple, les pompiers de la région la plus proche doivent pouvoir être appelés en remplacement. Les travaux de Loïc Bidoux se sont, pour cela, orientés vers un algorithme de planni cation.

En tant que perspective des deux thèses, il est prévu de réaliser une étude comparative entre les deux algorithmes (en terme de qualité des solutions nales et de temps de calcul), dans des contextes similaires. L'objectif de cette étude serait de trouver quel algorithme des deux est le plus adapté selon les contextes et les besoins des utilisateurs, et, ainsi, obtenir un système d'aide à la décision qui premettrait de choisir l'un ou l'autre, ou encore utiliser les deux approches ensemble.

Perspectives à moyen et long termes

Le système actuellement implémenté dans le cadre de cette thèse pourrait aussi être complété avec di érents services, comme expliqué ci-dessous.

Emergence automatisée de pro ls d'organisations et d'opportunités de collaboration

Pour les utilisateurs, établir leurs pro ls et décrire leurs opportunités peut être vu comme une étape laborieuse car il doivent eux-mêmes trouver les instances correspondantes dans les ontologies de collaboration, ce qui n'est pas toujours une tâche aisée. Il serait donc intéressant de proposer un moyen d'automatiser l'émergergence de nouveaux pro ls et opportunités:

• L'émergence de nouveaux pro ls peut être vue comme une extraction pertinente de données provenant des entreprises. Par exemple, Van Der Aalst [START_REF] Van | Process mining: discovery, conformance and enhancement of business processes[END_REF] a introduit le concept de process mining. L'objectif de cette nouvelle thématique est, à partir de jeux de données et de règles adaptées d'apprentissage automatique, de déduire des processus internes d'organisations. Le process mining est une discipline montante et de plus en plus d'entreprises s'intéressent à de telles solutions pour comparer les processus e ectivement réalisés sur le terrain avec les processus théoriques. En conséquence, n'importe quelle organisation ayant développé un tel outil serait donc capable de générer automatiquement ses processus internes, et chacun de ces processus pourraient être exploités comme une capacité que l'entreprise pourrait fournir dans son pro l. De plus, les ux de ces capacités pourraient aussi être déduits directement des processus générés.

• L'émergence de nouvelles opportunités peut être vu comme l'extraction pertinente de données d'entreprises selon des contextes de collaboration spéci ques (i.e. contexte économique pour de nouvelles opportunités économiques ou contexte de crise dans le cas de la gestion de crise). Dans le cadre de sa thèse et du projet MISE 2.0, Anne-Marie Barthe-Delanoë [START_REF] Barthe-Delanoë | Event-driven agility of interoperability during the run-time of collaborative processes[END_REF] Vers un outil de gestion de la connaissance Plus généralement, cette thèse jongle essentiellement entre trois concepts: données, information et connaissances. Chacun de ces trois niveaux amène un nouvel état de transition, de l'observation basique (données), à l'information contextualisée puis la connaissance structurée. Par exemple, chacune des perspectives données précédemment peut s'inscrire dans ce schéma à trois niveaux: l'émergence de nouveaux pro ls collecte des données a n de les transformer en information sur les organisations (ie. les capacités des organisations, qui deviennent des connaissances une fois intégrées à l'ECO.); la réconciliation sémantique proposée dans les travaux de Tiexin Wang [START_REF] Wang | Semantic approach to automatically de ned model transformation[END_REF] peut prendre comme entrées deux bases de connaissances et les fusionner , ce qui représente une transformation de la connaissance vers la connaissance.

La gure 5.17 n'ambitionne pas d'être exhaustive mais plutôt de donner une point de vue sur comment données, information et connaissances pourraient être manipulées, et résume les transitions possibles dans les trois états. Cette gure est divisée en trois parties associées respectivement à la conception de modèles (des données à l'information); la sémantique (de l'information à la connaissance) et l'exploitation (de la connaissance à une connaissance nouvellement générée). Pour chacune de ces trois étapes, des outils pertinents sont proposés, qui peuvent permettre de franchir les di érentes transitions entre les états.

Modélisation Sémantique Exploitation

Information Connaissances Données

Modèles

Modèles alignés

Connaissances générées

Inférences, Raisonnement à base de cas… Graphes, ontologies, confiance… Big data, process mining,

Contextualisation

Représentation sémantique Il serait intéressant de centrer un nouveau programme de recherche autour de ces trois termes. En tant que coeur de ce système, une interface basique destinée à la manipulation de connaissances pourrait être developpée. Puis, ce coeur pourrait être étendu: (i) à la discipline du data mining et ses disciplines connexes, (ii) à l'alignement de bases de connaissances et (iii) à l'exploitation de connaissances pour plusieurs objectifs (entre autre, la déduction de processus collaboratifs). D'un point de vue technique, un tel système peut se présenter comme une interface coeur développée petit-à-petit selon trois ces trois axes avec un système de plug-ins environnants, permettant de réaliser des transitions spéci ques entre les di érents états.

Deduction of inter-organizational collaborative business processes within an enterprise social network

Abstract. Especially in the context of collaborative supply chains and virtual enterprises, the step of designing the collaborative work ows remains laborious because either it is still carried out humanly or the methods lack of exibility. Based on an enterprise social network, this thesis aims at facilitating this step by proposing a service for the deduction of collaborative processes. It raises three main issues: (i) nding the activities to execute that answer the objectives of the collaboration (What?), (ii) selecting the corresponding partners (Who?) and (iii) ordering the activities into a collaborative business process (When?). Moreover, it is expected that many companies could be able to provide the same activities, on the enterprise social network. In this competitive context, a global optimization should be set up in order to nd the quasi-optimal collaborative process that answer these three questions simultaneously. A three-dimensional solution is proposed here. First, a non-functional framework has been set up in order to determine the criteria that make a « good » partner in a speci c collaborative context. Then, collaborative ontologies have been implemented and enable the representation and the acquisition of collaborative knowledge, so that the IT system can understand (a) the users' needs when they model their objectives of collaboration and (b) the users' capabilities when they model their pro les on the enterprise social network. And nally, a tool for decision support has been implemented thanks to an ant colony optimization algorithm that exploits the collaborative ontologies in order to provide a quasi-optimal process that ts the context of the collaboration and answers its objective. The results are in line with the FUI French project OpenPaaS which aims at o ering an enterprise social network to facilitate their collaborations.

Keywords. Inter-organizational collaboration, Interoperability, Business process deduction, Ontology, Ant Colony Optimization, Information system.

Déduction de processus métier collaboratifs inter-organisationnels au sein d'un réseau social d'entreprises

Résumé. Particulièrement lors de collaborations dans le cadre de chaînes logistiques ou d'entreprises virtuelles, établir les work ows collaboratifs est une étape laborieuse car souvent réalisée soit de façon humaine, soit avec des méthodes manquant de exibilité. Sur la base d'un réseau social d'entreprises, cette thèse vise à faciliter cette étape en proposant un service de déduction de processus collaboratifs inter-organisationnels. Cela soulève trois problèmes: (i) trouver les activités qui doivent être exécutées pour remplir les objectifs de la collaboration (Quoi?), (ii) sélectionner les partenaires pouvant réaliser ces activités (Qui?) et (iii) ordonner ces activités en un processus métier collaboratif (Quand?). Dans le cadre d'un réseau social, il est attendu que plusieurs organisations soient capables de fournir les mêmes activités. Dans un tel contexte de concurrence entre les organisations, une optimisation globale permet de trouver un processus nal quasi-optimal, en prenant en compte ces trois questions de manière simultanée: trouver l'ensemble des "meilleurs" partenaires et leurs activités dans un contexte de collaboration spéci que. A cette n, des ontologies de collaboration ont été développées et permettent de représenter et collecter des connaissances sur les collaborations. Ainsi, quand les utilisateurs remplissent leurs pro ls sur le réseau social, le système peut comprendre (i) les attentes des utilisateurs lorsqu'ils fournissent leurs objectifs de collaboration et (ii) les capacités qu'ils peuvent fournir. Un outil d'aide à la décision, basé sur un algorithme d'optimisation par colonies de fourmis, permet ensuite d'exploiter les ontologies de collaboration a n de trouver un processus quasi-optimal répondant aux attentes et objectifs de la collaboration. Les résultats de cette thèse s'inscrivent au sein du projet FUI OpenPaaS dont le but est d'établir un nouveau réseau social d'entreprises visant à faciliter leurs collaborations intra et interorganisationnelles.

Mots-clés. Collaboration inter-organisationnelle, Interopérabilité, Déduction de processus collaboratifs, Ontologie, Optimisation par colonies de fourmis, Système d'information.

Figure 1 . 1 -

 11 Figure 1.1 -Degree of sharing within collaborative networks, based on [12].

Figure 1 . 2 -

 12 Figure 1.2 -Topologies of collaborative networks.

Figure 1 .Figure 1 . 3 -

 113 Figure 1.3 summarizes the consequent three-dimensional framework proposed here.

"Figure 1 . 4 -

 14 Figure 1.4 -Integrated supply chain overview.

Figure 1 . 6 -

 16 Figure 1.6 -BPM lifecycle, inspired from [3, 52, 56, 57].

Figure 1 . 7 -

 17 Figure 1.7 -Overall structure of the MDA, [12].

Figure 1 . 10 -

 110 Figure 1.10 -OpenPaaS business level overview.

Figure 1 . 12 -

 112 Figure 1.12 -OpenPaaS design-time.

>Question 3 :

 3 Which are the non-functional criteria typically used to select partners (whatever the domain eld of the collaboration)? And how to use them in OpenPaaS context?

Figure 1 . 13 -

 113 Figure 1.13 -Key problematics of the thesis.

Figure 2 . 1 -

 21 Figure 2.1 -Mindmap of the di erent topics of interest around NFRs.

Figure 2 . 2 -

 22 Figure 2.2 -Publications about non-functional criteria,properties,requirements and factors on ScienceDirect (focusing on industry related topics).

Figure 2 . 3 -

 23 Figure 2.3 -Glinz's taxonomy for non-functional requirements [88]. ©2007IEEE

Figure 2 .Figure 2 . 4 -

 224 Figure 2.4 -How to assess the criteria on an ESN.

Figure 2 . 5 -

 25 Figure 2.5 -Inheritance of the four levels of application.

Figure 2 . 6 -

 26 Figure 2.6 -Precise illustration of the value concept, [127].

Figure 2 .

 2 Figure 2.7 provides an overview of the three dimensions that have been chosen to organize our framework.

Figure 2 . 7 -

 27 Figure 2.7 -Details of the three dimensions of the non-functional framework, applied to OpenPaaS needs.

Figure 3 . 1 -

 31 Figure 3.1 -De nition of knowledge, [144].

Figure 3 . 2 -

 32 Figure 3.2 -From data to knowledge through information.

  One of the most famous illustration of Semantic Web is probably the Semantic Web layer cake, presented by Tim Berneers-Lee [146], and represented in Figure3.3.

Figure 3 . 3 -

 33 Figure 3.3 -The Semantic Web layer cake, [146].

Figure 3 . 4 -

 34 Figure 3.4 -The Semantic Web stack, [147].

Figure 3 . 6 -

 36 Figure 3.6 -Languagues for Semantic Web, [159]. ©2002IEEE

  <owl:ObjectProperty rdf:about="&Music;hasComposed"> <rdfs:domain rdf:resource="&Music;Composer"/> <rdfs:range rdf:resource="&Music;Song"/> </owl:ObjectProperty> <!--Defining classes --> <owl:Class rdf:about="&Music;Human"/> <owl:Class rdf:about="&Music;Composer"> <rdfs:subClassOf rdf:resource="&Music;Human"/> </owl:Class> <owl:Class rdf:about="&Music;Song"/> <!--Defining instances--> <owl:NamedIndividual rdf:about="&Music;Bagatelle_No._25_in_A_minor"> <rdf:type rdf:resource="&Music;Song"/> <rdfs:comment rdf:datatype="&xsd;string">Bagatelle No. 25 in A minor</rdfs: comment> <owl:sameAs rdf:resource="&Music;furElise"/> </owl:NamedIndividual> <owl:NamedIndividual rdf:about="&Music;furElise"> <rdf:type rdf:resource="&Music;Song"/> <rdfs:comment rdf:datatype="&xsd;string">Fur Elise</rdfs:comment> </owl:NamedIndividual> <owl:NamedIndividual rdf:about="&Music;ludwigVanBeethoven"> <rdf:type rdf:resource="&Music;Composer"/> </owl:NamedIndividual> </rdf:RDF> Code 3.2 -Example of a OWL ontology.

Code 3 . 3 -

 33 rdfs:comment"/> <IRI>#Bagatelle_No._25_in_A_minor</IRI> <Literal datatypeIRI="&xsd;string">Bagatelle No. 25 in A minor</Literal> </AnnotationAssertion> <AnnotationAssertion> <AnnotationProperty abbreviatedIRI="rdfs:comment"/> <IRI>#furElise</IRI> <Literal datatypeIRI="&xsd;string">Fur Elise</Example of a OWL 2 ontology, with OWL/XML syntax.3.3 De nition of the ontology-based system 3.3.1 Structure of the problem, towards a collaborative metamodel

Figure 3 . 7 -

 37 Figure 3.7 -OMG's modeling infrastructure, [177]. ©2003IEEE

  .

  8.

Figure 3 . 9 -Figure 3 . 10 -

 39310 Figure3.9 -MISE core metamodel and its layered structure,[START_REF] Macé-Ramète | A road crisis management metamodel for an information decision support system[END_REF]. ©2012IEEE

Figure 3 . 11 -

 311 Figure 3.11 -Extraction of the classes of interest within the PhD thesis context.

Figure 3 . 12 -

 312 Figure 3.12 -Persistent knowledge to provide.

Figure 3 Figure 3 . 13 -

 3313 Figure 3.13.

Figure 3 . 14 -

 314 Figure 3.14 -Simpli ed representation of the BFO.

Figure 3 . 15 -Figure 3 . 16 -

 315316 Figure 3.15 -Social knowledge to acquire.

Figure 3 . 17 -

 317 Figure 3.17 -Updated metamodel according to the social knowledge to acquire.

Figure 3 . 18 -

 318 Figure 3.18 -Description of an Opportunity.

Figure 3 . 19 -

 319 Figure 3.19 -Description of a PartnerCapability.

Figure 3 . 20 -

 320 Figure 3.20 -PartnerCapability and Opportunity concept detailed.

Figure 3 . 21 -

 321 Figure 3.21 -Extended Collaborative Ontology structure.

  .22): the Process is made of Activities that invoked the Partner's PartnerCapabilities. The set of the Partners of this Process are gathered as a CollaborativeNetwork -which could be broken down into SubCollaborativeNetworks depending on the topology of the collaboration (see Chapter 1) -. Besides, this Process is intended to be orchestrated by the Mediator during the run-time. As such, the Mediator is considered as a speci c Partner (i.e. it is a central Partner that invokes Partners and their Activities all along the Process, see Chapter 4 and Appendix B).

Figure 3 . 22 -

 322 Figure 3.22 -Knowledge to be deduced.

Figure 3 .

 3 Figure 3.23 -SCOR decomposition overview, [181].

Figure 3 . 24 -

 324 Figure3.24 -Sample of APQC's PCF,[START_REF] Apqc | Process classi cation framework version 6[END_REF].

Figure 3 . 25 -

 325 Figure 3.25 -SUMO structure, [186].

Figure 3 .

 3 Figure 3.26 -MIT Process Handbook schema, [191].

  ............... ......... ......... ......... ......... .................. .................. .................. Combined office administrative service activities Wholesale of food… Freight transport by road Intersection .................. ..................

Figure 3 . 27 -

 327 Figure 3.27 -Example of PartnerCapability: Brake France's "Place order" capability.

  Eagerness to meet the needs: not assessed yet. Reputation: not assessed yet. Payment methods: bank transfer.

Figure 3 . 28 -

 328 Figure 3.28 -Example of pro le: Brake France's pro le.

Figure 3 . 29 -

 329 Figure 3.29 -Example of opportunity: bid for chocolate products and road delivery.

Figure 3 . 30 -

 330 Figure 3.30 -New interactions of the users with the system, [201].

Figure 4 . 2 -

 42 Figure 4.2 -Transformation from CO to a logical graph.

7 : 8 : 9 :

 789 chi l d r en ← children nodes of cur r entOb j chi l d ← chosen node in children, according to Equation4.5 if Type of chi l d = 'Capability' then 10: Add l i stC apa ← chi l d and its complementary capabilities 11: else if Type of chi l d = 'Objective' then 12:

5

 5

17 :Add pC apa to l i st pC apa 18

 1718 end procedure The choice of the children node depends usually on two parameters η ar c the attractiveness of each arc going to each children, and τ ar c its amount of pheromone. The variable ar cs represents the whole set of children arcs available, and ar c one of them. ar c = ar g max u∈ar cs [

Figure 4 . 3 -

 43 Figure 4.3 -Initial state of the construction algorithm illustrative case.

125 Chapter 4 .

 1254 Second step : left-to-right construction step This step aims at trying to involve the remaining PartnerCapabilities of pC apaSet that have not been used in the previously generated pr ocess, and it is detailed in Algorithm 4.The logic of this left-to-right construction step is the exact mirror to the right-to-left step. Indeed, instead of considering the input Flows of each Element of the pr ocess and trying to nd Knowledge Exploitation: Collaborative Business Processes Deduction Algorithm 3 Right-to-left OpenPaaS's ACO construction sub-algorithm.

Figure 4 . 4 -

 44 Figure 4.4 -Collaborative process state after the right-to-left step of the construction algorithm.

Figure 4 .

 4 Figure 4.5 shows the result of this right-to-left step of the Construction algorithm.Here, one can see that the BusinessFields of "PC4" task's output Flows are e ectively included in the input Flows of "PC5". Hence, "PC5" was linked as a successor of "PC4".

Figure 4 . 5 -

 45 Figure 4.5 -Collaborative process state after the right-to-left step of the construction algorithm.

Figure 4 . 6 -

 46 Figure 4.6 -Collaborative process state after start event and end events generation step of the construction algorithm.

Figure 4 . 7 -

 47 Figure 4.7 -Collaborative process state after parallel gateways generation step of the construction algorithm.

Figure 4 . 8 -

 48 Figure 4.8 -Weighted CO's logical graph.

  If par t ner C apLevel = 1 then cost ∈ [40; 80] and t i me ∈ [0; 20] • If par t ner C apLevel = 2 then cost ∈ [20; 40] and t i me ∈ [0; 20] • If par t ner C apLevel = 3 then cost ∈ [0; 20] and t i me ∈ [0; 20]

4 Figure 4 . 9 -

 449 Figure 4.9 -Results of the test scenarios on the four generated ECOs.

  Ce chapitre décrit donc l'exploitation d'une ontologie en la considérant comme un graphe de connaissances dont les noeuds représentent les individus de l'ECO résultant du Chapitre 3, et les arcs, les liens entre les di érents individus de l'ontologie (i.e. lien d'Objectif à ses SousObjectifs complémentaires, d'Objectif à ses Capacités à réaliser complémentaires et des Capacités aux Capacités d'organisations correspondantes). Le graphe obtenu est donc un graphe orienté, acyclique et chacun de ses noeuds peut être assimilé à un noeud ET ou un noeud OU (ex. relation ET entre un Objectif et ses SousObjectifs complémentaires, relation OU entre une Capacité et les Capacités d'organisations concurrentes correspondantes). Devant le problème combinatoire posé par l'exploitation de ce graphe, l'approche menée s'est portée sur l'utilisation de métaheuristiques, et plus particulièrement d'un algortihme d'optimisation par colonies de fourmis.

-Figure 5 . 1 -

 51 Figure 5.1 -Functional architecture.

Figure 5 . 3

 53 Figure 5.2 -Modelers overview.

Figure 5 .Figure 5 . 3 -

 553 Figure 5.3 -Pro le Modeler, modeling of a capability.

Figure 5 .

 5 Figure 5.4 presents the di erent tools implemented within the Pro le Modeler:

Figure 5 . 4 -

 54 Figure 5.4 -Objective Modeler, modeling of an objective.

Figure 5 . 6 -

 56 Figure 5.6 -Basic capability modeling.

Figure 5 . 7 -

 57 Figure 5.7 -Capability "Place order" description.

Figure 5 . 8 -

 58 Figure 5.8 -Linking the capability to the CO.

Figure 5 . 9 -

 59 Figure 5.9 -Linking the capability output to the BFO.

Figure 5 . 11 -

 511 Figure 5.11 -Basic objective modeling.

Figure 5 . 13 -

 513 Figure 5.13 -Linking the objective to the CO.

  Le manque d'une réconciliation sémantique D'une part, une des principales limites mises en avant dans cette thèse, dans les Chapitres 3 et 4 (i.e. représentation, acquisition et exploitation des connaissances) est le manque d'un service de réconciliation sémantique qui permettrait d'o rir une meilleure expérience aux utilisateurs.

Figure 5 . 17 -

 517 Figure 5.17 -Des données à la connaissances via l'information.

  They conducted a study on what are the main critical success factors depending on the objectives of the collaboration, and what are the key requirement indicators to choose a BPM standard. Their evaluation of the various BPM types based on these criteria shows that the graphical standards are the most understandable and available, and are good compromise for expressibility, enactibility and exibility. Executional languages are rather good According to Malekan and Afsarmanesh[START_REF] Soleimani | Overview of business process modeling languages supporting enterprise collaboration[END_REF] and Ko et al.[START_REF] Ko | Business process management (bpm) standards: a survey[END_REF], graphical languages usually include: Business Process Model and Notation (BPMN), Uni ed Modeling Laguage (UML),

	Event-driven Process Chains (EPC), Yet Another Work ow Language (YAWL), Business Process
	De nition Metamodel (BPDM), Integrated DEFinition (IDEF). And execution languages could
	be: Business Process Execution Language (BPEL), Business Process Modeling Language (BPML),
	Calculus [60], Web Service Choreography Interface (WSCI), Web Service Conversation Language
	(WSCL), Web Service Choreography Description Language (WS-CDL), Web Services FLow
	Language (WSFL), XML Process De nition Language (XPDL).

for enactibility, though they also provide good compromises on all other dimensions. According to them ontological languages could also be used as good compromise on understandability and excellent expressibility.

Table 2 .

 2 .1 depicts this set of components.

	Dimension	Key Components
		Product Availability
		Response time
		Asset Utilization
	Supply Chain Drivers	Return-on-investment Cost behavior Real-Time Communication
		Technology Transfers
		Risk of Quality Failure
		Risk of Information Failure
	Supply Chain Constraints	Capacity Service Compliance Extent of Demand
		Location
		Allocation
		Network Structuring
		Number of facilities and
	Supply Chain	equipment
	Decision Variables	Number of stages
		Service sequence
		Volume
		Inventory Level
		Size for Workforce
		Extent of Outsourcing

1 -Partners selection criteria,

[START_REF] Min | Supply chain modeling: past, present and future[END_REF]

Table 2 .

 2 . It is a veryReponse T i me = C l i ent Lat enc y + Net wor kLat enc y + Ser ver Lat enc y

	Category	Criteria		Metrics
	Business Value Quality	Price Penalty/Incentive	"Monetary value that a consumer pays for service to provider" Speci ed in contract. Based on service down-
			time, maximum or average reponse times, se-
			curity requirements...
		Business Performance	Can be speci ed by the time to complete the
			service or the throughput.T hr oug hput =
			Amount o f Out comes
		Service Reputation	T i meUni t Based on replies, comments or reviews from
			customers.
		Service Provider Reputa-	Based on brand value, nancial soundness,
		tion	quality of customer service, technical support
			and sustainability of the service provider.
	Service Level	Response Time
	Measurement
	Quality	Maximum Throughput	M axi mum	T hr oug hput	=
			max (

Number o f Request sP r ocessed Measur ed T i me ) Availability Av ai l abi l i t y = 1 -DownT i me Measur ed T i me Security Privacy Protection of privacy information implemented or not. Plus, privacy policy appropriate. 2 -Web service selection criteria and metrics, based on

  Saetta et al.[START_REF] Saetta | The innovative model of the virtual development o ce for collaborative networked enterprises: the gpt network case study[END_REF] provide a complete history of the emergence of GPT. Apart from being recognized for its wines, its tru es and its excellent extra-virgin olive oil [129], Umbria also owns a historical handicraft tradition in printing, for example in Foligno [130]. Saetta et al.[START_REF] Saetta | The innovative model of the virtual development o ce for collaborative networked enterprises: the gpt network case study[END_REF] explain that the competitive potential of the industries in this area is limited due to the lack of a way to aggregate them together (i.e. no leader company to orient them as a whole, in opposition with Airbus and the aerospace valley in the South-West of France for example). That is why in the beginning of the 2000's, three enterprises -namely Pasqui, Litop and Litograf-decided to initiate a collaborative network via the creation of the GPT company. Since then, 16 other

	Criteria Criteria	De nition De nition	App Who? App Who?	Metrics Metrics
	Technical char-acteristics Con dentiality -	Prod OP Each partners allow to sign a con dentiality Col	Syntactico-semantic description OP Accept or not
	Guaranteed life-time Reputation	Lifetime of the product, agreement guaranteed by the con-structor Reputation of the service Prod OP provider Org PP Number of time unit Average of evaluations
	Expected qual-Organizations Does the real quality matches the technical agreements Preferences and history of Prod PP collaboration Org S ity characteristics General assessment of the	Average of evaluations Feedback on former and ongoing partnerhips
	Real lifetime Contact	Does the product con-forms to the guaranteed relationship between the Prod PP partner and the organiza-Org PP Average lifetime Average of evaluations
		expected life? tion
	Eagerness of the organiza-Ability to under-E ciency of the company
	Eagerness to meet the needs ders stand special or-tion to understand and an-swer correctly to the part-ceptional orders to respond to special or ex-Org PP Org PP Average of evaluations Average of evaluations
	ner's needs Equipment used to exe-cute the activity Ability to o er shipping Serv OP ner arrangements Equipment Shipping arrangement to the part-Serv OP Syntactico-semantic description List of possibilities
	Knowledge and	Professionalism of the or-Accessibility to the avail-
	expertise assess-	ganization on the speci c able capacities. (i) Mon-Serv PP	Average of evaluations
	ment	service itoring: ask for the ad-
	Does the service conform Authorization vancement, anytime; (ii)	Serv OP	Accept or not
	Reliability	to the expected and guar-anteed accuracy and ca-Observability : subscribe Serv PP to advancement noti ca-	Average of evaluations
		pacity? tions
	Helps measuring the Execution location green house gas emis-sions Measures the quantity of Willingness and capacity Serv OP Serv OP Tons CO2 equivalent per year Geographic coordinates Large or small Location Carbon emis-sions small orders orders to respond to large or Serv OP Minimal and maximal sizes of order
	Air emissions polluant Labor equity COx, NOx, SOx, volatile organic compounds and	Serv OP Org OP Tons or kg per year
		particulate emitted.
		"Includes liquid waste dis-
	Liquid waste generated	posed of or released to open water or sewer sys-	Serv OP	Tons or kg per year
		tems"
	Solid waste gen-erated	Solid waste generated by service the process to provide the	Serv OP	Tons or kg per year
	Recycled waste	Percentage of waste recy-cled by the organization	Serv OP	r ec ycl ed w ast e Tot al w ast e
		Table 2.3 -Quality criteria of the framework

Table 2 .

 2

	4 -Service criteria of the framework
	companies joined them as new members. Saetta et al. [128] study the strategic behavior, and
	bring the de nition of a Virtual Development O ce (VDO): "A strategic association/alliance of
	organizations and the related supporting institutions, adhering to a base long term cooperation

agreement and adoption of common operating principles and infrastructures, with the main goal to create innovative Business Opportunities (BOs). This goal is accomplished by introducing a new for-pro t company, the VDO, operating as a permanent network management/coordination

Table 2 . 5

 25

-Cost criteria of the framework entity. In pursuing these business opportunities the VDO realizes VOs and Virtual Extended Enterprises (VEEs) of network members and/or external partners". This de nition is illustrated by the Figure

Table 2 .

 2

	Criteria		De nition	App Who?	Metrics
	On time deliv-ery	-	Org PP	On t i me d el i ver y Del i ver y
	Rapidly	re-
	sponding and solving the	-	Org PP	Average of evaluations
	problems
	JIT ability		Ability to o er JIT deliv-ery	Serv OP	Accept or not
	Delivery lead time	Deadline for making avail-able from the order receipt	Serv OP	Number and time unit
	Product avail-ability	Availability of the product in stocks	Prod OP	Number of products
	Quick on short notice delivery	Is the organization e -cient enough to deliver on short notice?	Serv OP	Minimal notice period and corre-sponding delivery time: number and time unit
			Ability to react quickly		Average of evaluations + average
	Agility		and e ectively to a sudden	Serv OP	of reaction times (number and time
			situation		unit)

6 -Time criteria of the framework

Hence, the selection of partners to answer speci c BOs is included in the second phase. According to [130], the creation of these atomic VEs, VOs and VEEs should be support by decision supporting tools. Thus, this is where the non-functional framework should come as a decision tool.

  Lors de la sélection de partenaires, de nombreux critères peuvent être pris en compte pour garder le meilleur candidat. Le plus souvent, c'est le triptyque délai/coût/qualité qui est évoqué. Or, ces trois dimensions ne sont pas assez précises et ne su sent généralement pas pour être e ectivement appliquées, en particulier lorsqu'il s'agit, comme dans cette thèse, d'automatiser la sélection des meilleurs partenaires.Un critère non-fonctionnel est un critère qui ne dé nit pas ce qu'un système peut réaliser, mais plutôt la façon dont cela est réalisé. Du génie industriel à l'informatique, nombreuses sont les disciplines qui se sont intéressées de près ou de loin aux critères non-fonctionnels, dans des contextes variés. Ainsi, a n d'o rir aux utilisateurs un large pannel de facteurs pour décrire leurs propres services métier et leurs opportunités de collaboration, une revue

	Now that non-functional criteria have been proposed, Chapter 3 aims at representing and
	acquiring knowledge on collaborative context, and as such will use the resulting non-functional
	framework for this Chapter to describe the non-functional collaborative context.

The non-functional framework detailed in this Chapter was presented during the I-ESA 2014 2.8 Résumé en français de littérature a été réalisée, en s'e orçant de répondre à trois contraintes: (i) le RSE doit être capable d'acquérir et exploiter automatiquement les critères non-fonctionnels retenus, (ii) pour faciliter l'exploitation, les critères doivent être les plus objectifs possible, associés à des échelles de sensibilités exploitables et (iii) doivent couvrir un large scope car le RSE peut être amené à supporter di érents types de collaborations.

Dans une première partie, quarante-deux critères non-fonctionnels ont été retenus et classés selon les quatre catégories proposées par Johansson et al.

[START_REF] Henry J Johansson | Business process reengineering: Breakpoint strategies for market dominance[END_REF]

: qualité, service, coût et temps. Puis, des métriques ont été associées à chacun de ses critères a n de les rendre exploitables et le moins subjectifs possible.

Finalement, un framework non-fonctionnel a été proposé a n d'appliquer cet ensemble de critères non-fonctionnels au contexte particulier des RSEs. Ce framework est composé de trois dimensions: (i) les quatre catégories citées précédemment, (ii) le niveau d'application des critères et (iii) les façons d'évaluer ces critères. Concrètement, les critères peuvent être appliqués selon quatre niveaux hiérarchiques: à la collaboration entière, à une organisation en particulier, à un service d'une organisation ou à un produit généré par une organisation. Ils peuvent aussi être évalués par un utilisateur sur son propre pro l, un partenaire d'une collaboration actuelle ou passée ou encore automatiquement par le système.

  mention several limitations of the rst version of OWL such as the lack of expressivity (lacks of constructs in OWL 1 DL that led to the creations of new surrounding patterns), datatype expressivity restrictions, syntax issues, etc. Actually, various syntaxes can be used when implementing an OWL 2 ontology (e.g. RDF/XML Syntax for a RDF serialization or Functional Syntax...). The OWL/XML syntax provides an XML serialization of OWL 2. Both Protégé and OWL API tools can be used in OWL 2 language. In this PhD thesis, it has been chosen to work with the OWL/XML serialization. OWL 2 is more verbose than OWL 1, but it has no real impact since ontologists actually rarely manipulate directly ontologies le[START_REF] Bernardo | Owl 2: The next step for owl[END_REF]. Code 3.3 corresponds to the same ontology as Code 3.2 in OWL 2 language, using OWL/XML syntax.

<Ontology xmlns="http://www.w3.org/2002/07/owl#" xml:base="http://www.music.fake/Music.owl" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:xml="http://www.w3.org/XML/1998/namespace" ontologyIRI="http://www.music.fake/Music.owl"> <Prefix name="rdf" IRI="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/> <Prefix name="rdfs" IRI="http://www.w3.org/2000/01/rdf-schema#"/> <Prefix name="xsd" IRI="http://www.w3.org/2001/XMLSchema#"/> <Prefix name="owl" IRI="http://www.w3.org/2002/07/owl#"/> <Declaration> <Class IRI="#Composer"/> </Declaration>

Table 3 .

 3 1 summarizes the transformations that have been done.

	MIT Process Handbook	CO
	Goal	Objective
	Process	Capability
	(Process) requires (Goal)	(Capability) contributesTo (Objective)
	(Goal) is-achieved-by (Process) (Objective) isAchievedBy (Capability)
	(Goal) has-part (Goal)	(Objective) hasSubObjective (Objective)

Table 3 .

 3

1 -Model transformation from MIT Process Handbook to CO.

Table 4 .

 4 Operators AL Atomic negation, concept intersection, universal restrictions, Limited existential quanti cation 1 -DL extensions and their operators.

	C	Complement
	H	Role hierarchy
	I	Inverse property
	O	Nominals
	N	Cardinality restiction
	Q	Quali ed cardinality restrictions
	R	Limited complex role inclusion axioms; re exivity and irre exivity; role disjointness.

Table 4 .

 4 2 -Result of the SPARQL query.

	:Aristotle :owns :Ferrari.
	:Ferrari rdf:type :Car.
	:owns rdfs:domain :Person.

  if pC apaOut put F l ow.type = i nput Domai n.type AND the Busi-nessField list of i nput Domai n contain all the BusinessFields of pC apaOut put F l ow AND el ement does not correspond to pC apa then newEl ement ← pr ocess.createElement(MISTask,i nt put Li st ,out put Li st )

	1: procedure C	S 1(ob j ec t i veDomai nLi st , pC apaSet )
	2:	Create new empty Process pr ocess
	3:	pr ocess.createElement(EndEvent, objectiveDomainList, null)
	4:	cond i t i on=true
	5:	while cond i t i on=true do
	6:	for all pC apa in pC apaSet do
	7:	cond i t i on= false
	8:	out put Li st ← the output ows list of pCapa
	9:	i nput Li st ← the intput ows list of pCapa
	10:	for all el ement in the elements of pr ocess do
	11:	for all i nput Domai n in the element's input list do
	12:	for all pC apaOut put F l ow in out put Li st do
	13:
	14:		cond i t i on=true
	15:
	16:		pr ocess.createSequenceFlow(newEl ement , el ement )
	17:		end if
	18:	end for
	19:

  Algorithm 4 Left-to-right OpenPaaS's ACO construction sub-algorithm. if pC apaI nput F l ow.type =out put Domai n.type AND the Busi-nessFields of pC apaI nput F l ow contain all the BusinessField list of out put Domai n AND el ement does not correspond to pC apaRemai n then newEl ement ← pr ocess.createElement(MISTask,i nput Li st ,out put Li st )

	1: procedure C	S 2(pr ocess, pC apaSet Remai ni ng )
	2:	cond i t i on=true
	3:	while cond i t i on=true do
	4:	for all pC apaRemai n in pC apaSet Remai ni ng do
	5:	cond i t i on= false
	6:	out put Li st ← the output ows list of pC apaRemai n
	7:	i nput Li st ← the input ows list of pC apaRemai n
	8:	for all el ement in the elements of pr ocess do
	9:	for all out put Domai n in the element's output list do
	10:	for all pC apaI nput F l ow in i nput Li st do
	11:
	12:		cond i t i on=true
	13:
	14:		pr ocess.createSequenceFlow( el ement , newEl ement )
	15:	end if
	16:	end for
	17:	end for
	18:	end for
	19:	end for
	20:	end whilereturn pr ocess
	21: end procedure

  a utilisé un Complex Event Processing (CEP) qui permet, sur la base de règles logiques, d'analyser des ux de données et a implémenté un service d'agilité s'appliquant à l'ensemble du schéma MISE (Figure??). Ainsi, en comparant un modèle attendu (generé par le design-time) avec un modèle terrain mis à jour (ce qui arrive e ectivement), ses travaux de recherche permettent de détecter les di érences et d'adapter dynamiquement la collaboration, (i) soit en appelant à nouveau le service d'automatisation du design-time, (ii) soit en changeant uniquement les tâches du processus métiers qui ne sont plus appropriées, (iii) soit en changeant les services techniques qui ne sont plus appropriés. Cela permet donc d'amener trois boucles de rétroactions dynamiques au système. Nous pouvons maintenant imaginer que le modèle terrain correspond au contexte économique actuel. Sur la base de règles logiques, un changement de ce contexte économique pourrait être détecté (par exemple, détection d'un nouveau marché privilégié à exploiter). Un lien pourrait ensuite être fait avec certains pro ls d'organisations stockés dans l'Extended Collaborative Ontology (ECO) (i.e. la CO étendue avec les capacités d'organisations), et, ainsi, une nouvelle opportunité pourrait être proposée à ces pro ls.La thèse d'Audrey Fertier, au sein de l'axe Intéropérabilité des Organisations, débutée en septembre 2015, vise d'ailleurs à mettre en place ces deux types d'émergences dans le cadre de la gestion de crise, ou comment connaître et exploiter en temps réel la situation terrain, à partir de l'analyse de données provenant de capteurs, de réseaux sociaux, ou autres sources pertinentes. Cette thèse évoluera donc entre data mining, big data, et règles métier d'exploitation.

OMG MDA web page: http://www.omg.org/mda/

OpenPaaS Overview: https://research.linagora.com/display/openpaas/Open+PaaS+Overview

Web site page: http://www.gptgroup.it/

URI (Uniform Resource Identi er) is a string of characters used to identify a name or a resource over a network.

Web site page: https://www.cs.umd.edu/projects/plus/SHOE

Web site page: http://protege.stanford.edu/

Standard Upper Ontology Knowledge Interchange Format, derived from KIF to support the de nition of the SUMO

Web site page: http://phios.com/

Web site page: http://process.mit.edu/

https:// les.i .uzh.ch/ddis/oldweb/ddis/research/completed-projects/semweb/ph-owl/index.html

https://resources.gs1us.org/rosettanet

http://ebxml.xml.org/

http://www.naics.com/

http://unstats.un.org/unsd/cr/registry/isic-4.asp

http://www.brake.fr/pub/fr/accueil/accueil.php

Site web page: http://owlapi.sourceforge.net/javadoc/org/semanticweb/owlapi/reasoner/structural/ StructuralReasoner.html

Remerciements

time or run-time to design-time. This PhD thesis assumptions to raise. After MISE 2.

Code 3.2 still presents a music ontology. One can see that beside classes, individuals and relations, a sameAs semantic relation has been added to express the fact that the song Für Elise is also known as Bagatelle No. 25 in A minor ( line 35): both individuals mention the same song of Beethoven. <rdf:RDF xmlns="http://www.music.fake/Music.owl#" xml:base="http://www.music.fake/Music.owl" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:Music="http://www.music.fake/Music.owl#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <owl:Ontology rdf:about="http://www.music.fake/Music.owl"/> <!--Defining properties --> Code 4.1 -Example of a RDF graph. A very simple example of a SPARQL query can be found in the Code 4.2.

Collaborative Ontology

Collaborative Ontology for the illustrative case

For this speci c illustrative case, a speci c CO has been developed based on the MIT Process Handbook [START_REF] Thomas W Malone | Organizing business knowledge: the MIT process handbook[END_REF]. This CO is limited to two levels: the top-level objective is "Buy wholesale", which can be decomposed into two complementary sub-objectives "Buy to producer" and "Transport". Figure 5.5 illustrates this adapted CO. For each objective of the ontology, the capabilities to execute to ful ll it are given.

In fact, the top-level consists in a turnkey solution, while the decomposition brings a bit more complexity by decomposing the solution into a "composite" one. Note that some capabilities should be used to ful ll several objectives (e.g. "place order"), which is rather intuitive in this case. However for readability reasons, they have been repeated for each corresponding objectives.

It is crucial to note the convenience of this decomposition of objectives into sub-objectives: it indeed allows to t several granularity levels, depending on the needs of the users. Hence, with this CO, the users can either choose "buy wholesale" for which the will almost have nothing to deal with; or they can choose "buy to producer", in which case they will have to arrange the transportation themselves.

Discussions and perspective of the present work

The research works conducted during this PhD have shown several limitations, which led to think of new high-level perspectives to give. There are often other related works within the MISE project that can provide a part of the answer, and it is thus interesting to confront MISE's other PhD current research works.

Short term perspectives

Lack of semantic reconciliation

On the one hand, one of the main limitations identi ed in the second and third phases of this PhD project (i.e. knowledge representation, acquisition and exploitation) is the lack of a semantic reconciliation service that would give a better experience to the users. It concerns the partner's capabilities and opportunities description (i.e. when linking them to already existing individuals in the collaborative ontologies), which could be seen as laborious steps.

On the other hand, the di culty to nd freely available knowledge bases to describe inter-

Discussions and perspective of the present work

organizational collaborations has been highlighted. The limitations of the chosen knowledge bases (i.e. MIT Process Handbook [START_REF] Thomas W Malone | Organizing business knowledge: the MIT process handbook[END_REF] and ISIC Classi cation [START_REF]United Nations and Statistical Division. International Standard industrial classi cation of all economic activities (ISIC)[END_REF]) to populate the collaborative ontologies have been also identi ed, and the ability of the system to work with any CO directly brought by the users would be a signi cant improvement.

Both can be ful lled by integrating the works on semantic reconciliation of model and metamodel levels of Tiexin Wang's PhD thesis [START_REF] Wang | Semantic approach to automatically de ned model transformation[END_REF] in the frame of the MISE 3.0 project. This integration constitute one of the main short-term perspectives that will be given to these PhD works.

Comparison to other works

There are not many research works oriented towards the automation of the design-time of inter-organizational collaborations. It has therefore been hard to compare the results of the ACO algorithm in this context. Hence, it is interesting to note that, within the MISE 3.0 project, Loïc Bidoux [START_REF] Bidoux | A model driven system to support optimal collaborative processes design in crisis management[END_REF] is currently working on the automation of the design-time of inter-organizational collaboration. The main di erences with these works are that Loïc Bidoux's PhD thesis is on the line of crisis management, and priorities are therefore di erent. Above all, the collaborative process should be deduced quickly even if it needs to be slightly adapted humanly, since time is the most critical dimension in such a context. Moreover, his thesis focuses as well on the resources availability. If the remen of a speci c area are already putting out a re, then the available remen of the closest other area should be called. Loïc Bidoux's works are oriented towards a planning algorithm.

As a perspective of both theses, it is planned to compare the response quality and computing time of the two algorithms in similar contexts. The goal is to nd which algorithm should be applied, depending on the context and user needs, and thus to obtain a high-level decision support system that would allows to relevantly choose on of the two optimization algorithm, or mix both approaches.

Mid-term and long-term perspectives

The current implemented system could be also extended with several complementary features, as explained in the two further Parts.

Automated emergence of organizations' pro les and opportunities

For the users, establishing their pro les and new opportunities could be seen as a laborious step, because they need to nd themselves each corresponding individual in the collaborative ontologies, which is not always convenient.

It is interesting to think of a way to automate the emergence of new organizations' pro les and Towards a knowledge management tool base, which is a transformation from knowledge to knowledge.

Figure 5.16 does not aim at being exhaustive but rather gives a point of view on how data, information and knowledge can be manipulated, and the transition between the di erent states could be achieved. This Figure is broken down into the three levels, associated respectively to model designing (from data to information), semantic (from information to knowledge) and exploitation (from knowledge to new generated knowledge). For each of these three steps, some relevant tools are given, that could allow the transition between the di erent states. A core of this system could be a basic interface to manipulate knowledge. This core could be extended on three research/development axes that are: (i) data mining and its related disciplines (from data to information and knowledge), (ii) knowledge bases alignment and (iii) knowledge exploitation towards various purposes (among others, collaborative process deduction). Technically, this core could be gradually enriched on these three axes, with surrounding plug-ins that would allow achieving speci c state transitions across the three data, information and knowledge dimensions.

Acronyms

A BPM classi cation