Mario Lezoche
email: mario.lezoche@cran.uhp-nancy.fr

Hervé Panetto
email: herve.panetto@cran.uhp-nancy.fr

Alexis Aubry
email: alexis.aubry@cran.uhp-nancy.fr

Conceptualisation approach for Cooperative Information Systems interoperability

Keywords: Conceptual modelling, cooperative information systems, semantic interoperability, data model conceptualisation Conceptual modelling, cooperative information systems, formal verification, data model conceptualisation Enterprise Models, Information Systems, Semantics Enactment

In order to increase enterprise performance, economics paradigms focus, now more than ever, on how to better manage information. The modern architecture of information systems is based on distributed networks with a grand challenge representing and sharing knowledge managed by those ISs. One of the main issues in making such heterogeneous Cooperative Information Systems (CIS) working together is to remove semantics interoperability barriers. This paper firstly analyses interoperability issues between CISs and then proposes patterns for data models conceptualisation for knowledge explicitation, based on expert knowledge injection rules and a fact-oriented approach. A case study is proposed related to a work order process in Sage X3, an Enterprise Resource Planning application.

To my beloved Bebaia and my faithful Chicca Acknowledgement This Post-Doctoral experience was firstly started under Interop VLab project and it was completed at the CRAN laboratory in the SYMPA team, SIO project, Université Henri Poincaré -Nancy 1 and at LORIA in the Score team. Therefore I would like to thank the CRAN laboratory director, Pr. Alain Richard, the SYMPA thematic manager, Pr. Thierry Divoux, the responsible of the SIO project, Pr. Benoit Iung, the LORIA director Françoise Simonot, the Score team manager Francois Charoy and Pr. Nacer Boudjlida, my guide in the Loria world, for welcoming me in such a warm way. I would like also to thank the Director of ESIAL School of engineering, Pr. André Schaff, who welcomed me during my pedagogic duties.

When I arrived in Nancy I found a weather that was quite different from that of my birth country. It was January and, I remember precisely, there were -18 Celsius degrees. I really hoped the people I would have met the next day would have been much warmer. My hopes were more than fulfilled. I am greatly attached to the concept of family and Life helped me letting meet people who became my new extended family.

Firstly, I would like to express my thankfulness to Professor Hervé Panetto who greeted me with an enormous smile. He guided me through the development of this research topic but also he let me acquire knowledge in different domains, better comprehension of research and pedagogic methodologies, involvement in laboratory and school life at all levels. It was really a diving experience in a new way to conceive this job, this passion. Our friendly relationship let me find the fire that warmed the cold distance to my family. I would like to thanks A/Professor Alexis Aubry, he is a special researcher and person. We had a lot of interesting and worthwhile discussions during this period and, from the moment we became roommates we deepened our knowledge and I find an all-accomplished person with whom I have many common interests. I like to thanks my colleague Esma Yahia for welcoming me in an enthusiastic way and for working hard together during all this time. Her feisty character spurred me to always deepen the topics we discussed on. We rapidly became friends and knowing and helping each other made me feel at home.

Next to the core people teams, with whom I worked, there are all the laboratory people that enriched in an extraordinary way my work and private Nancy life. Pierre, Gabriela, Pascale and Chiara created a little family, my little Nancy family, who shared sadness and happiness, failures and victories… Life.

I would like to thanks all the other kind people of the laboratory and of the school who were always nice and wishful to help, David, William, Thomas, Alexandre, Fabien, Yongxin, Leila, Sylvain, Jéremy, Alex, Ludovic, Romain and all the other really kind people with whom I passed my time in and out the laboratory.

What I am living is a dream, one of my oldest dream, living an experience in a country I always wanted to know and performing a job I was eager to transform in my life.

The same life that changed three years ago when I met the person who transformed the way I felt my life. I would like, so, to thank my beloved Costanza who gave me the strength, the energy and a new perspective to look at the events, a new hope in our private spiritual road and who made me remember what the meaning of Life is.

Introduction

The present Post-Doctoral work was firstly financed with a grant offered by the University Henri Poincaré, Nancy I, and it was completed at the Research Centre for Automatic Control (Centre de Recherche en Automatique de Nancy -CRAN) in the Ambient Manufacturing System (SYMPA) team, Inter Operating System (SIO) project, and at the Lorraine Research Laboratory in Computer Science and its Applications (Laboratoire Lorrain de Recherche en Informatique et ses Applications -LORIA) in the Score team.

During this period, passed working as a researcher in these laboratories, I had the possibility to act as a teacher at the School of Engineering in Information Technology ("École Supérieure d'Informatique et Applications de Lorraine" -ESIAL). This experience helped me to better comprehend the different views of the research and teaching life.

Research domain context

In a present expanded market, enterprises are forced to become increasingly fast adapting and flexible in order to manage the rapid changing business conditions. Today's challenges mainly concern Enterprise Interoperability (EI) that focuses on removing organisational barriers and improving different type of interaction between people, systems and companies. EI passes, mainly, through their Enterprise Information Systems (EISs). They involve large number of ISs distributed over large, complex networked architecture. Such cooperative enterprise information systems (CEIS) have access to a large amount of information and have to interoperate to achieve their purpose. CEIS architects and developers have to face a hard problem: interoperability.

Interoperability can be defined as the ability of two or more systems to share, to understand and to consume information (IEEE, 1990). The work (Chen et al., 2006) in the INTEROP NoE project has identified three different levels of barriers for interoperability: technical, conceptual and organisational. Organisational barriers are still an important issue but they are out of scope of this paper. The technological barriers are strongly studied by researchers in computer science and they are, in general, addressed by the models transformation (Frankel, 2003).

Enterprise Modelling (EM) plays a critical role in this interoperability action, enabling the capture of all the information and knowledge relevant for the enterprise operations and organisation [START_REF] Vernadat | Enterprise Modelling and Integration: principles and applications[END_REF]Panetto and Molina, 2004). The produced Enterprise Models must contain the necessary and sufficient semantics in order to be intelligible and then enabling the global Enterprise Interoperability. While studying an Information System (IS) model, we observe that its semantics is scrambled, due to the implementation requirements, and, more important, it is tacit.

Our research focuses on the conceptual level of interoperability, namely the ability to understand the exchanged information. Information may be defined as data linked to knowledge about this data. It is represented by so-called concepts. A concept is a cognitive unit of meaning (Vyvyan, 2006), an abstract idea, a mental symbol. It is created in the activity of conceptualisation, that is, a general and abstract mental representation of an object. During the history of human effort to model knowledge, different conceptualisation approaches regarding different application domains were developed (Aspray, 1985). This research memory will show the results obtained during the Post Doc study referring to the published works. It deals with a first phase from our general research work that focuses on the study of the semantic loss that appears in the exchange of information about business concepts. In order to quantify the semantic gap between interoperating ISs, their semantics needs to be enacted and structured by enriching, normalising and analysing their conceptual models. We propose a conceptualisation approach for explicitation of the finest-grained semantics, embedded into conceptual models in order to facilitate the semantic matching between two different information systems that have to interoperate. The structure of the document represents the different steps and the research domain on which the study focused.

In section 2, we present the general context of our work, namely cooperative enterprise information systems. The following section, the 3 rd section proposes a knowledge explicitation process that transforms implemented relational model to a fact-oriented conceptual one. This process allows us to discover the finest-grained semantics that must be enacted to study semantics interoperability between collaborating ISs. Then, we will define First Order Logic formalisations of UML artefacts (classes, attributes, associations).

In the 4 th section, the semantics structuring method is described. It assumes the definition of semantic aggregates that highlight the structure of the embedded semantics in the conceptual model obtained after the conceptualisation process. Each semantic aggregate (namely, each semantic block) is associated with a concept and defines the minimal mandatory semantics attached to this concept.

In order to illustrate the proposed approach, a case study is also presented in the section 5.

This case study deals with B2M (Business to Manufacturing) interoperability requirements between an Enterprise Resource Planning (ERP) system and a Manufacturing Execution System (MES) applications and consists in applying our approach in order to extract the semantics embedded into those ISs. In Section 6 new study on Semantic annotation structure and use is presented in order to better explicitate the tacit knowledge hidden in the Enterprise Models. Moreover, enriching this semantics is still an open issue; we can for example quote those researches made by [START_REF] Boudjlida | Annotation of enterprise models for interoperability purposes[END_REF] in terms of process models annotations.

In section 7 we will discuss about further works concerning using the resulting semantic conceptual model and architecture for facilitating the assessment of the (non)-interoperation barriers between Enterprise Information Systems or some of their subsystems (identified, for instance, by the semantic blocks) as suggested in (Yahia, 2011). The resulting analysis, based on an interoperability measures map, can help information technology consulting companies for parameterising and integrating enterprise applications (ERP, MES…) taking into account interoperability constraints. The Appendix, containing all the published research works, completes this report.

Cooperative Information System

Information Systems are systems whose activities are devoted to capture, store and process data and to produce knowledge, used by any stakeholders within an enterprise or among different networked enterprises. It is commonly agreed that Cooperative Information Systems provide a backbone for the Integrated Information Infrastructure (Sheth, 1998).

Fully understanding and exploiting the advances in computing is the only way to encompass the complexity of developing and maintaining such systems.

Although the progress made in Information Technology (IT) considerably improved the efficiency of software development, its drawbacks and limitations are obvious and serious.

In fact, the models involved in a single application development are numerous and diverse, each coping only with particular and partial aspects of the overall task. Moreover, the components' technologies are diverse, platform-and machine-dependant. The abovementioned limitations and barriers hinder the development and the maintenance process, significantly. Though our knowledge has been enriched by such diversity, an ancillary consequence has been separate research conversations, hampering cross-pollination of ideas and findings and making it difficult for those working outside the area to understand what we have learned. [START_REF] Melville | Information Technology and Organizational Performance: an Integrative Model of IT Business Value[END_REF].

There is a growing demand for integrating such systems tightly with organizational work so that these information systems can be fully, directly and immediately exploited by the intra and inter-enterprise processes [START_REF] Izza | Integration of industrial information systems: from syntactic to semantic integration approaches[END_REF].

Here, the need of interoperation clearly appears. In fact, to achieve the purpose of the cooperation between the different Information Systems, information must be physically exchanged (technical interoperability), must be understood (conceptual interoperability) and must be used for the purpose for which it has been produced (conceptual and organisational interoperability). When trying to assess the understanding of an expression coming from a system to another system, several possible levels of interoperability can be identified (Euzenat, 2001):

 encoding: being able to segment the representation in characters;

 lexical: being able to segment the representation in words (or symbols);

 syntactic: being able to structure the representation in structured sentences (or formulas or assertions);

 semantic: being able to construct the propositional meaning of the representation;

 semiotic: being able to construct the pragmatic meaning of the representation (or its meaning in context). This tiered structure is arguable in general; it is not as strict as it seems. In a way, it reflects maturity levels of the interoperability between the information systems, because each level cannot be achieved if the previous levels have not been completed (Euzenat, 2001).

The encoding, lexical and syntactic levels are the most effective solutions for removing technical barriers for interoperability, but they are not sufficient to achieve a practical interoperability between computerised systems. Enabling a seamless data and model exchange at the semantic and semiotic levels is still a big challenge which needs conceptual representation of the intended exchanged information and the definition of its pragmatic meaning in the context of the source and destination applications.

Different cooperation types have been investigated in ISO 14528 (ISO, 1999). In fact, this standard considers that models could be related in three ways:

(1) integration, when there exists a standard or pivotal format to represent these models;

(2) unification, when there exists a common meta-level structure establishing semantic equivalence between these models; and

(3) federation, when each model exists per se, but mapping between concepts could be done at an ontology level to formalise the interoperability semantics.

Integration is generally considered to go beyond mere interoperability to involve some degree of functional dependence (Panetto, 2007). Classification of the interoperability problems (Tursi, et al. 2009) may help in understanding the degree of development needed to solve, at least partially, these problems. However, conceptualisation and semantics extraction is still an important issue because of the different, often contextual understanding of tacit knowledge embedded into those applications. This issue is typically driven by the misbalance of the needed ontological commitment and epistemological dimension in the conceptualisation process. In this sense, our task is not really to conceptualise the EIS models, but to make assumptions on the mental models of the information systems' designers, which they then expressed as Entity-Relationship models, and to introduce the ontological commitments by making those models fully or partially equivalent to the real world semantics. The main prerequisite for achievement of interoperability of information systems is to maximise the amount of semantics which can be used and to enact it by making it increasingly explicit (Obrst, 2003).

This section is derived from the following scientific publication: Lezoche M., Panetto H., Aubry A., (2011). Conceptualisation approach for cooperative information systems interoperability, ACM. 13th International Conference on Enterprise Information Systems, ICEIS 2011, Jun 2011, Beijing, China. pp. 101-110 3 Our approach for semantics enactment in conceptual models In order to cooperate, two (or more) Information Systems have to interoperate. As previously discussed, we focus our interest on the conceptual level of interoperability and on enabling different information systems to share and use knowledge models which they represent. In order to make this possible, we consider (Lezoche et al., 2011) two steps that need to be taken: first, we need to understand the conceptual relationships between those models in the context of their use; and second, we need to unhide the tacit knowledge buried inside them, by using conceptualisation.

Conceptualisation is a decision process (Guarino, 1998), a view, in which knowledge of the studied part of reality, typically available in an implicit and complex form, is reorganised and generalised in different aggregates. Conceptual models range in type from the more precise, such as the mental image of a familiar physical object, to the abstractness of mathematical models which cannot be visualized in mind. They can be developed in different levels of abstraction of a single domain [START_REF] Zdravković | An approach for formalising the supply chain operations[END_REF]. Conceptual models also range in terms of the scope of the subject matter that they are taken to represent.

The variety and scope of conceptual models is due to the variety of purposes that people had while using them. The same applies for conceptualisation approaches, which are numerous and have been developed in different knowledge domains (LaOnsgri, 2009). According to (Engelbart, 1962), developing conceptual models means specifying the essential objects or components of the system to be studied, the relationships of the objects that are recognised, the types of changes in the objects or their relationships which affect the functioning of the system and the types of impact these changes have on the system. Similarly, Genesereth and Nilson (Genesereth and Nilson, 1987) define conceptualisation as "the objects, concepts and other entities that are assumed to exist in some area of interest and their inter-relationships".

Both definitions assume extensional character of the conceptualisation process, in the sense that they imply that the elements of the mental image of the specific domain are simply enumerated or listed. Some researchers [START_REF] Guarino | Understanding, building and using ontologies[END_REF] argue that this contradicts to an intentional character of a human thinking, where the meaning of elements is constituted by their necessary and sufficient conditions. These arguments are partially taken into account in our work by interpreting the semantics of the cardinality of relationships and existential constraints (mandatory elements).

Our contribution is to have at our disposal an approach which enables us to fragment knowledge through the transformation of attributes into entities and relationships, and thus to discover finest-grained knowledge atoms. In the proposed approach, presented in the Figure 1, different inputs can be used, such as an application, a data model, or a logical view. On this approach, the initial process (Step 1) is application of the reverse engineering methods, such as in (Fonkam, 1992) and in (Chiang, 1994), for delivering a conceptual model starting from the considered inputs. Then, the resulted initial model is enriched and validated through an Expert Knowledge Injection process (Step 2). In fact, the model is examined with the help of a domain expert or an end-user, who are the most qualified persons to describe the context of the particular domain and to affirm the conceptual model. According to the enterprise best practices and the associated data, they would clean and better organise the knowledge represented in the derived model. However, the obtained initial conceptual model, in the form of a UML class diagram, still has some major limitations from a semantic perspective. Indeed, for example, all the attributes are buried inside classes. Hence, their semantics is not explicit.

In order to overcome these limitations, in the next step of our approach (Step 3), namely a Fact-Oriented Transformation (Halpin, 1991), a set of rules for transforming the enriched conceptual model to a fact-oriented model (FOM) is applied. The core of this approach (FOM) is based on the so-called Lexical ObjecTs (LOTs) and Non-Lexical ObjecTs (NOLOTs). These artefacts are defined in (Meersman, 2003) as follows: a lexical object (LOT), a term, is an object in a certain reality that can be written down. LOTs always consist of letters, numbers, symbols or other characters. They can be used as names for or references to other objects. A non-lexical object (NOLOT), a concept, is an object in a certain reality that cannot be written down. Non-lexical objects must be named by lexical objects or referred to by means of lexical objects. In the outcome of the step 3, all the classes and their attributes are transformed into NOLOTs and LOTs respectively. The resulting fact-oriented model, displaying the finest-grained semantic atoms, is then used as an input for the structuring process presented in section 4.

In the following sub-sections, we will discuss, in detail, the proposed 3 steps.

Step 1: Reverse Engineering

Our scenario assumes that we start from an enterprise application database. So, the first process is a reverse engineering. It is an approach to extract the domain semantics from the existing database structures.

Typically, the reverse engineering process concerns the application of transformation rules which transform logical to conceptual schema. In (Fonkam, 1992), the authors propose a general algorithm based on several old attempts to make explicit the logical structure buried into DB schemas, application programs and assumed intent of designers and developers.

(Chiang, 1994) presents a methodology for extracting an extended Entity-Relationship model from a relational database, by using a combination of data schema and data instance analysis. In our study, we will consider and reuse the reverse engineering experiences developed in the past. These methods are, by now, adopted by the industry which produced a number of software tools. We choose MEGA Suite (http://www.mega.com), a modelling management environment to transform relational models into conceptual ones. MEGA Suite implements a parameterised reverse engineering method coping with major existing approaches from direct database metadata analysis to a semi-automatic conceptual models building from existing database schemas.

Step 2: Expert Knowledge Injection

Although most of the reverse engineering approaches (Fonkam, 1992) (Chiang, 1994) produce the information structure, they deliver models without the explicitation of the tacit semantics. The ADM (Architecture-Driven Modernization) initiative [START_REF] Omg | Object Management Group. Architecture-Driven Modernization specification[END_REF] from OMG (Bézivin et al., 2005) is tackling this problem by implementing a common Knowledge Discovery Meta-model to facilitate discovery of the tacit knowledge embedded inside existing software. Sometimes, Entity-Relationship models, namely database schemas, do not capture the semantics of the application functionality and underlying data models; when information systems are highly generic, the application semantics is actually captured in the populated table rows. For example, in Business Process Management systems, the structure of the enterprise processes, namely activities, associated data structures (messages), compensation and error handling blocks, etc. are defined by a system user and are not expressed by the database schema. In these cases, the intervention of the domain expert in enriching the conceptual model may be useful. Some research is tackling this issue by providing the tools to automatically or semi-automatically discover the semantics buried into existing data patterns [START_REF] Astrova | Reverse Engineering of Relational Databases to Ontologies[END_REF]. In our scenario, we are considering that enterprise applications store all their business knowledge into a DBMS. We can then extract, from each of them, some knowledge in a form of a conceptual model, by using reverse engineering approaches. Then, a domain expert has to enrich that model with enterprise best practices (knowledge coming from users). This is the goal of the current step.

After the reverse engineering process has produced a conceptual model, it is enriched by injecting some enterprise knowledge, expressed by the domain experts' or users' practices of using the corresponding enterprise application. These stakeholders know the domain peculiarities and they are capable to express the specific constraints that must be embedded into the conceptual model. However, this phase must follow a structured process, in order to preserve the ontological commitment. This is particularly important when more experts are involved in the knowledge injection. In such cases, the approaches of setting up a collaborative conceptualisation processes [START_REF] Guo | Collaborative conceptualisation: towards a conceptual foundation of interoperable electronic product catalogue system design[END_REF]) may be useful.

The first stage of the Step 2 is the renaming process. Usually, the database tables and columns (and consequently, the modelled concepts) do not have standard names. Thus, the renaming process is essential for bringing coherence and semantics to the lexical terms that otherwise would be very difficult to comprehend.

The next stage is the redefinition of the attributes and of the associations' roles multiplicities, according to the enterprise system users' practices. This step is fundamental for defining the real constraints which are not always explicit in the implementation model. For example, considering a particular attribute a 1 , two possible redefinition cases are identified:

(1) a 1 is a non-mandatory attribute in the conceptual model but, as users are always requested to populate it with a specific value, the enriched model must formalise that this attribute a 1 has to be treated as mandatory;

(2) a 1 is defined as mandatory in the conceptual model but, in practice, the users never care about its value and generally fill it with some dummy one. In such case, the enriched model may formalise that this attribute is not mandatory.

The last stage concerns of making explicit some implicit associations. Those implicit associations relate some concepts but they are defined only by enterprise practices even if they are not expressed in the model itself. For example, let us consider, in a given enterprise, a good practice imposed for achieving information update traceability. When a user updates information concerning one product, the application must store, in dedicated fields, the date of the update and the name of the logged user. This feature is implemented directly into an application like the ERP Sage X3 but it is not reflected in the data model. Moreover, for the sake of simplifying the implementation, the developers did not set these attributes as mandatory. In order to consider this practice in the conceptual model, the constraint must then be conceptualised as one mandatory association between the existing concepts Product and Users and by constraining the existing attribute UpdateDate in the previous association.

At this time, the enriched conceptual model formalises the whole application semantics (both the explicit ones and the users' implicit ones).

Step 3: Fact-Oriented Transformation

The quality of a conceptual model is often influenced by the conceptual language used for its specification. There are different approaches in conceptual modelling and these differences are reflected in the conceptual languages used for the modelling action. Entity-Relationship approaches (E-R) have been widely used and extended. They led to the development of different languages for data modelling (Barker, 1990), (Czejdo et al, 1990), (Hohenstein, 1991). Object-Oriented Modelling (OOM) (Rumbaugh et al, 1991) approach addresses the complexity of a problem domain by considering the problem as a set of related, interacting Objects. Entity-attribute-value model (EAV) [START_REF] Chen | Exploring Performance Issues for a Clinical Database Organized Using an Entity-Attribute-Value Representation[END_REF] is a data modelling approach used to represent entities with a potentially vast number of attributes (properties, parameters).

However, the abstract semantics inherent to these approaches imposes the modeller to make subjective choices between entities, attributes and relationships artefacts for modelling a universe-of-discourse. Let us consider, for instance, the same concept modelled in two different ways (Figure 2). Intuitively, those concepts (represented as UML classes) represent out similar semantics (at least from a global point of view), but are modelled differently. For instance, the WEIGHT of a PRODUCT on the right side of the figure is represented by a single class due to, for example, an implementation constraint. When other classes are related to this class, a querying for specific values related to the weight is facilitated. In contrast, on the left side of the figure, the WEIGHT of a PRODUCT is modelled by two attributes (its value and its unit).

Figure 2 -Two choices of concept modelling

In order to cope with such heterogeneous modelling patterns, we focus our interest on approaches that enable their normalization to a fine-grained semantic model by fragmenting the represented knowledge into atoms. NIAM (Natural-language Information Analysis Method) (Nijssen et al, 1989) proposed to model the world in term of facts (either presenting terms (real things), or representing characteristics (attributes) of these real things), and relationships between facts. NIAM is attribute-free. We adapted this fact-oriented modelling approach idea to the UML [START_REF] Omg | Object Management Group. UML 2.0 Superstructure Specification[END_REF] class notation representation of the conceptual models. Thus, we developed in (Lezoche et al., 2011) a set of transformation modelling rules, to be applied to selected UML patterns (Table1). In the resulting fact-oriented model, the semantics is preserved by adding annotations. The added annotations concern particular artefacts semantics such as generalisation, association class, aggregation and composite aggregation.

A set of transformation modelling rules, to be applied to selected UML patterns is presented on Table1.

Let us refer to the definitions of LOT and NOLOT facts given in the beginning of section 3.

Transforming a particular conceptual model in a fact-oriented model must follow these rules:

(1) all classes are transformed into LOT facts. Using UML Class notation, a LOT fact is represented by a UML Class.

(2) all attributes are transformed into NOLOT facts. Using the UML Class notation, a NOLOT fact is represented as a UML Class.

(3) for each attribute a belonging to a UML Class C, an association is created between the corresponding LOT a and the corresponding NOLOT C, created by the two previous rules.

(4) the multiplicity associated to each attribute a is copied as the multiplicity of the role of the previous association (rule 3) attached to the NOLOT a. The opposite role of the same association must have a constraint multiplicity equal to one.

(5) all "simple" associations between classes are transformed into "simple" associations between NOLOTs. [START_REF] Bidgol | The Internet Encyclopedia[END_REF] all generalisation relationships between classes are transformed into "simple" associations with a constraint multiplicity equal to one on the role attached to generalised NOLOT and a non-constraint multiplicity equal to * on the opposite role.

In order to trace the fact that this association was derived from a generalisation, we annotate semantically the new corresponding association with a logical predicate.

Moreover, the inheritance features of the generalisation association are mapped as new associations between LOTs representing the attributes of the generalised NOLOT, and all the specialised NOLOTs (sub-classes). ( 7) composite aggregation and aggregation relationships are transformed into simple association (rule 3) that keep unchanged the existing roles' multiplicities but trace their specific semantics by an attached semantic annotation. [START_REF] Chen | DI.2: Enterprise Interoperability Framework and knowledge corpus, Interoperability Research for Networked Enterprises Applications and Software Network of Excellence[END_REF] association classes are transformed into a LOT fact with two associations linked to the corresponding initial LOT facts. The multiplicities of the roles of these two associations are determined by inverting the ones initially formalised on the roles of the previous association. [START_REF] Chiang Roger | Reverse engineering of relational databases: Extraction of an EER model from a relational database[END_REF] any other specific constraints (generally modelled using OCL logical rules) are kept during the transformation process. [START_REF] Czejdo | A graphical data manipulation language for an extended entity-relationship model[END_REF] we did not take into account the special cases of constraints in generalisations because they are not usually used in data conceptual modelling.

One of the conceptual modelling requirements is that a conceptual model must have formal foundations, which allow comparing that model with other conceptual models in a formal and exact way.

FOL representation

A concern facing both developers and users of models is the degree of confidence in the model correctness. It is very easy to make errors, including errors in parameter estimations, in model assumptions and in programming. Verification methods are designed to address this question and have become important parts of model building process [START_REF] Wing | Formal methods: state of the art and future directions[END_REF], [START_REF] Störrle | Semantics and Verification of Data Flow in UML 2.0 Activities[END_REF].

As shown in Table1, a Fact-Oriented Model (FOM) uses semantic annotations to preserve coherence between the input and output models of transformation rules. Since those annotations are not formal objects, we need to verify the real semantics of the FOM model in comparison with the UML one. (Berardi et al, 2005) and (Tursi et al, 2009) formalised UML class constructs semantics in First Order Logic (FOL) assertions. We propose to adapt and to extend these works to formalise the fact-oriented model patterns (presented in Table 1) in FOL assertions.

Translation of UML Artefacts and Semantic Annotations in FOL

UML artefacts

The conceptual models, produced after the first two steps of our approach, are representing concepts semantics using UML artefacts such as class, attribute, association, association class, aggregation, composite aggregation and generalisation. Let us now formalise each of these artefacts in FOL.

Class.

A class in UML designates a set of object with common features [START_REF] Omg | Object Management Group. UML 2.0 Superstructure Specification[END_REF].

Formally a class C corresponds to a FOL unary predicate C.

∀ . ( 1
)
Attribute. An attribute a of type T for a class C associates to each instance of C a set of instances of AttribType, its multiplicity [i..j] specifies that a associates to each instance of C at least i and at most j instances of AttribType. Formally, an attribute a of type AttribType for class C corresponds to a binary predicate.

∀ ∀ ∧ , → .
(2)

A multiplicity [i..j] is composed of two specifications: the minimal value (i) and the maximal value (j). Those minimal and maximal values are specified as "0" or "1" or "*" or any positive integer. However, generally, in conceptual models, we do not specify positive integers for multiplicity because those numbers are embedded as constraints into the data processing of the software. We are then restraining our formalisation to the three generic cases: "1" (uniqueness), "0" (absence) and "*" (unlimited). This restraining postulate allows us to model each of the four general multiplicity cases (0..1, 1, 1..*, *) using a logical disjunction operator between the three logical expressions (( 3), ( 4), ( 5)):

Uniqueness ("1"): for any instance x of class C, there is a unique value for the attribute a in the instance x.

∀ → ∃ , ∧ ∀ , → . ( 3
)
Absence ("0"): for any instance x of class C, there is not any value for the attribute a in the instance x.

∀ → ∀ , . (4)
Unlimited ("*"): for any instance x of class C, there is an unlimited number of values for the attribute a in the instance x.

∀ → ∃ , . (5)
Association. An association in UML is a relation between two or more instances of classes.

The multiplicity [m.

.n] attached to each role of an association specifies that each instance of the class C can participate at least m times and at most n times to the related association. The n-ary association construct may always be transformed into two or more binary associations.

Thus an association between two classes and is represented by a unary predicate and two binary predicates and , one for each role name, and can be formalised as the following set of FOL assertions:

∀ ∀ ∧ , → . (6) ∀ ∀ ∧ , → . (7) ∀ → ∃ , . (8)
∀ → ∃ , .

∀ ∀ ∀ ∧ , ∧ , → z . ( (9)
) ∀ ∀ ∀ ∧ , ∧ , → z . ( 10
) ∀ ∀ ∀ ∀ ∧ ⋀ , ∧ , → z . ( 11
) 12
Assertions ( 6) and ( 7) are typing the association. Assertions ( 8), ( 9), ( 10) and ( 11) are specifying that any association has at least one role at each of its ends and that each role is unique; Assertion [START_REF] Euzenat | Towards a principled approach to semantic interoperability[END_REF] imposes that each instance of an association is unique.

The multiplicity constraints attached to association roles are formalised with logical expressions having the same structure as the previous ones (( 3), ( 4), ( 5)) for the attributes.

Association Class. An association may have a related association class that describes properties of the association, such as attributes, operations, etc. It can be formalised in the same way of an association.

Aggregation.

A particular kind of binary associations is aggregation, which plays an important role in UML class conceptual models. An aggregation is a binary relation between the instances of two classes and , denoting a part-whole relation, i.e., a non-symmetric relation which specifies that each instance of a class (the containing class, ) contains a set of instances of another class (the contained class, ). The aggregation is represented by a unary predicate Aggregation(x) for which all the association assertions are valid. To complete its semantics, in order to formalise the fact that an instance cannot be its own aggregate, the following FOL assertion has to be added:

∀ ∀ ∀ ∧ , ∧ , ∧ ∧ → .
Moreover, in order to formalise the non-symmetry of the aggregation, the following FOL assertion has to be added:

∀ ∀ ∀ ∀ ∧ ∧ ∧ , ∧ , ∧ ∧ → , ∧ , .
Composite aggregation. Composite aggregation is a strong form of aggregation that requires a component instance to be included in at most one composite at a time. The composite aggregation is represented by a unary predicate Composition(x) for which all the aggregation assertions are valid. To complete its semantics, in order to formalise the fact that a component cannot participate to more than one composite aggregation, the following FOL assertion has to be added:

∀ ∀ ∀ ∧ , ∧ , ∧ ∧ → ∀ , → .
Moreover, in order to formalise the non-sharing property of the components, the following FOL assertion has to be added:

∀ ∀ ∀ ∀ ∀ ∧ ∧ , ∧ , ∧ , ∧ , ∧ ∧ ∧ → .
Generalisation. In UML, one can use a generalisation between a parent class and a child class to specify that each instance of the child class is also an instance of the parent class.

Hence, the instances of the child class inherit the properties and the relationships of the parent class, but typically they also possess additional properties that do not hold for the parent class. Disjointness and completeness constraints can also be enforced on a class hierarchy. In this paper (and in our conceptualisation approach), we do not take into account overlapping and incompleteness constraints over a class hierarchy because they generate hidden and poor semantics.

The semantics of a UML class generalizing a class can be formally captured by means of the following FOL assertion:

∀ → .
Disjointness among the child classes … is expressed by the additional FOL assertion:

∀ → Λ , 1, … , .
The completeness constraint, expressing that each instance of the parent class is an instance of at least one of its child classes … , is formally defined by the additional assertion:

∀ → ∨ .

Semantic Annotation in Fact-Oriented Model

In order to keep track of the initial model semantics, which may be lost sometimes after applying the FOM transformation rules on specific UML artefacts, we embed semantic annotations of some key modelling constructs (association class, generalisation, aggregation, composite aggregation) in resulting models. These annotations highlight, with the presented logic assertions, the specific semantics that can be lost. For the composite aggregation construct the semantic annotation brings also, in a textual form, the particular semantics of life cycle that relate to its instances.

A semantics structuring process

After conceptualising and enacting finest-grained semantics embedded into CISs models, resulting with a normalised FOM, the latter has to be structured into semantic aggregates (Yahia et al., 2011). Each of those identified aggregates represents a "semantic molecule", composed of atomic concepts, with its own minimal mandatory semantics.

To build such aggregates, we propose a recursive approach for analysing the detailed semantics of the IS conceptual models obtained by the conceptualisation approach presented in section 3. We are considering that these models embed the whole explicited semantics of the associated IS.

Our structuring approach starts by identifying core atomic concepts and it ends by computing the semantic aggregates (namely, the semantic blocks) according to algorithms based on graph theory.

Core and extended semantics

When considering an available fact-oriented conceptual model from one IS (outputs from section 3), we can distinguish the mandatory (constrained) and non-mandatory (nonconstrained) association roles, which represent mandatory and non-mandatory concepts expressing semantics.

The set of mandatory concepts represents all the necessary and sufficient elements which make the conceptual model semantically coherent and understandable. It comprises all the non-lexical and lexical concepts linked to constrained association roles with a multiplicity equal to 1 or 1..*. On the contrary, the non-mandatory concepts correspond to the nonmandatory roles (multiplicity equal to 0..1 or *) and are only enriching the semantics of those IS conceptual models.

To some extent, the set of mandatory concepts corresponds to the core semantics that is embedded into a given IS conceptual model. The extended semantics is defined by the set of mandatory and non-mandatory concepts.

Some mathematical definitions

We define, for each IS conceptual model, the following notations. We can note that:

∪ ∩ ∅ ∩ ∩ Definition 5.
For each non-lexical concept , we can define the set of its associated mandatory lexical concepts as follows:

∈ ∃ , ∈ , ∈ 1,1. . * Definition 6.
For each non-lexical concept , we can define the set of its associated mandatory non-lexical concepts as follows:

∈ ∃ , ∈ , ∈ 1,1. . *
If we consider a concept defined in the context of the IS core semantics, we notice that, in order to be semantically effective in the studied domain, this concept needs to be associated on the one hand to its mandatory lexical concepts and on the other hand to other non-lexical concepts. This defines the notion of Semantic Block (SB).

Semantic blocks identification 1. Definition

Considering a particular non-lexical concept from , a semantic block, denoted as and associated with the concept , represents the set of the concepts necessary for the minimal semantics definition of the non-lexical concept given by the conceptual model. Formally, B is defined as follows:

∪ ∈ 1
This definition, suggests that the notion of semantic block is recursive.

In the following, the meta-model of the semantic block is given and a procedure to compute all the semantic blocks of a conceptual model is proposed.

Semantic block meta-model

Here we propose to formalise the semantic block architecture through the meta-model represented on Figure 3. This meta-model is based on the composite pattern (Gamma et al, 1995). This meta-model defines an arborescence of components representing hierarchies of objects.

Figure 3 -Meta-model of the semantic block structure

A semantic block defines the minimal mandatory semantics of one or several non-lexical concepts such that these concepts are in the same strongly connected component 1 . Moreover, the semantics of one or several concepts can be aggregated into one or several semantic blocks. As the semantic block is a specialisation of the abstract class "Concept", its semantics can be aggregated into one or several semantic blocks of higher levels. The Block System represents the last level of aggregation and contains the minimal mandatory semantics of the studied IS conceptual model.

How to build the Semantic blocks?

Let us consider the conceptual model on Figure 4 and its transformation on Figure 5 obtained by applying the third step presented in section 3. Let us build the semantic block of the concept 2. The intrinsic mandatory semantics of the concept 2 is defined by the 1 A strongly connected component of a directed graph is a maximal set of vertices such that for every pair of vertices u and v, there is a directed path from u to v and a directed path from v to u. semantics of the mandatory lexical concepts that are associated to it, namely 1 2 and 2 2. Moreover, a given instance of the concept 2 exists only if it is associated to at least one instance of the concept 5 . That means that 5 is mandatory for expressing the semantics of 2. Moreover, considering the roles of 1 and 3 in their association with 2, we can see that the minimal multiplicity is equal to 0. That means that the existence of any instance of 2 is not stipulated by the existence of one instance of 1 or 3. Finally, we find again 2 2 ∪ 1 2, 2 2 ∪ 5 as in equation ( 1).

Recursively, we can demonstrate that the intrinsic mandatory semantics of the concept 5 is defined by the semantics 1 5 and that a given instance of the concept 5 exists only if it is associated to exactly one instance of the concept 8 and exactly one instance of the concept 2. That means that 5 5 ∪ 1 5 ∪ 2 ∪ 8 .

Applying the same reasoning, we can build 8 as follows:

8 8 ∪ 1 8 .
Finally we can deduce that: 2 2, 5, 8 ∪ 1 2, 2 2 ∪ 1 5 ∪ 1 8 . To simplify the computation of the semantic block of one concept , we propose, first, to identify the set of non-lexical concepts that are included in the semantic block and, second, to add the associated mandatory lexical concepts. That means that is determined as follows:

Figure 4 -An instance of conceptual model

C1 +A1C1[1] +A2C1[0..1] C2 +A1C2[1] +A2C2[1] +A3C2[0..1] C3 +A1C3[1] +A2C3[0..1] C4 +A1C4[1] +A2C4[0..1] 1..* * 1 * 1..* 0..1 C5 +A1C5[1] +A2C5[0..1] 1..* 0..1 1 * C8 +A1C8[1] +A2C8[0..1] 1 * C6 +A1C6[1] +A2C6[0..1] 1..* 1..* C7 +A1C7[1] +A2C7[0..1]
∪ with 5, 8 and2 1 2, 2 2, 1 5, 1 8 .

 ⋃ ∈ and,  ∈ For instance, 2 2,
C1 C2 1..* * C3 * * 1 * C4 1..* 0..1 C5 1 * 1..* 0..1 C6 * 0..1 1..* 1..* C7 1 1..* 1..* * 1 1 C8 0..1 * 0..1 0..1 1 0..1 1 * A1C1 1 1 A2C1 1 0..1 A1C2 1 1 A2C2 1 1 A3C2 0..1 1 A1C5 1 1 A2C5 0..1 1 A1C8 1 1 A2C8 0..1 1 A1C6 1 1 A2C6 0..1 1 A1C3 1 1 A2C3 0..1 1 A1C4 1 1 A2C4 0..1 1 A2C7 1 0..1 A1C7 1 1

Using graph theory for building

To facilitate the building of the semantic blocks, we propose, for each from C , to identify the associated set by using graph theory modelling and its associated mathematical tools.

Let us first define a semantic-dependency graph associated with a conceptual model. This semantic-dependency graph is a digraph , where is the set of nodes and is the set of edges defined by a pair of nodes. Each node from represents a non-lexical concept of the conceptual model. Each edge from is built from the conceptual model as follows:

the edge , exists if (i) there is an association between and in the conceptual model, and (ii) if the minimal multiplicity for the role of is equal to 1 ∈ .

That means that the existence of the edge , represents the fact that is mandatory for expressing the semantics of .

The Figure 6 shows the semantic-dependency graph associated with the conceptual model of the Figure 5. all the concepts c that must be instantiated to ensure the existence of a particular instance of c , i.e. all the concepts c such that there is an association between c and c in the conceptual model, and the minimal multiplicity for c , considering this association, is equal to 1. This is the exact definition of all the successors of c in the semantic-dependency graph.

Note that, by definition, there is a directed path from the concept c to these concepts c .

Iteratively, the only new concepts c that can be added to SB c are the successors of those first concepts c . As successors of the concepts c , there exists also a directed path from the concept c to the concepts c (the path from c to c plus the edge c , c ).

Finally the semantic block of c contains exactly all the concepts c such that there exists a The theorem 3 implies that there is one semantic block per strongly connected component of the semantic-dependency graph.

A procedure to compute the semantic blocks

Applying theorems 1 to 3, we propose the following procedure to compute all the semantic blocks of a given conceptual model:

i. Building the associated semantic-dependency graph.

ii. Building the graph of the strongly connected components based on the semanticdependency graph.

iii. Computing the semantic blocks associated with each strongly connected component.

iv. Computing, for each , the semantic block by adding all the mandatory lexical concepts associated to each non-lexical concept from .

v. Computing ∪ .

These steps are detailed as follows.

Building the associated semantic-dependency graph

By definition of this graph, it can be easily obtained by considering each association between two concepts c and c and then building an edge from c to c if the minimal multiplicity for the role of c is equal to 1.

Building the graph of the strongly connected components

Theorem 3 implies that for building the semantic blocks, we can consider only one concept in a given strongly connected component (the other concepts share the same semantic block).

That is the reason why we can simplify the semantic-dependency graph by considering only an equivalent graph where the nodes represent each strongly connected component of the former semantic-dependency graph, and where one of these nodes (e.g. SCC1) is connected to another node (e.g. SCC2) if there exists at least one edge from a concept from SCC1 to a concept from SCC2.

Identifying all the strongly connected components of a graph is a well-known problem in graph theory that can be solved with polynomial effort by using Kosaraju-Sharir's algorithm (Sharir, 1981).

The graph of the strongly connected components related to the semantic-dependency graph of Figure 6 is given on Figure 7. On this graph, the strongly connected components are defined as follows SCC1 C1 , SCC2 C2, C5 , SCC3 C3, C4, C6, C7 and SCC4 C8 .

Computing associated with each strongly connected component

We propose now one algorithm for computing all the semantic blocks SB associated with each strongly connected component (see Algorithm 1 that invokes Algorithm 2). The algorithm 1 BuildSemBlocks is applied on the graph of the strongly connected components (denoted as G ).

Let us apply the algorithm BuildSemBlocks G on the graph of Figure 7. We obtain the following semantic blocks:

 1 1 ∪ 2 ∪ 3 ∪ 4,  2 2 ∪ 4,  3 3 ∪ 4 and 1 2 3 4  4 4.
And finally replacing the strongly connected components by their content we obtain the following semantic blocks: , 2, 3, 4, 5, 6, 7, 8 ,  2, 5 2, 5, 8 ,  3, 4, 6, 7 3, 4, 6, 7, 8 and 8 8 .

 1 1

Algorithm

[Initialisation]

: List of the strongly connected components in

 C1 1 1, 1 2, 2 2, 1 3, 1 4, 1 5, 1 6, 1 7, 1C8 ,  C2, C5 1 2, 2 2, 1 5, 1C8 ,  C3, C4, C6, C7 1 3, 1 4, 1 6, 1 7, 1C8 and
 C8 1C8 .

Computing each semantic block

Each semantic block is the union of and . By applying this definition on the instance of Figure 5 we obtain:

 1 1,2,3,4,5,6,7,8 ∪ 1 1,1 2,2 2,1 3,1 4,1 5,1 6,1 7,1 8 , 4,6,7,8 ∪ 1 3,1 4,1 6,1 7, 1C8 and

 C2, C5 2, 5, 8 ∪ 1 2, 2 2, 1 5, 1C8 ,  C3, C4, C6, C7 3,
 C8 8 ∪ 1C8 .
For validating our approach, next section will detail an industrial case study involving two enterprise information systems that need to interoperate: Sage X3 ERP and Flexnet MES.

This section is derived from the following scientific publication: application and Flexnet as a Manufacturing Execution System (MES). Such interoperation process is based on a deep semantics analysis of their own models. In order to illustrate our approach, we will detail the conceptualisation process applied to a subset of the ERP information system model in section 5.1. Section 5.2 will detail the semantics structuration process (computing semantic blocks) applied to a subset of the MES information system model. For sake of readability, in the following, we will name each subset of models by the name of the related enterprise applications.

Conceptualisation of Sage X3 ERP model

An Enterprise Resource Planning (ERP) system is an integrated computer-based system which is used to manage internal and external resources including tangible assets, financial resources, materials, and human resources (Bidgol, 1997). Its purpose is to facilitate the flow of information between all business functions inside the boundaries of the organization, as well as to manage the connections to outside stakeholders. Built on a centralised database, ERP systems integrate all business operations into a uniform system environment. Sage X3 provides different enterprise management functions: finance, commercial, industrial and services.

The objectives of this case study are (i) to analyse how the manufacturing order process inside the Sage X3 application is modelled, (ii) to use the proposed modelling process for making the implicit knowledge explicit in the model structure.

The model depicted on Figure 8 is the output from the first two steps of our approach. This means that we have already completed the "Reverse Engineering" and the "Expert knowledge injection" steps. The "Manufacturing Order Heading" concept represents the management function of production orders and planned activities. This function allows the generation of a manufacturing order by variation of one or more classifications and a single production line. For each manufacturing order, the achievement of the material benefits and sequencing operations is possible. The function captures general information, such as planning and production facility and the status of the order. It allows entering general information about the production order. The availability of components is then checked through the information given by the bill of material related to the launched products. Once the above initial information is determined, the system updates the list of materials and operations of the created or modified orders.

Step 1: Reverse Engineering All this information is stored in the Sage X3 application database. The first step of our method is to reverse-engineer the database, in order to extract the initial conceptual model by using standard tools in MEGA Suite. In this particular case, the resulting model is composed only of a set of classes and attributes without any associations. This is due to the fact that all relationships between concepts are directly implemented into the application software instead of in the database. We can note also that the implementation names of the entities (coming from tables and columns) are quite raw and not expressive. The bottom of Figure 9 shows two classes extracted from the reverse-engineered conceptual model. The objective of the next step is then to clean and enrich this model. Let us consider the same example as in section 3.2. In the studied enterprise, a good practice is imposed for achieving information update traceability. When a user updates information concerning one product, the application must store, in dedicated fields, the date of the update and the name of the logged user. This feature is implemented directly into Sage X3 ERP but it is not reflected in the data model. Moreover, for the sake of simplifying the implementation, the developers did not set these attributes as mandatory. In order to consider this practice in the conceptual model, the expert can conceptualise this constraint as one mandatory association between the existing concepts Product and Users and by constraining the existing attribute UpdateDate in the association class related to the previous association (as on Figure 9).

Step 3: Fact-Oriented Transformation

Applying the pattern transformation rules, presented in the previous section, classes and attributes are transformed into NOLOTs and LOTs respectively to increase the granularity of the knowledge embedded into the model. These rules have been coded by using a Mega Suite internal version of VBA scripting language and then automatically executed inside MEGA Suite.

Figure 10 shows the resulting FOM after applying our approach to the Sage X3 work order process.

At the first glance, it seems that the resulting model is much more complex than the initial one. This may looks true from a visual point of view, but it is false in terms of expressiveness of the model's semantics. Indeed, the finest-grained atoms of semantics are now made explicit, which helps any automatic computing. An important result is that using the model with such high level of granularity will facilitate automatic execution for semantic gap evaluation. Figure 14 provides a model representing all the semantic blocks related to the Flexnet purchase order process and their inclusion relationships. Figure 15 provides the conceptual model associated to the semantic block PRODUCT , and including all the mandatory concepts required to obtain the full semantics for the concept PRODUCT.  It can be used to discover matching between models elements, which helps information systems integration (Agt, et al., 2010).

 It can semantically enhance XML-Schemas' information, which supports XML documents transformation (Köpke and Eder, 2010).

 It can describe web services in a semantic network, which is used for further discovery and composition (Talantikite, et al., 2009).

 It can support system modellers in reusing process models, detecting cross-process relations, facilitating change management and knowledge transfer (Bron, et al., 2007).

 It can link specific resources according to its domain ontologies.

The main contribution of our research work is identifying three main components of semantic annotation, gives a formal definition of semantic annotation and presenting a metamodel of the proposed semantic annotation structure model.

What is semantic annotation?

In Oxford Dictionary Online3 , the word "annotation" is defined as "a note by way of explanation or comment added to a text or diagram". It is used to enrich target object's information, which can be in the forms of text descriptions, underlines, highlights, images, links, etc. Annotation has special meanings and usages in different fields. In software programming, an annotation is represented as text comments embedded in the code to expand the program, which is being ignored when the program is running. In mechanical drawing, an annotation is a snippet of text or symbols with specific meanings. In Library Management, an annotation is written in a set form (numbers, letters, etc.), which helps the classification of books.

Further, different annotation types are identified by the following papers : Bechhofer, et al. (2002) and Boudjlida, et al. (2006) distinguished annotation as (i) Textual annotation: adding notes and comments to objects; (ii) Link annotation: linking objects to a readable content; (iii) Semantic annotation: that consists of semantic information which is machine-readable.

Similarly, three types of annotation are described in the research of Oren, et al. (2006): (i)

Informal annotation: notes that are not machine-readable; (ii) Formal annotation: notes that are formally defined and machine-readable (but it does not use ontology terms); (iii) Ontological annotation: notes that use only formally defined ontological terms that are commonly accepted and understood.

According to the above classification, semantic annotation can be considered as a kind of formal metadata, which is machine and human readable. This will be further discussed in the following sections.

Semantic annotation

The term "Semantic Annotation" is described as "the action and results of describing (part of) an electronic knowledge by means of metadata whose meaning is formally specified in an ontology" (electronic knowledge can be text contents, images, video, services, etc.) by Fernández (2010). Talantikite, et al. (2009) introduced it as "An annotation assigns to an entity, which is in the text, a link to its semantic description. A semantic annotation is referent to an ontology". In the research of Lin (2008), semantic annotation is concerned as "an approach to link ontologies to the original information sources". All above definitions from different papers show one thing in common: a semantic annotation is the process of linking electronic knowledge to a specific ontology. Ontology here is only one of the possible means to provide a formal semantic.

As it can be seen on Figure 16, the left side represents an Electronic Knowledge (EK) and on the right side, there are the three main components of semantic annotation: (1) Ontology, which defines the terms used to describe and represent a body of knowledge (Boyce, et al., 2007). It can be reused from existing ontologies or designed according to different requirements. (2) Semantic Annotation Structure Model (SASM), which organizes the structure/schema of an annotation and describes the mappings between electronic knowledges and an ontology. (3) Application, which is designed to achieve the user's purposes (composition, sharing and reuse, integration, etc.) by using SASM. This figure also shows the three main steps on how to use semantic annotation, which is introduced in section 4: ontology (section 4.1), semantic annotation structure model (section 4.2) and application (section 4.3).

Figure 16 -Semantic annotation components

The following definition formally defines a semantic annotation: a Semantic Annotation is a tuple , consisting of the SASM and an application .

∶ , ,

Where:

, , … , , is the set of ontology that bring some meaning to any annotated element.

An A mapping , may represent three different kinds of semantic relations:

(1) ∼ , is a binary equivalence relation. If ∼ , then an electronic knowledge is semantically equivalent to , an element of the powerset , in the context of an application .

(2) ⊃ , is a binary relation stating that the semantic of an electronic knowledge subsumes the semantic of an element of the powerset , in the context of an application .

(3) ⊂ , : is a binary relation stating that the semantic of an electronic knowledge is subsumed by the semantic of an element of the powerset , in the context of an application .

can be further extended, including also some additional parameters or constraints c k , generally expressed using, in the worst case, natural language, or, better, a formal logical expression. is then defined as ≔ , .

The main issue, related to mappings such as in (2) and in (3), is being able to measure the semantic gap (2) or the over semantic (3), brought by the semantic annotation. Such measures have been studied by researchers in the domain of information retrieval (Ellis, 1996) or in the domain of ontology matching (Maedche and Staab, 2002), mapping (Doan et al, 2002), merging [START_REF] Stumme | FCA-MERGE: Bottom-Up Merging of Ontologies[END_REF], alignment (Noy and Musen, 2000).

In addition, Peng, et al. (2004)

Metamodel of Semantic Annotation Structure Model

After the identification of the three main components of semantic annotation and given its formal definition, in this section we can briefly present the metamodel of the Semantic Annotation Structure Model (Figure 17).

Conclusions

In this section we identify three main components of semantic annotations that are Ontology, Semantic Annotation Structure Model and Application. In addition, a formal definition of semantic annotation is proposed. It contributes to better understand what a semantic annotation is and then contributes to a common reference model. We presented a Metamodel explaining the formal links between the identified semantic annotation components.

But how to use semantic annotation? There are still many problems can be further discussed during the annotation process. For example, how to optimize ontology and an annotated model? How to solve the inconsistency or conflicts during the mapping? How to add consistent semantic on models in different levels of a system? How to achieve semiautomatic or automatic annotation?

We are currently investigating how semantic annotations can help collaborative actors (organizations, design teams, system developers, etc.) in co-designing, sharing, exchanging, aligning and transforming models. In particular, this research work will be based on general systems with several kinds of interactions. We can have interoperation between systems that with different versions (during many years, systems may have been modified or updated).

We can also have systems with same functions but used by different enterprises. Semantic annotations can bridge this knowledge gap and identify differences in models, in schemas, etc. In some case, interoperation is a process between a set of related systems throughout a product lifecycle (Marketing, Design, Manufacture, Service, etc.), and semantic annotations can influence the existing foundations and techniques which supports models reuse, semantic alignment and transformation, etc. Above all, our research work will focus on designing, and reusing appropriate ontologies in relationship with a formal semantic annotation structure model.

This section is derived from the following scientific publications:

Liao Y., Lezoche M., Panetto H., [START_REF] Liao | Why, Where and How to use Semantic Annotation for Systems Interoperability[END_REF]

Conclusions

In this research manuscript, we proposed a conceptualisation approach for enacting implicit semantics embedded into Enterprise Information System models by a deep analysis of existing data models enriched by users' and experts' knowledge. This approach is composed of 3 steps, staging from the traditional database reverse engineering process, through a knowledge elicitation and model enrichment by domain experts, to the application of formal fact-oriented modelling rules for externalising tacit semantics. Moreover, in order to structure the whole semantics into independent aggregates that may emphasize subsystems, we defined the concept of semantic block (SB) and we developed an automatized procedure to compute these SBs. The resulting semantics architecture allows the identification of semantically self-contained subsystems, facilitating further interoperation analysis.

The conceptualisation and structuring processes have been validated on a case study involving two industrial Enterprise Applications demonstrating the applicability of our approach.

Further works concern using the resulting semantic conceptual model and architecture for facilitating the assessment of the (non)-interoperation barriers between Enterprise Information Systems or some of their subsystems (identified, for instance, by the semantic blocks) as suggested in (Yahia, 2011). The resulting analysis, based on an interoperability measures map, can help information technology consulting companies for parameterising and integrating enterprise applications (ERP, MES…) taking into account interoperability constraints.

Scientific Contribution

This manuscript is the scientific product of our study on the applied semantic interoperability domain. During my Post-Doc period, I produced, with the laboratory team, the following scientific communications.

Zdravković M., Trajanović M., Panetto H., Aubry A., Lezoche M., (2011)

Introduction

The actual archetype for the Information Systems (ISs) involves large number of ISs distributed over large, complex computer/ communication networks. Such cooperative information systems (CIS) have access to large amount of information and have to interoperate to achieve their purpose. The cooperative information systems architects and developers have to face a hard problem: interoperability.

Interoperability can be defined as the ability for two or more systems to share, to understand and to consume information (IEEE, 1990). Some work (Chen et al., 2006) in the INTEROP NoE project has identified three different levels of barriers for interoperability: technical, conceptual and organisational. Organisational barriers are still an important issue but out of scope of this paper. The technological barriers are strongly studied by researchers in computer science and are generally based on models transformation (Frankel, 2003).

Our research focuses on the conceptual level of interoperability that is the ability to understand the exchanged information. A concept is a cognition unit of meaning (Vyvyan, 2006), an abstract idea, a mental symbol. It is created through the action of conceptualisation, that is, a general and abstract mental representation of an object.

During the history of human effort to model knowledge, different conceptualisation approaches regarding different application domains were developed (Aspray, 1985). This paper is dealing with a first step from a more general work focusing on the study of the semantic loss during the exchange of information representing business concepts.

Quantifying the semantic gap between interoperating ISs implies enacting their semantics through their normalized conceptual models. Indeed, in this context, the starting point for semantics interoperability is related to models conceptualisation.

We will present a conceptualisation approach to make explicit the finest-grained semantics embedded into conceptual models for finally enabling two different information systems seamlessly interoperating.

Next section presents the general context of our work. Then, the following section details the fundamental pillars of our conceptualisation process. Then, we will propose a knowledge explicitation process starting from an implemented relational model to a fact-oriented conceptual one. This process allows us emphasizing the finest-grained semantics that must be enacted to study semantics interoperability between collaborating ISs.

Finally, to validate our proposal, a practical case study is presented based on an Enterprise Resource Planning application involved in a B2M (Business to Manufacturing) interoperation process.

Cooperative Information systems

Information Systems are systems whose activities are devoted to capture and to store data, to process them and produce knowledge, used by any stakeholders within an enterprise or among different networked enterprises. It is commonly agreed that Cooperative Information Systems provide a backbone for the Integrated Information Infrastructure (Sheth, 1998). Fully understanding and exploiting the advances in computing is the only way to encompass the complexity of constructing and maintaining such systems.

Although the progress made in information technology considerably improved the efficiency of applications development, its drawbacks and limitations are obvious and serious. In fact, the application models involved in a single application are numerous and different, each coping only with particular and partial aspects of the overall task. Moreover, the components technologies are heterogeneous, platform-and machinedependant.

The above-mentioned limitations and barriers measurably hinder the development and the maintenance process.

There is a growing demand to integrate such systems tightly with organizational work so that these information systems can be directly and immediately used by the business activity.

Here, the need of interoperation clearly appears. In fact, to achieve the purpose of the cooperation between the different Information Systems, information must be physically exchanged (technical interoperability), must be understood (conceptual interoperability) and must be used for the purpose that they have been produced (conceptual and organisational interoperability). When trying to assess the understanding of an expression coming from a system to another system, there are several possible levels of interoperability (Euzenat, 2001):  encoding: being able to segment the representation in characters;  lexical: being able to segment the representation in words (or symbols);

 syntactic: being able to structure the representation in structured sentences (or formulas or assertions);  semantic: being able to construct the propositional meaning of the representation;  semiotic: being able to construct the pragmatic meaning of the representation (or its meaning in context). This tiered structure is arguable in general; it is not as strict as it seems. It makes sense because each level cannot be achieved if the previous levels have not been completed (Euzenat, 2001).

The encoding, lexical and syntactic levels are the most effective solutions for removing technical barriers for interoperability, but not sufficient, to achieve a practical interoperability between computerised systems. Dealing with trying to enable a seamless data and model exchange at the semantic level is still a big issue that needs conceptual representation of the intended exchanged information and the definition of the pragmatic meaning of that exchanged information in the context of the source and destination applications.

Different cooperation types have been investigated in ISO 14528 (ISO, 1999). In fact, this standard considers that models could be related in three ways:

(1) integration when there exists a standard or pivotal format to represent these models; (2) unification when there exists a common meta-level structure establishing semantic equivalence between these models; and

(3) federation when each model exists per se, but mapping between concepts could be done at an ontology level to formalise the interoperability semantics.

Integration is generally considered to go beyond mere interoperability to involve some degree of functional dependence (Panetto, 2007). Classifying interoperability problems (Tursi, et al. 2009) may help in understanding the degree of development needed to solve, at least partially, these problems but conceptualisation and semantics extraction is still an important issue because of the various contextual understanding of tacit knowledge embedded into those applications. The main prerequisite for achievement of interoperability of information systems is to maximise the amount of semantics which can be used and make it increasingly explicit (Obrst, 2003), and consequently, to make the systems semantically interoperable. To highlight this issue, the paper is based on a referenced scenario involving enterprise systems applications. Most of reverse engineering approaches (Fonkam, 1992) (Chiang, 1994) return the information structure but present a model with tacit semantics. The ADM (Architecture-Driven Modernization) initiative [START_REF] Omg | Object Management Group. Architecture-Driven Modernization specification[END_REF] from OMG (Bézivin et al., 2005) is tackling this problem by promoting a common Knowledge Discovery Meta-model to facilitate discovering tacit knowledge embedded inside existing software. In our scenario, those applications are still implemented and running using databases. We can extract, from them, by using reverse engineering approaches, some knowledge in a form of a conceptual model. We have then to enrich that model with enterprise applications best practices (knowledge coming from users). Finally, we make explicit all disclosed knowledge hidden in the resulting model.

Our approach for Semantics Enactment In Conceptual Models

In order to cooperate, two (or more) Information Systems have to interoperate. As previously discussed, we focus our interest on the conceptual level of interoperability letting different information systems to share and use knowledge models that they represent. Our principal issues are, therefore, first to understand the conceptual relationships between those models in the context of their use and secondly how, through conceptualisation, to unhide the tacit knowledge buried inside them. A usual approach for making explicit the tacit knowledge, concealed in attributes and classes, is the relationships-oriented perspective composed of a set of transformation rules. In that transformation method, an attribute a1 of type T1 pertaining to class C1 is modelled as a relationship between the class C1 and a standard type T1. This approach does not resolve entirely the semantics elicitation problem because it focuses its point of view on the values instead of on the concepts. The attribute semantics is somewhat yet hidden in the relationship just created. In literature, (Meersman, 2003) presented the definition of two different objects types, a lexical object (LOT), a term, is an object in a certain reality that can be written down. LOTs always consist of letters, numbers, symbols or other characters. They can be used as names for or references to other objects. A non-lexical object (NOLOT), a concept, is an object in a certain reality that cannot be written down.

Non-lexical objects must be named by lexical objects or referred to by means of lexical objects.

Applying these definitions, we can flatten the nested knowledge embedded in a model to simplify semantic enactment resulting from a set of modelling transformations. Our contribution is to have at our disposal an approach letting us to fragment knowledge through the transformation of attributes into entities and relationships, and thus to emphasize some fine-grained knowledge atoms. In the proposed approach, that is the first part (Figure 1) of our general methodology, the starting point can be various: an application, a data model, a logical view, a model. We have already mentioned that there are several reverse engineering methods, such as in (Fonkam, 1992) and in (Chiang, 1994), through which a model from the application or schema level can be derived (Step 1). Then, the resulted initial model is enriched and corrected through an Expert Knowledge Injection step (Step 2). In fact, the model is examined with the help of a domain expert or an end-user, who are the most qualified persons to describe the context of the peculiar domain and to put in evidence the contextual knowledge. According to the enterprise best practices and its data, they would clean and better organise the knowledge represented in the derived model. However, the obtained initial conceptual model, in the form of a UML class diagram, has yet a major limit. In fact, its semantics is in a tacit form because all the attributes are buried inside single classes and it is then difficult to make their semantics explicit.

Figure 1 -Conceptualisation approach Thus, the next step of our approach (Step 3) is a Fact-Oriented Transformation (Halpin, 1991) through the application of a set of patterns rules for transforming the enriched conceptual model to a fact-oriented model (FOM) with its semantics completely displayed. The consequence is that all the classes and their attributes are transformed into respectively LOTs and NOLOTs objects. The resulting fact-oriented model, displaying the finest-grained semantic atoms, is then used as an input for the second part of our methodology for semantic loss evaluation (not presented in this paper). In the following sub-sections, we will discuss, in detail, the proposed 3 steps.

Step 1: Reverse Engineering

Conceptualisation is a decision process (Guarino, 1998), a view, in which studied part of reality knowledge, usually in an implicit and complex form, is reorganised in different aggregates usually simpler to be represented. According to (Engelbart, 1962), developing conceptual models means specifying the essential objects or components of the system to be studied, the relationships of the objects that are recognised and what kinds of changes in the objects or their relationships affect the functioning of the system and in which ways. Conceptual models range in type from the more precise, such as the mental image of a familiar physical object, to the abstractness of mathematical models that do not appear to the mind as an image. Conceptual models also range in terms of the scope of the subject matter that they are taken to represent. The variety and scope of conceptual models is due to the variety of purposes that people had while using them. Conceptualisation approaches are numerous and have been developed in different knowledge domains (LaOnsgri, 2009). Our scenario assumes that we start from enterprise application database. So, the first studied approach is the Reverse engineering. It is, in database (DB) community, an approach to extract the domain semantics from the existing database structures. Typically, it concerns making the reverse transformation from logical to conceptual schema. In (Fonkam, 1992), the authors propose a general algorithm based on several old attempts to make explicit the logical structure buried into DB schemas, application programs and in the minds of designers and developers. (Chiang, 1994) presents a methodology for extracting an extended Entity-Relationship model from a relational database, through a combination of data schema and data instance analysis. In our study we will consider at profit the reverse engineering experiences developed in the past. These methods are, by now, acquired by the software industry that produces countless tools.

We choose MEGA Suite (http://www.mega.com), a modelling management environment to transform relational models into conceptual ones.

Step 2: Expert Knowledge Injection

After the reverse engineering process has created a conceptual model, the current step concerns enriching it by injecting the enterprise knowledge, expressed by users' best practices or experts. These stakeholders know the domain peculiarities and they are capable to embed specific constraints into the new conceptual model. The first stage is the renaming process. Usually the database tables, and the derived concepts, have not standard names. The renaming process is essential to bring coherence and semantics in concepts that otherwise would be of very difficult comprehension. The following stage is the redefinition of the attributes and of the associations' roles multiplicities according to the enterprise users' best practices. This step is fundamental to define the real constraints that are not always made explicit into the implementation model. As an example, considering a particular attribute a 1 , two cases can be considered: 1) a 1 is a non-mandatory attribute in the conceptual model but, as users are requested to always fill it with a specific value, the enriched model must formalise that this attribute a 1 is to be treated as mandatory; 2) a 1 is defined as mandatory in the conceptual model but, by practice, the users never care about its value and fill it with some dummy one. In such case, the enriched model may formalise that this attribute is not mandatory. Note that the same cases may happen also to the roles of associations. The last stage concerns of making explicit some implicit associations. Those implicit associations relate some concepts but they are defined only by enterprise practices even if they are not expressed in the model itself. At this time, the enriched conceptual model formalises the whole application semantics (both the explicit one and the users' implicit one).

Step 3: Fact-Oriented Transformation

The quality of a conceptual model is often influenced by the conceptual language used for its specification. Most conceptual languages for data modelling are based on a version of Entity-Relationship modelling (E-R) (Barke, 1990) (Czejdo et al., 1990) (Hohenstein et al., 1991). However, these modelling languages are making a distinction between entities, attributes and relationships. On the contrary, in order to normalise the way that knowledge is represented, NIAM (Natural-language Information Analysis Method) (Nijssen & Halpin 1989) proposed to model the world in term of facts (either presenting terms (real things), or representing characteristics (attributes) of these real things), and relationships between facts. NIAM is attribute-free, it does not use explicitly the notion of attribute, treating all elementary facts as relationships. Some authors have extended the concepts and notations developed by NIAM with object orientation. It is the case of ORM (Object Role Modelling) (Halpin, 1998). Our purpose is to adapt this fact-oriented modelling approach to enriched conceptual models represented using the UML (OMG, 2004) class notation. Thus, we developed a set of transformation modelling rules, to be applied to selected UML patterns (Table 1). Let us refer to the definitions of LOT and NOLOT facts given in the beginning of section 3. Transforming a particular conceptual model in a fact-oriented model must follow these rules:

1 One of the conceptual modelling requirements is that a conceptual model must have formal foundations, which allow comparing that model with other conceptual models in a formal and exact way. (Berardi et al, 2005) and (Tursi, 2009) formalise UML class constructs semantics in First Order Language (FOL) axioms. We propose to adapt these works to formalise the fact-oriented model patterns (presented previously) in FOL axioms. Due to the lack of space we will present only one pattern rule formalisation in FOL: the "Class and Attributes" as reported in Table 5.

Patterns represented in FOL

A class in UML designates a set of object with common features. (Russel and al, 1995), we are able to demonstrate that the semantics formalised in the initial conceptual model is equivalent or included into the one transformed in FOM.

Case study

Interoperability between organisational and manufacturing activities is crucial in manufacturing enterprises. Production services have to produce, quickly and efficiently, the good product at the right moment. For this reason, they need at time information coming from others services, which need in return precise and update data on production. We propose here to study and present the first part of such a B2M interoperability issue by considering a particular IS implemented in a real manufacturing environment: Sage X3 as an Enterprise Resource Planning (ERP) application.

Specific analysed Enterprise

Information System: Sage X3 ERP An Enterprise Resource Planning (ERP) is an integrated computer-based system used to manage internal and external resources including tangible assets, financial resources, materials, and human resources (Bidgol, 1997). Its purpose is to facilitate the flow of information between all business functions inside the boundaries of the organization and manage the connections to outside stakeholders. Built on a centralized database, ERP systems centralise all business operations into a uniform system environment. Sage X3 presents different enterprise management functions: finance, commercial, industrial and services. The focus for this case study is (i) to analyse how the work order process inside the Sage X3 application is modelled, (ii) to use the proposed modelling process to externalise the implicit knowledge in the model structure. The model depicted in figure 2 is already the result from the two first steps of our approach. This means that we have already passed the "Reverse Engineering" and the "Expert knowledge injection" stages. The "Manufacturing Order Heading" concept is the management function of production orders and planned activities. It allows the generation of a production order by variation of one or more classifications and a single production line. For each production order, the achievement of the material benefits and sequencing operations is possible. This block captures general information about the work order, such as, planning facility and facility of production, status of the order (manufacturing order product). It allows entering general information about the production order. The availability of components is checked through the information given by the bill of material related with the launched products. Once that initial information is determined, the system updates the list of materials and operations of the created or modified orders.

Step 1: Reverse Engineering All these information are coded in the Sage application database. The first step of our method is the reverse engineering to extract the initial conceptual model.

Step 2: Expert Knowledge Injection Currently the model depicted in Figure 2 is the result of the reverse engineering step enriched by a domain expert because the architecture of the Sage X3 ERP is built with all the database relationships implemented directly into the application layer and not in the database. The reverse engineering result, as shown in the lower part of the Figure 3, creates a model containing unlinked classes with coded names. The expert work was about cleaning this conceptual model according to the best practices in the enterprise, modifying the attributes multiplicity, adding explicit names to the concepts, the attributes and the associations and others operations to fit the conceptual model to the "real" use of the Enterprise Information System. A usual case that requests the domain expert attention is about the mandatory properties in forms' attributes.

Step 3: Fact-Oriented Transformation Applying the pattern transformation rules, presented in the previous section, class attributes are transformed into NOLOTs to increase the atomic representation of the knowledge embedded into the model. These rules have been coded using a programming language and then automatically executed inside MEGA Suite.

Figure 4 shows an extract of the resulting FOM after applying our approach to the Sage X3 work order process. The resulting full FOM is composed of 23 NOLOTs, 56 LOTs and 46 associations. It seems then that the resulting model is much more complex than the initial one, which it is true in a visual point of view but it is false in term of expressiveness of its semantics. Indeed, the fine-grained atoms of semantics are now made explicit, which helps any automatic computing. An important result is that such semantically detailed model will help automating the next part of our methodology for semantic gap evaluation, as explained in section 3.

Conclusions

In this article, a conceptualisation approach for enacting implicit semantics from Enterprise Information Systems is proposed. Our approach if divided into 3 steps from the traditional reverse engineering process, through a knowledge elicitation and model enrichment by domain experts, till making use of fact-oriented modelling patterns to externalise tacit knowledge. These patterns have been formalised in FOL axioms to verify their semantic coherence. Our contribution can be assimilated to a reverse engineering methodology. However, the main objective is to formalize the whole semantics of such models in order to help automatic knowledge computing. An industrial case study, related to an enterprise information system implemented into an ERP system demonstrates the applicability of our approach.

Our current work concerns applying this approach for evaluating the (non)interoperation through the measurement of the semantic gap occurring between CISs interoperability (Yahia, 2011).

Introduction

The actual archetype for the Information Systems (ISs) involves large number of ISs distributed over large, complex computer/ communication networks. Such cooperative information systems (CIS) have access to large amount of information and have to interoperate to achieve their purpose. The cooperative information systems architects and developers have to face a hard problem: interoperability. Interoperability can be defined as the ability for two or more systems to share, to understand and to consume information [START_REF][END_REF]. Some work [START_REF] Chen | DI.2: Enterprise Interoperability Framework and knowledge corpus, Interoperability Research for Networked Enterprises Applications and Software Network of Excellence[END_REF] in the INTEROP NoE project has identified three different levels of barriers for interoperability: technical, conceptual and organisational. Organisational barriers are still an important issue but out of scope of this paper. The technological barriers are strongly studied by researchers in computer science and the solution is generally based on models transformation [START_REF] Frankel | Model Driven Architecture: Applying MDA to Enterprise Computing[END_REF]. Our research [START_REF] Lezoche | Conceptualisation approach for Cooperative Information Systems interoperability[END_REF] focuses on the conceptual level of interoperability that is the ability to understand the exchanged information. A concept is a cognition unit of meaning [START_REF] Vyvyan | Lexical Concepts, Cognitive Models and Meaning-Construction[END_REF], an abstract idea, a mental symbol. It is created through the action of conceptualisation, that is, a general and abstract mental representation of an object. During the history of human effort to model knowledge, different conceptualisation approaches regarding different application domains were developed [START_REF] Aspray | The Scientific Conceptualization of Information: A Survey[END_REF]. This paper is dealing with a first step from a more general work focusing on the study of the semantic loss during the exchange of information representing business concepts. Quantifying the semantic gap between interoperating ISs implies enacting their semantics through their normalized conceptual models. Indeed, in this context, the starting point for semantics interoperability is related to models conceptualisation.

We will present a conceptualisation approach to make explicit the finestgrained semantics embedded into conceptual models for finally enabling two different information systems seamlessly interoperating.

Next section presents the general context of our work. Then, the following section details the fundamental pillars of our conceptualisation process. Then, we will propose a knowledge explicitation process starting from an implemented relational model to a fact-oriented conceptual one. This process allows us emphasizing the finest-grained semantics that must be enacted to study semantics interoperability between collaborating ISs.

Finally, to validate our proposal, a practical case study is presented based on an Enterprise Resource Planning application involved in a B2M (Business to Manufacturing) interoperation process.

Cooperative Information systems

Information Systems are systems whose activities are devoted to capture and to store data, to process them and produce knowledge, used by any stakeholders within an enterprise or among different networked enterprises. It is commonly agreed that Cooperative Information Systems provide a backbone for the Integrated Information Infrastructure [START_REF] Sheth | Changing Focus on Interoperability in Information Systems: From System, Syntax, Structure to Semantics[END_REF]. Fully understanding and exploiting the advances in computing is the only way to encompass the complexity of constructing and maintaining such systems.

Although the progress made in information technology considerably improved the efficiency of applications development, its drawbacks and limitations are obvious and serious. In fact, the application models involved in a single application are numerous and different, each coping only with particular and partial aspects of the overall task. Moreover, the components technologies are heterogeneous, platform-and machine-dependant. The above-mentioned limitations and barriers measurably hinder the development and the maintenance process.

There is a growing demand to integrate such systems tightly with organizational work so that these information systems can be directly and immediately used by the business activity.

Here, the need of interoperation clearly appears. In fact, to achieve the purpose of the cooperation between the different Information Systems, information must be physically exchanged (technical interoperability), must be understood (conceptual interoperability) and must be used for the purpose that they have been produced (conceptual and organisational interoperability). When trying to assess the understanding of an expression coming from a system to another system, there are several possible levels of interoperability [START_REF] Euzenat | Towards a principled approach to semantic interoperability[END_REF]:  encoding: being able to segment the representation in characters;  semiotic: being able to construct the pragmatic meaning of the representation (or its meaning in context). This tiered structure is arguable in general; it is not as strict as it seems. It makes sense because each level cannot be achieved if the previous levels have not been completed [START_REF] Euzenat | Towards a principled approach to semantic interoperability[END_REF].

The encoding, lexical and syntactic levels are the most effective solutions for removing technical barriers for interoperability, but not sufficient, to achieve a practical interoperability between computerised systems. Dealing with trying to enable a seamless data and model exchange at the semantic level is still a big issue that needs conceptual representation of the intended exchanged information and the definition of the pragmatic meaning of that exchanged information in the context of the source and destination applications.

Different cooperation types have been investigated in ISO 14528 [START_REF]ISO 14528: Industrial Automation Systems -Concepts and rules for Enterprise Models[END_REF]. In fact, this standard considers that models could be related in three ways:

(4) integration when there exists a standard or pivotal format to represent these models;

(5) unification when there exists a common meta-level structure establishing semantic equivalence between these models; and ( 6) federation when each model exists per se, but mapping between concepts could be done at an ontology level to formalise the interoperability semantics.

Integration is generally considered to go beyond mere interoperability to involve some degree of functional dependence. Classifying interoperability problems [START_REF] Tursi | Ontological approach for Products-Centric Information System Interoperability in Networked Manufacturing Enterprises[END_REF] may help in understanding the degree of development needed to solve, at least partially, these problems but conceptualisation and semantics extraction is still an important issue because of the various contextual understanding of tacit knowledge embedded into those applications. The main prerequisite for achievement of interoperability of information systems is to maximise the amount of semantics which can be used and make it increasingly explicit [START_REF] Obrst | Ontologies for semantically interoperable systems[END_REF], and consequently, to make the systems semantically interoperable. To highlight this issue, the paper is based on a referenced scenario involving enterprise systems applications. Most of reverse engineering approaches [13] [9] return the information structure but present a model with tacit semantics. The ADM (Architecture-Driven Modernization) initiative [START_REF] Omg | Object Management Group. Architecture-Driven Modernization specification[END_REF] from OMG [START_REF] Bézivin | Model-based Technology Integration with the Technical Space Concept[END_REF] is tackling this problem by promoting a common Knowledge Discovery Meta-model to facilitate discovering tacit knowledge embedded inside existing software. In our scenario, those applications are still implemented and running using databases. We can extract, from them, by using reverse engineering approaches, some knowledge in a form of a conceptual model. We have then to enrich that model with enterprise applications best practices (knowledge coming from users). Finally, we make explicit all disclosed knowledge hidden in the resulting model.

Our approach for Semantics Enactment In Conceptual Models

In order to cooperate, two (or more) Information Systems have to interoperate. As previously discussed, we focus our interest on the conceptual level of interoperability letting different information systems to share and use knowledge models that they represent. Our principal issues are, therefore, first to understand the conceptual relationships between those models in the context of their use and secondly how, through conceptualisation, to unhide the tacit knowledge buried inside them. A usual approach for making explicit the tacit knowledge, concealed in attributes and classes, is the relationshipsoriented perspective composed of a set of transformation rules. In that transformation method, an attribute a 1 of type T 1 pertaining to a class C 1 is modelled as a relationship between the class C 1 and a standard type T 1 . This approach does not resolve entirely the semantics elicitation problem because it focuses its point of view on the values instead of on the concepts. The attribute semantics is somewhat yet hidden in the relationship just created. In literature, [START_REF] Meersman | Creating a "DOGMAtic" Multilingual Ontology Infrastructure to Support a Semantic Portal On The Move to Meaningful Internet Systems[END_REF] presented the definition of two different objects types, a lexical object (LOT), a term, is an object in a certain reality that can be written down. LOTs always consist of letters, numbers, symbols or other characters. They can be used as names for or references to other objects. A non-lexical object (NOLOT), a concept, is an object in a certain reality that cannot be written down. Non-lexical objects must be named by lexical objects or referred to by means of lexical objects. Applying these definitions, we can flatten the nested knowledge embedded in a model to simplify semantic enactment resulting from a set of modelling transformations. Our contribution is to have at our disposal an approach letting us to fragment knowledge through the transformation of attributes into entities and relationships, and thus to emphasize some fine-grained knowledge atoms. In the proposed approach, that is the first part (Figure 1) of our general methodology, the starting point can be various: an application, a data model, a logical view, a model. We have already mentioned that there are several reverse engineering methods, such as in [START_REF] Fonkam | An Approach to Eliciting the Semantics of Relational Databases[END_REF] and in [START_REF] Chiang Roger | Reverse engineering of relational databases: Extraction of an EER model from a relational database[END_REF], through which a model from the application or schema level can be derived (Step 1). Then, the resulted initial model is enriched and corrected through an Expert Knowledge Injection step (Step 2). In fact, the model is examined with the help of a domain expert or an end-user, who are the most qualified persons to describe the context of the peculiar domain and to put in evidence the contextual knowledge. According to the enterprise best practices and its data, they would clean and better organise the knowledge represented in the derived model. However, the obtained initial conceptual model, in the form of a UML class diagram, has yet a major limit. In fact, its semantics is in a tacit form because all the attributes are buried inside single classes and it is then difficult to make their semantics explicit.

Figure 18 -Conceptualisation approach

Thus, the next step of our approach (Step 3) is a Fact-Oriented Transformation [START_REF] Halpin | A fact-oriented approach to schema transformation[END_REF] through the application of a set of rules for transforming the enriched conceptual model to a fact-oriented model (FOM) with its semantics completely displayed. The consequence is that all the classes and their attributes are transformed into respectively LOTs and NOLOTs objects. The resulting fact-oriented model, displaying the finest-grained semantic atoms, is then used as an input for the second part of our methodology for semantic loss evaluation (not presented in this paper). In the following sub-sections, we will discuss, in detail, the proposed 3 steps.

Step 1: Reverse Engineering

Conceptualisation is a decision process [START_REF] Guarino | Formal Ontology in Information Systems[END_REF], a view, in which studied part of reality knowledge, usually in an implicit and complex form, is reorganised in different aggregates usually simpler to be represented. According to [START_REF] Engelbart | Augmenting human intellect: a conceptual framework[END_REF], developing conceptual models means specifying the essential objects or components of the system to be studied, the relationships of the objects that are recognised and what kinds of changes in the objects or their relationships affect the functioning of the system and in which ways. Conceptual models range in type from the more precise, such as the mental image of a familiar physical object, to the abstractness of mathematical models that do not appear to the mind as an image. Conceptual models also range in terms of the scope of the subject matter that they are taken to represent. The variety and scope of conceptual models is due to the variety of purposes that people had while using them. Conceptualisation approaches are numerous and have been developed in different knowledge domains [START_REF] Laongsri | Semantic Extensions and a Novel Approach to Conceptual Modelling[END_REF]. Our scenario assumes that we start from enterprise application database. So, the first studied approach is the Reverse engineering. It is, in database (DB) community, an approach to extract the domain semantics from the existing database structures. Typically, it concerns making the reverse transformation from logical to conceptual schema. In [START_REF] Fonkam | An Approach to Eliciting the Semantics of Relational Databases[END_REF], the authors propose a general algorithm based on several old attempts to make explicit the logical structure buried into DB schemas, application programs and in the minds of designers and developers. [START_REF] Chiang Roger | Reverse engineering of relational databases: Extraction of an EER model from a relational database[END_REF] presents a methodology for extracting an extended Entity-Relationship model from a relational database, through a combination of data schema and data instance analysis. In our study we will consider at profit the reverse engineering experiences developed in the past. These methods are, by now, acquired by the software industry that produces countless tools. We choose MEGA Suite (http://www.mega.com), a modelling management environment to transform relational models into conceptual ones. MEGA Suite implements a parameterised reverse engineering method coping with major existing approaches from direct database metadata analysis to a semiautomatic conceptual models building from existing database schemas.

Step 2: Expert Knowledge Injection

After the reverse engineering process has created a conceptual model, the current step concerns enriching it by injecting the enterprise knowledge, expressed by users' best practices or experts. These stakeholders know the domain peculiarities and they are capable to embed specific constraints into the new conceptual model. The first stage is the renaming process. Usually the database tables, and the derived concepts, have not standard names. The renaming process is essential to bring coherence and semantics in concepts that otherwise would be of very difficult comprehension. The following stage is the redefinition of the attributes and of the associations' roles multiplicities according to the enterprise users' best practices. This step is fundamental to define the real constraints that are not always made explicit into the implementation model. As an example, considering a particular attribute a 1 , two cases can be considered: 1) a 1 is a non-mandatory attribute in the conceptual model but, as users are requested to always fill it with a specific value, the enriched model must formalise that this attribute a 1 is to be treated as mandatory; 2) a 1 is defined as mandatory in the conceptual model but, by practice, the users never care about its value and fill it with some dummy one. In such case, the enriched model may formalise that this attribute is not mandatory. Note that the same cases may happen also to the roles of associations. The last stage concerns of making explicit some implicit associations. Those implicit associations relate some concepts but they are defined only by enterprise practices even if they are not expressed in the model itself. At this time, the enriched conceptual model formalises the whole application semantics (both the explicit one and the users' implicit one).

Step 3: Fact-Oriented Transformation

The quality of a conceptual model is often influenced by the conceptual language used for its specification. Most conceptual languages for data modelling are based on a version of Entity-Relationship modelling (E-R) [3] [10] [19]. However, these modelling languages are making a distinction between entities, attributes and relationships. On the contrary, in order to normalise the way that knowledge is represented, NIAM (Natural-language Information Analysis Method) [START_REF] Nijssen | Conceptual Schema and Relational Database Design[END_REF] proposed to model the world in term of facts (either presenting terms (real things), or representing characteristics (attributes) of these real things), and relationships between facts. NIAM is attribute-free, it does not use explicitly the notion of attribute, treating all elementary facts as relationships. Some authors have extended the concepts and notations developed by NIAM with object orientation. It is the case of ORM (Object Role Modelling) [START_REF] Halpin | Handbook on Architectures of Information Systems Chapter 4[END_REF]. Our purpose is to adapt this fact-oriented modelling approach to enriched conceptual models represented using the UML [START_REF] Omg | Object Management Group. UML 2.0 Superstructure Specification[END_REF] class notation. Thus, we developed a set of transformation modelling rules, to be applied to selected UML patterns (Table 1). Let us refer to the definitions of LOT and NOLOT facts given in the beginning of section 3. Transforming a particular conceptual model in a factoriented model must follow these rules:

1. all classes are transformed into LOT facts. Using UML Class notation, a LOT fact is represented by a UML Class.

2. all attributes are transformed into NOLOT facts. Using the UML Class notation, a NOLOT fact is represented as a UML Class.

3. for each attribute a belonging to a UML Class C, an association is created between the corresponding LOT a and the corresponding NOLOT C, created by the two previous rules.

4. the multiplicity associated to each attribute a is copied as the multiplicity of the role of the previous (rule 3) association attached to the NOLOT a. The opposite role of the same association must have a constraint multiplicity equal to one.

5. all "simple" associations between classes are transformed into "simple" associations between NOLOTs.

6. all generalisation relationships between classes are transformed into "simple" associations with a constraint multiplicity equal to one on the role attached to generalised NOLOT and a non constraint multiplicity equal to * on the opposite role. In order to trace the fact that this association was coming from a generalisation, we annotate semantically the new corresponding association with a logical rule using OCL (Object Constraint Language) notation. Moreover, the inheritance feature of the generalisation association is mapped as new associations between LOTs representing the attributes of the generalised NOLOT, and all the specialised NOLOTs (sub-classes).

7. composition and aggregation relationships are transformed into simple association (rule 3) that keep unchanged the existing roles' multiplicities but trace their specific semantics through an attached semantic annotation formalised with an OCL logical rule.

8. association classes are transformed into a LOT fact with two associations linked to the corresponding initial LOT facts. The multiplicities of the roles of these two associations are determined inverting the ones initially formalised on the roles of the previous association.

9. any other specific constraints (generally modelled using OCL logical rules) are kept during the transformation process.

10. we did not take into account special cases of constraints in generalisations because they are not usually used in data conceptual modelling.

One of the conceptual modelling requirements is that a conceptual model must have formal foundations, which allow comparing that model with other conceptual models in a formal and exact way. [START_REF] Berardi | Reasoning on UML class diagrams[END_REF] and [START_REF] Tursi | Ontological approach for Products-Centric Information System Interoperability in Networked Manufacturing Enterprises[END_REF] formalise UML class constructs semantics in First Order Language (FOL) axioms. We propose to adapt these works to formalise the fact-oriented model patterns (presented previously) in FOL axioms.

Patterns represented in FOL

We will present only one pattern rule formalisation in FOL: the "Class and Attributes" rule as presented in Table 1.

A class in UML designates a set of object with common features. Formally a class C corresponds to a FOL unary predicate C.

An attribute a of type T for a class C associates to each instance of C a set of instance of T, its multiplicity [i..j] specifies that a associates to each instance of C at least i and at most j instances of T. Formally, an attribute a of type T for class C corresponds to a binary predicate.

An association in UML is a relation between the instances of two or more classes. The multiplicity [m..n] attached to the role of a binary association specifies that each instance of the class C can participate at least m times and at most n times to the Table 6 -Fact-Oriented modelling patterns using UML notation related association. An association A between two classes can be formalised as a binary predicate. In the studied pattern, we formalise a class C 1 containing two attributes A 1 and A 2 with respectively a multiplicity of 1 and [0..1], and with associated types respectively, A 1 Type and A 2 Type. Its formalisation in FOL assertions is the following:

∀ , , ∧ , ⊃ ∀ , , ∧ , ⊃ ∀ , ⊃ 1 | , ∀ , ⊃ 0 1 | ,
Applying the transformation rule, presented in section 3.3, to the class C 1 , and to the two attributes A 1 and A 2 , we will obtain the Fact-Oriented Model (FOM) in UML notation as shown in Table 1 "Class and Attributes".

Its formalisation in FOL assertions is the following:

∀ , , , ⊃ ∧ ∀ , ⊃ 1 | , ∀ , ⊃ 1 | , ∀ , , , ⊃ ∧ ∀ , ⊃ 0 1 | , ∀ , ⊃ 1 | ,
We used as demonstration tools Prover9, an automated theorem prover for first-order and equational logic, and Mace4 searcher for finite models and counterexamples. We implemented our models in prover9 syntax to verify them in FOL formalised transformation models rules.

These artefacts are the constituent basis to represent the transformation rules in First Order Logic. After the translation, we own two sets of FOL expression facts. We named them A and B. They represent the formalised semantics of UML and FOM models. They can be used to verify the models semantic equality. We will use a standard verification algorithm based on set theory. The verification algorithm takes as input assumptions the two expression sets, A and B.

The goal of the verification task is to demonstrate ∀x A x ∧ B x → ∅.

With this evaluation method we are able to demonstrate that the semantics formalised in the initial conceptual model is equivalent or included into the one transformed in FOM and so it is sufficient for our verification purpose.

Case study

Interoperability between organisational and manufacturing activities is crucial in manufacturing enterprises. Production services have to produce, quickly and efficiently, the good product at the right moment. For this reason, they need at time information coming from others services, which need in return precise and update data on production.

We propose here to study and present the first part of such a B2M interoperability issue by considering a particular IS implemented in a real manufacturing environment: Sage X3 as an Enterprise Resource Planning (ERP) application. An Enterprise Resource Planning (ERP) is an integrated computer-based system used to manage internal and external resources including tangible assets, financial resources, materials, and human resources [START_REF] Bidgol | The Internet Encyclopedia[END_REF]. Its purpose is to facilitate the flow of information between all business functions inside the boundaries of the organization and manage the connections to outside stakeholders. Built on a centralized database, ERP systems centralise all business operations into a uniform system environment. Sage X3 presents different enterprise management functions: finance, commercial, industrial and services. The focus for this case study is (i) to analyse how the work order process inside the Sage X3 application is modelled, (ii) to use the proposed modelling process to externalise the implicit knowledge in the model structure.

The model depicted in figure 2 is already the result from the two first steps of our approach. This means that we have already passed the "Reverse Engineering" and the "Expert knowledge injection" stages. The "Manufacturing Order Heading" concept is the management function of production orders and planned activities. It allows the generation of a production order by variation of one or more classifications and a single production line. For each production order, the achievement of the material benefits and sequencing operations is possible. This block captures general information about the work order, such as, planning facility and facility of production, status of the order (manufacturing order product). It allows entering general information about the production order. The availability of components is checked through the information given by the bill of material related with the launched products. Once that initial information is determined, the system updates the list of materials and operations of the created or modified orders.

Step 1: Reverse Engineering All these information are coded in the Sage application database. The first step of our method is the reverse engineering to extract the initial conceptual model.

Step 2: Expert Knowledge Injection Currently the model depicted in Figure 2 is the result of the reverse engineering step enriched by a domain expert because the architecture of the Sage X3 ERP is built with all the database relationships implemented directly into the application layer and not in the database. The reverse engineering result, as shown in the lower part of the Figure 3, creates a model containing unlinked classes with coded names.

The expert work was about cleaning this conceptual model according to the best practices in the enterprise, modifying the attributes multiplicity, adding explicit names to the concepts, the attributes and the associations and others operations to fit the conceptual model to the "real" use of the Enterprise Information System. A usual case that requests the domain expert attention is about the mandatory properties in forms' attributes.

Step 3: Fact-Oriented Transformation Applying the pattern transformation rules, presented in the previous section, class attributes are transformed into NOLOTs to increase the atomic representation of the knowledge embedded into the model. These rules have been coded using a programming language and then automatically executed inside MEGA Suite. Figure 4 shows an extract of the resulting FOM after applying our approach to the Sage X3 work order process. The resulting full FOM is composed of 23 NOLOTs, 56 LOTs and 46 associations. It seems then that the resulting model is much more complex than the initial one, which it is true in a visual point of view but it is false in term of expressiveness of its semantics. Indeed, the fine-grained atoms of semantics are now made explicit, which helps any automatic computing. An important result is that such semantically detailed model will help automating the next part of our methodology for semantic gap evaluation, as presented in [START_REF] Yahia | Contribution à l'Evaluation de l'Interopérabilité Sémantique entre Systèmes d'Information d'Entreprises : Application aux Systèmes d'Information de Pilotage de la Production[END_REF].

Conclusions

In this article, a conceptualisation approach for enacting implicit semantics from Enterprise Information Systems is proposed. Our approach if divided into 3 steps from the traditional reverse engineering process, through a knowledge elicitation and model enrichment by domain experts, till making use of fact-oriented modelling patterns to externalise tacit knowledge. These patterns have been formalised in FOL axioms to verify their semantic coherence. Our contribution can be assimilated to a reverse engineering methodology. However, the main objective is to formalize the whole semantics of such models in order to help automatic knowledge computing. An industrial case study, related to an enterprise information system implemented into an ERP system demonstrates the applicability of our approach. Our current work concerns applying this approach for evaluating the (non)interoperation through the measurement of the semantic gap occurring between CISs interoperability [START_REF] Yahia | Semantics enactment in Enterprise Information Systems[END_REF] and [START_REF] Yahia | Contribution à l'Evaluation de l'Interopérabilité Sémantique entre Systèmes d'Information d'Entreprises : Application aux Systèmes d'Information de Pilotage de la Production[END_REF]. When evolving in a competitive global market, enterprises are forced to become increasingly agile and flexible in order to manage the fast changing business conditions. Today's challenges mainly concern Enterprise Integration (EI). Indeed, EI deals with removing organisational barriers and/or improving interactions among people, systems, applications, departments, and companies (in terms of material, informational, decision and workflows) [START_REF] Vernadat | Enterprise Integration and Interoperability[END_REF] Enterprise Modelling (EM) plays a critical role in this integration, enabling the capture of all the information and knowledge relevant for the enterprise operations and organisation [START_REF] Vernadat | Enterprise Modelling and Integration: principles and applications[END_REF]Panetto and Molina, 2004) The produced Enterprise Models are mainly related to artefacts such as processes, behaviours, activities, information, resources, objects/material flows, goals, systems infrastructure and architectures... Those Enterprise Models must contain the necessary and sufficient semantics in order to be intelligible and then enabling the global Enterprise Integration.

For instance, if we consider the process model, its business semantics is mainly brought along by languages such as the Business Process Modelling Notation (BPMN4 ). Moreover, enriching this semantics is still an open issue; we can for example quote those researches made by [START_REF] Boudjlida | Annotation of enterprise models for interoperability purposes[END_REF] in terms of process models annotations.

Among all Enterprise Models, Information Systems (IS) models are considered as the core models of the enterprise. Concretely, the complexity of EI relies on the fact that an enterprise (a single or a networked enterprise) comprises numerous and heterogeneous Information Systems either at the business or manufacturing level such as ERP (Enterprise Resource Planning), MES (Manufacturing Execution System), SCM (Supply Chain Management), PDM (Product Data Management) and CRM (Customer Relationship Management). Those ISs need i) to share specified information and ii) to operate on that information according to a shared operational semantics iii) in order to realise a specified purpose in a given context. Achieving these actions is commonly called interoperation [START_REF] Whitman | An Enterprise Model of Interoperability[END_REF].

While studying an Information System (IS) model, we observe that its semantics is tacit as it is scrambled due to the implementation requirements.

The intent of this paper is to define a method for semantics enactment in IS. This allows bringing out the tacit semantics in order to get explicit semantics required when studying and using Enterprise Models.

In section 2, we present a modelling approach called factoriented modelling that allows releasing all the entities within the ISs conceptual models.

A recursive approach is thus proposed, in section 3, to analyse the detailed semantics of those ISs conceptual model. This approach starts by representing the basic concepts and ends by building semantic aggregates (so-called semantic blocks) according to predefined rules.

In order to illustrate the proposed approach, a case study is presented in the section 4. This case study deals with B2M (Business to Manufacturing) interoperability requirements between an Enterprise Resource Planning (ERP) system and a Manufacturing Execution System (MES) applications and consists in applying our approach in order to extract the semantics embedded into those ISs.

Finally, we conclude this paper with some remarks and perspectives for ongoing research.

FACT-ORIENTED PERSPECTIVE FOR SEMANTICS MODELLING

Fact-oriented modelling

The difficulty of operating with the various Enterprise Models comes out from the fact that the majority of those models have been made by different experts with several modelling experiences. That has led, for instance, to various conceptual representations for the same semantics.

Since the majority of conceptual models have been fulfilled a posteriori and not a priori, implementation-based functionalities and constraints can cause interferences in the semantics understanding of those models. Let us consider, for instance, the extract of two different conceptual models in figure 1. Intuitively, those classes carry the same semantics, but are modelled differently. For instance, the WEIGHT of a PRODUCT on the right side of the figure is represented by a class due to an implementation constraint; when other classes are related to it, this facilitates querying for specific values related to the weight for example. While, on the left side of the figure, the WEIGHT of a PRODUCT is modelled by two attributes (its value and its unit). Fact-oriented modelling is a conceptual, natural language based approach avoiding such conflicting conceptual representations. It queries the information semantics of business domains in terms of the underlying facts of interest, where all facts and rules may be verbalised in a language readily understandable by users of those business domains [START_REF] Halpin | Fact-oriented modeling: Past, present and future[END_REF]. Fact-oriented models are attribute-free, treating all elementary facts as relationships.

Object-Role Modelling (ORM) is the most popular fact-oriented approach. In fact, ORM makes no explicit use of attributes; instead it pictures the world in terms of lexical and non-lexical concepts that play roles (take part in relationships) (Halpin, 1998). This leads to a greater semantics stability and populatability, as well as facilitates natural verbalisation [START_REF] Halpin | Fact-oriented modeling: Past, present and future[END_REF].

In our work, we could use ORM as a modelling language. However, the existing conceptual models, in industrial context, are mainly represented with the UML notation. Hence getting a spread out of an attribute-free conceptualisation could be made using the UML notation but based on the ORM approach. Taking into account the ORM definitions, we will use the UML class diagram notation and we then call the UML concepts and the UML attributes as respectively non-lexical concepts and lexical concepts.

When applying the fact-oriented modelling on the examples of the figure 1, we obtain the following models (figure 2) that eases the semantics enactment.

PRODUCT We ig ht-un

We ig ht-val

IS1 IS2

Fig. 2. The conceptual models of Fig. 1 using the factoriented modelling perspective.

Core and extended knowledge

When considering an available fact-oriented conceptual model from one IS, we can distinguish the mandatory and non-mandatory "relationships", which represent mandatory and non-mandatory concepts expressing semantics.

In fact, the mandatory concepts contain all the necessary and sufficient elements to make the IS conceptual model semantically coherent and understandable. It comprises all the non-lexical and lexical concepts linked to constraint association roles with a multiplicity of 1 or 1..*. On the contrary, the non-mandatory concepts correspond to the non-mandatory roles (constraints 0..1 or *) and are only enriching the semantics of those IS conceptual models.

Somehow, the mandatory knowledge corresponds to the minimal semantics that should be contained in a given IS conceptual model. It could eventually represent the essence of the IS that is the core knowledge of the conceptual model. The extended knowledge includes the core and the nonmandatory knowledge.

Let us note that we consider that these models have made correct and that the implicit constraints are all represented explicitly in those models, that means that any constraint implemented into the software by developers have been reported in the models, themselves through roles multiplicities.

Some mathematical definitions

We define, for each IS conceptual model, the following notations.

Definition 1.

is the set of the identified attributes or lexical concepts, formally defined by | is an attribute from the IS conceptual model Definition 2.

is the set of the identified concepts or nonlexical concepts, formally defined by | is a concept from the IS conceptual model Definition 3. Rel IS is the set of the identified binary relationships between concepts such as hierarchy relationship and also between concepts and their related attributes. Formally, it is defined by Rel IS = rel a c j , c j , ∈ × ∧c j is related to ∪ rel c c j ,c j ' c j ,c j ' ∈ ∧ c j is related to If we consider a concept defined in the context of the IS core knowledge, we notice that in order to be semantically effective in the studied domain, this concept needs to be related on the one hand to its mandatory attributes and on the other hand to other concepts. This defines the notion of Semantic Block.

SEMANTIC BLOCK IDENTIFICATION

Definition of a semantic block

Considering a particular concept from , a semantic block, denoted as and associated with the concept , represents the minimal set of non-lexical concepts necessary for the minimal semantics definition of the concept given by the conceptual model.

Let us consider the conceptual model on figure 3. minimal multiplicity is 0 for role 5 when considering the association between 6 and 5, the existence of any instance of 6 is not conditioned by the existence of one instance of 5.

Finally, continuing the same reasoning step by step, we can demonstrate that all the concepts are mandatory for expressing the semantics of 1 . That means that 1 1, 2, 3, 4, 5, 6, 7, 8 . The semantic block of a concept finally contains all the concepts that must be instantiated for ensuring the existence of one instance of .

A semantic-relationships graph

To facilitate the building of the semantic blocks, we propose to use graph theory modelling.

Let us define a semantic-relationships graph associated with a conceptual model. This semanticrelationships graph is a digraph , where is the set of nodes and is the set of edges defined by a pair of nodes. Each node from represents a non-lexical concept of the conceptual model. Each edge from is built from the conceptual model as follows: the edge , exists if (i) there is an association between and in the conceptual model, and (ii) if the minimal multiplicity for the role , considering the existing association between and , is equal to 1. That means that the existence of the edge , represents the fact that is mandatory for expressing the semantics of .

For each ∈ , we define the function : → that gives the initial node of the edge and we define the function : → that gives the terminal node of the edge .

The figure 4 shows the semantic-relationships graph associated with the conceptual model of the figure 3.

Some Properties

Theorem 1. Given two particular concepts and , belongs to if and only if there exists a directed path from to .

Proof. Let us consider the conceptual model on figure 3. To build the semantic block of the concept , we consider this concept as the starting point. This concept can thus be considered as the root in the associated semantic-relationships graph. Now we add in all the concepts that must be instantiated to ensure the existence of a particular instance of , i.e. all the concepts such that there is an association between and in the conceptual model, and the minimal multiplicity for , considering this association, is equal to 1. This is the exact definition of all the successors of in the semantic-relationships graph. Note that, by definition, there is a directed path from the concept to these concepts . Iteratively, the only new concepts that can be added to are the successors of those first concepts . As successors of the concepts , there exists also a directed path from the concept to the concepts (the path from to plus the edge , ). Finally the semantic block of contains exactly all the concepts such that there exists a directed path from to . ∎ Theorem 2. Given two particular concepts and , if belongs to then is included in .

Proof. belongs to means that there exists a path from to (see theorem 1). Let us now consider a particular concept from denoted as . By definition of , there exists a path from to and then a path from to (the path from to plus the path from to ). That means that is in . Finally ⊆ . ∎ Theorem 3. All the concepts that are in the same cycle in the semantic-relationships graph are associated with the same unique semantic block.

Proof. A cycle is a closed path. Let us consider two particular concepts, denoted as and , which belong to a cycle. In particular there is a 3, 4, 6, 7 3, 4, 6, 7, 8

The semantic block architecture Meta-model

In this section, we propose to formalise the semantic block architecture by the meta-model represented on the figure 6. This meta-model uses the pattern composite (Gamma et al., 1995). The intent of this pattern is to compose the elements of the model into tree structures to represent partwhole hierarchies. In fact, each concept defined in a given context details its semantics and can be afterwards subsumed by a Semantic Block.

Besides, the semantics of a set of aggregated concepts could be defined by a Semantic Block.

Thus the Semantic Block properties emerge from the fact that those concepts are related to each others. Moreover, a Semantic Block could contain other blocks; this means that a given semantics could be subsumed by low level semantics. The "Block System" represents the last level of the Semantic Block aggregation, it could be interpreted as the semantics of the IS itself.

The automatic elaboration of semantic blocks

In this part, we present the tool prototype that automatically computes the semantic blocks for a given IS conceptual model. In fact the procedure presented in section 3.4 has been implemented into the MEGA EA Suite. The MEGA EA Suite provides repository-based modelling tools to support projects ranging from capability mapping, to process analysis and application analysis and design. Covering all layers and phases of Enterprise Architecture, all modules are integrated into a consistent end to end solution 5 . Moreover the MEGA EA Suite supports UML notations and allows building our own meta-model based on its ad-hoc meta-model. The meta-model presented on figure 6 has been implemented into the MEGA EA Suite. In this implementation, the semantic block is conceptualised as an UML package and the lexical and non-lexical concepts are conceptualised as UML classes.

The procedure presented in section 3.4 has been implemented taking advantage of MEGA programming facilities.

Figure 7 shows an extract of the result after computing the implemented algorithm on the conceptual model presented in figure 3. This figure shows the semantic block 2, 5 denoted as SB(2) (represented as an UML package) associated with 2 and 5 , and including the concept 8 . Figure 8 shows the sub-model formalising the semantics of 2, 5 . This sub-model is the extract of the complete conceptual model given on figure 3 by conserving only the concepts contained in 2, 5 and the associations concerning these concepts. In order to illustrate the proposed approach of ISs semantics enactment, we choose the following case study that consists of two ISs dealing with B2M interoperability requirement. These ISs have been provided by a local technical centre: the AIPL-PRIMECA 6 (Atelier Inter-établissements de Productique Lorrain) in which the ERP Sage X3 application is cooperating with the MES Flexnet application in order to insure the manufacturing of a certain family of products. In such industrial large scale Enterprise Information Systems, applications comprise a multitude of tables and relations. Flexnet (a MES application) has around 800 tables with 300 relations, once we conceptualise its model, we get about 600 concepts and 500 associations. SAGE X3 has around 1600 tables with 900 relations, and when it is conceptualised, 1200 concepts and 1000 associations can be highlighted.

Actually, a specified process has been chosen to support our research; it consists of the Raw Material Purchase. For instance, Figure 9 represents the conceptual model for the purchase order process related to Flexnet.

When considering the long term planning, the ERP computes, for a given period, its needs in term of raw materials and then launches some purchase orders. Hence, those purchase orders have to be exported from the ERP to the MES that have to bring backward the ERP with the stock state and the purchase order status.

Once we apply the fact-oriented modelling with the UML notation, the tool generates the normalised conceptual models of Flexnet on figure 10 and the conceptual model of Sage X3 on the figure 11.

In order to extract the semantics from MES and ERP conceptual models, we compute the implemented algorithm for Flexnet and Sage X3 conceptual model. Table 1 and 2 lists the different semantic blocks related to respectively Sage X3 and Flexnet applications, for purchase order process.

CONCLUSION

Semantics enactment among ISs conceptual models is a critical issue in the context of Enterprise Models. Indeed, extracting these semantics has the advantage to ease the understanding and then the use of the exchanged information among heterogeneous information systems (In single or distributed Enterprises)

We proposed in this paper the fact-oriented modelling to get a spread out representation for ISs conceptual models. This has allowed us to identify the Core and the extended Knowledge for a given IS, respectively composed by the mandatory and non mandatory concepts.

The originality of this paper lies on the elaboration of the semantic blocs for enacting Enterprise Models semantics embedded and, often hidden, in complex Information Systems models. Moreover, each semantic block identifies and emphasises the border of one sub-system model with its own core semantics. It focuses on "what is important" in the system without taking care on implementation artefacts.

INTRODUCTION

Nowadays, the need of systems collaboration across enterprises and through different domains has become more and more ubiquitous. But because the lack of standardized models or schemas, as well as semantic differences and inconsistencies problems, a series of research for data/model exchange, transformation, discovery and reuse are carried out in recent years. One of the main challenges in these researches is to overcome the gap among different data/model structures. Semantic annotation is not only just used for enriching the data/model's information, but also it can be one of the useful solutions for helping semi-automatic or even automatic systems interoperability.

Semantically annotating data/models can help to bridge the different knowledge representations. It can be used to discover matching between models elements, which helps information systems integration (Agt, et al., 2010). It can semantically enhance XML-Schemas' information, which supports XML documents transformation (Köpke and Eder, 2010). It can describe web services in a semantic network, which is used for further discovery and composition (Talantikite, et al., 2009). It can support system modellers in reusing process models, detecting cross-process relations, facilitating change management and knowledge transfer (Bron, et al., 2007). Semantic annotation can be widely used in many fields. It can link specific resources according to its domain ontologies.

The main contribution of this paper is identifying three main components of semantic annotation, gives a formal definition of semantic annotation and presenting a survey, based on the literature, of current semantic annotation methods that are applied for different purposes and domains. These annotation methods vary in their ontology (languages, tools and design), models and corresponding applications.

The remaining of this paper is organized as follows: Section 2 describes the definition of annotation and gives a formal definition of semantic annotations. Section 3 provides the answers to why and where to use semantic annotation. Section 4 first presents an introduction to ontologies and semantic annoation structure models, and then discusses the usage of semantic annotations. Section 5 concludes this paper, together with some related work and potential extensions.

WHAT IS SEMANTIC ANNOTATION?

In this section, we first illustrate the types of annotations from different papers (section 2.1), and then propose a formal definition of semantic annotation together with its three main components (section 2.2).

Definition and Types of annotation

In Oxford Dictionary Online7 , the word "annotation" is defined as "a note by way of explanation or comment added to a text or diagram". It is used to enrich target object's information, which can be in the forms of text descriptions, underlines, highlights, images, links, etc. Annotation has special meanings and usages in different fields. In software programming, an annotation is represented as text comments embedded in the code to expand the program, which is being ignored when the program is running. In mechanical drawing, an annotation is a snippet of text or symbols with specific meanings. In Library Management, an annotation is written in a set form (numbers, letters, etc.), which helps the classification of books.

Further, different annotation types are identified by the following papers : Bechhofer, et al. (2002) and Boudjlida, et al. (2006) distinguished annotation as (i) Textual annotation: adding notes and comments to objects; (ii) Link annotation: linking objects to a readable content; (iii) Semantic annotation: that consists of semantic information which is machine-readable. Similarly, three types of annotation are described in the research of Oren, et al. (2006): (i) Informal annotation: notes that are not machine-readable; (ii) Formal annotation: notes that are formally defined and machine-readable (but it does not use ontology terms); (iii) Ontological annotation: notes that use only formally defined ontological terms that are commonly accepted and understood. Bechhofer, et al. (2002) further classified the annotation according to six possible uses that are not always clear and disjoint: (a) Decoration, comments on an object; (b) Linking, link anchors; (c) Instances Identification, strong assert that an object is an instance of a particular class. It may use a URI; (d) Instance Reference, less clear than instance identification, reference depending on background and world knowledge; (e) Aboutness, loose association of the object with a concept; (f) Pertinence, assertions about the concepts within an ontology without encoding that information. can be further extended, including also some additional parameters or constraints c k , generally expressed using, in the worst case, natural language, or, better, a formal logical expression.

is then defined as ≔ , .

The main issue, related to mappings such as in (2) and in (3), is being able to measure the semantic gap (2) or the over semantic (3), brought by the semantic annotation. Such measures have been studied by researchers in the domain of information retrieval (Ellis, 1996) or in the domain of ontology matching (Maedche and Staab, 2002), mapping (Doan et al, 2002), merging [START_REF] Stumme | FCA-MERGE: Bottom-Up Merging of Ontologies[END_REF], alignment (Noy and Musen, 2000).

In addition, Peng, et al. (2004) also gave a very simple definition of semantic annotation in their paper, which is ∶ , , where is set of resources and is an ontology. Furthermore, Luong and Dieng-Kuntz (2007) defined it as ∶ , , , , . In this definition, is a set of resources; is a set of concept names; is a set of property names; L is a set of literal values; and is a set of triple , , , where ∈ , ∈ , ∈ ⋃ . To the best of our knowledge, in this definition is duplicated.

WHY, WHERE TO USE SEMANTIC ANNOTATION

A semantic annotation uses ontology objects for enriching resource's information that tells a computer the meanings and relations of the data terms. It can be used in many areas, such as Business Process Models, Web services, XML Schema, Strategic Data Models, Information Systems, etc. Several usages of semantic annotation are introduced:

Business Process Models: In the research of Lin ( 2008), a semantic annotation framework is designed to manage the semantic heterogeneity of process model, to solve the discovery and sharing of process models problems in/between enterprise(s). Born, et al. (2007) used semantic description of process artefacts to help a modeller in graphical modelling of business processes.

Web Services: Talantikite, et al. (2009) used a semantic annotation to represent web services as a semantic network. Based on the network and submitted requests, the composition algorithm produces the best composition plan. Patil, et al. (2004) proposed an annotation framework for semi-automatically marking up web service descriptions (WSDL files) with domain ontologies to help web services discovery and composition.

XML Schema:

In the research of Köpke and Eder (2010), a path expression method is used to add annotation to XML-Schemas. Then they transform paths to ontology concepts and use them to create XML-Schema mappings that help XML document transformation.

Strategic Data Models: Diamantini and Potena (2008) presented a novel model that uses a mathematical ontology in semantic annotation to describe mathematical formulas in Data Warehouse schemas.

Information System: Agt, et al. (2010) used semantic annotations to help information system integration. They annotate the model/object at CIM (Computation Independent Model), PIM (Platform Independent Model) and PSM (Platform Specific Model) levels of the MDA approach (Mellor, et al. 2002;2004), and then they discover some matching between model elements with respect to semantic process requirements.

In short, semantic annotation can be considered as a semantically enrichment of models or data, which may be widely used for many purposes. In business process models and Information system, it can be used to bridge the gap between two models. In Web service and Strategic Date Models, it can be used as additional information that helps description, discovery and composition. To the best of our knowledge, the path expression method in XML Schema will lead to lose information in Schema (e.g. restrictions of max-occur/min-occur, sequence or choice of elements, etc.), which still needs to be improved.

HOW TO USE SEMANTIC ANNOTATION

In this section, we present an introduction to the three main components of semantic annotation: the languages and tools which can be used in designing ontology; semantic annotation model's structure and mappings; and the applications of semantic annotation.

Introduction to Ontology

Designing an appropriate ontology for semantic annotations is the first step of the annotation process. Ontology has been actively studied for a long period of time, and there are many research works proposing ontology engineering techniques. We are not going to give, here, a complete overview of every ontology languages, but we provide a brief introduction to the three more representative languages. We will show also some simple examples and typical development tools.

Ontolingua was developed by KSL (Knowledge Systems Lab, Stanford University) (Fikes, et al, 1997). It is an extension of KIF 8 (Knowledge Interchange Format) through adding frame-based representation and translation functionalities. But because of the newly development of semantic web ontology, Ontolingua is not frequently used recently. Figure 2-a) shows a simple Ontolingua example from Mizoguchi (2003). Ontolingua Server 9 provides an editor, which can be used to browse, create, edit, modify, and use Ontolingua ontologies.

F-Logic was presented by Michael Kifer (Stony Brook University) and Georg Lausen (University of Mannheim) (Kifer and Lausen, 1995). It is an object-oriented language that is frequently used for Semantic Web. It also can map straightforward to most frequent ontological constructs. Figure 2-b) shows a simple F-logic example from Liao, et al. (2010). Flora2 10 is an F-logic ontology development application, which extends F-logic with HiLog and Transaction Logic.

OWL (Web Ontology Language) was developed by World Wide Web Consortium, which shares many characteristics with RDF 11 (Resource Description Framework) and RDF Schema (Horrocks, et al., 2003). It is written using the XML syntax, and contains three sublanguages: OWL Lite, OWL DL and OWL Full. OWL is considered as a standard language for ontology representation for semantic web. Figure 2-c) shows a simple OWL example from OWL Guide 12 . Protégé 13 ontology editor is a Java-based tool that can export ontology into formats such as OWL, RDF and XML Schema. OntoStudio 14 supports the modelling of RDF(S), OWL and Object-Logic with possible transformation between them. The design methods of ontology for annotations have their own purposes and structures. Lin (2008) used Protégé OWL editor to design the ontology. In order to separately annotate meta-models (modelling language) and their process models, the author designs two ontologies: General Process Ontology (GPO) and Domain Ontology. The design of GPO is based on Bunge-Wand-Weber (BWW) Ontology (Bunge 1977;Wand and Weber, 1993). GPO contains nine main concepts: Activity, Artifact, Actor-role, Input, Output, Precondition, Postcondition, Exception and WorkflowPattern. Relations between above concepts are has_actorrole, has_artifact, has_subActiviy, has_input, has_output, related_to, has_precondition, has_postcondition, has_exception, handled_by (e.g Born, et al. (2007) used two kinds of ontologies: sBPMN 16 ontology and a domain ontology. The first ontology is used to represent BPMN process models. The second ontology defines domain objects, states and actions according to objects lifecycle, which is used to provide the user advices during the modelling process. More details of above ontologies can be found in references.

The second component of a semantic annotation is SASM. It is the connection between electronic resources and ontology concepts. A study in this direction is pursued by SAWSDL Working Group 17 that developed SAWSDL (Semantic Annotation for Web Services Definition Language) which provides two kinds of extension attributes as follow: (i) modelReference, to describe the association between a WSDL or XML Schema component and a semantic model concept; (ii) liftingSchemaMapping and loweringSchema-Mapping, to specify the mappings between semantic data and XML (Martin, et al., 2007;Kopecký, et al. 2007).

To be more specific, we analyse four SASMs that are designed for different requirements. Figure 3 below gives an overview of these four SASMs: Model A is the annotation schema for enterprise models from Boudjlida and Panetto (2007); Model B is designed to annotate the business process model from Born, et al. (2007); Model C is proposed to conceptually represent a web service from Talantikite, et al. (2009); and Model D is the annotation model for an activity element which is part of the Process Semantic Annotation Model (PSAM) from Lin (2008).

In order to compare above semantic annotation structure models, we identify five types for classifying the contents in SASM:

(1) identity of annotation (e.g. id, name, etc.);

(2) reference to ontology concept (e.g. element Customer has a reference "same_as" which is referenced to ontology concept Buyer); (3) reference to element (represent the relationship between element themselves. e.g. element manufacture has a reference "has_input" which is referenced to element material); (4) text description, the natural language definitions of annotation contents; ( 5) others (extinction contents, such as: execution time, restriction, annotation types, etc.). The classification results of each SASM are described by linking model contents to type numbers

We can easily find that the basic components of SASMs are: identity of annotation and reference to ontology concepts; reference to element, text description and others are added for different usages. As an example, Lin (2008) adds "has_Actor-role" to denote the relationship between activity element and actor-role element; Boudjlida and Panetto (2007) added "Informal Content" for explaining the intent of the annotation; Talantikite, et al. (2009) added "exec-time" into SASM to record the execution time of a web service request. In the rest of this section, the discussion is focused on the design of reference to ontology concepts. As can be seen from above figure, reference to ontology concepts in model A is just a conceptual reference without meanings. Model B describes the references with meaning of states of objects (current, before and after). Model C uses inputs and outputs to represent the relationships. Model D gives more meanings to references like same_as, kind_of, phase_of, etc. Further, one to one mapping is not the only mapping type in SASM. For example, in Model C, there can be more than one input, which means the mapping between model content and ontology concept is one to many. Here, we analyses "reference to ontology concepts" according to mapping types and definitions of mappings.

Mappings are separated into two levels in the research of Lin (2008) 2 shows the comparison and classification of the mappings from Agt, et al. (2010) and Lin (2008). In order to classify those mappings, we assume the mapping direction in the table is from a model element to an ontology concept. In our opinions, there are three high level mapping types: 1 to 1 mapping, 1 to n mapping and n to 1 mapping (n to n is a combination of 1 to n and n to 1). For each of the mapping, we can design different semantic relationships for further usages. Figure 4 shows the mapping types and semantic relationships for each kind of mapping. 1 to 1 means one element is annotated by one ontology concept. Semantic relationships can be: equal_to, similar_to, etc. 1 to n means one element is annotated by the composition/aggregation of several ontology concepts. Semantic relationships can be: contains, has, etc. n to 1 means the composition/aggregation of several elements are annotated by one ontology concept. Semantic relationships can be: part_of, member_of, etc. One element can have several semantic relationships, but for each relationship, they belong to one mapping type.

Fig. 4. Mapping types and semantic relationships

Since the structure and semantic relationships of SASM are designed, we should consider how to implement the annotation process. The annotation process can be performed manually, semi-automatically or automatically (Reeve and Han, 2005). In the research of Lin (2008), mapping is manually linking the process models to ontology. In the work of Patil, et al. (2004), mapping is semi-automatically computed. They developed algorithms to match and annotate WSDL files with relevant ontologies. Automatic mapping is, for the moment, restricted to some simple cases because of the impossibility to completely explicit knowledge from the different models.

Introduction to Application

Once the semantic annotation structure model is defined, designers can begin to design the application to achieve their purpose (composition, sharing and reuse, integration, etc.). Several applications of semantic annotation are introduced as follow: Talantikite, et al. (2008) designed an application, which uses a matching algorithm to process the "input" and "output" (SASM model C, Figure 3) of elements, and builds a semantic network for web services. This semantic network is explored by a composition algorithm, which automatically finds a composite service to satisfy the request. Authors implement a prototype in java, which includes: Pellet 18 Reasoner (matching algorithm), RSsw (Réseau Sémantique des Services Web), Request and Composor (returns an optimal composite service for requesters).

Lin (2008) developed a prototype Process Semantic Annotation tool (Pro-SEAT) to describe the relationship between process models and ontologies. They use Metis 19 as a modelling environment integrating Protégé OWL API to provide the OWL ontology browser. Ontologies (GPO, Domain ontology, etc.) are stored on an ontology server, which can be loaded by annotators. The output of the annotation is an OWL instance file, which is used by a knowledge repository service to support the process knowledge query, discovery and navigation from users. Born, et al. (2007) used Tensegrity Graph Framework 20 as environment to support graphical design functions. Name-base and Process Context-base matchmaking functionalities are designed to help user annotating process models. Name-base matching uses string distance metrics method for the matching between business process models and domain ontology, and it supports the user for specifying or refining the process. Process Contextbase matching uses the lifecycle (state before, state after, etc.) in domain ontology for suggesting the next activity during modelling.

Indeed, there are many tools and technologies that enable designing applications in semantic annotation. The selections of tools are always depending on the design of semantic annotation structure models and ontologies.

In any case, all three components of semantic annotation are closely related

CONCLUSIONS

In this paper, a brief survey of semantic annotation in different domains is presented. We identify three main components of semantic annotations that are Ontology, Semantic Annotation Structure Model and Application.

In addition, a formal definition of semantic annotation is proposed. semantic annotation is and then contributes to a common reference model. But how to use semantic annotation? There are still many problems can be further discussed during the annotation process. For example, how to optimize ontology and an annotated model? How to solve the inconsistency or conflicts during the mapping? How to add consistent semantic on models in different levels of a system? How to achieve semi-automatic or automatic annotation?

We are currently investigating how semantic annotations can help collaborative actors (organizations, design teams, system developers, etc.) in co-designing, sharing, exchanging, aligning and transforming models. In particular, this research work will be based on general systems with several kinds of interactions. We can have interoperation between systems that with different versions (during many years, systems may have been modified or updated). We can also have systems with same functions but used by different enterprises. Semantic annotations can bridge this knowledge gap and identify differences in models, in schemas, etc. In some case, interoperation is a process between a set of related systems throughout a product lifecycle (Marketing, Design, Manufacture, Service, etc.), and semantic annotations can influence the existing foundations and techniques which supports models reuse, semantic alignment and transformation, etc. Above all, our research work will focus on designing, and reusing appropriate ontologies in relationship with a formal semantic annotation structure model.

Figure 1 -

 1 Figure 1 -Conceptualisation process

Figure 5 -

 5 Figure5-"Fact-oriented modelling" transformation of the model of Figure4

Figure 6 - 5 Theorem 1 .

 651 Figure 6 -Semantic-dependency graph associated with the conceptual model of Figure 5

Theorem 3 .

 3 directed path from c to c . ∎ Theorem 2. Given two particular concepts c and c , if c belongs to SB c then SB c is included in SB c . Proof. c belongs to SB c means that there exists a path from c to c (see theorem 1). Let us now consider a particular concept from SB c denoted as c . By definition of SB c , there exists a path from c to c and then a path from c to c (the path from c to c plus the path from c to c). That means that c is in SB c . Finally SB c ⊆ SB c . ∎ All the concepts that are in the same cycle in the semantic-dependency graph are associated with the same unique semantic block. Proof. A cycle is a closed path. Let us consider two particular concepts, denoted as c and c , which belong to a cycle. In particular there is a path from c to c . That means that c is in SB c . Following the theorem 2, we can also demonstrate that SB c ⊆ SB c . Moreover, there is a path from c to c . That means that c is in SB c . Following the theorem 2, that means that SB c ⊇ SB c . Finally, SB c SB c . ∎

Figure 7 -

 7 Figure 7 -Graph of the strongly connected components related to the graph of Figure 6

  contains the mandatory lexical concepts associated to the nonlexical concepts in . By applying the definition of ∈ on the instance of Figure5we obtain:

  Yahia E.,Lezoche M., Aubry A., Panetto H., (2011). Semantics enactment in Enterprise Information Systems, IFAC. 18th IFAC World Congress, IFACWC'2011, Aug 2011, Milan, Italy. Elsevier -IFACPapersOnline, 18, 13064-13073 5 Case Study Interoperability between organisational and manufacturing activities is crucial in manufacturing enterprises. Production services have to produce, quickly and efficiently, the right volume of the right product at the right moment. For this reason, they need real time information coming from others services, which need in return a precise and updated data on production. We propose here to study and present the first part of such a B2M interoperability issue by considering Sage X3 as an Enterprise Resource Planning (ERP)

Figure 8 -

 8 Figure 8 -Enriched Sage X3 manufacturing order process model

Figure 9 -

 9 Figure 9 -Sage X3 architecture and expert knowledge injection

Figure 10 -

 10 Figure 10 -Sage X3 manufacturing order process model -fact-oriented version

Figure 11 - 1 )Figure 12 .Figure 12 -Figure 13 -

 111121213 Figure 11 -Enriched fact-oriented model of the purchase order process in Flexnet application

Figure 14 -Figure 15 -Flexnet

 1415 Figure 14 -The computed semantic blocks related to Flexnet MES

  Formally,: 〈 , 〉| and represents the set of relationships between an element of the set of electronic knowledge and an element of the powerset of the ontology set .

Figure 17 -

 17 Figure 17 -Semantic annotation structure model metamodel

  Formally a class C corresponds to a FOL unary predicate C. An attribute a of type T for a class C associates to each instance of C a set of instance of T, its multiplicity [i..j] specifies that a associates to each instance of C at least i and at most j instances of T. Formally, an attribute a of type T for class C corresponds to a binary predicate. An association in UML is a relation between the instances of two or more classes. The multiplicity [m..n] attached to the role of a binary association specifies that each instance of the class C can participate at least m times and at most n times

Figure 2 -

 2 Figure 2 -Sage X3 work order enriched process model

Figure 3 -

 3 Figure 3 -Sage X3 architecture and expert knowledge injection

Figure 4 -

 4 Figure 4 -Sage X3 work order process model part transformed with fact-oriented approach



  lexical: being able to segment the representation in words (or symbols);  syntactic: being able to structure the representation in structured sentences (or formulas or assertions);  semantic: being able to construct the propositional meaning of the representation;

Figure 19 -

 19 Figure 19 -Sage X3 work order enriched process model

Figure 4 -

 4 Figure 4 -Sage X3 work order process model part transformed with factoriented approach

Fig. 1 .

 1 Fig. 1. Two extracts of conceptual models.

Definition 4 .

 4 Multiplicity is defined as Multiplicity = {*, 0..1, 1, 1..*} and serves to count the minimum and maximum number of instances when linking two given entities from the IS conceptual model. For each , . * and it is read is related to with a multiplicity ∈ * ,0. .1,1,1. . * .

Fig. 3 .

 3 Fig. 3. A conceptual modelA given instance of the concept 1 exists only if it is associated with exactly one instance of the concept 3 and at least one instance of the concept 2 . That means that 2 and 3 are mandatory for expressing the semantics of 1 . Moreover an instance of 3 exists only if it is associated with at least one instance of 4 and at least one instance of 6. On the contrary, as the

Fig. 4 .

 4 Fig. 4. Semantic-relationships graph associated with the conceptual model of figure 3.

Fig. 6 .

 6 Fig. 6. The semantic block architecture meta-model

Fig. 7 . 3 Fig. 8 .

 738 Fig. 7. The semantic block 2, 5 for the conceptual model of figure 3

  6 AIPL-PRIMECA, www.aip-primeca.net/lorraine/

Fig. 10 .FACIFig. 11 .

 1011 Fig. 10. The conceptual model of a purchase order in Flexnet application: fact-oriented model

Fig. 2 .

 2 Fig. 2. Examples of Ontolingua (a), F-logic (b) and OWL (c).

Fig. 3 .

 3 Fig. 3. Semantic Annotation Structure Model Examples.

Table 1 -Fact-Oriented modelling patterns using UML notation

 1

Table 2

 2

	lists the different semantic blocks	related to Flexnet application after applying
	algorithm 1 (BuildSemBlocks) to the graph of the strongly connected components on Figure
	13.
		Concepts
	WAREHOUSE	WAREHOUSE, FACILITY
	ORDER_PARTNER	ORDER_PARTNER, PARTNER
	PARTNER_ADDRESS	PARTNER_ADDRESS, PARTNER
	PARTNER	PARTNER

Table 2 -Semantic Blocks of Flexnet MES 4) Computing, for each , the related semantic block

 2

Table 3

 3

	lists the different semantic blocks	related to Flexnet application.
		Concepts
	WAREHOUSE	WarehouseName, FacilityName, Division
	ORDER_PARTNER	PartnerOrderNo, PartnerOrderType, PartnerName
	PARTNER_ADDRESS	AdressDetail, PartnerName
	PARTNER	PartnerName

Table 3 -Semantic Blocks of Flexnet MES 5) Computing ∪Table 4

 34 lists the different semantic blocks related to Flexnet application.

	Concepts

Table 4 -Semantic Blocks of Flexnet MES The

 4 procedure presented in section 4.5 has been implemented in the MEGA Suite environment. MEGA Suite supports UML notations and allows building our own metamodel based on its ad-hoc MOF 2 meta-model. The meta-model presented on Figure3 has

been implemented in the MEGA Suite. In this implementation, the semantic block is conceptualised as a UML package and the lexical and non-lexical concepts are conceptualised as UML classes. The procedure presented in section 4.5 has been implemented taking advantage of MEGA programming facilities.

  . Why, Where and How to use

	Semantic Annotation for Systems Interoperability, 1st UNITE Doctoral
	Symposium, Jun 2011, Bucarest, Romania. pp. 71-78

Liao Y.,

[START_REF] Liao | Why, Where and How to use Semantic Annotation for Systems Interoperability[END_REF]

. Semantic Annotation Model Definition for Systems Interoperability, OTM. OTM 2011 Workshops 2011 -6th International Workshop on Enterprise Integration, Interoperability and Networking (EI2N), Oct 2011, Hersonissos, Crete, Greece. Springer-Verlag, LNCS 7046, pp. 61-70, Lecture Notes in Computer Science

  . Ontology-based supply chain process configuration, University of Nis. 34th International Conference on Production Engineering, ICPE 2011, Sep 2011, Nis, Serbia. pp. 399-402

	Liao Y., Lezoche M., Panetto H., Boudjlida N., (2011). Semantic Annotation Model
	Definition for Systems Interoperability, OTM. OTM 2011 Workshops 2011 -6th
	International Workshop on Enterprise Integration, Interoperability and Networking
	(EI2N), Oct 2011, Hersonissos, Crete, Greece. Springer-Verlag, LNCS 7046, pp. 61-
	70, Lecture Notes in Computer Science
	Présentation without peer reviewing (1)

Yahia E.,

Lezoche M., Aubry A., Panetto H., (2011)

. Extraction de la sémantique dans les modèles de systèmes d'information d'entreprises collaboratifs, Journée Nationale du GT Easy-DIM, Apr 2011, Lyon, France.

Table 5 -Fact-Oriented modelling patterns using UML notation related

 5

	Its formalisation in FOL assertions is the
	following:
	∀ , ,	∧	,	⊃
	∀ , ,	∧	,	⊃

association. An association A between two classes can be formalised as a binary predicate. In the studied pattern, we formalise a class C 1 containing two attributes A 1 and A 2 with respectively a multiplicity of 1 and [0..1], and with associated types respectively, A 1 Type and A 2 Type.

Table 2 . Flexnet semantic blocks

 2

	Semantic Block	Concepts
	Block system 2	All the concepts
	B 2 (WAREHOUSE)	WAREHOUSE,
		WarehouseID,
		FACILITY, FacilityID,
		Division
	B 2 (ORDER_PARTNER)	ORDER_PARTNER,
		PartnerOrderNo,
		PartnerOrderType,
		PARTNER, PartnerID
	B 2 (PARTNER_ADDRESS)	PARTNER_ADDRESS,
		AdressID, PARTNER,
		PartnerID
	B 2 (PARTNER)	PARTNER, PartnerID
	B 2 (WIP_ORDER,	WIP_ORDER,
	ORDER_DETAIL,	WipOrderNo,
	ORDER_HEADER,	CreatedOn,
	WIP_ORDER_TYPE)	OrderQuantity,
		WIP_ORDER_TYPE,
		WipOrderType,
		ORDER_DETAIL,
		OrderLineNo,
		CreatedOn,
		ORDER_HEADER,
		OrderDate,	OrderNo,
		WIP_ORDER_STATUS
		,	WipOrderStatus,
		PROCESS, ProcessId,
		ProcessDescription,
		FUID,	FACILITY,
		FacilityId,	Division,
		PRODUCT,
		LotTrackingCode,
		ProductId, ProductNo,
		RevisionControlFlag,
		SerialTrackingCode,
		UOM,	UOMCode,
		ORDER_STATUS,

  8 http://www-ksl.stanford.edu/knowledge-sharing/kif/ 9 http://www.ksl.stanford.edu/software/ontolingua/ 10 http://flora.sourceforge.net/ 11 http://www.w3.org/RDF/ 12 http://www.w3.org/TR/2004/REC-owl-guide-20040210/ 13 http://protege.stanford.edu/ 14 http://www.ontoprise.de/en/products/ontostudio/

  . Activity uses has_actor-role relation to link Actor-role). The Domain ontology is formalized according to SCOR 15 specifications (Supply Chain Operations Reference-model).Agt, et al. (2010) designed a semantic meta-model (SMM) to describe domain ontologies. Artefacts in ontology are castigated as DomainFunction and DomainObject. The relations (predicates) among Objects and Functions are defined as: IsA, IsInputOf, IsOutputOf, Has, IsListOf, IsEquivalentTo, etc. A RDF-like triple (e.g., Tax Has TaxNumber) is used as the statement in SMM.

  : meta-model level and model level. In the meta-model level, mapping direction is from ontology to model contents. The mappings are defined as: Atomic Construct (one to one. e.g. Activity is mapped to Task), Enumerated Construct (one to many. e.g. Artifact is mapped to Information or Material) and Composed Construct (one to combination. e.g. Workflow Pattern is mapped to a combination of Flow and Decision Point). In model level, semantic relationships are: Synonym (same_as, alternative_name), Polysemy (different_from), Instance (instance_of), Hyponym (superConcept_of), Meronym (part_of, member_of, phase_of and partial Effect_of), Holonym (composition Concept_of) and Hypernym (kind_of). (e.g. Meronym: Airline member_of Air Alliance).Agt, et al. (2010) described five mapping types in their work: single representation (one model element to one ontology concept), containment (one model element to multiple ontology concepts), compositions (multiple model elements to one ontology concepts), multiple and alternative representation (the mappings with AND and OR/XOR operators). Table

Table . 1

 . . Mappings from Model to Ontology

	Types	Lin (2008)	Lin (2008)	Agt, et al.(2010)
	1 to 1	Atomic Construct	Instance	Single represent
			Synonym
			Polysemy Hyponym
			Hypernym
	1 to n			Containment,
				Multiple
				Alternative
	n to 1	Enumerated	Meronym	Composition
		Construct Composed Construct	Holonym

  It contributes to better understand what a 18 http://clarkparsia.com/pellet/ 19 http://www.troux.com/ 20 http://www.tensegrity-software.com/

		1 to 1			n to 1
	Identity	①	ID	FirstName	③	Name
		1 to n		LastName	③
		②	City	Semantic Relationships
	Address			①equal_to
		②	Stree	②contains ③part_of

OMG's MetaObject Facility: http://www.omg.org/mof/

http://oxforddictionaries.com

http://www.bpmn.org

http://oxforddictionaries.com

We illustrate the semantics blocks identification in a use case based on existing B2M applications: the ERP Sage X3 and the MES Flexnet enterprise software applications, which have to interoperate in order to achieve a global process performance.

Future work aims at using the semantic blocks formalisation in order to facilitate models matching and concepts mapping when formalise and evaluate the interoperability process between enterprise applications in a virtual networked enterprises environment.

Appendix

In the appendix will be presented a selection of the published papers.

Appendix A:

Lezoche M., Panetto H., Aubry A., (2011). Conceptualisation approach for cooperative information systems interoperability, ACM. 13th International Conference on Enterprise Information Systems, ICEIS 2011, Jun 2011, Beijing, China. pp. 101-110 Appendix B: Lezoche M., Panetto H., Aubry A., (2011). Formal Fact-Oriented model transformations for cooperative information systems semantic conceptualisation, Selected extended version of ICEIS 2011. Lecture Notes in Business Information Processing (LNBIP),

Proof read

Appendix C: Yahia E., Lezoche M., Aubry A., Panetto H., (2011). Semantics enactment in Enterprise Information Systems, IFAC. 18th IFAC World Congress, IFAC WC'2011, Aug 2011, Milan, Italy. Elsevier -IFACPapersOnline, 18, 13064-13073, IFACPapersOnline Appendix D: Liao Y., [START_REF] Liao | Why, Where and How to use Semantic Annotation for Systems Interoperability[END_REF] Research Centre for Automatic Control (CRAN), CNRS,Campus Scientifique,Faculté des Sciences et Techniques,BP 70239,Mario.Lezoche,Alexis.Aubry, Abstract: The grown complexity of the modern enterprise poses a series of challenges, among them keeping competitiveness in the fast changing environment in which the enterprise evolves. Addressing Enterprise Integration is considered as a key to achieve the goal of any enterprise either it is a single or a networked enterprise. Enterprise Modelling is a prerequisite to enable the common understanding of the enterprises and its various interactions in order to "provide the right information, at the right time, at the right place". However, problems often emerge from a lack of understanding of the semantics of the elaborated models resulting from various modelling experience based on different methods and tools. In this paper, we describe the challenges associated to semantics enactment in Information Systems models. To facilitate this enactment, we propose an approach based on a factoriented modelling perspective. Then, we also provide an algorithm to automatically build semantic aggregates that help in highlighting Enterprise Models core embedded semantics. A case study on the field of B2M interoperability is performed in order to illustrate the application of the presented approach. path from to . That means that is in . Following the theorem 2, we can also demonstrate that ⊆ . Moreover, there is a path from to . That means that is in . Following the theorem 2, that means that ⊇ . Finally, . ∎

For each cycle of the semantic-relationships graph, the theorem 3 implies that there is one shared semantic block associated with all the concepts that are in the same cycle, i.e. a strongly connected component of the semantic-relationships graph.

Thus there is one semantic block per strongly connected component of the semantic-relationships graph.

Building the semantic blocks

Applying the theorems 1 to 3, we propose the following procedure to build all the semantic blocks of a given conceptual model:

Building the associated semantic-relationships graph, based on this associated semanticrelationships graph, building the graph of the strongly connected components, And finally, building the semantic block associated with each strongly connected component.

Building the associated semanticrelationships graph

Following theorem 1, the semantic block of a concept contains all the concepts ′ such that it exists a directed path from to ′ in the associated semantic-relationships graph. This graph can be easily obtained by considering each association between two concepts and and then building an edge from to if the minimal multiplicity for is equal to 1.

Building the graph of the strongly connected components

Theorem 3 implies that for building the semantic blocks, we can consider only one concept in a given strongly connected component (the other concepts have the same semantic block), that is the reason why we can simplify the semanticrelationships graph by considering only a graph where the nodes are the strongly connected components of the semantic-relationships graph and where an edge from one strongly connected component 1 to a second strongly connected component 2 exists if there exists at least one edge from a concept from 1 to a concept from 2.

Identifying all the strongly connected components of a graph is an easy problem that can be solved with polynomial effort by using Kosaraju-Sharir's algorithm (Sharir, 1981).

The graph of the strongly connected components associated with the semantic-relationships graph of figure 4 is given on figure 5. On this graph, the strongly connected components are defined as follows 1 1 , 2 2, 5 , 3 3, 4, 6, 7 and 4 8 .

Building the semantic block associated with each strongly connected component

We propose now a set of 2 algorithms to build all the semantic blocks associated with each strongly connected component (see Algo 1 and 2). The algorithm BuildSemBlocks is applied on the graph of the strongly connected components (denoted as ).

Let us apply the algorithm on the graph of figure 4. We obtain the following semantic blocks:

.

And finally replacing the strongly connected components by their content we obtain the following semantic blocks: Figure 13 shows the conceptual model associated to the semantic block , and including all the mandatory concepts required to obtain the full semantics for the concept . Abstract: Semantic annotation is one of the useful solutions to enrich target's (systems, models, metamodels, etc.) information. There are some papers which use semantic enrichment for different purposes (integration, composition, sharing and reuse, etc.) in several domains, but none of them provides a complete process of how to use semantic annotations. This paper identifies three main components of semantic annotation, gives a formal definition of semantic annotation method and presents a survey of current semantic annotation methods which include: languages and tools that can be used to develop ontology, the design of semantic annotation structure models and the corresponding applications. The survey presented in this paper will be the basis of our future research on models, semantics and architecture for systems interoperability.

Keywords: Semantic Annotation, Models, Ontology, Systems Interoperability. According to the above classification, semantic annotation can be considered as a kind of formal metadata, which is machine and human readable. This will be further discussed in the following sections.

Semantic annotation

The term "Semantic Annotation" is described as "the action and results of describing (part of) an electronic resource by means of metadata whose meaning is formally specified in an ontology" (electronic resource can be text contents, images, video, services, etc.) by Fernández (2010). Talantikite, et al. (2009) introduced it as "An annotation assigns to an entity, which is in the text, a link to its semantic description. A semantic annotation is referent to an ontology". In the research of Lin (2008), semantic annotation is concerned as "an approach to link ontologies to the original information sources". All above definitions from different papers show one thing in common: a semantic annotation is the process of linking electronic resource to a specific ontology. Ontology here is only one of the possible means to provide a formal semantic.

As it can be seen on Figure 1, the left side represents an Electronic Resource (ER) and on the right side, there are the three main components of semantic annotation: (1) Ontology, which defines the terms used to describe and represent a body of knowledge (Boyce, et al., 2007). It can be reused from existing ontologies or designed according to different requirements.

(2) Semantic Annotation Structure Model (SASM), which organizes the structure/schema of an annotation and describes the mappings between electronic resources and an ontology. ( 3) Application, which is designed to achieve the user's purposes (composition, sharing and reuse, integration, etc.) by using SASM. This figure also shows the three main steps on how to use semantic annotation, which is introduced in section 4: ontology (section 4.1), semantic annotation structure model (section 4.2) and application (section 4.3).

Fig. 1. Semantic Annotation components

The following definition formally defines a semantic annotation: a Semantic Annotation is a tuple , consisting of the SASM and an application . ∶ , , Where:

, , … , , is the set of ontology that bring some meaning to any annotated element.

An Ontology is a 4-tuple ( , is_a, , ), where is a set of concepts, is_a is a partial order relation on , is a set of relation names, and : → is a function which defines each relation name with its arity (Stumme and Maedche, 2001a).

Formally,

: 〈 , 〉| and represents the set of relationships between an element of the set of electronic resources and an element of the powerset of the ontology set .

A mapping

, may represent three different kinds of semantic relations: (4) ∼ , is a binary equivalence relation. If ∼ , then an electronic resource is semantically equivalent to , an element of the powerset , in the context of an application . (5) ⊃ , is a binary relation stating that the semantic of an electronic resource subsumes the semantic of an element of the powerset , in the context of an application . ( 6) ⊂ , : is a binary relation stating that the semantic of an electronic resource is subsumed by the semantic of an element of the powerset , in the context of an application .