Transformation of Enterprise Model to Enterprise Ontology

105
Transformation of Enterprise Model to Enterprise Ontology Nadeem Ahmed Khan MASTER THESIS 2011 INFORMATICS

Transcript of Transformation of Enterprise Model to Enterprise Ontology

  • Transformation of Enterprise Model to Enterprise Ontology

    Nadeem Ahmed Khan

    MASTER THESIS 2011 INFORMATICS

  • Postadress: Besksadress: Telefon: Box 1026 Gjuterigatan 5 036-10 10 00 (vx) 551 11 Jnkping

    Transformation of Enterprise Model to Enterprise Ontology

    Nadeem Ahmed Khan

    Detta examensarbete r utfrt vid Tekniska Hgskolan i Jnkping inom mnesomrdet informatik. Arbetet r ett led i masterutbildningen med inriktning informationsteknik och management.Frfattarna svarar sjlva fr framfrda sikter, slutsatser och resultat. Handledare: Kurt Sandkuhl, Lin Feiyu, Anders Carstensen Examinator: Vladimir Tarasov Omfattning: 30 hp (D-niv) Datum: Arkiveringsnummer:

  • Abstract

    i

    Abstract

    Enterprise models are usually developed with ambition to capture the current or desired situation in enterprises with respect to performed or planned processes, organizational structure (including organization units, roles and competences), products or services produced and IT systems available in the enterprise.The above aspects are mutually reflective. Such enterprise models are often represented in formal modeling languages, like UEML (Unified Enterprise Modeling Language) or GEM (General Entity Manipulator) language allowing for the development of applications, which interprets or compute them.

    Enterprise ontologies basically allow the representation of the same aspects of an enterprise (processes, organizational structure, products and systems). However, enterprise ontologies use another representation (like OWL- Web Ontology Language) and often are developed for other application purposes than enterprise model.

    The objective of this thesis is to develop strategies for transforming enterprise models into enterprise ontologies. There should be maximum preservation of semantics and minimum loss of information during the process of transformation. On the basis of meta-model (model to model) transformation, we propose three elements mapping approaches. Each approach has a number of elements mapping rules. After comparative study the best suitable approach according to objective of this thesis is selected for implementation purpose. From a technical perspective, a tool named EM2EO is developed, which accepts an enterprise model as input and produces ontology as output.

  • Sammanfattning

    ii

    Sammanfattning

    Enterprise modeller utvecklas vanligen med ambitionen att fnga den nuvarande eller nskade situationen i fretag med avseende p utfrda eller planerade processer, organisatoriska struktur (inklusive organisation enheter, roller och befogenheter), produkter eller producerade tjnster och IT-system som finns i fretaget. Ovanstende aspekter r msesidigt reflekterande. Sdana fretag modeller r ofta representerade i formella modellering sprk, som UEML (Unified Enterprise ModelingLanguage) eller GEM (generell entitet Manipulator) sprk som mjliggr utvecklingen av tillmpningar, som tolkar eller berkna dem.

    Enterprise ontologier tillter i princip tergivningen av samma aspekter i ett fretag (processer, organisation, produkter och system). Men fretaget ontologier anvnda en annan representation (som OWL-Web OntologyLanguage) och ofta r utvecklade fr andra ndaml ndaml n fretagets modell.

    Syftet med denna avhandling r att utveckla strategier fr att omvandla fretaget modeller i fretagspolitiken ontologier. Det br vara max bevara semantik och minimal frlust av information under omvandlingsprocessen. P grundval av meta-modell (modell till modell) omvandling, freslr vi tre delar kartlggning strategier. Varje metod har ett antal faktorer kartlggning regler. Efter jmfrande studie bsta lmpliga metoden enligt syftet med denna avhandling har valts fr genomfrandet ndaml. Ur ett tekniskt perspektiv, ett verktyg som heter "EM2EO" utvecklas, som accepterar ett fretag modell som indata och producerar ontologi som utdata.

  • Acknowledgements

    iii

    Acknowledgements

    First of all, I am very thankful to almighty God, without grace of God, it is impossible for me to doanything.

    I am also very thankful to Kurt Sandkuhl, VladimirTarasov, Anders Carstensen and Lin Feiyu for providing ideas, feedback and encouragement. These peoplewere always accessible for discussion,and guided me throughoutthis thesis period.

    Sincerest thanks to my family in Pakistan, for their encouragement since the first moment I came in Sweden.

    At the end, I am also very thankful to my friends for their help and time for discussion.

  • Key words

    iv

    Key words

    Enterprise models, enterprise ontologies, model transformation, meta-modeling.

  • Contents

    v

    Contents

    1 Introduction ............................................................................... 1

    1.1 BACKGROUND ............................................................................................................................. 1 1.2 PURPOSE/OBJECTIVES ................................................................................................................ 2 1.3 LIMITATIONS ............................................................................................................................... 2 1.4 THESIS OUTLINE.......................................................................................................................... 2

    2 Theoretical background .............................................................. 4

    2.1 ENTERPRISE MODEL .................................................................................................................... 4 2.1.1 Content of the enterprise model .................................................................................................. 5

    2.1.2 Categories of enterprise model .................................................................................................... 6

    2.1.3 Elements of enterprise model ..................................................................................................... 6

    2.1.4 Objects and object type ............................................................................................................ 6

    2.1.5 Attribute & attribute value ..................................................................................................... 8

    2.1.6 Relations ............................................................................................................................ 10

    2.1.7 Source and target of a relation ................................................................................................. 11

    2.1.8 Purposes of enterprise model .................................................................................................... 11

    2.1.9 Languages& tools ................................................................................................................ 11

    2.2 XML- EXTENSIBLE MARKUP LANGUAGE .................................................................................. 12 2.2.1 Origin and goals .................................................................................................................. 13

    2.3 ONTOLOGY ............................................................................................................................... 14 2.3.1 Enterprise ontology ............................................................................................................... 14

    2.3.2 Approaches to develop ontology ................................................................................................ 15

    2.3.3 Components/Elements of ontology ........................................................................................... 16

    2.3.4 Usage ................................................................................................................................ 19

    2.3.5 Languages & tools ............................................................................................................... 19

    2.4 OWL LANGUAGE ...................................................................................................................... 20 2.4.1 Why OWL? ...................................................................................................................... 21

    2.4.2 Sublanguages of OWL ......................................................................................................... 21

    2.5 XSL ........................................................................................................................................... 22 2.5.1 Usage ................................................................................................................................ 24

    2.5.2 Tools ................................................................................................................................. 24

    2.6 MODEL TRANSFORMATION APPROACHES .................................................................................. 25 2.6.1 Functional approach ............................................................................................................. 25

    2.6.2 Logic programming approach .................................................................................................. 25

    2.6.3 Graph transformation approach .............................................................................................. 25

    2.6.4 Meta-model base transformation approach ................................................................................. 25

    3 Research Methods .................................................................... 27

    4 Results ..................................................................................... 30

    4.1 META MODEL BASED MODEL TRANSFORMATION ....................................................................... 30 4.1.1 Transformation of enterprise model to enterprise ontology............................................................... 30

    4.2 PROPOSED TRANSFORMATION APPROACHES ............................................................................. 32 4.2.1 Rules of transformation approach 1 .......................................................................................... 32

    4.2.2 Rules of transformation approach 2 .......................................................................................... 35

    4.2.3 Rules of transformation approach 3 .......................................................................................... 37

    4.2.4 Comparison among proposed approaches ................................................................................... 41

    4.3 PROBLEMS AND SOLUTIONS ....................................................................................................... 43 4.3.1 Problem: How to maintain relation between two objects of enterprise model if one is becoming class and other

    is instance in enterprise ontology? ........................................................................................................... 43

    Solution ........................................................................................................................................... 43

    4.3.2 Problem: How to indentifythat anobjects is class or instance? ......................................................... 43

  • Contents

    vi

    Solution ........................................................................................................................................... 43

    4.3.3 Problem: How to maintain the hierarchy among same kind of objects? ............................................. 45

    Solution ........................................................................................................................................... 45

    4.3.4 Problem: Need of class on the basis of object type? ....................................................................... 46

    Solution ........................................................................................................................................... 46

    5 Implementation ........................................................................ 48

    5.1 CONCEPT BUILDING .................................................................................................................. 48 5.2 SYSTEM BUILDING ..................................................................................................................... 49 5.3 MODULES OF SYSTEM ................................................................................................................ 51 5.3.1 Enterprise model analyzer (EM Analyzer) ............................................................................... 52

    5.3.2 Information Refiner (IR) ....................................................................................................... 52

    5.3.3 Enterprise ontology builder (EO Builder) .................................................................................. 53

    5.3.4 User interface module ............................................................................................................ 53

    6 Recommendations for enterprise modeler ................................. 58

    7 Conclusion and discussion ....................................................... 60

    7.1 EVALUATION ............................................................................................................................ 60 7.1.1 Enterprise model .................................................................................................................. 60

    7.1.2 Manually developed enterprise ontology & enterprise ontology developed through developed tool .............. 61

    7.1.3 Classes .............................................................................................................................. 62

    7.1.4 Instances ............................................................................................................................ 62

    7.1.5 Attributes and values ............................................................................................................ 62

    7.1.6 Object property, domain and range ........................................................................................... 63

    7.1.7 Comparison between manually developed ontology and ontology developed through developed tool ............ 63

    7.2 SUMMARY OF THE RESULTS ........................................................................................................ 64 7.3 APPLICABILITY OF THE RESULTS ................................................................................................ 64 7.4 FUTURE STUDY ......................................................................................................................... 65

    8 References ................................................................................ 66

    9 Appendix .................................................................................. 69

  • List of Figures

    vii

    List of Figures

    FIGURE 2-1: ENTERPRISE MODELS OBJECTS AND THEIR TYPES ............... 7

    FIGURE 2-2: ENTERPRISE MODELS OBJECTS AND THEIR TYPES IN

    KMV FILE ...................................................................................................................... 7

    FIGURE 2-3: ATTRIBUTES AND THEIR VALUES FOR OBJECT DAVID

    SCOTT AS ONE SEE THROUGH GUI OF TROUX ARCHITECT ................. 8

    FIGURE 2-4: ATTRIBUTES OF OBJECT DAVID SCOTT WITH

    RESPECTIVE VALUES BY VIEWING THE *.KMV FILE .................................. 9

    FIGURE 2-5: RELATIONS BETWEEN TWO OBJECTS (GRAPHICAL VIEW) . 10

    FIGURE 2-6: RELATIONS BETWEEN TWO OBJECTS IN XML FORMAT ....... 10

    FIGURE 2-7: STORE INFORMATION IN XML FORMAT .................................... 13

    FIGURE 2-8: CLASSES & SUB CLASSES IN EO ..................................................... 16

    FIGURE 2-9: INSTANCE WITH DATA PROPERTIES (PROPERTY/VALUE

    PAIR) ................................................................................................................................ 17

    FIGURE 2-10: DIRECT RELATION HAS_EMPLOYEE BETWEEN

    ORGANIZATION AND PERSON CLASSES ................................................... 18

    FIGURE 2-11: INVERSE RELATION BETWEEN ORGANIZATION AND

    PERSON CLASSES .................................................................................................... 18

    FIGURE 2-12: TWO CLASS DEFINITIONS IN OWL XML SYNTAX [3] ......... 20

    FIGURE 2-13: XML TRANSFORMATION TO MULTIPLE OUTPUTS [18] ..... 23

    FIGURE 4-1: TRANSFORMATION PROCESS OVERVIEW .................................... 31

  • List of Figures

    viii

    FIGURE 4-2: MAPPING ELEMENTS OF EM TO EO............................................... 31

    FIGURE 4-3: PERSON TYPE OBJECTS IN EM .......................................................... 33

    FIGURE 4-4: DATA PROPERTIES WITH VALUES OF OBJECT TYPE

    PERSON ........................................................................................................................ 34

    FIGURE 4-5: CLASS PERSON WITH SUB CLASSES ............................................ 35

    FIGURE 4-6: CONTAINER 'PERSONNEL' WITH OBJECT TYPES 'PERSON'

    AND 'LOCATION' ......................................................................................................... 37

    FIGURE 4-7: OBJECT 'DAVID SCOTT' WITH ATTRIBUTES AND VALUES

    IN EM ................................................................................................................................ 38

    FIGURE 4-8: INSTANCE 'DAVID_SCOTT' WITH DATA PROPERTIES AND

    VALUES IN EO .............................................................................................................. 39

    FIGURE 4-9: RELATION BETWEEN TWO OBJECTS (ADMIN AND DAVID SCOTT) IN EM ............................................................................................. 40

    FIGURE 4-10: RELATION BETWEEN TWO INSTANCES IN EO .................... 40

    FIGURE 4-11: USER CHOOSES OBJECT TYPE THROUGH GUI ....................... 44

    FIGURE 4-12: XSL PATTERN FOR SELECTION OF OBJECTS TYPE .............. 44

    FIGURE 4-13: ORGANIZATION HIERARCHICAL STRUCTURE IN EM .......... 45

    FIGURE 4-14: ORGANIZATION HIERARCHICAL STRUCTURE IN EO ........... 46

    FIGURE 4-15: PERSON TYPE OBJECTS IN EM ....................................................... 47

    FIGURE 4-16: PERSON AS CLASS AND ITS INSTANCES IN EO ........................ 47

    FIGURE 5-1: PROCESS FOR TRANSFORMING EM TO EO ................................ 50

  • List of Figures

    ix

    FIGURE 5-2: DIFFERENT MODULES OF SYSTEM ................................................ 51

    FIGURE 5-3: UI TO CHOOSE SOURCE AND TARGET FILES ............................ 54

    FIGURE 5-4: UI FOR SELECTION OF TYPE OF OBJECT ................................... 54

    FIGURE 5-5: UI TO SHOW RESULTS TO USER ....................................................... 55

    FIGURE 5-6: UI TO LOAD/EDIT/SAVE REGEX FILE .......................................... 56

    FIGURE 5-7: UI TO LOAD/EDIT/SAVE XSL PATTERN FILE ............................... 57

    FIGURE 5-8: UI TO CHOOSE SOURCE & TARGET FILE AND TO SEE THE

    RESULTS OF OPERATIONS..................................................................................... 57

    FIGURE 6-1: CONTAINER WITH DIFFERENT TYPE OF OBJECTS ................. 58

    FIGURE 6-2: CONTAINER WITH SAME TYPE OF OBJECTS .............................. 59

    FIGURE 6-3: CONTAINER WITH SAME TYPE OF OBJECTS .............................. 59

    FIGURE 9-1: ENTERPRISE MODEL OF AN ORGANIZATION ............................ 70

    FIGURE 9-2: OBJECT DETAILS OF ORGANIZATION CONTAINER ........... 70

    FIGURE 9-3: OBJECTS DETAILS OF PERSON CONTAINER .......................... 71

    FIGURE 9-4: OBJECTS DETAILS OF LOCATION CONTAINER .................... 71

    FIGURE 9-5: OBJECTS DETAILS OF PRODUCTS CONTAINER ..................... 72

    FIGURE 9-6: OBJECTS OF REQUIREMENTS CONTAINER ............................. 72

    FIGURE 9-7: DESCRIPTION OF RELATIONS AMONG ORGANIZATIONS OBJECTS AND PERSONS OBJECTS ................................................................... 73

  • List of Figures

    x

    FIGURE 9-8: RELATION DESCRIPTION AMONG PERSONS OBJECTS AND LOCATIONS OBJECTS ................................................................................. 74

    FIGURE 9-9: RELATION DESCRIPTION AMONG ORGANIZATIONS OBJECTS AND PRODUCTS OBJECTS ................................................................ 74

    FIGURE 9-10: RELATIONS DESCRIPTION AMONG OBJECTS OF PRODUCTS AND OBJECTS OF REQUIREMENTS ........................................ 75

    FIGURE 9-11: DETAILS OF CLASSES OF ORGANIZATION STRUCTURE ONTOLOGY ................................................................................................................... 76

    FIGURE 9-12: DETAIL DESCRIPTION OF CLASSES OF ORGANIZATION ...................................................................................................... 76

    FIGURE 9-13: DETAIL DESCRIPTION OF CLASSES OF PRODUCTS CLASS .............................................................................................................................. 77

    FIGURE 9-14: DETAIL DESCRIPTION OF INSTANCES OF PERSON CLASS .............................................................................................................................. 77

    FIGURE 9-15: INSTANCES OF LOCATION CLASS ............................................. 78

    FIGURE 9-16: INSTANCES OF REQUIREMENTS CLASS ................................ 78

    FIGURE 9-17: RELATIONS AMONG ORGANIZATION CLASS AND PERSON CLASS ......................................................................................................... 79

    FIGURE 9-18: DETAIL DESCRIPTION OF RELATIONS AMONG INSTANCES OF PERSON CLASS AND INSTANCES OF LOCATION CLASS ................................................................................................... 79

    FIGURE 9-19: DETAIL DESCRIPTION OF RELATIONS AMONG SUB CLASSES OF ORGANIZATION AND SUB CLASSES OF PRODUCTS ................................................................................................................... 80

    FIGURE 9-20: DETAIL DESCRIPTION OF INSTANCES OF PRODUCTS CLASS AND INSTANCES OF REQUIREMENTS CLASS ......................... 81

  • List of Figures

    xi

    FIGURE 9-21: ENTERPRISE MODEL MASTER THESIS EXAMPLE ........... 82

    FIGURE 9-22: DETAIL DESCRIPTION OF CLASSES OF MASTER THESIS EXAMPLE ONTOLOGY .......................................................................................... 83

    FIGURE 9-23: DESCRIPTION OF RELATIONS AMONG CLASSES ROLES, COMPETENCES AND PROCESS .................................................... 84

    FIGURE 9-24: DETAIL DESCRIPTION OF RELATIONS OF ROLES AND SUB CLASSES OF ROLES AMONG CLASS PROCESS AND SUB CLASSES OF PROCESS ........................................................................................... 84

    FIGURE 9-25: DETAIL DESCRIPTION OF RELATIONS BETWEEN CLASS ROLES, COMPETENCES AND AMONG THEIR SUB CLASSES ........................................................................................................................ 85

    FIGURE 9-26: ENTERPRISE MODEL THESIS EXAMPLE ............................... 86

    FIGURE 9-27: DETAIL DESCRIPTION OF CLASS HIERARCHY OF THESIS EXAMPLE ONTOLOGY, RESULT OF TRANSFORMATION OF ENTERPRISE MODEL THESIS EXAMPLE ............................................ 87

    FIGURE 9-28: DETAIL RELATION DESCRIPTION OF AMONG SUB CLASSES OF ORGANIZATION CLASS ........................................................... 88

    FIGURE 9-29: DETAIL RELATION DESCRIPTION BETWEEN PERSON, ORGANIZATION CLASSES AND AMONG THEIR SUB CLASSES ..... 88

    FIGURE 9-30: DETAIL RELATION BETWEEN CLASSES PERSON AND INFORMATION_OBJECT AND AMONG THEIR SUB CLASSES .......... 89

    FIGURE 9-31: RELATION DESCRIPTION AMONG SUB CLASSES OF CLASS PERSON ......................................................................................................... 89

    FIGURE 9-32: RELATION DESCRIPTION BETWEEN CLASSES PERSON AND REQUIREMENT AND AMONG THEIR SUB CLASSES ................ 90

  • List of Tables

    xii

    List of Tables

    TABLE 1: COMPARISON AMONG PROPOSED TRANSFORMATION APPROACHES .............................................................................................................. 42

    TABLE 2: COMPARISON BETWEEN MANUALLY DEVELOPED ONTOLOGY AND ONTOLOGY DEVELOPED THROUGH DEVELOPED TOOL .................................................................................................. 63

  • List of Abbreviations

    xiii

    List of Abbreviations

    GEM Generic Enterprise Model

    OWL Ontology Web Language

    XML Extensible Markup Language

    XSL Extensible Style sheet Language

    XSLT Extensible Style sheet Language Transformation

    EM Enterprise Model

    EO Enterprise Ontology

    GUI Graphical User Interface

    CIM Computer Integrated Manufacturing

    RDF Resource Description Framework

    RDFS Resource Description Framework Schema

    HTML Hyper Text Markup Language

    DTD Data Type Definition

    SGML Standard Generalized Markup Language

    ASCII American Standard Code for Information Interchange

    EMSE Enterprise Modeling Software Environment

  • Introduction

    1

    1 Introduction Use of enterprise models is very common in companies.Enterprise models are usually developed with the ambition to capture the current or desired situation in enterprises with respect to

    the processes performed or planned

    the organization structure, including organization units, roles and competences

    products or services produced and their components

    IT systems available in the enterprise

    The above aspects are mutually reflective, i.e. relationships between the different elements in the perspectives exist. Such enterprise models often are represented in formal modeling languages, like UEML (Unified Enterprise Modeling Language) or MEAF (Metis Enterprise Architecture Framework), allowing for the development of applications, which interpret or compute them.

    Enterprise ontologies also represent same aspects of an enterprise like process, organizational structure and products etc. However, enterprise ontologies use another presentation like OWL and often are developed for other applications, purposes than enterprise models, e.g. as knowledge base for reasoning purposes.

    The objective of this chapter is to introduce our research problem. It describes how the thesis is conducted in order to solve research problems and showing the limitations and scope of work. There is also a short description about remaining parts of report.

    1.1 Background

    The thesis subject aims at defining the strategies to transform the enterprise models into enterprise ontologies. This task requires following steps.

    Parsing and identification of representative elements of enterprise model and enterprise ontology.

    Mapping the representative elements of enterprise model to representative elements of enterprise ontology.

    Preserve maximum semantic and it should be minimum loss of information while transformation.

    In this thesis work, research problems are solved from theoretical perspective as well as technical perspective. Regarding theoretical perspective,existing knowledge about enterprise models, enterprise ontologies, XML, XSL and different approaches of transformation (one modelinto other model) are summarized.

  • Introduction

    2

    1.2 Purpose/Objectives

    As it is mentioned earlier that enterprise models and enterprise ontologies represent same aspect of enterprises but both use different presentation and developed for different purposes. This led us to search for a way, make dynamic use of enterprise models and transform enterprise models into enterprise ontologies. Here are our research questions, infer from this problem area.

    Q 1.How to map elements of enterprise model to enterprise ontology?

    Q 2.What kind of information can be lost during the process of transformationof enterprise model to enterprise ontology?

    1.3 Limitations

    In practical part of thesis work, different enterprise models from different modelers are used as source and transform these enterprise models into enterprise ontologies. As different modelers have different theoretical and technical background and develop enterprise models according to their needs, requirements and intentions. If there is error or ambiguity while developing an enterprise model,using different elements (objects) of enterprise model then this error or ambiguity can lead to build a semantically ambiguous and erroneous or incorrect ontology at the end.

    1.4 Thesis outline

    The thesis report is divided into following way. In the second chapter, the theories related to our research problem are presented. In this chapter, we first present what enterprise models are and how to use them in organizations. In our case (we use the models developed through Troux Architect1 tool), as the information regarding enterprise models is stored in XML files by Troux Architect tool. So, we briefly introduce the XML language and how the storage of information is performed in XML document. Then, we describe what enterprise ontologies are and how they are used to represent the information or knowledge. There is description about ways of developing enterprise ontology and OWL language. In practical part of our thesis, we use XSL to write our transformation rules at some extent, so there is also brief introduction about XSL and SXLT. Later there is description of different approaches used for model to model transformation.As we choose meta-model based transformation approach for transformation of enterprise model to enterprise ontology, so at the end of this chapter there is description about meta-modeling and usage of meta-modeling.

    The third chapter is related with research methodologies which we used during this research processto get answers of research questions and to implement the rules of selected proposed transformation approach.

    1http://www.troux.com/products/troux_architect/

  • Introduction

    3

    In the fourth chapter we get answers of research questions, in it we describe the meta-model based transformation approach, and based on this approach we map elements of enterprise model to enterprise ontology.

    Then we propose our own transformation approaches based on meta-model based transformation approach and make comparison among these proposed approaches. Later there is descriptionabout different problems which we faced during our research work and how we got solutions of these problems to preserve maximum semantic of enterprise model in enterprise ontology.

    The fourth chapter is related with implementation or development phase of EM2EO (enterprise model to enterprise ontology) tool. In this chapter, we describe about different modules which we have developed and how these modules interlink with each other to get final output.

    The fifth chapter is about recommendations for enterprise modelers. During this research, we studied different enterprise models from different enterprise modelers and found some deficiencies andinformation which lead to confusionwhile understanding the enterprise model. So, in fifth chapter, we propose some recommendations which should be considered by modeler while developing an enterprise model.

    In the last chapter we evaluate the results, discuss the conclusionof this research and further research work.

  • Theoretical Background

    4

    2 Theoretical background This chapter is related with description of enterprise model, XML, ontology, enterprise ontology, OWL, XSL and different model to model transformation approaches. We describe briefly that is found about these topics in literature.

    2.1 Enterprise model

    Enterprise modeling came into born in United States (US) at the beginning of 80s within the initiative of Computer Integrated Manufacturing (CIM) and people came into know about it through large CIM projects like ICAM or CAM-I [2]. In mid 80s Europe also launched different Enterprise Modeling projects.

    In literature a number of definitions exist, given by different authors. Here we discuss few of them.

    A model is a representation of something else[23]. Soaccording to this definition one can say that anything that represents something could be considered as model.

    The word model is interpreted and can be interpreted in various ways according to different situations. It might be a simplified representation of real world or may be an abstract picture, existing in someones mind [22] [24] [29].

    An enterprise model must serve a purpose. There are many different purposes but fundamentally any enterprise model aims to make people understand, communicate, develop and cultivate solutions [22].

    An enterprise model is a computational representation of the structure, activities, processes, information, resources, people, behavior, problems, goals, and constraints of a business, government, or other enterprise. A model can be both descriptive and definitional and covering or spanning what is and what should be. The role of an enterprise model for an enterprise is to achieve model-driven enterprise design, analysis, and operation [21].

    Enterprise modeling is the abstract representation, description and definition of the structure, process, information and resources of an identifiable business, government body or other large organization.

    Enterprise modeling is the set of activities or processes used to develop the various parts of an enterprise model to address some desired modeling finality. It can be defined as the art of externalizing enterprise knowledge [2].

  • Theoretical Background

    5

    The prime goal of enterprise modeling is not only applied for better enterprise(s) integration but also to support analysis of an enterprise, and more specifically, to represent and understand how the enterprise works, to capitalize acquired knowledge and know-how for later use, to design (or redesign) a part of the enterprise, to analyze some aspects of the enterprise (by e.g. economic analysis, organization analysis, qualitative analysis or quantitative analysis,..), to simulate the behavior of (some part of) the enterprise, to make better decisions about enterprise operations and organization, or to control, coordinate and monitor some parts f the enterprise[2].

    Enterprise modeling is an engineering discipline closely related to computerized systems. As such, it requires the combined use of Enterprise Modeling Software Environments (EMSE), Enterprise Modeling Languages (EML) and Enterprise Engineering Methodologies (EEM)[2].

    Enterprise modeling deals with the process of understanding an enterprise business and improving its performance through creation of enterprise models.

    2.1.1 Content of the enterprise model

    The enterprise can be viewed and analyzed from different aspects. In practice it makes a model very complex or in other words it is not possible to show all the aspects of an enterprise in one model. The model would be so complex that it would be impossible to handle and to work with. Usually the enterprise model contains those aspects which are crucial to solve the problem. In a manufacturing context the following aspects need to be modeled [24].

    Processes, that means manufacturing and business processes like administrative, management, finance, etc. In other words it is description of the flow of activities.

    Products that mean products related information, all technical data related to a product and the manufacturing processes which are necessary to produce the product.

    Resources, that means physical machines and devices,computer applications (software packages).

    Raw Material

    Information that means anything that can be represented by data can be modeled.

    Organization, that means organization itself and management related issues. It involves organizational chart, goals and objectives.

    Environment, that means the environment of the enterprise, business constraints, government regulations, legal issuesand other enterprises and business partners.

  • Theoretical Background

    6

    2.1.2 Categories of enterprise model

    On the basis of purpose of enterprise model, one can dividethe enterprise models into three categories which are as follow [24].

    1. Human sense making and communication - where the main or basic purpose of enterprise modeling is to make sense of aspects of an enterprise and make communication with other actors of enterprise.

    2. Computer assisted analysis - where the main purpose of enterprise modeling is to gain knowledge about the enterprise by the use of simulation or deduction.

    3. Model deployment and activation - where the main purpose of enterprise modeling is to integrate the model in or with an enterprise wide information system and actively take part in the work performed by the enterprise [25].

    2.1.3 Elements of enterprise model

    Entities/Concepts- Process, goals, problems, actors, resource, concepts.

    Relations-Entities are linked with each other through relations. Relations can be supports, hinders, responsible for, dependent upon, Is-A, Part-of etc.

    Rules/constraints- For different kind of restrictions, there are rules or constraints which can be applied at different levels.

    2.1.4 Objects and object type

    We use enterprise models which are developed in Troux Architect 7.1. In these models the representing elements of enterprise model are objects. And object can be process, goal, problem, actor, resource, concepts etc.

    In the Figure 2-12, there are four objects ABC Corp, Sale, Admin and Production. The type (object type) of these objects is organization. The ABC Corp. object has has-a relation with Sales, Admin and Production objects.

    2 The model is found in samples of Troux Architect 7.1 tool and we modified some parts of his model according to our requirements and needs.

  • Figure 2-1: Enterprise models objects and their types

    Figure 2-2 shows the information in XML formatand Admin and Productionfrom kmv file, it is one of the file that is used by Troux Architect Tool to store information about enterprise model. We use this file as input to retrieve information about enterprise model.

    Figure 2-2: Enterprise models objects and their types in kmv file

    Theoretical Background

    : Enterprise models objects and their types

    2 shows the information in XML format about ABC Corp.and Admin and Production objects. This part of information is retrieved from kmv file, it is one of the file that is used by Troux Architect Tool to store information about enterprise model. We use this file as input to retrieve information about enterprise model.

    : Enterprise models objects and their types in kmv file

    about ABC Corp., Sales, information is retrieved

    from kmv file, it is one of the file that is used by Troux Architect Tool to store information about enterprise model. We use this file as input to retrieve

    : Enterprise models objects and their types in kmv file

  • 2.1.5 Attribute & attribute value

    Each object can have a number of attributescommon among objects. For example, the attribute country is coobject type organization and person while the attribute Gender is only found in object type person but not in object type organization. Figure shows the attributes of object type person with values. The figure 2the attributes of object named David Scott in XML format.

    Figure 2-3: Attributes and their values for object David Scott as one see through GUI of Troux Architect

    Theoretical Background

    Attribute & attribute value

    a number of attributes. The attributes may or may not For example, the attribute country is common in

    object type organization and person while the attribute Gender is only found in object type person but not in object type organization. Figure

    bject type person with values. The figure 2object named David Scott in XML format.

    : Attributes and their values for object David Scott as one see through GUI of Troux Architect

    attributes may or may not be mmon in

    object type organization and person while the attribute Gender is only found in object type person but not in object type organization. Figure 2-3,

    bject type person with values. The figure 2-4 shows

    : Attributes and their values for object David Scott as one see

  • Figure 2-4: Attributes of object David Scott with respective values by

    Theoretical Background

    : Attributes of object David Scott with respective values by viewing the *.kmv file

    : Attributes of object David Scott with respective values by

  • 2.1.6 Relations

    Objects are connected with each other through relations. figure 2-5 &2-6, Admin object has relation named has employee David Scott.

    Figure 2-5 shows the graphical representation of relation between two objects. While the figure 2-6 shows the informatioobjects in XML format.

    Figure 2-5: Relations between two objects (graphical view)

    Figure 2-6: Relations between two objects

    Each relation may have an inverse relation, for example, David Scott object has employed by relation with Admin. So, has employee and employed by are inverse to each other.

    Theoretical Background

    s are connected with each other through relations. For example, Admin object has relation named has employee with object

    5 shows the graphical representation of relation between two objects. 6 shows the information about relationship between same

    : Relations between two objects (graphical view)

    : Relations between two objects in XML format

    Each relation may have an inverse relation, for example, David Scott object d by relation with Admin. So, has employee and employed

    by are inverse to each other.

    For example, see at with object

    5 shows the graphical representation of relation between two objects. n about relationship between same

    Each relation may have an inverse relation, for example, David Scott object d by relation with Admin. So, has employee and employed

  • Theoretical Background

    11

    2.1.7 Source and target of a relation

    Each relation has origin and target object.In Figure 2-5& 2-6, relation name is has employee, origin is Admin and target is David Scott and relation named employed by has origin David Scott and target Admin.

    2.1.8 Purposes of enterprise model

    An enterprise model can be developed to serve one purpose but it could as well be used for many different purposes.Here are few formal purposes of enterprise modeling [26].

    1. To capitalize enterprise knowledge and know how.

    2. To illustrate relations and dependencies within the enterpriseand with other enterprises, to achieve better control and management over all aspects.

    3. To provide support to business process re-engineering.

    4. To get a common and complete understanding of the enterprise.

    5. To improve information management across organizational and application system boundaries and provide a common means for communication throughout the organization. Rationalize and secure information flows.

    6. To provide operative support for daily work at all levels in the enterprise from top to bottom.

    7. To control, co-ordinate and monitor some parts of the enterprise.

    8. To provide support for decision making.

    9. To provide support the design of new parts of the enterprise.

    10. To simulate processes.

    2.1.9 Languages& tools

    A model is always expressed or illustrated in terms of a language. This language is more or less formal and is made of constructs. The most formal languages (mathematics) and less formal (natural languages) can be used to represent models. And in between these two extremes, many forms of languages exist to model things or reality such as

    Symbolic languages - an example of symbolic languages is the set of symbols for the traffic regulations.

    Graphical or diagramming languages graphical languages is the set of diagrams (rectangles, diamonds and arcs) to represent entity-relationship models.

    Semi-formal languages - an example of semi-formal languages is the IDEF [24] notations.

  • Theoretical Background

    12

    Formal description techniques - an example of formal description techniques is the LOTOS language [24].

    There are a number of modeling languages available like GRAI, CIMOS, ITM, GEM, EEMM, IEM, EEML etc.In 90s different commercial tools were available to make enterprise model or business process model in market like ARIS ToolSet3, METIS, Enterprise Modeller4, FirstSTEP5, KBSI, CimTool,6 MO2GO7etc [2].

    In Globeman21 project, METIS 2.1 tool was used for enterprise modeling purpose. Along with otherbusiness process engineering model, an extended enterprise engineering platform was built in the course of the project. The model (extended enterprise engineering model) serves as a knowledge management tool in the extended enterprise and enables extended enterprise integration [24].

    METIS was renamed as Troux Architect 8tool. Once an enterprise model is developed by EMSE and saved the information as XML file format then other tools can read this model if those have access to DTD (data type definition) of Troux Tech.

    2.2 XML- Extensible Markup Language

    Extensible Markup Language and abbreviated as XML, describes a class of data objects called XML application profile or restricted form of SGML (Standard Generalized Markup Language).

    By construction, XML documents are conforming SGML documents. XML documents are made up of or constituted by storage units called entities; these entities may contain either parsed or unparsed data. Characters form parsed data, some of which form character data and some of which form markup. Markup encodes/contains a description of the document's storage layout and logical structure. XML provides a mechanism to apply constraints upon the storage layout and logical structure of document.

    To read XML documents, a software module called XML processor is used and it provides access to the contents and structure of XML document. It is assumed that an XML processor is doing its job on behalf of another software module, called the application [8].

    See figure 2-7, it shows how the information are stored in XML format.

    3http://maloy30.softarchive.net/aris_toolset_modeling_business_processes_eng_rus.153327.html 4http://www.hiteclabs.com/ 5http://www.interfacing.com/ 6http://www.cimosa.de/IctSupport/CimTool.html 7http://www.modelbased.net/aif/solutions/singular_solutions/solution_mo2go.html 8http://www.troux.com

  • Figure 2

    Enterprise models developed through organization) are used in this research workand stored in XML format. Each Following are Metis file types [30]. KMV Knowledge Model View

    opened through Metis Client Toofiles.

    KMD Knowledge Model Data Views. One can load KMD files into Metis, but nothing is shown in the modeling area, only listed in the trees. It can reference other through URI properties.

    SVG Scalable Vector Graphic reference PNG files.

    PNG Portable Network Graphicsreplaces GIF as the internet standard for

    2.2.1 Origin and goals

    XML was developed by an XML Working Group (known as the SGML Editorial Review Board) in 1996. XML Working Group was formed under the auspices(W3C). The group was chaired by Jon Bosak of Sun Microsystems. XML Special Interest Group (previously known as the SGML Working Group), it also organized by the W3C, took active part in development of XML.

    Here are the design goals of XML

    XML shall be usable over the Internet straightforwardly.

    XML shall provide support to a wide variety of applications.

    XML shall be compatible with SGML (Standard Generalized Markup Language).

    To write/develop programs which process XML documents, will be easy.

    The number of optional features in XML shall be kept to the absolute minimum, ideally zero.

    Theoretical Background

    2-7: Store information in XML format

    prise models developed through Troux Architect 7.1 (product of Metis ) are used in this research work. All Metis [30] components are created

    and stored in XML format. Each kmv file is a set of xml tags to describe metaFollowing are Metis file types [30].

    Model View contains at least one Model View. This file is opened through Metis Client Tools. This file has reference to KMD and SVG

    Knowledge Model Data it contains any Metis entity, except Model Views. One can load KMD files into Metis, but nothing is shown in the modeling area, only listed in the trees. It can reference other KMD, SVG and other files

    Scalable Vector Graphic contains one or more symbols. It has

    Portable Network Graphics used to represent bitmaps in symbols. It replaces GIF as the internet standard for representing bitmaps.

    Origin and goals

    XML was developed by an XML Working Group (this group is originally known as the SGML Editorial Review Board) in 1996. XML Working Group was formed under the auspices or support of the World Wide Web Consortium

    . The group was chaired by Jon Bosak of Sun Microsystems. XML Special Interest Group (previously known as the SGML Working Group), it also organized by the W3C, took active part in development of XML.

    Here are the design goals of XML[8]:

    e over the Internet straightforwardly.

    XML shall provide support to a wide variety of applications.

    XML shall be compatible with SGML (Standard Generalized Markup

    To write/develop programs which process XML documents, will be easy.

    optional features in XML shall be kept to the absolute minimum, ideally zero.

    product of Metis ] components are created

    file is a set of xml tags to describe meta-model.

    contains at least one Model View. This file is ls. This file has reference to KMD and SVG

    it contains any Metis entity, except Model Views. One can load KMD files into Metis, but nothing is shown in the modeling

    KMD, SVG and other files

    contains one or more symbols. It has

    used to represent bitmaps in symbols. It

    originally known as the SGML Editorial Review Board) in 1996. XML Working Group

    of the World Wide Web Consortium . The group was chaired by Jon Bosak of Sun Microsystems. XML

    Special Interest Group (previously known as the SGML Working Group), it

    XML shall be compatible with SGML (Standard Generalized Markup

    To write/develop programs which process XML documents, will be easy.

    optional features in XML shall be kept to the absolute

  • Theoretical Background

    14

    XML documents should be reasonably clear and human readable.

    The XML design should be prepared quickly.

    There should be formality and conciseness in design of XML.

    XML documents shall not be complex and easy to create.

    The specification [8] and other associated standards (Internet RFC 1766 for language identification tags, Unicode and ISO/IEC 10646 for characters, ISO 639 for language name codes and ISO 3166 for country name codes), provides all the information that is necessary to understand XML Version 1.0 and construct computer programs to process XML.

    2.3 Ontology

    There are a number of ontology definitions in literature. Here are few of them.

    The term ontology has its roots in philology, where ontology means a systematic description of existence. In computer science, there are different definitions of ontology but each definition tries to define ontology in three aspects, content, form and purpose of ontology [6].Ontology is specification of conceptualization[13].Ontology is the description of basic terms and their relationships and the axioms for constraining the relationships among[13].

    Ontology is the science of analyzing of objects, properties of objects, events, processes and relations in every area of reality [15]. Ontology is description of the concepts and relationships among the concepts[16].

    2.3.1 Enterprise ontology

    Here are number of definitions of enterprise ontology found in literature.

    Enterprise ontology can be defined as description of a domain and parts of domain of an enterprise. The enterprise ontology is used in an enterprise to solve specific problems of that enterprise [3].

    Enterprise ontologies are usually created and organize relevant knowledge about activities, processes, organizations, strategies, marketing etc. All this knowledge is meant to be used by enterprises [32].

    Enterprise ontology [1] defined as enterprise ontology as the realization and implementation independent essence of an enterprise, in short, as the deep

    structure behind its observable surface structure.

    The main purpose of enterprise ontology is to promote the common understanding among people across enterprises and to serve as a communication medium between people and applications, and among different applications [33].

  • Theoretical Background

    15

    2.3.2 Approaches to develop ontology

    Top-down:In top-down ontology development, process starts with the definition of the most general concepts in the domain and subsequent specialization of the concepts. For example, if one takes the example of wine ontology, then one can start with creating classes for the general concepts of Wine and Food. Then one specializes the Wine class by creating some of its subclasses: White wine, Red wine, Ros wine. Then one can further categorize/specialize the Red wine class, for example, into Syrah, Red Burgundy, Cabernet Sauvignon, and so on [17].

    Bottom-up:In bottom-up ontology development, the process of development starts with the definition of the most specific classes, the leaves of the hierarchy, with subsequent grouping of these classes into more general concepts. For example, one starts by defining classes for Pauillac and Margaux wines. Then one creates a common superclass for these two classes Medoc which in turn is a subclass of Bordeaux [17].

    Middle-out:In middle-out ontology development, a development process is a combination of the top-down and bottom-up approaches. Onestarts by defining the more salient concepts first and then generalizes and specialize concepts. One might start with a few top-level concepts such as Wine, and a few specific concepts, such as Margaux. One can then relate them to a middle-level concept, such as Medoc. Then one may want to generate all of the regional wine classes from France, in this way generating a number of middle-level concepts [17].

  • 2.3.3 Components/Elements

    Class - A class is a collection of objects. A class contains all objects which are related to the associated type.things which have certain things in common

    For example, see at figure 2class Organization. The class ABC_Corp. has three sub classes named Sales, Admin and Production

    Figure

    Individuals- Instances, objects or elements of classes.most specific concepts represented in a knowledge base [16][17].

    Theoretical Background

    /Elements of ontology

    A class is a collection of objects. A class contains all objects which are related to the associated type.Classes or collections or concepts are

    hich have certain things in common[1][16].

    For example, see at figure 2-8, we have class ABC_Corp. i.e. sub class of class Organization. The class ABC_Corp. has three sub classes named

    , Admin and Production.

    Figure 2-8: Classes & sub classes in EO

    Instances, objects or elements of classes. Individual instances are the most specific concepts represented in a knowledge base [16][17].

    A class is a collection of objects. A class contains all objects which are are kinds of

    , we have class ABC_Corp. i.e. sub class of class Organization. The class ABC_Corp. has three sub classes named

    Individual instances are the

  • Property- Properties are divided into data property and object property.

    Data Property-Attributes, aspects, parameters which classes can have [16].

    In the figure 2-9, shows avalues (at right hand side)xyz street, the data property privatePhoneNo has values 776

    Figure 2-9: Instance with data properties (property/valu

    Theoretical Background

    divided into data property and object property.

    Attributes, aspects, data properties, features, characteristics or parameters which classes can have [16].

    shows a number of data properties (at left hand side)t right hand side), for example, the street data property has value , the data property privatePhoneNo has values 776-876-444

    : Instance with data properties (property/value pair)

    properties, features, characteristics or

    (at left hand side) with example, the street data property has value

    444 etc.

    e pair)

  • Object Property- Relations, individuals can be related to one other [16].

    In context of OWL language, the term object property is used as a synonym to relation. Classes are related (make reobject property and instances are also related (make relation) to instances of other classes through object property.

    Figure 2-10 &2-11 show the object properties among classes OrganizatioPerson.

    Figure 2-10: Direct relation has_employee between Organization and

    Figure 2-11: Inverse relation between Organization and Person classes

    Domain & range- The RDF (Resource Description Framework, is recommended by W3C) model is based on triples. It is consisting of a subject (domain), a property (object property) and object (range) [3].

    In the figure 2-10, the object property has_employee has domain Organization class and range Person class. Whileproperty employed_by has domain Person class and range Organization class.

    AxiomsAxioms are used to represent business rules capabilities.

    Theoretical Background

    Relations, object properties, slots, ways in which classes and individuals can be related to one other [16].

    In context of OWL language, the term object property is used as a synonym to relation. Classes are related (make relation) with other classes through object property and instances are also related (make relation) to instances of other classes through object property.

    11 show the object properties among classes Organizatio

    : Direct relation has_employee between Organization and Person classes

    : Inverse relation between Organization and Person classes

    The RDF (Resource Description Framework, is recommended by W3C) model is based on triples. It is consisting of a subject (domain), a property (object property) and object (range) [3].

    , the object property has_employee has domain rganization class and range Person class. While in figure 2-11, the object

    property employed_by has domain Person class and range Organization

    Axioms are used to represent business rules and enhance reasoning

    slots, ways in which classes and

    In context of OWL language, the term object property is used as a synonym lation) with other classes through

    object property and instances are also related (make relation) to instances of

    11 show the object properties among classes Organization and

    : Direct relation has_employee between Organization and

    : Inverse relation between Organization and Person classes

    The RDF (Resource Description Framework, is recommended by W3C) model is based on triples. It is consisting of a subject

    , the object property has_employee has domain the object

    property employed_by has domain Person class and range Organization

    enhance reasoning

  • Theoretical Background

    19

    2.3.4 Usage

    Here are some of the usages of ontology models[17].

    Share common understanding of the structure of information among people and software agents.

    Enable reuse of domain knowledge.

    Make domain assumptions explicit.

    Separate domain knowledge from the operational knowledge.

    Analyze the domain knowledge.

    2.3.5 Languages & tools

    Ontology languages are formal languages which are used to construct ontologies. As ontology languages have reasoning rules, so these encoded the knowledge about specific domains and provide support to process the knowledge on the basis of reasoning rules. As the ontology languages are usually declarative languages so these are commonly based on first order logic or description logic. Here are few ontology languages [7].

    Traditional ontology languages- KIF (Knowledge Interchange Format), OKBC (Open Knowledge Base Connectivity), OCML (Operational Conceptual, Modeling Language), FLogic (Frame Logic), DOGMA (Developing Ontology-Grounded Methods and Applications)etc[24].

    Ontology languages which use markup schema- Here are one of those languages which use mark up schema to encode knowledge.DAML+OIL, OIL (Ontology Inference Layer), OWL (Web Ontology Language), RDF (Resource Description Framework), RDF Schema (Resource Description Framework Schema), SHOE (Simple HTML Ontology Extension)etc[24].

    There are different tools are available to develop ontologies such as TopBraid9Composer, Protg 10etc.

    9http://www.topquadrant.com/products/TB_Composer.html 10http://protege.stanford.edu/

  • 2.4 OWL language

    Web Ontology Language (documents needs to be proceswhere the content of documents, only needs to be presented to humans. OWL can be used to explicitly express or represent the meaning of terms in vocabularies and the relationships among those terms. This represterms and their interrelationships among these terms is called has more facilities for expressing meaning and semantics as compare to XML, RDF, and RDF-S languages, and thus OWL language has greater ability to represent machine interpretable content on the Web. OWL is a revision of the DAML+OIL web ontology language. The lessons which were learned during design and application of DAML+OIL, were used while design, development and application of OWL [4].

    See figure 2-12, [3], it showpresented in OWL XML syntax.

    Figure 2-12: Two class definitions in OWL XML syntax [3]

    Theoretical Background

    anguage

    Web Ontology Language (OWL) is used when the information contained in documents needs to be processed by applications and opposed to situations where the content of documents, only needs to be presented to humans. OWL can be used to explicitly express or represent the meaning of terms in vocabularies and the relationships among those terms. This representation of terms and their interrelationships among these terms is called ontologyhas more facilities for expressing meaning and semantics as compare to XML,

    S languages, and thus OWL language has greater ability to terpretable content on the Web. OWL is a revision of the

    DAML+OIL web ontology language. The lessons which were learned during design and application of DAML+OIL, were used while design, development and application of OWL [4].

    it shows how the two classes Human and Gender are syntax.

    : Two class definitions in OWL XML syntax [3]

    ) is used when the information contained in sed by applications and opposed to situations

    where the content of documents, only needs to be presented to humans. OWL can be used to explicitly express or represent the meaning of terms in

    entation of ontology. OWL

    has more facilities for expressing meaning and semantics as compare to XML, S languages, and thus OWL language has greater ability to

    terpretable content on the Web. OWL is a revision of the DAML+OIL web ontology language. The lessons which were learned during design and application of DAML+OIL, were used while design, development

    s how the two classes Human and Gender are

  • Theoretical Background

    21

    2.4.1 Why OWL?

    The semantic web is a vision for the future of the web. In semantic web, information is given explicit meaning, making it easier for machines to automatically process the information and integrate information available on the web. The semantic web will build on XML's ability to define customized tagging schemes and RDF's flexible approach to representing data. The first level above RDF required for the semantic web is an ontology language what can formally describe the meaning of terminology used in web documents. If machines are expected to perform useful reasoning tasks on these documents, the language must go beyond the basic semantics of RDF schema. The OWL Use Cases and Requirements Document provide more details on ontologies and motives which need for a web ontology language in terms of six use cases, and formulates design goals, requirements and objectives for OWL [4].

    OWL has been designed to meet this need for a web ontology language. OWL is part of the growing stack of W3C recommendations related to the semantic web.

    XML provides a surface syntax for structured documents, but imposes no semantic constraints on the meaning of these documents.

    XML Schema is a language for restricting the structure of XML documents and also extends XML with data types.

    RDF is a data model for objects ("resources") and relations between them provides a simple semantics for this data model, and these data models can be represented in XML syntax.

    RDF Schema is a vocabulary for describing properties and classes of RDF resources, with a semantics for generalization-hierarchies of such properties and classes.

    OWL adds more vocabulary for describing properties and classes: among others, relations between classes (e.g. disjoint), cardinality (e.g. "exactly one"), equality, richer typing of properties and characteristics of properties (e.g. symmetry), and enumerated classes.

    2.4.2 Sublanguages of OWL

    OWL provides three increasingly expressive sublanguages designed for use by specific communities of implementers and users.

    OWL Lite:It supports those users who primarily need a classification among hierarchy and simple constraints. For example, while it supports limited cardinality constraints, by using it user can write only cardinality values of 0 or 1. It is easy to develop such tool which can provide support for OWL Lite rather than its more expressive relatives, and OWL Lite provides a quick migration path for thesauri and other taxonomies. Owl Lite is also less complex formally than OWL DL [4].

  • Theoretical Background

    22

    OWL DL:Itsupports maximum expressiveness while retaining computational completeness i.e. all conclusions are guaranteed to be computable and decidability i.e. all computations will finish in finite time. Ithas all OWL language constructsbut these constructs can be used only under certain restrictions. For example, a class may be a subclass of many classes (multiple inheritances) but class cannot be an instance of another class. The name of OWL DL is due to its correspondence with description logics (a field of research that has studied the logics that form the formal foundation of OWL) [4].

    OWL Full:It is for users who want maximum expressiveness and the syntactic freedom of RDF with no computational guarantees i.e. all conclusions may or may not be computable. For example, in OWL Full a class can be treated simultaneously as a collection of individuals and as an individual in its own right. OWL Full allows an ontology to augment the meaning of the pre-defined (RDF or OWL) vocabulary. It is impossible that any reasoning software will be able to support complete reasoning for every feature of OWL Full [4].

    2.5 XSL

    Using XSL different XSLT patterns are developed and can be developed according to different models for identification of objects of enterprise model (consider the specific object type as class or instance while transforming enterprise model to enterprise ontology). For example, there is an enterprise model that has objects types organization and person. By using XSLT pattern, extra information (xml nodes attribute object type with value class or instance) can be inserted into XML document that specifies the type of object as class or instance.

    Extensible Stylesheet Language (XSL) is a generic language to manipulate and display data in an XML document. W3C started development of the Extensible Stylesheet Language [18].

    Extensible Stylesheet Language Transformation (XSLT) is a language for transforming XML documents into other XML documents [19].

    Extensible Stylesheet Language Transformations (XSLT) is designed to transform XML data into some other form, most commonly HTML, XHTML, or another XML format [20].

    A transformation expressed in XSLT is called a stylesheet. A stylesheet contains a set of template rules. A template rule has two parts:

    1. A pattern which is matched against nodes in the source tree

    2. A template which can be instantiated to form part of the result tree.

    This template allows a stylesheet to be applicable for a wide range of documents which have similar source tree structures [19].

  • XSLT is programming language but it is based on means that code is executed when a certain piece of data is encountered. Other programming languages like C,execution [18].

    Extensible Stylesheet Language Transformations (XSLT) language was developed by the W3 Consortium the closest you can get to a standard on the World Wide Web[18].

    XSL consists of XSL Formatting Objects (XSLFO) and XSL Transformations (better known as XSLT). The former, officially still called vocabulary that defines elements used to specify how an XML document is to be displayed. An XML vocabulary is a set of XML tags that have been defined for a certain purpose. XHTML is another example of an XML vocabulary [18].

    XSLT is a language used to manipulaan XML vocabulary. The actual manipulation of an XML document with XSLT is called transformation. Transformation is the process of creating a new document based on the original document. This process does not chansource document [18].

    Figure 2-13, [18] shows how XML document can be converted into different outputs (HTML, INDEX, Code Samples etc)

    Figure 2-13: XML transformation to multiple

    Theoretical Background

    ng language but it is based on data-driven executiont code is executed when a certain piece of data is encountered. Other

    programming languages like C,C++ and Java etc are based on event

    Extensible Stylesheet Language Transformations (XSLT) language was developed by the W3 Consortium (W3C) and now has Recommendation status, the closest you can get to a standard on the World Wide Web[18].

    XSL consists of XSL Formatting Objects (XSLFO) and XSL Transformations (better known as XSLT). The former, officially still called XSL is an XML

    ulary that defines elements used to specify how an XML document is to be displayed. An XML vocabulary is a set of XML tags that have been defined for a certain purpose. XHTML is another example of an XML vocabulary [18].

    XSLT is a language used to manipulate XML structures or documents. It is also an XML vocabulary. The actual manipulation of an XML document with XSLT is called transformation. Transformation is the process of creating a new document based on the original document. This process does not chan

    shows how XML document can be converted into different (HTML, INDEX, Code Samples etc)through XSLT pattern.

    : XML transformation to multiple outputs [18]

    driven execution, which t code is executed when a certain piece of data is encountered. Other

    event-driven

    Extensible Stylesheet Language Transformations (XSLT) language was (W3C) and now has Recommendation status,

    XSL consists of XSL Formatting Objects (XSLFO) and XSL Transformations is an XML

    ulary that defines elements used to specify how an XML document is to be displayed. An XML vocabulary is a set of XML tags that have been defined for a certain purpose. XHTML is another example of an XML vocabulary [18].

    te XML structures or documents. It is also an XML vocabulary. The actual manipulation of an XML document with XSLT is called transformation. Transformation is the process of creating a new document based on the original document. This process does not change the

    shows how XML document can be converted into different

  • Theoretical Background

    24

    2.5.1 Usage

    Because XML documents themselves dont contain any formatting information, one needs something else to format and display the data so that it looks pleasant. With XSLT, one has a language to manipulate an XML document. From that document, one can create another document that contains formatting information, such as Hypertext Markup Language (HTML), Portable Document Format (PDF), or Rich Text Format (RTF). In addition, one can use XSLT to restructure XML documents [18].

    The benefits/advantages of using XSLT are closely related to the benefits of using XML. Assume that data is either stored or communicated as XML (which is what XML is for), the benefits of XSLT are as follows [18].

    Retrieving data from data in an XML document.

    Formatting data from an XML document for display.

    Translating between an XML document used for communication and a format used within a system.

    Adding new information into data on the basis of existing information or data.

    2.5.2 Tools

    The transformation process of an XML document is performed by a processor, which is an application (or software component) that reads an XML document and an XSLT document and applies the XSLT to the XML. XSLT processor performs transformations using one or more XSLT stylesheets, which are also XML documents. Processors are available as command-line (run able applications) and as software components that can be used in an application such as Xalan11(developed by the Apache), MSXML12 (it is the XML parser/processor developed by Microsoft), Saxon 13(is a Java-based XSLT processor developed by Michael Kay, It comes with a SAX Parser but can work with other SAX parsers as well), Sun's JAXP, XT written by James Clark, LotusXSL14from IBM Alphaworks15etc [18][20].

    11http://xml.apache.org/xalan-j/ 12http://www.microsoft.com/downloads/en/details.aspx?FamilyID=3144b72b-b4f2-46da-b4b6-c5d7485f2b42 13http://saxon.sourceforge.net/ 14http://www.stylusstudio.com/xsllist/200004/post70810.html 15http://www.alphaworks.ibm.com/

  • Theoretical Background

    25

    2.6 Model transformation approaches

    A number [12] of model to model transformation approaches are available in literature. These transformation approaches are functional approach, logic programming approach, graph transformation approach and meta-model base transformation.

    2.6.1 Functional approach

    This approach is looking very appealing. In [12] approach, any transformation is regarded as function, this function transforms input (the source model) into output (the target model). The big disadvantage of this approach is that it becomes awkward to maintain state during transformation process.

    2.6.2 Logic programming approach

    A logic language[9] has a number of features which are very important for model transformation process. These features are backtracking, constraint propagation, bi-directionality of rules and unification. The logic languages also provide query mechanism, so there is no need of separate query language. The example of logic languages are Prolog or Mercury etc.

    2.6.3 Graph transformation approach

    Graph rewriting [9] is a powerful tool for graph transformation. Graph transformation contains transformation rules. Each transformation rule contains LHS (left hand side) graph and RHS (right hand side) graph. The rewriting rule works in this way: the LHS of a rule is matched against input graph; the matched portion of input graph is replaced with RHS of the rule.

    2.6.4 Meta-model base transformation approach

    This approach [11] describes mappings between different models which are created using different concepts from possibly overlapping domains. The process of transformation provides the facility to reuse the models developed by using a domain specific modeling language into another domain specific modeling language.

    As most of the languages which are used to develop enterprise models and enterprise ontologies, conform meta-model structure, so model to model transformation approaches based upon meta-models can be applied to transform enterprise model into enterprise ontology.

    There is need of a common basis to define the mapping between two conceptually different models. This common basis describes the source domain, the target domain and the vocabulary of transformation [11]. We have chosen meta-model as a common basis for transformation.

  • Theoretical Background

    26

    The meta-model based transformation approaches use only elements of the meta-models, so the transformation is described in terms of two meta-models [11].

    The meta-model based transformation approach is used to transform object model to relational paradigm [10], transformation of enterprise ontology into conceptual model [11], UML to Java transformation [31] etc.

    2.6.4.1 Meta-modeling & meta-models

    In order to understand the links between distinct languages, meta-modeling is an important issue. Meta-modeling allows defining the syntax of a language. The product of meta-modeling is usually called a meta-model.

    Meta-modeling determines the concepts, a concept can be anything about which something is said, and, therefore, could also be the description of a task,

    function, action, strategy, reasoning process, etc [7] and relationships in a particular model. For example, an UML meta-model describes the concepts such as classes, associations, generalizations etc. A Relational meta-model describes the concepts such as tables, columns and relations. A Petri Net meta-model describes the concepts such as places and transitions [10].

    2.6.4.2 Advantages of meta-modeling

    Here are few advantages of meta-modeling.

    If the same meta-model is used by different people to represent their data, then it can be shared and understood by others easily.

    As meta-models describe the content, structure and semantic of data that carries the information. On the basis of above, one can easily access and share the information.

    Formally defined meta-models are helpful to define rules to transform one semantic model into different semantic model [10].

  • Research Methods

    27

    3 Research Methods Research [34] in any field begins with curiosity. Yet method texts often read as

    primes on how to kill curiosity by subjecting it to formula.

    Perhaps one of the most important parts of a research is the research methods, which determines the success and credibility of any study. According to [36] research can be classified by its objective or purpose, application and process or enquiry mode. When a research examined through purpose perspective then it can be classified as explanatory or analytical, co-relational, descriptive and exploratory.

    Explanatory research [36] normally clarifies why and how a relationship exists between two variables of a phenomenon and thus often referred to as causal research. In co-relational research, the main emphasis is to establish or discover the existence of a relationship, association or interdependence between two aspects of a situation or a phenomenon. Descriptive research seeks to give a more detailed and systematic description of a phenomenon, situation, or problem as it exists to provide a clearer understanding of the situation. Normally, data collected in descriptive research are quantitative and subjected to statistical analysis. According to [37], this kind of research thus usually answers a why and what question. According to [35] the objective of exploratory research is to gather preliminary information that will help to define problems and suggest hypotheses.

    Exploratory research[14] [35][36] [38] is undertaken when the objective of the research is to explore a research area where little is known or just few earlier studies exist from which reference could be drawn. It could also be conducted to develop, refine, and/or test measurement tools and procedures. The main purpose of this kind of research is to identify trends, patterns, hypothesis, or theory instead of testing an existing hypothesis.

    According to [14], exploratory research assess phenomenon in a new light, to generate ideas and hypotheses for future research.

    We have not found any literature within the subject which provides any specific guidelines for transformation of enterprise modelto enterprise ontology. Although many have used meta-model based transformation approach to transform one model to other model and we have discussed about it in section 2.6.4.

    Our aim is to propose new approaches to transform enterprise model to enterprise ontology while keeping in mind that there should be minimum loss of information and maximum preservation of semantic during transformation process. This is the reason why we believe the exploratory study is appropriate in our case.

  • Research Methods

    28

    In first step/phase of our research, we had to build the research questions and get knowledge related to these research questions presented by other scholars and researchers in this research field. Accordingly, we reviewed the literature to get knowledge and discussed things with domain experts to build our concepts regarding research topic. This step resulted in an overview of existing literature and it is presented in chapter one as Theoretical background.

    In the second step of our research, we had to choose one of the model to model transformation approach from a number of approaches (discussed in detail in section 2.7) given by other scholars and researchers. After careful study of each approach, knowing about its implementation and discussion with domain expert16, we chose meta-model based transformation approach.

    At the third step/phase of our research, we proposed three approaches of elements mapping, from one model to other model(mapping of elements of enterprise model to enterprise ontology). This mapping is done on the basis meta-models. Each proposed approach consists of a number of rules. For our study purpose, we chose GEM meta-model (used to develop enterprise model) and OWL (ontology web language, used to develop ontology development). After comparative study of our proposed approaches and discussion with domain experts, we chose Approach 3 for implementation. Because this approach guarantees minimum loss of information, preserve maximum semantic during transformation process of enterprise model to enterprise ontology.

    At the fourth step/phase of our research, we developed a tool that takes enterprise model (XML file of Troux Architect tool, Troux Architect tool is used to develop enterprise model and uses GEM as a language [28]) as input and transforms this input into OWL file. For this purpose we chose flexible research design. If the focus is on processes then a flexible design is probably more desirable [14]. For development purpose, we used Java (because Java is object-oriented and platform independent and has other many features for selection reasons). Regarding Integrated Development Environment (IDE), we chose NetBeans 6.917, because it is open source and provides other many facilities for GUI development and facilitates a programmer through a number of ways. The tool is developed while using Microsoft Window XP18 as operating system. For testing and evaluation of ontology (we get owl files as a result of our transformation process, then these owl files are opened in Protg), we chose Protg 4.119because it is also open source and provide a number of plug-in for number of purposes.

    16 Kurt Sandkuhl (PhD), Professor Information technology, [email protected], Anders Carstensen (Master of Science), Lecturer computer technology, [email protected], Lin Feiyu (Master of Science), Ph.D. Student Information technology, [email protected] 17http://netbeans.org/ 18http://windows.microsoft.com/en-US/windows/products/windows-xp 19http://protege.stanford.edu/

  • Research Methods

    29

    At the fifth step/phase of our research, that was evaluation phase. In this phase we had to evaluate the ontologies which were result of transformation of enterprise models through our transformation tool named EM2EO. We tested/evaluated our tool upon three different enterprise models, these models were acquired from three different sources (two from two different domain experts20 and one was the sample model in Troux Architect tool). The ontologies which came into existence as a result of transformation process were tested and evaluated by domain experts21 regarding each and every perspective.

    The third, fourth and fifth steps/phases of our research were very iterative in nature. During these steps or phases, we did activities like brain storming, discussion, analyzing different possible outcomes, implementation, testing and evaluation.

    20Kurt Sandkuhl, Professor Information technology, Jnkping University, Sweden Anders Carstensen, Lecturer computer technology, Jnkping University, Sweden 21Vladimir Tarasov, Senior Lecturer Information technology, Jnkping University, Sweden Lin Feiyu, Ph.D. Student Information technology, Jnkping University, Sweden

  • Results

    30

    4 Results In this chapter, we describe about transformation approach that we selected to transform enterprise model to enterprise ontology, map the elements of enterprise model to enterprise ontology. This elements mapping gives the answer of our first research question. Later we describe the rules of our own proposed approaches. After description of rules of proposed approaches, there is comparison among these proposed approaches and this comparison gives us crystal clear picture that which proposed approach is most suitable to get aim of our research (there should be minimum loss of information and maximum preservation of semantics while process of transformation). At the end of this chapter, there is description about some of the problems which we faced during this research and how we got solutions of these problems.

    4.1 Meta model based model transformation

    As there are many model to model transformations approaches, available in literature and discussed in section 2.7, after careful study of each approach, knowing about its implementation and discussion with domain experts, we chose meta-model base transformation approach to transform enterprise model to enterprise ontology.

    4.1.1 Transformation of enterprise model to enterprise ontology

    After careful study and analyzing of each model transformation approach, we got the results that by adopting this approach there is minimum loss of information and semantic as compare to other model transformation approaches.

    As we have enterprise mod